最近看 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 项目的最终形态。架构是否合适也不取决于图里有多少个圆圈而取决于每一次拆分有没有真正降低复杂度。