面试题 · Agent
搜索「提示工程」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请解释在构建AI Agent系统时，为什么要将复杂任务拆解为多个协作Agent，而不是使用单一Agent？这种设计有什么优势和考量？
1. 能力边界与上下文限制
2. 专业化分工的必要性
复杂任务 → 拆解为子任务 → 专用Agent处理
例如：代码Agent → 只负责生成；Review Agent → 只负责检查；Test Agent → 只负责验证| 维度 |
|---|
学习内容与项目面试，在同一条路上。
| 单一Agent |
|---|
| 多Agent协作 |
|---|
| 质量 | 泛而不精 | 每个Agent深耕特定领域 |
| 可维护 | 牵一发而动全身 | 独立迭代，不影响全局 |
| 容错 | 单点失败全崩 | 故障隔离，可降级重试 |
| 效率 | 串行执行 | 子任务可并行 |
| 成本 | 全程调用大模型 | 小模型处理简单子任务 |
粒度权衡
典型模式
落地经验
场景切入
假设我们做一个智能客服系统，要同时处理咨询、退换货、投诉。你觉着用一个全能Agent好，还是拆成几个专门Agent各管一摊？比如一个只处理退货，一个只处理投诉。
层层追问
你做过AI Agent吧？复杂任务你怎么设计的？……如果只用单一Agent，会遇到什么问题？……那你觉得拆成多个协作Agent，优势在哪里？主要考量什么？
直球架构
解释一下在构建AI Agent系统时，为什么要把复杂任务拆解成多个协作Agent，而不是用一个单一Agent？从优势、瓶颈和设计考量几个方面说说。
这道题其实在问一个本质矛盾：当任务变得足够复杂时，单一[[Agent]]的能力边界在哪里，以及我们怎么用架构去突破这个边界。我的理解是，这不仅仅是“拆开更好”的问题，而是复杂任务天然就需要专业化分工，就像一个大项目你不会让一个人做所有事一样。
先说单一Agent的瓶颈。最直观的问题是上下文窗口爆炸。想象一下，一个Agent既要理解用户意图，又要调用多个工具，还要跟踪长链推理，很快它的上下文就会被各种中间结果填满，关键信息被淹没，决策质量直线下降。我在处理一些需要多步推理的任务时，比如写一个复杂的SQL查询，如果让一个Agent从头干到尾，它常常在中间步骤就忘记前面的约束条件。这其实就是[[ReAct]]模式的典型局限：工具调用越多，决策越不稳定。
所以多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不是银弹，它解决的是单一Agent的能力边界问题，但引入了新的复杂度。落地时我会优先保证职责清晰、监控到位，再逐步优化协作效率。