规划、状态与多 Agent 编排¶

两地政策分别检索，一路成功，一路限流，协调者仍交出了一份完整比较报告。这个错误可能发生在计划、等待条件或合并规则上；多加一个“审查专家”以前，先把每条箭头的输入和终态画出来。

本篇沿着循环、依赖、恢复和交接阅读。口述时给出下一步由谁决定、何时停止，再故意插入一个失败，看看流程还能否说明当前完成了什么。

先限时口述短答，再打开详细答案回答三个追问，最后画出案例的失败分支并完成微练习。

Q009 最小 Agent Loop 应包含哪些环节？¶

优先级：P0

30–60 秒回答：

最小闭环是读取目标与状态、请求下一动作、检查动作、执行工具、记录观察，再判断继续或结束。模型只提出动作，程序负责工具白名单、参数验证、权限和预算。每轮都要有可追踪的状态变化；最终答案、等待输入、预算耗尽与不可恢复失败应该是不同终态，便于用户知道是否完成。

展开详细答案、追问与案例

详细答案：

先把目标转成可检查的终态，再定义循环读取的状态：用户已给条件、有效证据、待解决问题、操作关联与剩余预算。一次迭代先观察这些信息，请策略提出下一动作；动作可以是调用工具、澄清、等待或结束。策略可能由模型实现，也可以用脚本替身检查控制流，两者能够证明的能力范围不同。

执行前由运行时验证工具集合、参数、可信身份和业务条件，需要的批准也在这里检查。通过后才进入真实工具路径，返回观察并更新状态。决定、尝试和结果应分别记录：决定调用一次，不代表仅有一次底层尝试；模型同时要求多个工具时，还要按调用标识关联结果，检查依赖，不能按返回先后随便拼接。

循环每次都要判断是否继续。证据充分且满足任务合同才完成；缺输入进入等待，权限拒绝或无法恢复的错误结束，预算不足则报告完成项与缺口。工具结果不是天然可信指令，模型建议结束也需要验收。将事件与状态串起来，可以像查派工单一样区分拟办、已受理和已办结，但外部系统状态还需独立核对。只写无限循环会把终止、失败与副作用都藏在循环体里，出了故障就很难解释到底停在哪一步。

常见追问：

一轮可以有多个工具调用吗？ 可以，模型响应可能包含多个调用。执行器要保留各自标识、结果和错误，检查是否有依赖与副作用冲突；不能因为它们同时出现就默认能够并发，也不能把一份结果配给另一动作。
模型输出最终答案，运行时就直接完成吗？ 先核对任务合同。只读问答要检查必要证据，写任务还要检查后端对象与内容；缺少材料时可以结束并报告未完成，但不能把一个结束字符串当成功证据。
脚本循环测试通过说明什么？ 说明覆盖到的参数、分支和停止合同按预期运行。脚本预设选择与答案，不能证明真实模型能正确理解问题；接入模型后仍需任务集评测工具选择、参数和最终结果。

实战案例：

以仓库 happy 场景为教学对象：脚本先提出搜索，再给出结束决定。初看 steps=2 容易误读成执行了两次搜索，实际 search_attempts=1。处理时按 decision、observation、stop 逐项对应，确认第二步是结束。验收复核事件、读尝试与对象数，再插入无批准的写建议：执行器应拒绝、实际创建数为零。测试检查控制合同，不把固定脚本输出当作真实模型正确处理政策的证据。

常见误区：

while True 加工具执行就完成系统设计；忽略无进展循环和工具副作用。把工具重试次数、策略步数和模型输出 token 数混成同一个预算，也会让停止条件失去含义。

微练习：

手写六个状态及合法转移。验收：从每个非终态出发，都能解释如何到达完成、等待或失败状态。再给每条转移标出输入事件与状态字段，选一个外部写结果未知的情形，说明为什么不能直接进入成功。

学习与参考： 可追踪的工具循环

Q010 ReAct 与先规划后执行有何不同？¶

优先级：P1

