中困难

多Agent协作架构#

一句话答案#

多 Agent 通过角色分工协作完成复杂任务，常见模式：主从式（Orchestrator）、辩论式、流水线式。

核心要点

使用 Multi-Agent 的核心场景：

任务复杂度超过单 Agent 能力上限：任务需要的工具太多，Context 装不下
并行化加速：任务可分解为相互独立的子任务，并行执行（如同时分析多份报告）
专业化分工：不同 Agent 针对不同领域优化（如代码 Agent、文档 Agent、数据 Agent）
长流程任务：避免单次对话 Context 超限
对抗验证：一个 Agent 生成结果，另一个 Agent 负责验证/批评

协作模式：

1. Supervisor 模式（主从模式）

用户请求
  → Supervisor（主控 Agent，负责任务分解和调度）
      → Sub-Agent A（专注子任务1）
      → Sub-Agent B（专注子任务2）
      → Sub-Agent C（专注子任务3）
  → Supervisor 汇总结果 → 返回用户

plaintext

Supervisor 负责：理解用户意图、分解任务、选择子 Agent、汇总结果
子 Agent 负责：执行具体任务，返回结果给 Supervisor

2. Pipeline 模式（流水线）

A → B → C，每个 Agent 处理上一个的输出
适合有明确顺序依赖的任务（如：提取信息 → 分析 → 生成报告）

3. 平行（Parallel）模式

多个 Agent 同时处理，结果合并
适合并行处理大量相同类型任务

4. Debate 模式（辩论）

多个 Agent 对同一问题给出不同答案，再由裁判 Agent 综合判断
提升准确性，降低单点误差

5. Agent 互操作协议：A2A 与 MCP#

上面四种模式默认多个 Agent 在同一个进程/同一套框架里协作；一旦 Agent 分属不同团队、不同厂商、不同运行时，就需要一个跨边界的”握手协议”。A2A（Agent2Agent）协议就是做这件事的：Google 在 2025 年 4 月发布，同年 6 月捐给 Linux 基金会；2026 年 3 月发布第一个稳定版 v1.0，之后加入 Linux 基金会下的 Agentic AI Foundation（和 MCP 同属一个基金会）。

A2A 的核心对象：

Agent Card：每个 Agent 发布一份 JSON 描述（能力/技能列表、服务端点、鉴权方式），供其他 Agent 发现并决定是否委托
Task：协作的基本单位，有完整生命周期（提交 → 进行中 → 需输入 → 完成/失败/取消），远端 Agent 以 Task 为粒度接活、回报进度
Message / Artifact：Task 内的往返消息与产出物，可含文本、文件、结构化数据
传输：v1.0 支持 JSON-RPC 2.0 over HTTPS、gRPC、HTTP+JSON/REST 三种绑定，一张 Agent Card 可以按优先级列出多个传输端点；长任务用 SSE 流式推送状态更新或推送通知回调，支持跨网络的长耗时协作
v1.0 的其他变化：Signed Agent Card（用 JSON Web Signature 签名，防止伪造 Agent Card 冒充身份）、原生多租户（一个端点托管多个 Agent）；从 0.3 升级有字段和路径的不兼容改动，客户端要带版本头声明协议版本（细节以官方规范和迁移指南为准）

与 MCP 的关系（面试高频）：

维度	MCP	A2A
连接对象	Agent ↔ 工具 / 数据源（“纵向”）	Agent ↔ Agent（“横向”）
抽象粒度	Tool / Resource / Prompt	Agent Card / Task / Artifact
典型问题	模型怎么统一调工具	一个 Agent 怎么找到并委托另一个 Agent

两者互补不替代：一个 Agent 通过 MCP 接数据库与 API，再通过 A2A 把自己做不了的子任务交给别的 Agent（对方内部又用自己的 MCP 工具）。MCP 原理见 MCP协议原理。

适用场景：跨团队/跨厂商的 Agent 协作（如采购 Agent 调用供应商 Agent 询价）、不想暴露内部实现只想暴露”能力”的场景。同一代码库内的 Supervisor-Worker 不需要 A2A，直接函数调用或消息队列更简单。

6. 主流框架里的多 Agent 形态#

各框架对多 Agent 的叫法不同，但基本能归到上面几种模式（以各自官方文档为准）：

