面试题 · Agent
搜索「RAG」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在复杂任务中，为什么需要将系统拆分为多个协同工作的Agent？请分析其优势和设计考量
复杂任务往往跨越多个专业领域（如代码生成+测试+部署），单Agent面临：
| 维度 |
|---|
学习内容与项目面试，在同一条路上。
| 单Agent |
|---|
| 多Agent |
|---|
| 专业化 | 通用但浅 | 每个Agent深耕特定领域 |
| 并行度 | 串行执行 | 多路并发处理独立子任务 |
| 容错性 | 单点失败 | 隔离故障，可重启/替换单个Agent |
| 可维护性 | 提示工程复杂 | 模块化迭代，边界清晰 |
1. 任务分解策略
2. 协作模式选择
3. 通信与状态
代码开发Agent系统：
需求分析Agent → 架构设计Agent → 代码生成Agent → 代码审查Agent → 测试Agent
↑___________________________________________________________↓
（反馈循环）设计底线：只有当任务确实存在正交的职责边界且需要持续协作时，才引入多Agent复杂度，避免过度设计。
场景切入
假设我们做个智能客服系统，需要同时处理订单查询、退换货、投诉等，你会让一个Agent包揽所有，还是拆成多个各司其职的Agent？为什么这么设计？
层层追问
复杂任务里，你一般用单Agent还是多Agent？……单Agent有什么瓶颈？……那多Agent怎么解决这些瓶颈，具体优势在哪？设计时你要注意什么？
直球架构
直接说，复杂任务为什么要拆成多个协同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之间的超时和重试策略，以及状态一致性。