一个 Agent 不够用了：什么时候才真正需要 Multi-Agent？

多智能体（Multi-Agent）可以简单理解为“多个 Agent 分工协作”。比如，一个负责检索，一个负责分析，一个负责写作，再由另一个检查结果。

这种设计看起来合理，然而，在实际项目中，需要思考的问题并不是“能不能拆成多个 Agent”，而是“为什么一定要拆”。

如果单 Agent 已经能够稳定完成任务，继续增加 Agent 往往意味着更多模型调用、上下文传递、状态管理和协调工作。系统越复杂，调试和定位问题也越困难。

因此，要不要使用 Multi-Agent，不能只看任务复杂程度，还要看单 Agent 是否已经遇到了明确的能力边界。

本文先介绍模型、单 Agent 和 Multi-Agent 及它们之间的区别，再看实际项目中应该怎样选择 Workflow、单 Agent 以及 Multi-Agent。

大语言模型（LLM）接收输入并生成输出，对于翻译、摘要、回答问题等这些任务，通常一次调用即可完成任务。

Agent 则多了一层持续执行的过程。

它会根据当前任务判断下一步该做什么，需要外部信息时调用工具，再根据工具返回的结果继续执行、调整方案或结束任务。

例如，对于一个智能助理 Agent，用户问：

今天要处理的任务有哪些？

Agent 可以调用接口获取实时数据，再根据结果生成答案。

需要明确的是，一个系统使用了大模型，并不代表它就是 Agent。Agent 更重要的特点，是能够围绕目标完成推理、行动、沟通和调整。这四个动作的执行内容如下：

• 推理：判断下一步做什么；
• 行动：调用 API、执行代码、检索信息等工具；
• 沟通：接收任务、返回结果、补充信息；
• 调整：结果不符合预期时修改后续做法。

模型负责做判断，Agent 则把判断、工具调用和结果反馈连接成一个持续执行的过程。

一个常见的 Agent 通常包括三个部分：模型、工具和记忆。

模型（Model）负责理解任务和做决策。它根据目标、当前状态和历史信息，决定是否调用工具以及下一步怎么做。

工具（Tools）决定 Agent 实际能做什么，例如搜索网页、查询数据库、发送请求、运行代码。

记忆（Memory）保存后面还要使用的信息，包括当前对话、工具结果、任务进度，以及必要的历史信息。

三者组合起来，就形成了基本的 Agent 循环：

模型判断 → 调用工具 → 获取结果 → 更新状态 → 继续判断

因此，对单个 Agent 来说，只要 System Prompt 足够清晰明确，工具的数量与描述都恰到好处，它就已经能胜任不少复杂任务。

单 Agent 并非只适合简单任务。问题在于，任务一多，若都交给同一个 Agent，往往就会力不从心，预期结果不可控。

以技术研究报告为例，它可能需要完成：

• 搜索资料；
• 判断来源是否可信；
• 提取事实；
• 比较方案；
• 撰写正文；
• 检查引用。

如果全部交给同一个 Agent，它就要同时承担研究、分析、写作和审校等不同职责。

任务越来越多后，上下文也会越来越长。搜索结果、网页正文、分析笔记和草稿全部放在一起，真正与当前步骤有关的信息可能只占其中一部分。

另外，前面的错误还会继续向后传递。比如，研究阶段用了错误数据，后面的分析和写作可能依然十分流畅，只是结论已经建立在错误前提上。

当职责混杂、上下文过长和错误传播开始频繁出现，就应该考虑由单 Agent 拆分为多 Agent。

Multi-Agent 系统由多个职责不同的 Agent 共同完成任务。相比单 Agent，它主要增加了四个方面：专业化、通信、协调和控制流。

专业化（Specialization）指让不同 Agent 专门负责不同工作。

例如：

• 研究 Agent 负责搜索和整理资料；
• 写作 Agent 负责生成正文；
• 审校 Agent 负责检查事实和引用。

每个 Agent 只处理自己的任务，指令、工具和上下文都会更集中。

通信（Communication）解决 Agent 之间怎么传递信息。