30–60 秒回答：

ReAct 将推理与环境动作交替组织，根据新观察调整下一步。先规划后执行先列任务分解，再执行和更新计划，适合依赖较清楚的任务。比如比较两地政策，可以先列检索、核对、比较的计划，在每次检索后用局部循环判断证据是否足够。两种组织方式可以组合；计划前提失效时要重规划，不能拿旧清单一直往下勾。ReAct 原论文

展开详细答案、追问与案例

详细答案：

先看工作如何组织。ReAct 把推理与环境动作交错：当前观察支持什么、还缺什么，下一步就针对缺口行动，再根据结果调整。先规划后执行先显式分解目标和依赖，再逐步执行；两者都需要工具观察，区别不在于是否写过一句“先想一想”。一次计划也无法预先知道所有真实返回值。

比较两地政策时，可以先列确认日期、分别检索、核对条件和综合的计划。局部检索又可以采用动态循环：缺例外条款就补查，发现旧版就换有效来源。这个组合把全局依赖和局部探索分开。计划像施工顺序表，能告诉你先铺哪段路，却不能把尚未查到的证据提前填成事实；输入条件改变时，要标记受影响工作并更新计划版本。

取舍看任务是否容易预先分解，以及反馈变化多大。显式计划利于跟踪覆盖与交接，也可能造成机械执行；逐步选择灵活，却容易局部反复探索。两者都需要全局预算、无进展检查和可验收终态。记录决策摘要、计划变更、调用与来源，就能解释为何换路；不需要索取模型隐藏的思维链，也不能把生成的自述当成实际执行记录。评测应比较证据覆盖、无效调用、失效计划继续执行和最终交付。

常见追问：

面试时需要展示完整思维链吗？ 不需要。提供计划摘要、动作选择依据、实际工具观察与状态变更，便于核对行为；隐藏内部推理不应作为可观测性前提，也不能用自述替代外部结果。
计划发现错误后要全部推倒吗？ 先检查依赖与版本，保留条件仍成立的结果，失效项重新打开。整体重做可能浪费预算，盲目保留又可能传播旧前提，应该用来源与输入关联判断影响范围。
什么时候先规划更有价值？ 目标包含明确子任务和覆盖要求时，计划便于检查遗漏。若信息逐步揭示，可用粗计划约束局部循环；是否值得仍用固定任务比较质量、重做与额外调用。

实战案例：

任务是查资料后比较两个部署方案。预写计划把某来源标成权威，执行时该来源已失效，初版仍照清单生成结论。改为每次取得材料后检查有效性，失效则更新证据节点与受影响比较项；局部循环寻找允许的替代来源。验收分别记录两种组织方式的轨迹，检查旧来源不进入最终引用、预算内能更新下一步；无法补齐时返回缺口，不能靠多轮改写把未确认说成已确认。

常见误区：

把工具调用次数多当作推理能力强；把任何“先想一想”的提示都叫 ReAct 实现。计划越长并不天然越完整；没有输入、依赖和验收条件的步骤，很容易只是漂亮清单。

微练习：

为“查资料后比较两个部署方案”分别写两条执行轨迹。验收：加入来源失效后，两种流程都能更新下一步。再修改一个用户条件，标出可以复用与必须重做的步骤，并为两条轨迹设置共同调用上限。

学习与参考： 规划与多 Agent

Q011 为什么用状态图组织 Agent？¶

优先级：P0

30–60 秒回答：

状态图把任务信息、执行节点和转移条件显式化。节点读取当前状态并产生更新，边决定下一步；这样能独立检查哪条路径会重试、请求人工输入或终止。图不会自动保证正确，它只是让控制逻辑更可见；业务不变量、状态字段约束和节点测试仍需自己定义。LangGraph Graph API

展开详细答案、追问与案例

详细答案：

状态图让任务数据、执行节点与转移条件显式存在。状态可保存目标、已确认条件、证据指针、错误、待审批动作与预算；节点读取所需字段并产生更新，边依据结果选择下一处。图形本身只展示控制结构，正确性来自字段含义、转移前提与业务不变量，而不是线条看上去很完整。

