多 Agent 协作
多 Agent 协作把一个任务分给多个各自拥有提示词、工具和上下文的 Agent 完成，再汇总结果。本文说明常见的组织方式、通信与状态共享、拆分依据，以及拆分带来的冲突和成本。
1. 面试核心
先记住这几条，再读正文- 拆分的主要收益是上下文隔离和并行：子 Agent 在独立窗口中处理大量材料，只把结论返回给主 Agent。卡 · 组织方式
- 最常用的是编排者—执行者结构：编排者拆分任务、分派、汇总，执行者之间不直接对话。
- 通信用结构化消息或共享状态，必须带任务 ID、输入范围、输出格式和完成状态，不能只传自然语言摘要。
- 多 Agent 增加 Token 成本、延迟、通信失真和调试难度。子任务强依赖、需要共享大量上下文时，单 Agent 更合适。卡 · 拆分依据与代价
- 并行写入同一资源会冲突，要按文件或数据范围划分所有权，或用锁、独立工作区和合并步骤处理。卡 · 资源竞争与隔离
2. 组织方式
| 方式 | 结构 | 适用情况 |
|---|---|---|
| 编排者—执行者 | 中心节点拆分并汇总，执行者只与中心通信 | 子任务可独立完成，如多方向调研、分模块检查 |
| 流水线 | 每个 Agent 处理一个阶段，输出传给下一个 | 阶段清晰，如抽取 → 校验 → 生成报告 |
| 层级 | 编排者下还有子编排者 | 任务规模大、需要多级拆分 |
| 对等/群聊 | Agent 之间直接对话或共享黑板 | 讨论、辩论类任务；最难控制和收敛 |
生产中常用前两种，因为控制流清楚、失败容易定位。对等结构需要额外的发言顺序、终止条件和冲突裁决，否则容易出现互相推诿或无休止的讨论。
3. 通信与状态共享
子 Agent 之间传递信息有两种方式：
- 消息传递：编排者把子任务描述发给执行者，执行者返回结果。描述中要包含目标、输入范围、可用工具、输出格式和停止条件。执行者看不到编排者的完整上下文，子任务描述缺信息时，它会重复劳动或做错方向。
- 共享状态：所有 Agent 读写同一个状态对象或存储，例如 LangGraph 的图状态、数据库中的任务表、共享文件。需要定义每个字段由谁写、写入时如何合并。
{
"task_id": "research-3",
"goal": "统计 2026 年三家云厂商 GPU 实例的按需价格",
"scope": ["官网价格页", "官方公告"],
"output": {"format": "table", "fields": ["vendor", "instance", "price", "source_url"]},
"status": "done",
"result_ref": "s3://runs/42/research-3.json"
}
大结果放在外部存储中，只回传引用和摘要，避免主 Agent 的上下文被子结果撑满。
3.1 结果汇总
汇总是编排者的职责：检查每个子任务是否完成、去除重复、合并冲突。不同子 Agent 给出矛盾结论时，按证据来源和时间裁决，无法裁决的冲突应在最终结果中标明，而不是让模型选一个看起来合理的答案。
4. 拆分依据与代价
适合拆分的信号：
- 子任务之间依赖少，可以并行。
- 每个子任务需要读取大量材料，单个窗口装不下。
- 子任务需要不同的工具集或权限，例如一个只读检索、一个可以写代码。
不适合拆分的信号：
- 子任务强依赖，后一步需要前一步的完整细节。
- 需要共享大量上下文，通信本身就要传递大部分信息。
- 单 Agent 已能完成，拆分只为“看起来更先进”。
代价包括：每个子 Agent 都要重新读入任务背景，总 Token 数成倍增加；通信中的信息丢失导致重复或偏差；失败时需要查看多条轨迹才能定位。
5. 资源竞争与隔离
| 竞争对象 | 问题 | 处理方式 |
|---|---|---|
| 文件或数据 | 两个 Agent 同时修改同一文件 | 按文件或模块划分所有权；独立工作区（如 Git worktree）后合并 |
| 外部 API 配额 | 并发请求触发限流 | 全局并发上限和令牌桶 |
| 模型配额与预算 | 并发子 Agent 迅速消耗 Token | 为每个子任务分配预算，汇总统计 |
| 上下文 | 子 Agent 被无关信息干扰 | 只传子任务需要的材料，结果以摘要返回 |
状态隔离要求每个子 Agent 有自己的消息历史和工作目录，共享状态只通过定义好的字段读写。
6. 常见问题
6.1 A2A 和 MCP 有什么区别
MCP 连接 Agent 与工具、数据源，Server 提供能力，Host 中的模型决定何时调用。A2A（Agent2Agent）协议用于不同 Agent 之间的协作：一个 Agent 通过 Agent Card 发现另一个 Agent 的能力，以任务为单位发送请求并接收状态和结果。前者是“Agent 调用工具”，后者是“Agent 委托另一个 Agent”。
6.2 如何避免多个 Agent 互相推诿
明确每类任务的唯一负责人，转交时记录原因并限制转交次数；编排者跟踪任务状态，超过次数或超时未完成时由编排者接管或转人工。
7 · 面试题卡片
7.1 多 Agent 协作系统如何设计？Agent 之间的通信机制和状态共享如何实现？
出现公司：字节跳动、快手、腾讯、阿里云、美团
考察重点
- 组织方式的选择。
- 消息传递与共享状态的内容、格式和汇总。
参考回答
常用编排者—执行者结构：编排者拆分任务并为每个子任务写清目标、输入范围、可用工具、输出格式和停止条件；执行者在独立上下文中完成，返回结构化结果。执行者之间不直接对话，控制流集中在编排者。
通信有消息传递和共享状态两种。消息中带任务 ID 和状态，大结果写入外部存储只回传引用。共享状态要规定字段归属和合并规则。汇总时编排者检查完成情况、去重，并按证据来源与时间裁决冲突，无法裁决的保留并标注。还要限制委派深度和总预算。
7.2 为什么不默认使用多 Agent？拆分后有哪些风险？
出现公司：小红书、美团、阿里淘天
考察重点
- 拆分的收益条件。
- 成本、通信失真、冲突和调试难度。
相关内容：拆分依据与代价。
参考回答
多 Agent 的收益来自上下文隔离和并行，只在子任务依赖少、材料多到单窗口装不下，或需要不同工具与权限时才明显。子任务强依赖时，通信需要传递大部分上下文，拆分反而丢信息。
风险包括：每个子 Agent 重新读入背景，总 Token 和延迟增加；子任务描述不完整导致重复或方向错误；并行修改同一资源产生冲突；结论互相矛盾需要裁决；失败时要排查多条轨迹。因此先用单 Agent 建立基线，评测证明拆分带来提升后再引入。
7.3 多个 Agent 并发执行时会争抢哪些资源？如何隔离上下文和状态？
出现公司：小红书、字节跳动
考察重点
- 文件、API 配额、模型预算和上下文的竞争。
- 所有权划分、独立工作区与合并。
相关内容：资源竞争与隔离。
参考回答
竞争对象有四类：共享文件或数据、外部 API 配额、模型并发与 Token 预算、上下文空间。
文件按模块划分所有权，或者每个 Agent 在独立工作区（如 Git worktree）中修改，最后由编排者合并并运行测试；必须共享的数据用锁或版本号。API 和模型调用设全局并发上限、令牌桶和每个子任务的预算。上下文隔离要求每个子 Agent 有独立消息历史，只接收子任务所需材料，结果以摘要和引用返回；共享状态只通过约定字段读写。