“新客转化下降，帮我找原因并给建议。”Agent 先查了渠道，再查地区，第三步遇到超时，于是从头重跑；或者生成十几步计划，却在拿到第一张结果表后忘了最初要验证的假设。它看起来会“思考”，任务仍然没有完成。
规划层的职责不是输出一段漂亮的待办清单，而是把复杂目标变成一个能保存状态、检查证据、恢复失败并在必要时交给人的执行过程。
图中每一步都应该有输入、产物、通过条件和失败去向。缺少其中任何一个，所谓“自主循环”很容易变成无界重试。
先分流任务，再决定是否需要规划
并非所有问题都值得启动 Agent 循环：
- 已有指标、单次只读查询、风险低的问题，可以直接走受约束的查询模板。
- 需要多个数据源、多个假设或代码分析的任务，才进入计划—执行—验证循环。
- 涉及写入、外发、敏感数据或高成本计算的任务，应在规划前标出审批节点。
- 目标、口径或数据覆盖不清时，先澄清，不要用规划掩盖需求缺口。
复杂度分流既节省成本，也缩小故障面。让每个问题都进入多 Agent 编排，通常只会增加延迟和排错难度。
一份可执行计划需要七个字段
每个步骤至少包含：
| 字段 | 作用 |
|---|---|
step_id | 稳定引用，便于恢复和审计 |
objective | 这一步要减少哪项不确定性 |
inputs | 使用的数据、语义版本和前置产物 |
tool_contract | 允许调用的工具、参数和权限 |
output_contract | 预期结果的结构、版本和保存位置 |
verification | 通过条件、容差和独立检查 |
on_failure | 重试、改计划、降级、澄清或升级给人 |
“分析渠道影响”不是合格步骤，因为它没有说明使用什么数据、怎样判定完成。更好的目标是：“按渠道计算本月与基准期转化率，在相同口径和覆盖范围下标记绝对变化最大的三个渠道，并验证分母完整性。”
状态不能只存在对话里
长任务的事实状态应存放在 Harness，而不是靠模型记忆：任务目标、约束、当前计划版本、完成步骤、产物引用、失败次数、预算、审批和未解决问题。模型每轮只接收完成当前判断所需的切片。
一个实用状态机可以包含：PLANNING → READY → RUNNING → VERIFYING → COMPLETED，以及 WAITING_INPUT、WAITING_APPROVAL、REPLAN_REQUIRED、FAILED 和 CANCELLED。状态迁移由规则和工具结果触发，模型可以建议迁移，但不能随意把失败改成完成。
检查点应保存逻辑产物与版本，而不是完整复制所有敏感数据。恢复时先检查数据、语义、权限和批准是否仍有效；不能拿昨天的批准运行今天已经改变参数的动作。
规划、执行和验证要分工
常用模式是 Planner 提出下一步，Executor 通过受控工具运行，Verifier 检查结果与约束。它们可以是三个独立组件，也可以由同一模型在不同权限和上下文下完成。关键不在角色名称，而在控制面是否隔离：
- Planner 不能持有生产凭证。
- Executor 不自行扩张任务范围。
- Verifier 使用独立规则、查询结果或测试，不只让模型评价自己的输出。
- Harness 决定预算、重试和停止。
多 Agent 只有在专业上下文、工具权限或并行工作确实需要隔离时才有价值。把一个任务拆成许多拟人角色，却共享同一上下文、权限和评分器，只增加通信损耗。
重新规划必须有触发条件
合理触发包括：关键来源不可用、验证失败、发现新的必要依赖、预算接近上限、用户改变目标。重新规划时保留已验证产物，不从头重复所有步骤；同时记录旧计划为什么失效。
需要禁止的模式包括：同一参数无限重试、为绕过策略更换工具、失败后静默扩大数据范围、为了让结论成立而修改原始目标。计划的目的不是不惜代价完成，而是在约束内找到可验证路径。
贯穿案例：诊断转化下降
一个窄而完整的计划可能是：
- 固定“新客转化”的指标版本、周期、渠道覆盖和基准期。
- 验证数据水位与分母完整性；不完整则停止归因。
- 计算渠道分解，找出贡献最大的变化项。
- 对候选渠道检查地区、设备和活动结构变化，避免辛普森悖论。
- 把观察、假设和缺失证据分开，生成进一步核查项。
- 由独立查询复算关键数字，再形成报告草稿。
如果第二步发现数据缺失，正确状态是 WAITING_INPUT 或 PARTIAL，不是继续生成“可能原因”。如果第五步只有相关性证据，计划也不能把输出合同偷偷改成因果结论。
衡量任务完成，而不是计划长度
规划层可以用这些指标验收：
- 端到端任务成功率：最终产物满足输出合同且通过验证的任务比例。
- 有效步骤率：产生被后续使用的合格产物的步骤比例。
- 恢复成功率：工具或数据故障后，在预算内恢复且不重复副作用的比例。
- 升级质量：需要人介入时，是否给出缺口、已完成工作和明确选择。
- 预算遵守率：是否遵守步骤、时间、调用和扫描量上限。
- 状态一致性：报告、动作与任务状态是否相互匹配。
不要把 Token 数或思考轮数当作规划质量。更长的轨迹有时只是更昂贵的迷路。
从两类任务开始落地
先选一种确定性较高的多步任务和一种允许部分完成的开放分析。为它们明确状态、步骤契约、验证器、最大预算和人工升级点。运行影子流量，积累真实的失败路径，再决定是否并行化或引入专业 Agent。
好的编排不会让系统显得更会说话，而是让人知道任务走到了哪里、为什么停下、哪些结果已经可信，以及下一步由谁接手。