框架	官方给出的模式	对应本文
OpenAI Agents SDK	Agents as tools（管理者用 `Agent.as_tool()` 调专家，自己保留最终回答）、Handoffs（分诊 Agent 把本轮交给专家，专家直接回复）、代码编排（结构化输出、串联、循环评估、并行）	Supervisor / 路由 / Pipeline / Parallel
LangChain / LangGraph	Subagents（主 Agent 把子 Agent 当工具调）、Handoffs（工具调用改状态，触发切换）、Skills（单 Agent 按需加载专用提示）、Router（分类后派给一个或多个专家再汇总）、Custom workflow（用 LangGraph 自己编排）	Supervisor / 路由 / Pipeline
Microsoft Agent Framework	AutoGen 和 Semantic Kernel 的后继（AutoGen 已进入维护模式），用基于图的 Workflow 显式编排多个 Agent，支持 checkpoint、暂停恢复、人工审批	Pipeline / Parallel / Supervisor
CrewAI	Crew（角色 + 任务，顺序或层级流程）+ Flow（事件驱动的确定性编排）	Pipeline / Supervisor

一个趋势：框架普遍把”子 Agent 当工具调用”和”handoff 转交控制权”区分开。前者由主 Agent 保留对话和最终回答，子 Agent 在独立上下文里跑、只回摘要；后者是把对话本身交出去。选哪种取决于谁该对最终答案负责。

面试回答（2分钟版）

多Agent协作是解决单Agent能力瓶颈的架构方案。使用多Agent的典型场景有：任务复杂度超过单Agent的Context窗口或工具数量限制、需要并行处理加速、不同子任务需要专业化分工。常见的协作模式有四种：Supervisor模式由一个主控Agent负责任务分解和调度，把子任务分配给专业Agent执行后汇总结果，类似项目经理分活；Pipeline模式是顺序流水线，A的输出作为B的输入，适合有明确依赖关系的场景比如信息提取到分析到报告生成；Parallel模式多个Agent并行处理同类任务再合并，适合批量处理；Debate模式多个Agent对同一问题给出不同答案再由裁判综合判断，通过对抗提升准确性。选型原则是能用单Agent就不用多Agent，多Agent带来的通信开销、状态同步、错误传播都是额外复杂度。

追问与易错

追问方向：

多 Agent 之间的通信开销怎么控制？上下文怎么传递？ → 只传递必要的结构化结果（不传原始对话历史），用共享状态对象或消息队列解耦。框架的工具函数签名固定、塞不进额外上下文时，一种做法是用请求级的上下文对象（如 ThreadLocal / contextvars）旁路传递，代价是要保证在线程或协程切换时正确传递和清理
一个 Agent/Worker 失败了怎么办？错误传播怎么处理？ → Worker 级别独立超时 + 失败降级为空结果而非抛异常，不阻塞其他 Worker。关键 Worker 可设重试，非关键 Worker 直接跳过
什么时候该用多 Agent 而不是单 Agent？判断标准是什么？ → 两个信号：①单 Agent 工具数超过 15-20 个（Context 装不下）②子任务需要不同的 System Prompt 和专业角色。否则用单 Agent 更简单
Supervisor 模式和 Pipeline 模式怎么选？ → Supervisor 适合需要动态分解与结果汇总的子任务（可串可并）；Pipeline 适合有严格依赖链的顺序任务（A 的输出是 B 的输入）
A2A 和 MCP 有什么区别？ → MCP 是 Agent 到工具/数据源的纵向接口，抽象是 Tool/Resource；A2A 是 Agent 到 Agent 的横向接口，抽象是 Agent Card（能力发现）+ Task（任务生命周期），v1.0 支持 JSON-RPC、gRPC、HTTP+JSON 三种传输，长任务用 SSE 推送状态。两者互补：一个 Agent 用 MCP 调工具、用 A2A 把子任务委托给别的 Agent

易错点：

❌ 为了用多 Agent 而用 → 简单任务单 Agent 更快更稳，多 Agent 的编排开销可能得不偿失
❌ 忽略 Agent 间状态同步 → 多个 Worker 并发访问共享状态需要同步机制（如 synchronized/CAS）
❌ 没有降级方案 → 某个 Worker 挂了不能影响整体，需要设计 Worker 级别的 fallback

结合项目时可以讲：为什么拆成多个 Worker、Worker 失败时整体怎么降级、上下文怎么在 Agent 之间传递，以及拆分前后在延迟和质量上的对比数据。