面试题 · Agent
搜索「大模型 Agent 架构」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在多Agent系统中，将任务拆解给多个Agent协作完成相比单一Agent有哪些优势和设计考量？
1. 专业化分工
2. 并行效率
3. 可扩展与容错
学习内容与项目面试，在同一条路上。
| 维度 | 设计要点 |
|---|---|
| 任务拆解策略 | 按能力边界拆（规划Agent/执行Agent/验证Agent）；或按数据分区拆（分片处理再聚合） |
| 通信机制 | 短期协作用消息队列；需状态共享用集中式记忆池；复杂流程用工作流引擎编排 |
| 调度协调 | 中央调度器（Master-Worker）适合强依赖任务；去中心化P2P适合松散协作 |
| 一致性保障 | 定义统一输出Schema；关键决策点设置人工确认或投票机制 |
| 成本控制 | 简单子任务用小模型，核心决策用大模型，避免全链路调用GPT-4 |
实际选型建议：任务步骤>3步且步骤间能力差异大时，优先考虑多Agent；否则单Agent+工具调用更简洁。
场景切入
假设你在做一个电商客服系统，用户问“我的订单什么时候发货”，然后追问“能改地址吗”，再到“退款流程呢”。你是一个人把这个对话从头到尾处理，还是想拆成三个Agent各自负责？说说你倾向怎么做，为什么？
层层追问
你平时设计Agent系统时，一个Agent包揽全部任务和拆成多个Agent协作，你会怎么选？……如果拆，按什么维度拆？……拆完以后它们之间怎么通信？……如果其中一个Agent挂了，系统会怎样？
直球架构
聊一下多Agent系统中任务拆解的优势和设计要点。优势方面，专业化、并行、容错这些；设计上，拆解策略、通信机制、调度协调、一致性保障和成本控制，你按自己的理解说。
这道题其实问的是，当单[[Agent]]搞不定的时候，我们怎么通过拆任务和多Agent协作来解决问题。说白了，就是判断什么时候该拆、怎么拆、拆完怎么管。
先说优势。最核心的是 专业化分工。一个Agent什么都干，就像一个人既要写代码又要做测试还要写文档，很容易样样通样样松。拆成多个Agent，每个只干自己最擅长的事，比如一个专门写代码，一个专门跑测试，一个专门写文档，每个都能独立优化。而且，新能力可以通过加Agent来实现，不用重训整个大模型。
再一个是并行效率。如果子任务之间没有依赖，可以同时跑，比如批量处理数据，用Map-Reduce的思路，总时间能降很多。还有容错，一个Agent挂了不影响全局，可以优雅降级。
但是，优势不是白来的，设计上有很多坑。先看任务拆解的粒度。拆得太粗，Agent还是太全能，优势不明显；拆得太细，通信开销可能比计算收益还大。我会按能力边界来拆，比如规划、执行、验证各一个，或者按数据分区拆，比如处理不同地区的订单。判断标准是：如果任务步骤超过三步，且步骤之间能力差异大，比如一个需要创意，一个需要精确计算，那就值得拆。
接着说通信机制。Agent之间怎么协作？简单场景用消息队列就行，一个发消息另一个收；如果需要共享状态，比如多个Agent都要看同一个订单信息，那就用集中式记忆池，大家读写同一个地方。复杂流程最好用工作流引擎编排，比如一个Agent做完，把结果传给下一个。这里有个坑：如果通信设计不好，很容易出现 循环依赖，A等B、B等A，最后死锁。所以一定要加超时熔断。
再补充调度。是中央调度器好还是去中心化好？我的经验是，强依赖的任务用Master-Worker，比如一个Agent负责规划，把子任务派给执行Agent；松散协作的场景，比如多个Agent各自处理不同数据最后合并，用P2P更灵活。
还有成本控制。不要所有任务都调同一个大模型。简单子任务用小模型，核心决策才用大模型，这样可以大幅降低成本。
举个具体例子：在电商客服退款场景里，一个Agent负责理解用户意图，一个Agent查订单状态，一个Agent判断退款规则，最后一个Agent生成回复。这几个Agent各司其职，意图理解用大模型，查订单用轻量模型，判断规则用规则引擎，回复生成用大模型。如果单Agent做，很容易在查订单时出错，或者规则判断不准确。
落地时我特别关注两点：一是 状态爆炸，共享上下文无边界，Token消耗失控。所以我会限定每个Agent的上下文窗口，定期清理历史。二是过度拆分，如果Agent之间通信频繁，反而比单Agent还慢。所以上线前我会做压力测试，比较单Agent和多Agent的延迟和准确率。
还有一个点值得深入：在需要严格一致性的场景，比如金融交易，多Agent怎么保证最终结果一致？我一般会定义统一的输出Schema，关键决策点设置投票机制或人工确认。
所以整体上，我更倾向于把多Agent看成一种架构模式，而不是银弹。如果任务简单，单Agent加工具调用更直接；只有任务复杂且能力差异大时，才值得拆。判断标准就是：拆了之后，通信和协调的成本不能超过并行和专业化带来的收益。