循环能运行以后，下一个问题很实际。每轮都让模型自由决定，会不会一直绕圈？先列一份计划，又能不能应付做到一半才发现的新问题？

ReAct 和 Plan-and-Execute 给出了两种组织办法。前者随着工具反馈决定行动，后者显式保存计划，再根据执行结果调整。它们都需要真实观察，也都需要停止条件。

先观察，再决定下一步

原教程用修复程序一类任务解释 ReAct。开始时只知道页面有问题，具体原因还没有定位。先读报错，找到组件，再检查初始化过程。每次行动所需的信息，来自上一次结果。

把这个方式用到知识库助手，过程也一样。用户问登录以后为什么会跳回首页，助手先检索登录文档。如果文档只说明正常流程，就需要继续查看回调配置；回调中出现新的路径，再检查路由规则。

这里的示例是任务设计。能否作出最后判断，要看程序实际找到了哪些证据。只要工具结果没有支持结论，助手就应该继续查或说明缺口。

ReAct 记录里最有用的内容，是行动名称、参数、执行结果和下一步状态。调试循环时，不必强制模型公开完整内部推理。简短的行动说明足够帮助用户理解进度，正确与否仍要用文件、日志和检查结果验证。

自由行动的困难是局部判断容易重复。工具连续几次返回相同内容，程序就该识别重复状态；缺少权限或凭证时，再试一次通常也不会多得到信息。把“是否可以重试”作为工具结果的一部分，会比让模型从一句报错里猜更清楚。

长任务需要保存全局位置

Plan-and-Execute 会先把任务分成步骤。原教程区分 Planner、Executor 和 Replanner，分别负责制定计划、执行当前步骤和调整剩余安排。

以项目知识库助手为例，可以先确认资料目录，再读取内容，接着组织答案，最后核对引用。执行到读取资料时，如果发现一个关键文件缺失，后面的计划就需要改变。

已经读到的内容应当留下。重规划时只调整尚未完成的部分，避免把前面的工作再做一次。

// 自定义任务状态，用于说明需要保存什么
type TaskState = {
  goal: string;
  completed: Array<{ step: string; evidence: string[] }>;
  remaining: string[];
  status: "running" | "completed" | "failed" | "limit_reached";
};

执行器收到当前步骤时，还需要原始目标、必要的已完成结果和限制条件。只给它“整理引用”，它不知道哪些资料来自本次检索，也不知道最终文章要求引用到什么程度。

计划中的步骤也要能判断完成。把“研究一下”改成“找到开发指南，记录来源与更新时间”，执行器才能交回可核对的东西。

计划什么时候值得调整

发现新的依赖、原先假设失效或某一步已经无法继续时，需要重规划。一次普通工具调用成功以后，可以直接进入下一步。每做一个小动作都再调用模型审查整份计划，会增加延迟和费用。

两种方法可以组合。外面保存一份阶段计划，里面用 ReAct 查清某个未知问题。例如“核对启动方式”是计划中的一步，执行时可能要先读文档，再查包配置，最后比较两者是否一致。

这也解释了为什么不能只凭模式名称判断成本。计划要生成，工具要执行，必要时还要重规划。总费用与模型选择、上下文大小及调用次数有关。拆成更多角色以后，信息传递本身也需要工作。

反思要有一个检查对象

让模型再检查一遍，有时能够发现遗漏。它也可能重复原来的错误。检查最好有外部标准。

知识问答可以核对引用 ID 是否来自本次检索，以及结论有没有被对应片段支持。代码任务可以运行针对改动的检查。固定输出则可以先验证 schema。

这些检查各自覆盖一部分问题。字段齐全只能证明结构符合要求，不能证明内容正确；引用存在，也不能证明引用支持那句话。把结构检查与内容判断分别记录，故障才容易定位。

可以给自己设计一次练习。把知识库中的关键文件暂时移走，观察助手会不会调整计划；再给它一个不存在于资料中的问题，观察它能否停止并说明缺少依据。计划最后应保留已经完成的步骤，同时明确指出剩余部分为什么无法完成。

延伸阅读

本篇依据冴羽《AI Agent 开发实战》学习整理稿中的执行模式与工程补充重写。原教程见 Agent 常见设计模式、ReAct 原理、计划与执行原理 和 计划执行的 JavaScript 实现。

上一篇 · 系列目录 · 下一篇