一、为什么需要规划？

工具使用解决的是“能不能做”。规划解决的是“先做什么、后做什么、失败后怎么办”。

只会调用工具的 Agent，像一个执行员。你让它查日志，它就查日志。你让它查数据库，它就查数据库。但复杂任务不是一个动作能解决的。

真正的复杂任务，往往有目标、有约束、有依赖、有风险。Agent 需要先把目标拆成路线，再一步步执行。

二、Planning 到底是什么？

Planning，就是让 Agent 根据一个高层目标，自动拆出一组可执行步骤。

它不是提前写死的流程。它也不是简单提示链。它更像一个项目经理：先看目标，再看资源，再排计划，执行中还要根据结果调整方向。

目标：用户到底想完成什么。

约束：哪些事情不能做，哪些风险必须控制。

状态：任务现在推进到哪一步。

工具：Agent 能调用哪些系统能力。

计划：把目标拆成有顺序、有依赖、有检查标准的步骤。

三、核心流程：先计划，再执行，再观察

一个实用的 Planning Agent，通常不是一次性“想完就结束”。它会经历四个动作。

1. Planner 生成计划：把用户目标拆成多个步骤。

2. Executor 执行步骤：根据步骤调用工具或子流程。

3. Observer 观察结果：判断当前结果是否满足步骤目标。

4. Replanner 重新规划：遇到失败、证据冲突或目标变化时调整路线。

这里的关键不是“模型很聪明”，而是系统把任务运行过程显式保存下来了。目标、计划、当前步骤、工具结果、错误原因，都必须进入状态。

四、三种规划方式

不是所有任务都要上动态规划。工程上要看任务复杂度。

流程明确，就用固定流程。路径不确定，但目标清楚，就用 Plan-then-Execute。任务很长、外部环境会变化，就需要动态重规划。

五、案例：线上订单接口故障排查 Agent

用户目标：订单支付成功，但查不到订单，帮我排查原因。

如果没有规划，Agent 可能随机查日志、随机查数据库，很快迷路。

有规划后，它会先明确排查路线。

1. 确认订单号、用户 ID、支付时间。

2. 检查支付回调是否成功。

3. 查询订单服务日志和错误码。

4. 查看链路追踪，定位失败节点。

5. 对比数据库和缓存状态。

6. 输出证据链、影响范围、建议动作。

如果中间发现支付回调失败，就不需要继续乱查数据库。计划会收缩到支付链路。如果发现缓存未同步，就进入缓存修复路径。

六、源码级逻辑：核心是状态机

Planning 在源码里，不能只是一段 prompt。

更可靠的做法，是把它实现成一个状态机：计划是数据，步骤是节点，执行结果是状态，重规划是条件分支。

一个 step 至少应该包含：step_id、action、tool、args、depends_on、success_criteria。

这样才能做到可追踪、可恢复、可重试。否则 Agent 失败时，你连它卡在哪一步都不知道。

七、什么时候不要用 Planning？

Planning 很强，但不是万能。用错了会变慢、变贵、变不可控。

任务只有一步，不需要规划。

流程已经完全固定，用普通工作流更稳定。

业务风险很高，不能让模型自由决定路线。

工具权限太大，但没有审批和审计。

没有状态存储，任务中断后无法恢复。

一句话：路径明确，用流程；路径不确定，用规划。

八、上线前必须检查什么？

Planning Agent 一旦上线，就不能只看结果是否能跑通。更要看边界、权限、成本和可追踪性。

九、总结

Planning 是 Agent 从“工具调用器”升级为“任务执行者”的关键一步。

它把一个模糊目标，拆成可执行步骤。

它让 Agent 知道先做什么，后做什么。

它让失败不再是终点，而是重新规划的起点。

真正能落地的 Planning，不是让模型自由发挥，而是用状态、工具、约束、日志和审批，把模型能力装进工程边界里。