先为每个节点约定输入、输出和失败。检索节点返回候选与版本，校验节点检查可见性和支持关系，回答节点处理证据充分或需澄清。缺权限和无证据应走不同路径，不能都用一个空列表解释。授权、计费和关键业务更新可以使用确定性代码，只有确实需要判断的部分才调用模型；每个方框都放模型会增加不可控变化。

状态也不是当前上下文的同义词。程序保存的内部审批字段未必全部提供给模型，长期偏好有独立生命周期，大原文可以放外部存储，图内只保留位置、版本和必要摘要。像案卷目录能指到原件，目录本身不能替代原件的访问权限和内容。并发更新还需要字段合并与冲突规则，恢复需要检查点及版本兼容；这些机制各自解决问题，不能因采用了图就省略节点测试、权限重验或外部幂等。

常见追问：

状态中为什么不直接塞所有文件？ 大文件复制和传递会增加存储、输入和维护成本。保存稳定位置、内容版本、必要摘要与来源，按需取回；读取时仍检查权限，指针失效也要有明确分支。
状态图与记忆有什么关系？ 图状态服务当前任务执行，跨任务记忆有自己的主体、保存与读取规则。二者可能通过存储连接，但状态存在不代表模型本次可见，也不代表写入了模型参数。
框架提供合并规则，冲突就解决了吗？ 合并规则只规定数据更新方式。两份证据金额不同，仍需对齐实体、时间和适用条件；列表追加或最后写入覆盖不能自动决定哪份事实正确。

实战案例：

教学图从接收进入检索、校验、回答。初版把无权限、旧版与真实空结果都送进“再检索”，导致不断重试。改为让工具返回明确状态，分别转到拒绝、重查版本或缺证据；原文外置，状态保留文档和版本指针。验收对三种输入逐条走图，检查每条分支的终态和字段；大文件不会被无条件重复送入模型，合法引用仍可按权限回查，错误分支不会生成成功文字。

常见误区：

把所有节点都写成模型调用；支付、鉴权、计费等通常需要确定性代码。图上有一条成功边，不证明它的前置条件已经被检查；状态保存也不能替代真实环境结果。

微练习：

画 接收→检索→校验→回答，加入无权限、无证据和来源过期分支。验收：每条分支都有可观察结果。为每个节点列两个字段约束，再模拟原文指针失效，说明应更新哪些状态以及怎样继续或结束。

学习与参考： 记忆与状态

Q012 如何防止循环、反复重规划与无效重试？¶

优先级：P0

30–60 秒回答：

我同时设置步数、总耗时和资源预算，并检测进展，例如是否出现新证据、状态是否改变、是否连续重复同一参数调用。暂时错误可以有限重试，权限失败或非法参数应换处理路径。耗尽预算时返回当前完成项、未完成项和停止原因。单个“最大轮数”只能保底，无法识别很早就卡住的任务。

展开详细答案、追问与案例

详细答案：

先声明哪些状态结束任务：已完成、等待补充、无法继续、预算耗尽或取消。再设置不同维度的上限，步数限制策略决定次数，工具尝试限制重试，总期限限制经过的时间，token 与费用约束资源。一个工具阻塞很久，即使策略还在第一步，也可能已经超出用户愿意等待的时间，所以最大轮数不能包办所有限制。

进展判断要依据任务状态。是否出现新的有效证据、未知条件是否减少、上次失败原因是否改变，都比只比较文本是否换了措辞更有用。权限拒绝后改写查询通常不会授予权限，非法日期要修请求。暂时读错误按合同有限重试，写结果未知先查询或对账；不要让模型把所有异常都翻译成“再试一次”。

