多 Agent 协同为什么必要?

30 秒回答

1. 明确单Agent的局限性（能力边界、上下文限制、错误累积）
2. 阐述多Agent的核心优势（专业化分工、并行效率、容错隔离）
3. 说明关键设计考量（通信协议、任务路由、状态同步）
4. 提及典型协作模式（层级式、对等式、流水线式）

回答与解析

答案要点

• 明确单Agent的局限性（能力边界、上下文限制、错误累积）
• 阐述多Agent的核心优势（专业化分工、并行效率、容错隔离）
• 说明关键设计考量（通信协议、任务路由、状态同步）
• 提及典型协作模式（层级式、对等式、流水线式）
• 结合实际场景举例说明

核心原因：单Agent存在本质瓶颈

复杂任务往往跨越多个专业领域（如代码生成+测试+部署），单Agent面临：

• 能力稀释：通用提示难以兼顾深度与广度
• 上下文爆炸：长链条推理导致关键信息淹没
• 错误级联：一步出错后续全错，缺乏纠错机制

多Agent的核心优势

关键设计考量

1. 任务分解策略

• 按技能维度拆分（Coder/Reviewer/Tester）
• 按流程阶段拆分（规划→执行→验证）

2. 协作模式选择

• 层级式：Orchestrator统一调度，适合强管控场景
• 对等式：Agent自主协商，适合探索性任务
• 流水线式：标准输入输出，适合确定性流程

3. 通信与状态

• 共享内存 vs 消息传递
• 关键：定义清晰的Agent契约（输入schema、输出承诺、超时机制）

典型场景示例

代码开发Agent系统：

需求分析Agent → 架构设计Agent → 代码生成Agent → 代码审查Agent → 测试Agent
         ↑___________________________________________________________↓
                              （反馈循环）

设计底线：只有当任务确实存在正交的职责边界且需要持续协作时，才引入多Agent复杂度，避免过度设计。

口语版讲法(约4分钟)

• 本质问的是系统复杂度与职责边界
• 单Agent的瓶颈：能力稀释、上下文爆炸、错误级联
• 多Agent优势：专业化、并行、容错
• 设计考量：任务分解、协作模式、通信契约
• 落地风险与取舍：正交边界、过度设计

这道题其实是在问，当任务复杂到一定程度，你是用一个全能的Agent硬扛，还是拆成多个专业Agent协作。我的理解是，单Agent有本质的瓶颈，不是提示词能解决的。比如一个Agent同时做代码生成、测试、部署，通用提示很难兼顾深度和广度，这叫能力稀释；长链条推理中关键信息容易被淹没，上下文爆炸；而且一步出错后面全错，没有纠错机制。所以复杂任务下，我倾向于拆成多Agent。

多Agent的核心优势是三个：专业化分工、并行效率、容错隔离。每个Agent只深耕一个领域，比如一个专门写代码，一个专门做审查，一个专门跑测试。它们可以并行处理独立子任务，不像单Agent只能串行。而且某个Agent挂了，可以单独重启替换，不影响整体。

设计多Agent系统，有几个关键考量。先说任务分解策略。我一般按技能维度拆，比如Coder、Reviewer、Tester，或者按流程阶段拆，规划、执行、验证。这里有个坑：分解的粒度要正交，也就是职责边界清晰，不重叠。如果两个Agent干的事有交叉，协调成本会急剧上升。

再一个协作模式。常见的有三种：层级式、对等式、流水线式。层级式有个Orchestrator统一调度，适合强管控场景，比如客服退款流程，总控Agent拆单分配给退款、审核、通知三个子Agent；对等式Agent自主协商，适合探索性任务，比如市场调研，多个Agent各自抓数据再协商结论；流水线式标准输入输出，适合确定性流程，比如订单处理，从下单到发货一条线。实际落地常常是混合的，比如代码开发用流水线，但中间有反馈循环，需求分析Agent输出给架构设计Agent，再给代码生成Agent，然后审查和测试Agent反馈回来。

通信与状态这块，我特别关注Agent契约。每个Agent的输入输出schema要定义清楚，包括承诺和超时机制。共享内存还是消息传递要看场景，消息传递更解耦，但延迟高；共享内存快，但一致性难保证。

举个例子，电商平台处理退款纠纷。一个Agent负责理解用户诉求，一个查订单状态，一个查退款规则，一个执行退款。如果单Agent做，上下文太长容易漏掉关键规则。拆开后，每个Agent专注自己的事，理解诉求的只做情感分析和意图识别，查规则的去匹配政策，最后汇总给执行Agent。这样每个Agent的提示词可以很精炼，出错也能定位到具体哪个环节。

这里有个延伸点：什么时候不该拆？ 如果任务本身很简单，或者子任务之间耦合太紧密，强行拆成多Agent反而引入通信开销和一致性难题。比如一个简单的FAQ问答，单Agent加RAG就够，拆成两个Agent反而慢。所以我的判断是：只有当任务存在正交的职责边界且需要持续协作时，才引入多Agent复杂度。否则我会倾向先用单Agent加工具调用试试，不行再拆。

总结一下，我会把多Agent看作一种系统架构模式，核心是职责分离和容错，但前提是边界清晰、契约严谨。上线后我会特别关注Agent之间的超时和重试策略，以及状态一致性。

关键一句:什么时候不该拆多Agent：任务简单或子任务耦合紧密时，单Agent加工具调用更优。

面试官还可能这样问

1. 问法 1 · 场景切入

   假设我们做个智能客服系统，需要同时处理订单查询、退换货、投诉等，你会让一个Agent包揽所有，还是拆成多个各司其职的Agent？为什么这么设计？

2. 问法 2 · 层层追问

   复杂任务里，你一般用单Agent还是多Agent？……单Agent有什么瓶颈？……那多Agent怎么解决这些瓶颈，具体优势在哪？设计时你要注意什么？

3. 问法 3 · 直球架构

   直接说，复杂任务为什么要拆成多个协同Agent？优势有哪些？设计一个多Agent系统，关键考量点是什么？比如任务分解、协作模式、通信等。