Agent 任务规划：从 ReAct 到 Plan-and-Execute

上一节，咱们实现了一个最小 ReAct Agent。

它会执行一个 Action，读取工具返回的 Observation，再根据这份结果决定下一个 Action。

任务结束以后，程序还会打印完整的 trajectory，就是这玩意

通过这份执行轨迹，咱们可以知道 Agent 已经调用过哪些工具。

但是，我现在问大家一个问题：

只看这份 trajectory，你知道 Agent 还有多少事情 没做吗？

不知道。

因为 trajectory 记录的是已经发生的事情。

对于上一节只有四次工具调用的案例，这个问题还不明显。

如果 Agent 需要连续运行几十分钟，中间涉及多个数据源和前后依赖，问题就会出来了。

如果我们想要在前端展示：当前执行到第几步了，任务中断以后还想继续执行 ，那么就不行了。

所以，这一节咱们就要解决这个问题，来做一个 可以被应用程序读取、检查和修改的： 任务计划，即：Plan

思考一个问题：任务计划会变吗？

咱们先思考一个问题，那就是：Agent 最先定义好的步骤，是不是可以一直按原样执行下去？

还是上一节的故障任务：

payment-service 从 15:10 开始出现大量支付失败。

告警中出现过 DB_POOL_ACQUIRE_TIMEOUT。

请找出最可能的故障原因。

DB_POOL_ACQUIRE_TIMEOUT 表示某次请求等待数据库连接时发生了超时。

所以，Agent 一开始会怀疑数据库连接池有问题，并安排两个步骤：

1. 先查询监控指标
2. 如果监控也指向数据库，再检查数据库连接池

这就是第一版 任务计划（Plan）。

但是要注意，这里的第二步不是马上执行的。

Agent 要先执行第一步，看看真实监控是否支持“数据库连接池异常”这个判断。

假设，现在监控工具返回：

• 支付接口 5xx 错误率：31.8%
• 数据库连接池使用率：46%

那就说明，支付接口确实出故障了。

但是，数据库连接池只使用了 46%，并没有耗尽。

这意味着最开始的数据库判断不成立，原计划里的第二步也就没有继续执行的必要了。

所以，计划需要改成：

查询监控指标 → 已完成

检查数据库连接池 → 取消

查询错误日志 → 接下来执行

这里就是第一次 计划变化。

没有意义的数据库检查被取消，然后增加一个更符合当前情况的新步骤：查询错误日志。

日志工具继续返回：

主要错误：PAYMENT_CURRENCY_UNDEFINED
错误版本：v2.4.1

现在，Agent 知道支付失败和 v2.4.1 中的 currency 字段错误有关。

但是，只看日志还不能确定这个错误是不是新版本发布引起的。

所以，任务计划再增加一步：

查询监控指标 → 已完成 检查数据库连接池 → 已取消 查询错误日志 → 已完成 查询最近发布记录 → 接下来执行

发布记录最终是：

v2.4.1 在故障出现前 24 秒完成发布

本次发布修改了币种归一化逻辑

到这里，Agent 才有足够的信息生成故障结论。

那么，回顾整个过程，其实咱们可以发现：任务计划是一直在变的。

这就是这一节最先要理解的事情：

任务计划不是提前写死的执行流程。Agent 每得到一份新的工具结果，都可能需要取消原来的步骤，或者增加新的步骤。

把刚才的过程换成 Agent 术语

看完上面的过程之后，再看专业概念就容易多了。

这里涉及到的东西还挺多的，我总结了一下