重复调用有时是合理轮询，例如等待一个已知异步任务完成。它需要明确对象、轮询间隔、状态变化和截止条件，不能和无目标反复检索混为一谈。共享预算也要覆盖子任务与重试，重规划不能刷新整套额度。停止时保留完成项、未决项、操作标识和原因，让用户能补资料、等待或转人工；失败结束可以准确交付状态，不能为了满足“必须回答”把最后一次错误包装成结果。

常见追问：

同样参数调用两次就要终止吗？ 不能只凭重复判断。先看是否符合允许的轮询或重试合同，是否等待外部状态变化；没有新证据、没有可改变条件的路径时再按规则停止，避免误杀合理查询。
步数没超，为什么还会失控？ 单步可能包含多次尝试、长时间等待或多个分支。总期限、尝试和全局资源预算需独立落实；前端停止显示也不能自动取消远端动作。
预算耗尽时应该返回什么？ 返回已确认部分、未完成节点、停止原因与可继续条件，并保留结果未知的操作以便对账。若完整比较是硬要求，终态应是未完成，不能把局部内容当完整成功。

实战案例：

在固定脚本中，策略不断搜索同一词，运行时只设每次回复长度，任务始终不结束。改为加入步数上限、尝试预算和无进展记录；真实服务还要有总期限。验收参考仓库 loop 场景，三次检索后停止，不再索取第四个决定；再用有间隔的异步状态查询作对照，允许合同内轮询。输出必须说明两种路径为何不同，脚本的步数测试也不能被宣称为已实现真实总超时。

常见误区：

所有异常都交给模型自行修复，导致输入错误被不断重试。无限刷新预算、让子任务自行继续派生，也会绕开主任务看似严格的上限。

微练习：

模拟工具连续返回同一错误。验收：给出第几次结束、结束码、保留的证据及用户可采取的下一步。再写一条允许重复的轮询规则，比较其间隔、期限和进展信号，避免所有重复都被误判。

学习与参考： 工具循环与停止

Q013 多个分支何时可以并发？¶

优先级：P1

30–60 秒回答：

没有数据依赖且不会争用同一副作用资源的任务，可以考虑并发，例如分别读取两份公开资料；比较结论则要等所需资料回来。先画“谁等谁”，再决定同时启动哪些分支。还要规定合并、部分失败与超时处理，共享字段需要去重、冲突规则或串行化；调用同时发出去，只完成了调度，最终状态仍需检查。状态归并参考

展开详细答案、追问与案例

详细答案：

先把任务画成数据依赖。查询两地公开政策，如果日期与人员类别已经明确，两路可以独立读取；比较结论需要两路证据，不能提前把缺失一地当成零或默认规则。若第二个查询要用第一个返回的项目 ID，就存在真实依赖，再快的并发工具也不能补出尚未确定的输入。

接着检查共享资源和副作用。两个读取也可能看到不同版本，需要记录快照、来源时间或明确允许的差异；两个写入若影响同一订单，更要按业务约束协调。退款与发货分别通过检查，不说明组合状态合法。执行前的检查与真正更新之间还可能变化，需要资源侧的事务或条件更新，而不能只靠调度器先问两次“可以吗”。

合并需要字段所有权、稳定结果标识和部分失败策略。分支可返回证据与缺口，协调者按版本去重，再验收最终结论；追加列表只收材料，不替你判断相互矛盾的条款。并发同时占用连接、配额和峰值预算，应有在途上限、统一预留与共同截止时间。理想情况下独立分支缩短关键路径，但排队、限流与重试可能抵消收益。评估应保持任务与质量合同一致，分别看关键路径、资源峰值和失败恢复，不能以启动了多少任务判断优化。

常见追问：

并发越多，为什么可能反而更慢？ 速率限制、连接与共享服务容量会造成排队和重试。限制在途数量，优先派发必要证据；记录等待和执行时间，再按真实负载选择并发度，不能只看孤立调用耗时。
分支结果都成功，能直接拼起来吗？ 先核对日期、对象、版本和权限口径，再按稳定标识去重。两份成功响应可能内容冲突，最终比较仍要验收；旧计划的迟到结果也不能覆盖新版结论。
一支失败时一定要取消全部吗？ 看任务合同和副作用。如果允许局部报告，可保留成功证据并声明缺口；完整比较是硬要求时就不能交完整成功。已发出的写操作还要确认终态，取消等待不等于撤销。

