为何拆解任务给多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起步，遇到上下文瓶颈或质量瓶颈时，再按职责拆解。而且不一定所有子任务都用大模型，简单任务可以用小模型甚至规则，这样能省成本。