研究 Agent 不必把完整搜索过程交给写作 Agent，只需要传递来源、关键事实、存在争议的内容和必要说明。

Agent 之间仅传递经过处理的结果，可以减少无关内容对后续任务的干扰。

协调（Coordination）解决多个 Agent 如何配合。

例如，写作需要等待研究完成；审校发现证据不足后，需要重新回到研究阶段；互不依赖的任务则可以并行执行。

如果没有恰当的协调，多个 Agent 则只是各做各的，并不能完成目标任务。

控制流（Control Flow）决定当前由谁执行、下一步交给谁，以及什么时候结束。

这些规则既可以由开发者提前写成 Workflow，也可以由一个调度者根据结果动态决定。

归根结底，一个设计良好的 Multi-Agent 系统，关键在于职责如何划分、信息如何传递、执行按什么顺序推进，以及失败之后怎么收场。

Multi-Agent 更适合下面几类特征同时存在的任务。

1. 任务能够清楚分工

每一部分都有相对明确的目标、输入和输出，并且能够说明彼此之间的关系。

如果任务本身都很难拆清楚，增加 Agent 通常也不会让问题变得更清晰。

2. 不同步骤需要不同能力

有些任务虽然属于同一个目标，但不同阶段需要的知识、工具和判断方式差别很大。

例如合规报告可能同时涉及数据处理、业务分析和法规检查，这时分工会更有价值。

3. 不同步骤需要不同上下文

如果任务涉及大量资料，但每一步只需要其中一部分，可以让不同 Agent 分别读取自己需要的信息。

这样既减少干扰，也能避免上下文越来越长。

4. 下一步需要根据结果决定

有些任务无法提前确定完整流程。

例如数据源不可用后切换来源，审校不通过后重新研究，都需要根据当前结果调整后续步骤。

这类任务更适合通过多个 Agent 配合完成。

模型调用、Workflow、单 Agent 和 Multi-Agent，根据自身的特点可以对应不同复杂度的任务场景。

如果整体流程明确清晰，部分步骤需要引入模型判断，可以使用 Workflow。

如果任务需要动态调用工具，但职责范围明确、有限，可以优先使用单 Agent。

只有当任务已经形成明显分工，并且单 Agent 出现了职责冲突、上下文过长或某些任务长期不稳定的问题时，Multi-Agent 才会更有意义与价值。

实际项目里，比较稳妥的做法是先实现一个简单版本。

如果调用模型能完成，就先用单模型；需要工具调用时，再做成单 Agent。

然后记录任务成功率、执行时间、Token 消耗、工具调用次数和人工介入情况。

有了这些数据，才能判断拆成多个 Agent 后是否真的有所改善。

如果某类特定任务长期表现不稳定，再考虑拆出独立 Agent。

如果问题主要来自上下文过长，则先优化信息筛选和传递方式。

拆分以后，每个 Agent 至少要明确：

• 负责什么；
• 可以使用什么工具；
• 接收什么输入；
• 返回什么结果；
• 什么情况下结束。

同时还要规定失败后是重试、返回上一步，还是交给人工处理。

如果这些规则都不清楚，增加 Agent 只会让问题更难追踪。

回到开头的问题：什么时候可以说“一个 Agent 不够用了”？

可以重点看几个方面：

任务能否清楚分工？

不同部分是否需要明显不同的知识、工具或指令？

每一步需要的信息是否不同？

后续步骤是否经常需要根据前面的结果重新决定？

如果这些问题越来越明显，并且单 Agent 已经因此出现稳定性、上下文或维护上的问题，Multi-Agent 才可能会有实际价值。

Multi-Agent 的价值主要来自三个方面：分工、隔离和协作。

不同 Agent 分别处理自己的任务，只读取当前需要的信息，再通过通信和调度把结果连接起来。

当然，这种设计也有成本。Agent 越多，调用越多，信息传递越多，需要维护的状态也越多。

因此，只有当单 Agent 已经暴露出明确问题，而这些问题确实能够通过分工、上下文隔离和协作来改善时，Multi-Agent 才真正值得引入。