实战案例：

两路政策读取分别需 0.8 秒和 1.2 秒，输入已确定，忽略开销时串行为 2 秒，并发读阶段为 1.2 秒。若第二路失败，初版用第一地制度补齐。处理时记录各分支状态与共同预算，只有必要证据齐全才比较；允许部分交付时明确缺哪一地。验收既复算理想等待，也注入重复证据、旧版本与限流，检查去重、版本核对和并发上限，不把下界写成线上 p95。

常见误区：

对同一订单并行执行“退款”和“发货”；两次独立检查通过也不代表组合动作合法。并发是调度方式，单个执行器也能组织；增加 Agent 数量不能消除数据依赖或业务冲突。

微练习：

两个分支分别返回 [A,B] 与 [B,C]。验收：写出有稳定顺序的去重结果，并说明一支失败时是否允许回答。给结果标上计划与来源版本，加入一条迟到的旧结果，说明它为何不能覆盖当前比较。

学习与参考： 依赖与多 Agent 编排

Q014 Checkpoint 能保证恢复后不重复扣款吗？¶

优先级：P0

30–60 秒回答：

Checkpoint 保存应用执行状态，便于恢复和人工介入。若支付已成功、本地还没记下就崩溃，恢复时仍可能再次支付：进度本记录了上次翻到哪页，却不能代替银行账本。这个类比强调两边没有天然共享事务；支付接口还需支持幂等键，应用保存请求与外部操作标识，状态未知时先查询核对，再决定补偿或重试。持久化参考

展开详细答案、追问与案例

详细答案：

先把本地进度和远端事实画在两条线上。检查点记录应用在某个边界的状态，恢复时可能重新进入节点；它不天然参与支付服务的事务。支付已经提交、本地还没保存结果就崩溃，是典型窗口。恢复读到“待支付”，只能说明本地没有确认，不能据此断言钱没扣。

同一业务意图应在首次提交前固定操作 ID 和规范化参数，重试时沿用，具体去重与结果返回由支付接口的幂等合同支持。还要确认调用者和资源范围、同 ID 不同参数的冲突行为、记录保留期以及并发语义。只把 ID 放进请求而服务端不处理，没有产生保护；只对参数做 hash，也可能把用户确实要发起的第二笔相同付款误认成重试。

结果未知时优先按原标识查询或对账，确认已有结果再补写本地状态；有明确幂等合同才按原意图恢复。无法确认时等待或转人工，不能自动换新 ID 补付。恢复还要检查代码与状态格式、工具合同、当前权限和审批对象，字段变化不能随意补默认值继续。测试需要在本地保存前后、远端提交前后插入中断，核对真实对象与所有尝试；状态恢复、幂等和业务补偿各有职责，补偿也不是把本地记录改回去就算完成。

常见追问：

代码升级后旧检查点能直接继续吗？ 需确认状态 schema、节点顺序与工具含义兼容，固定旧版本或按明确规则迁移。原字段缺少币种等关键条件时应补信息，不能随手填默认值后沿用旧批准。
远端不支持幂等接口怎么办？ 先看能否按操作或业务关联查询结果，用日志和对账恢复；无法安全判定就暂停或人工处理。不能因为本地有去重表，就承诺跨系统窗口已经消失。
幂等是不是保证请求只发送一次？ 不是。传输和尝试可以重复，目标是在服务声明的合同内，同一业务意图不再产生额外副作用。独立新意图仍需新标识，去重保留期与并发行为也要明确。

实战案例：

教学支付服务接收 op17 后创建支付记录 P9，调用方在保存成功状态前退出。初版恢复换新 ID 再付，可能重复扣款。改为持久保存原意图与参数，恢复查询 P9 并核对内容，再更新本地状态。验收在写前、远端成功后和本地确认后分别注入中断，检查同一意图只关联一个符合参数的支付对象；同 ID 改金额被拒绝，新独立意图可创建新对象，未知结果不会被伪装成明确失败。

