最近看 Agent 项目时，经常能看到一种很自然的设计：一个 Agent 负责理解需求，一个负责规划，一个负责查知识库，还有一个负责调用工具。看起来分工明确，也很像一个真正的团队。

我之前做 Agent Workflow 时，也有过类似的想法。功能越来越多以后，总觉得把每件事交给一个专门的 Agent，结构会更“高级”。但真正开始梳理调用链后，我发现很多任务其实没有复杂到需要多个 Agent。

例如一个常见的企业助手请求：用户问某项制度，系统先从知识库检索；如果用户还要求提交申请，再调用对应工具。这个过程用一个 Agent 加一条明确的工作流就能完成：识别意图、检索信息、补全参数、调用工具、返回结果。

如果硬拆成多个 Agent，事情反而会变麻烦。

检索 Agent 找到的内容，要以什么格式交给执行 Agent？规划 Agent 判断错了，后面的 Agent 是照着执行，还是重新判断？一个 Agent 已经理解过的用户意图，传到下一个 Agent 时还要不要连同对话历史一起发送？

这些问题并不是不能解决，只是每增加一次 Agent 之间的交接，就增加了一次信息丢失、理解偏差和重复消耗 Token 的机会。

我现在更愿意先区分两个概念：能力变多，不等于必须增加 Agent。

知识库检索、工具调用、会话记忆和结果校验，可以是同一个 Agent 使用的不同能力。只要任务目标仍然统一、执行过程比较固定，就没必要为了“分工”而分工。很多时候，一个 Agent 配合清晰的状态机或工作流，比多个 Agent 自由协作更容易理解，也更容易排查问题。

当然，多 Agent 并不是没有价值。下面几种情况，我觉得拆分才比较合理：

• 子任务确实需要明显不同的角色、工具或上下文；

• 多个子任务可以并行执行，拆分后能缩短整体耗时；

• 某个 Agent 的输出可以被独立验证，而不是只能相信它；

• 单个 Agent 的工具和规则已经多到难以稳定选择；

• 不同子任务需要隔离权限，例如只读查询与高风险写操作。

这里有一个很实用的判断方法：如果把某个子 Agent 换成一个普通函数、工具节点或固定流程，系统仍然能完成任务，那它可能就不需要成为 Agent。

Agent 更适合处理需要判断、规划和动态决策的部分。确定性的事情，交给确定性的代码通常更稳。

现在设计 Agent 系统时，我不会先问“应该拆成几个 Agent”，而会先问：任务中到底有几个相对独立、必须自主决策的问题？

如果答案只有一个，那先把单 Agent 做稳定，往往比一开始搭一个多 Agent 团队更实际。

多 Agent 是解决复杂问题的一种手段，不是 Agent 项目的最终形态。架构是否合适，也不取决于图里有多少个圆圈，而取决于每一次拆分有没有真正降低复杂度。