多 Agent 共享哪些上下文，如何同步和管理？

核心回答

多 Agent 应共享协作所需的任务信息和可交付结果，而不是把所有 Agent 的完整历史放进同一个 Prompt。通常可以分成三部分：

• 任务公共信息：当前目标、有效约束、必要的用户确认、任务版本，以及供执行层使用的身份和资源范围；每个 Agent 按职责读取其中需要的部分。
• 可共享结果：各子任务的完成状态、结论、证据位置、数据时间、产物引用和待解决问题，便于下游继续处理。
• 分支私有内容：各自的详细工具过程、临时草稿和无关历史，默认留在分支内，需要核查时再提供必要证据。

同步时由编排器传入明确的输入快照，子 Agent 返回局部更新；并行结果按分支保存，再由归并节点形成最终结论。对共同修改的字段定义合并或单一写入规则，对旧版本、重复和迟到结果做检查。简单的同进程任务用参数、返回值和 State 就能实现，需要跨进程恢复或并发写入时，再补可靠存储、条件更新或消息机制。

展开说明

1. 共享范围按任务与职责确定

共享信息首先要有任务、用户或租户范围。所有 Agent 都需要理解总体目标，但不一定需要读取同一份用户资料、全部记忆或所有工具结果。执行层可以保存可信身份和访问策略，模型只接收完成当前子任务必要的业务信息，凭据不随公共上下文广播。

例如设计一个研搜任务，两个分支分别检索公开资料和内部知识库。它们可以共享主题、时间范围、输出要求和已确认术语；各自维护查询过程，交回“结论、来源位置、数据时间、缺失项”。主 Agent 根据这些结果组织报告，需要复核时再读取相应原文，而不是先把两条搜索历史全部互相复制。

来源、时间和适用条件要跟随结论保留。一个分支的假设不能因为写进共享区就自动变成已确认事实；两边结论矛盾时，应保留证据并由归并步骤判断，不能靠最后写入者覆盖另一个结论。

2. 并行结果怎样合并

最直接的做法是各分支写自己的结果，权威字段由一个明确的归并步骤更新。例如公开资料分支提交 web_result，知识库分支提交 kb_result，分支状态和错误也分别记录；两个分支都不直接覆盖 final_report。

也可以把结果汇总到一个集合，但需要按稳定的子任务或结果 ID 合并，明确重复结果、更新和排序规则。简单列表相加只会追加，不会自动识别重试带来的重复内容；两个分支都返回整份旧列表，也可能重复已有项或丢掉对方更新。节点宜提交本次新增或修改的部分，而不是各自改完一份旧快照再整份覆盖。

以 LangGraph 为例，State 保存共享数据，节点返回局部更新，每个字段通过对应的 Reducer 合并。消息字段的 add_messages 可以按消息 ID 追加或更新；业务证据集合仍需按自己的主键和版本定义规则。同一步中，多个并行节点同时写一个不支持并发合并的字段，会触发并发更新错误，不能依赖默认的“谁晚到就保留谁”。

归并节点还需知道哪些分支是必需的、哪些可以降级。必需资料未完成时不能直接生成完整结论；允许部分结果时，应明确缺失项。共享状态不会让两个并行 Agent 实时看到对方尚未提交的中间变化，需要相互依赖的步骤应安排在后续阶段。

3. 用版本避免旧结果覆盖新任务

设两个分支开始时都接到任务版本 7，要求查询“第一季度”。执行中用户改为“第二季度”，编排器将有效目标更新为版本 8。分支返回时要携带任务 ID、子任务 ID 和输入版本，接收方先判断结果是否仍适用；受时间范围变化影响的旧结果应标记过期并重查，不能直接填入新版报告。未受影响的材料也应经过适用性检查后再复用。

共同存储中的写入竞争则是另一个问题。若两个执行者都基于状态修订号 12 计算更新，存储端可以要求“当前修订号仍为 12 才提交，并推进版本”。第一个更新成功后，第二个会发生条件冲突；它需要重读当前状态，再决定如何合并或重新计算，而不是照着旧快照重试覆盖。

版本检查必须与写入在存储端原子完成。本地先比较版本、随后无条件写入，之间仍可能被其他任务修改。进程内可以由单一协调者串行提交；持久化场景可使用数据库事务或条件更新，不要求一开始就引入分布式锁平台。

状态合并也不能代替业务幂等。两份相同通知即使只在 State 中保留一份，外部可能已经发送了两次；真正的副作用还需明确执行责任和业务幂等控制。

4. 状态放在哪里，怎样取回上下文

可以区分三种用途：运行状态保存任务目标、分支进度和结果索引；原始材料或产物保存长文、文件和详细工具输出；长期记忆保存经确认、跨任务仍有意义的信息。它们可以由同一套存储承载，不必物理上各建一个系统。

同进程短任务可以直接传参数与返回值，由编排器维护状态。需要中断恢复时，配置相应检查点或数据库后端；向量检索适合找相关历史，不能替代精确定位当前任务状态和版本。SSE、WebSocket 等进度通道可以展示变化，持久状态仍需由明确的存储维护。

每次调用模型时，再按当前步骤从这些信息中选择必要部分。共享状态保存了什么，与某个 Agent 这次实际看到什么，是两回事。 长结果可以按引用读取，状态变化也可以在下一次调用前刷新，不需要把所有分支的每次变化都立即广播给所有模型。

常见追问

主子 Agent 是直接共用全部 State 吗？

取决于框架和组装方式。可以共享部分键，也可以通过适配节点显式转换输入输出。研搜参考环境中的子 Agent 会以任务描述开始自己的消息历史，部分非私有状态字段另行传递和合并；设计时应检查实际传递的字段，而不能只根据“子 Agent”判断完全共享或完全隔离。

两个 Agent 同时改同一个文件怎么办？

优先明确一个写入者，其他分支交付建议、补丁或独立产物。如果确实需要并行修改，可以拆到不同文件或隔离工作副本，汇总时检查基线版本、冲突和验证结果。把文件路径放在共享 State 中，并不会自动防止覆盖。

Schema 标成 private，就能保证其他 Agent 看不到吗？

Schema 可以约束节点的输入和输出接口，但不等于底层访问控制。日志、流式输出或共享存储仍可能暴露字段；例如 LangGraph 的私有通道不应被理解成安全沙箱。敏感数据需要在传入节点、工具访问和对外展示的实际边界上控制。

怎样验证同步规则有效？

用明确场景检查：两个分支并发提交时都能保留，重放结果不重复追加，用户改目标后旧结果不覆盖新版，必需分支失败时不会被当作成功，不同用户和任务不会串数据。再检查每个 Agent 实际收到的输入及最终产物，不能只看共享字典里出现了全部键。

对应教程

参考资料