约 9 分钟4 张卡

多 Agent 协作

多 Agent 协作把一个任务分给多个 Agent 完成，再汇总各自的结果。每个 Agent 可以拥有自己的提示词、上下文和工具范围，专注于分配给它的子任务。

本文介绍协作的组织方式，以及子任务所需的信息怎样传递和共享。选型时重点看任务是否适合独立执行，并结合失败处理、结果汇总和资源冲突评估拆分代价。

1. 面试核心

先记住这几条，再读正文

组织方式决定谁分配工作、谁接收结果，以及谁处理冲突。选择时先看子任务之间的依赖，再决定是否需要中心编排者。

编排者—执行者结构把分配和汇总集中在一个节点，执行者只与编排者通信。流水线则把前一阶段的输出交给下一阶段。这两种结构的结果去向明确，所以更容易追踪任务归属和定位失败。

层级结构让子编排者继续拆分工作，适合需要多级管理的任务。对等协作中，Agent 可以直接交换消息，或把信息写到共同读取的状态区。讨论越自由，越需要明确发言顺序、终止条件和冲突裁决方式，否则会反复争论或转交任务。

执行者需要知道具体要做什么，也需要知道哪些信息属于自己的任务范围。信息可以通过两种方式传递：

消息传递：编排者发送子任务，执行者返回结果。执行者使用自己的消息历史，因此任务描述要包含所需背景。缺少关键条件时，它会重复探索，或沿错误方向执行。
共享状态：多个 Agent 读写同一份任务数据，例如数据库中的任务表、共享文件或框架中的图状态。图状态是执行节点之间传递的数据对象，需要明确每个字段由谁写入。

派发任务时，要写清以下五项要求：

请求和结果还要带任务 ID 与完成状态，方便程序关联。下面是一个接口兼容性检查的结果消息，大产物保存在文件中，消息只返回引用。

{
  "task_id": "review-3",
  "goal": "检查订单模块的接口兼容性",
  "scope": ["src/orders/"],
  "status": "done",
  "result_ref": "artifacts/review-3.json"
}

结果引用指向完整产物，摘要则帮助编排者快速了解结论。这样能减少汇总时读入的内容，避免主 Agent 的上下文被子任务结果占满。这个结果消息省略了派发阶段的工具权限、输出格式和停止条件，实际任务描述仍需提供它们。

共享状态需要规定字段归属和合并规则。比如两个执行者同时更新检查结论，直接覆盖会丢失其中一份结果。可以用版本检查拒绝过期写入，或用归并函数把新旧结果合成一份。数据库、共享文件与图状态都要落实这些约束。

汇总要把多个结果变成一份可核验的结论。编排者先检查各子任务是否完成，再去除重复内容，并核对结论对应的证据。

不同 Agent 给出矛盾结论时，要比较证据来源、时间与适用条件。比如一个结果针对旧接口，另一个针对新接口，两者就应分别说明适用版本。证据不足以裁决时，保留争议并说明它对最终结果的影响。

部分子任务超时后，能否继续汇总，取决于它是否影响最终验收。必需子任务失败时，父任务保持未完成；可选子任务失败时，可以返回部分结果，但要列出缺失范围与影响。

重试沿用子任务 ID，同时增加尝试编号。这样，编排者就能区分同一任务的多次执行，只接纳当前有效尝试的结果，避免迟到结果覆盖新结果。重试次数和消耗仍受总预算约束。

父任务取消后，编排者停止派发新工作，并通知仍在运行的执行者停止。已经写入的文件或发出的外部请求仍要核对，取消消息无法撤销此前的副作用。

拆分是否有收益，要看它能否减少等待，或让每个 Agent 更专注于自己的输入。以下三类任务特征值得考虑拆分：

如果后一步需要前一步的完整细节，执行者之间就要传递大量上下文。这会增加交接成本，摘要还容易遗漏关键条件。因此，强依赖任务更适合先保留在同一个 Agent 中处理。

拆分后还要计算以下几项代价：

并行可以缩短独立工作的等待时间，但总耗时还包括排队、最慢子任务和汇总。等待时间下降时，总 Token 消耗仍会增加。所以应以单 Agent 为基线，在同一任务集上比较质量、耗时和总成本，再决定是否拆分。

独立上下文解决的是信息干扰，文件和外部服务仍可能被多个 Agent 同时访问。并发执行前，需要为这些共享资源规定访问与合并方式。