常见误区：

“框架支持持久化，所以已经实现 exactly-once”。本地恢复到同一节点，不能证明远端还处在原来的状态；检查点也不是永久权限凭证。

微练习：

列出“写入前崩溃”“远端成功但响应丢失”“状态保存后崩溃”。验收：每种情况说明查询、重试与幂等键如何配合。再增加同 ID 改参数与幂等记录到期两种条件，写清可确认事实、必须暂停的情形和禁止动作。

学习与参考： 可靠性与安全

Q015 什么时候值得使用多个 Agent？¶

优先级：P1

30–60 秒回答：

先用单 Agent 或固定流程建立基线。若任务可以拆成较独立的子目标，需要隔离上下文或不同工具权限，多 Agent 才可能带来收益。成本包括任务分配、结果整合、重复工作和通信错误。是否值得，要看在相同验收规则下成功率、延迟与成本的变化，不能从角色数量推断系统更聪明。

展开详细答案、追问与案例

详细答案：

先建立单 Agent 或固定流程的基线，记录它为什么失败。某个独立研究任务需要大量中间材料、专用工具或单独复核时，拆分可能减少主上下文负担并提高并行机会。若只是把连续函数改叫几个专家，新增的分配、聊天和汇总往往没有解决原来的缺口。角色名称不能代替任务边界。

可拆任务要有输入、产物和完成条件。主协调者可以持有共同日期和人员类别，地区研究者各自返回来源、版本、条款和未知项，协调者再统一比较。子任务像委托一段可验收的工作，不能只说“研究一下”就等一段肯定结论。上下文隔离也不会自动限制权限，工具、凭据和存储范围应按任务授予，不能让每位研究者继承发布能力。

收益评估看最终产物。多个相似模型可能引用同一错误材料，相互赞同并没有增加独立证据；复核者需要明确的评分合同与可核对原文。成本则包括额外调用、摘要损失、重复工作、迟到结果和协调等待。固定任务与可比预算，比较成功、错误动作、延迟和费用，再通过移除某个角色检查贡献。多分支还需要统一预算、停止规则和失败收敛，否则每个子任务都觉得还能继续研究，主任务就很难真正结束。

常见追问：

独立评审一定比自己检查可靠吗？ 不一定。相似模型与共享来源可能有共同偏差，评审还会误读候选。让它对照原证据和明确规则，在人工标注与客观终态上校准，再判断减少了哪类错误。
不同工具权限是否必须用不同 Agent？ 可以用任务范围、执行器与独立工具合同实现限制，多 Agent 只是组织方式之一。先看上下文和控制需求，权限始终要由可信服务落实，角色提示不能当授权凭据。
怎样证明拆分值得？ 在同题、相近资源与同一验收规则下对照，报告逐题差异与退步；再去掉某角色或替换成简单基线，检查收益是否只是来自更多尝试，并统计整项任务成本。

实战案例：

三地研究初版由主助手一次处理，长原文挤掉了比较条件。改为让地区工作单元返回统一证据合同，主任务保留日期、类别和综合职责；另设一种只压缩工具输出的单 Agent 基线。验收用相同任务比较来源覆盖、条件遗漏、错误发布与总费用，并让一路失败，检查缺口可见、重试受总预算约束。若简单基线已同样完成，就没有证据说增加角色更值得。

常见误区：

把每个函数包装成一个“专家”，让简单任务被大量对话拖慢。多位角色共用高权限凭据，可能同时扩大错误影响；隔离消息不等于隔离资源。

微练习：

对一个五步任务画单 Agent 与三 Agent 两版。验收：标出新增通信、可并行步骤以及需要什么实验才能证明拆分有效。再给三 Agent 版设计一次消融：去掉谁、其余条件怎样固定、哪些结果支持继续保留这个角色。

