08 · 规划与多 Agent：把依赖、证据和责任写清楚¶

用户让内部政策助手比较海岚与云洲的差旅规则，列出例外审批材料，再准备申请草稿。两路检索看起来可以同时开始，可出差日期还没确认；即使各自查完，也可能拿回不同版本的制度。增加角色以前，先得弄清每一步需要等谁、交回什么。

本章学习几种规划方式，画出能并发的依赖图，并为多 Agent 的合并、失败和预算设计规则。任务验收先写清：两地有效规则均有出处，材料清单完整，草稿没有提交。建议先读工具循环、工具合同和状态与记忆，再来安排多步任务。

几种模式，改变的是怎样组织工作¶

ReAct 将推理与动作交错：根据已有观察决定下一步，执行工具，再利用新观察继续。原始研究强调这类交错能连接推理与环境反馈，结果仍需通过工具观察与外部证据核对。ReAct 原始论文在工程中可记录决策摘要、工具调用和结果，不必把不可见的内部推理当作审计证据。

Plan-and-execute 先生成显式任务计划，再逐项或按依赖执行；有新证据时可以重规划。对两地政策任务，计划可以先写“确认条件、分别检索、比较、起草”，执行时再填入真实证据。若计划预先认定某地允许报销，后续步骤就可能沿着未经查证的前提跑偏，因此计划也需要接受检查。Plan-and-Execute Agents

Reflection 利用反馈审查并修改下一次尝试，例如逐项检查引用是否支持金额，或在执行失败后留下经验笔记。Reflexion 原始方法通过语言反馈和情节记忆影响后续尝试，明确不以更新模型权重为机制。Reflexion 原始论文

记忆时可以想成给下一次尝试附一张复盘便签：“先核对生效日期”。便签对应新增的上下文或外部记录，没有把模型参数重新训练一遍。便签本身也可能总结错，因此自评之后仍需对照外部证据检查，不能因多改了几稿就默认质量提高。

把任务画成依赖，而不是一串角色名¶

先由 router 判断请求是政策问答、比较，还是需要草稿。这是有限类别的路由任务，可以用规则、分类器或模型实现；选错路线要能澄清和回退。对本例，确定出差日期和员工类别后，海岚与云洲的政策检索可独立进行；最终比较依赖两路结果，草稿又依赖比较结果与用户补齐字段。

教学依赖图：
确认条件 ─┬→ 检索海岚政策 ─┐
          └→ 检索云洲政策 ─┴→ 核对版本并比较 → 形成草稿 → 用户审阅
                                               （不自动提交）

如果两个检索都要等前面的条件，却在条件未知时并发猜测，会更快地产生两份不适用资料。反之，已知条件下独立读取可并发；为了写“多 Agent”而把这两次 API 调用强行包装成两个角色，未必带来收益。并发是调度属性，不是多 Agent 的专属能力。

逐步跑一次，并故意制造失败¶

第一步，协调者记录任务范围、共同输入和共享预算：本例假设最多 8 次检索、总期限 30 秒、只生成草稿。第二步，两路工作单元接收相同日期、员工类别与权限上下文，各自返回政策 ID、版本、适用条件、关键条款和证据，不返回一句无法核对的“都可以报”。

第三步，假设海岚结果成功，云洲工具限流。协调者只按允许策略重试失败分支；没有云洲证据就不能凭海岚制度补齐。截止时间到时，可以交付海岚的已核验部分并说明缺口，或者转人工；若任务要求完整比较，终态应是未完成，而不是把部分结果伪装成成功。

第四步，两路成功后统一比较。一个分支读到旧制度、另一个读到新制度时，先消除版本口径冲突；两个 Agent 给出相同结论也不自动构成独立证据，因为它们可能引用同一份错误资料。第五步，草稿填入已核验条件，让用户审阅。若后续要求真正提交，进入独立授权、具体动作审批与结果核对，不让下游 Worker 因为“接到任务”就自行获得更广权限。

多 Agent 增加了哪些责任¶

例如子任务需要不同工具权限、专业上下文、独立审查或可并行的大块探索时，多 Agent 的收益可能抵消协调成本；固定短流程通常先用单一执行器验证。其他场景也应按任务内实验判断。使用多个模型可能增加延迟、token 成本与错误传播，要在同一任务集上比较，不能根据角色数量判断能力。

共享状态要规定谁能写什么。两路都往 evidence 追加时，可按稳定证据 ID 合并去重；两路同时写 final_answer 时，简单采用最后到达的文本可能丢掉另一份结论。

Reducer 规定每个字段怎样合并更新，LangGraph 的状态字段可以配置这类规则。LangGraph Graph API：Reducers 例如把两份证据列表拼接起来，只完成了数据合并；金额冲突是否源于不同日期，还需要应用继续判断。不要让一个列表拼接函数临时兼职政策专家。

本例让 Worker 只返回各自证据，协调者独占最终结论；冲突保留来源并触发核验。追加也要考虑重试重复，不能把同一结果记两次。若外部动作有副作用，状态合并不替代幂等与对账。预算也要由公共账本扣减，子任务与重试都计入，避免每个 Worker 各自认为“还能再用 8 次”。

人审点应放在需要用户判断或产生重要副作用的位置。审阅者看到当前计划、具体草稿、证据及影响，而不是空泛的“同意继续吗”。子任务失败、取消、超时、需补信息都要回报协调者；不能让上游等一个永远不会出现的“成功”字符串。

练习：先证明并发值得，再增加角色¶

把两地政策检索分别设为 0.8 秒和 1.2 秒，比较两路都成功时串行与并发的必要等待时间；随后让第二路失败，设计剩余预算与最终状态。再让两路各返回同一个证据 ID、互相矛盾的两个金额，写出合并和核验规则。

验收： 理想读调用阶段串行为 2 秒、并发为 1.2 秒（忽略开销）；比较必须等待必要证据；失败不会被摘要藏掉；重复证据去重，矛盾不会用“多数票”直接抹掉；Worker 无法越过用户审阅自行提交。

自检与参考答案¶

有三步计划就是三个 Agent 吗？ 不是。一个执行器也能执行计划；是否独立 Agent 要看控制、上下文和职责设计。
Reflection 后答案变好，证明权重更新了吗？ 没有。新增反馈进入上下文就可能改变输出；参数更新需要独立训练机制和证据。
两条分支都成功，为什么仍可能无法合并？ 日期、版本、实体或权限口径可能不一致；执行成功不代表语义一致。

进一步练习见规划与编排题。

配套面试练习¶

先合上正文讲一分钟，再用追问和案例检查理解。每题都可以跳回对应学习内容。

展开本章相关面试题