学习与参考： 规划与多 Agent

Q016 多 Agent 如何交接，冲突如何处理？¶

优先级：P1

30–60 秒回答：

交接应像函数契约：明确目标、输入、约束、可用工具、预算、输出 schema 和完成条件。下游返回结论、证据引用、未解决问题与执行状态。协调者按预定义规则处理冲突，例如以最新有效版本或更高可信来源为准；无法判定就补充检索或请求决策，而不是按票数决定事实。

展开详细答案、追问与案例

详细答案：

先把交接对象做成可检查的任务合同。说明原始目标、共同输入、已确认事实、允许动作、工具与资源范围、预算、产物格式及终止条件。上游传递“请完成比较”不能自动赋予下游发布或付款权限；可信身份和能力范围仍由运行时传递与服务端检查。任务版本也应一起发送，防止旧计划结果混入新结论。

返回值要能用于下一步判断。除了结论，还应有来源 ID、内容版本、生效区间、适用对象、未解决项和执行状态。把“暂时没取到材料”与“有证据证明不允许”分开，协调者才能正确补查或结束。可以把交接想成带附件的委托单：表格字段帮助接手，附件是可回查依据；格式完整并不能证明结论真实，仍需核对内容。

合并先处理重复和口径，再处理语义。相同片段重送按稳定标识去重，不同金额要核对主体、日期和规则层级，不能让最新到达或多数投票直接裁决。来源相同的转载也不能当独立支持。无法判定时保留冲突并补检索或请求决策，最终报告由明确所有者写入。交接越精简越省上下文，却不能删掉限制与未知；整段历史全转发又会增加污染、敏感信息传播和成本，应先传必要状态与指针，按需回查。

常见追问：

下游需要发布权限，上游说同意够吗？ 不够。角色消息不是可信审批凭证，仍需检查用户、对象、当前授权和业务要求的具体批准。可以返回待发布草稿，由拥有对应能力的执行路径单独处理。
两个 Agent 都引用了最新版，为什么还冲突？ 可能主体、人员类别、地区或生效日期不同，也可能一方误读条款。先对齐条件与原始出处，再核对是否真正矛盾；“最新版”标签本身不能替代有效区间判断。
如何处理重复与迟到结果？ 结果带任务、计划和来源版本，重复按稳定标识处理；旧版本结果可以归档或重新验证，不能直接覆盖当前状态。重试追加列表也会重复，合并规则需明确去重与冲突分支。

实战案例：

两位研究者对培训政策生效时间给出不同日期，一个读到公告发布时间，一个读到条款生效日。初版按两人的口头信心投票，报告取错日期。改为交回原文位置、版本、时间字段含义与适用范围，协调者按正式条款核对；未确认的条件保留为待查。验收注入重复证据与旧任务迟到结果，检查无重复计数、不覆盖新版报告；读取角色也不能因为交接消息写着“顺便发布”就生成外部发布对象。

常见误区：

把完整历史无差别转发给所有 Agent，造成成本、污染和敏感信息传播。把摘要中的推测写成已确认事实，或把建议提交写成用户批准，会在交接时放大原始错误。

微练习：

两个 Agent 对政策生效时间给出冲突答案。验收：用包含版本、来源、日期和置信边界的结构交接，说明如何裁决。再让一个来源撤回，说明哪些交接字段、比较结论和待发布草稿失效，如何保留其余有效工作。

学习与参考： 规划与多 Agent

参考资料¶

核心主张	一手来源	阅读要点
ReAct 交替组织推理与动作	ReAct	实验结论对应论文中的任务与设置
图使用状态、节点、边与更新归并	LangGraph Graph API	此处不固定 SDK 版本
Checkpointer 与跨线程 store 有不同作用	LangGraph Persistence	外部副作用仍需业务幂等设计
编排可包含路由、并行和动态分解	Anthropic 模式讨论	结合路由、并行和动态分解的适用条件阅读

复习入口：仓库首页 · 上一篇：基础 · 下一篇：RAG