从单 Agent 到 Multi-Agent 系统

发表于 分类于 Waline： 本文字数： 4.9k 阅读时长 ≈ 18 分钟

1. 单 Agent 的能力边界

在 LLM 应用发展的早期阶段，一个 Agent 往往就能完成大部分任务。最常见的结构，用户问题 → Agent → Tool → 最终答案。

Agent 负责理解需求、规划步骤、调用工具，并最终组织回复。在工具数量较少、业务范围单一时，这种结构简单直接，开发成本也比较低。例如一个旅游助手，最初可能只需要查询景点、查询路线、查询交通和查询天气，一个 Agent 配合几个 Tool 就足以覆盖大部分需求。

1.1 工具规模扩张带来的决策复杂度

随着业务不断扩展，旅游助手可能继续增加查询酒店、查询民宿、查询餐厅、查询航班、生成行程等能力。对应的 Tool 数量也会不断增加。

此时 Agent 每次接收到请求，都需要在越来越多的工具之间做决策：

1
问题 → 选择 Tool → 调用 Tool → 判断是否继续调用 Tool → 生成答案

从架构角度看，Agent 仍然只有一个，但内部复杂度已经开始快速增长。首先是 Prompt 变得越来越长。为了让 Agent 正确使用工具，通常需要向模型说明每个 Tool 的用途、输入参数、调用条件和返回结果。当 Tool 达到十几个甚至几十个时，仅工具描述就会占据大量上下文窗口。

其次是决策成本不断增加。Agent 不仅需要理解用户问题，还要判断该调用哪个 Tool、是否需要多个 Tool，以及多个 Tool 之间的调用顺序。随着可选工具增加，模型做出正确决策的难度也会越来越高。

1.2 单 Agent 架构的职责边界

更大的问题并不是 Tool 数量本身，而是业务领域开始混杂。以旅游场景为例，查询景点属于旅游知识领域，查询酒店属于住宿领域，查询航班属于交通领域，推荐餐厅又属于本地生活领域。

这些能力之间虽然存在关联，但背后的知识体系、数据来源和工具完全不同。如果全部塞进同一个 Agent，会逐渐形成一个“万能 Agent”。这种 Agent 看似能力很强，实际上会带来两个问题：

  • 维护困难：任何新增能力都需要修改原有 Prompt 和 Tool 配置。
  • 专业性下降：模型需要同时理解多个领域的规则，更容易出现判断失误。例如本应查询酒店库存，却错误调用了旅游信息工具；本应查询机票，却走到了天气查询流程。

这种问题本质上并不是模型能力不足，而是系统职责划分不清晰。

1.3 从工具管理到能力拆分

传统开发中有一个基本原则：一个模块只负责一类事情。Agent 系统同样适用这一原则。当业务复杂度持续上升时，更合理的做法不是继续扩充单个 Agent，而是拆分能力边界。

例如，可以把旅游助手拆分为几个职责明确的专业 Agent：

Agent 职责
Travel Agent 负责旅游信息
Accommodation Agent 负责住宿信息
Flight Agent 负责航班信息
Restaurant Agent 负责餐饮推荐

每个 Agent 都拥有自己的 Prompt、知识范围和 Tool 集合。此时系统关注点从“如何给 Agent 增加更多 Tool”，转向“如何把复杂能力拆分成多个专业 Agent”。

进入 Multi-Agent 阶段后，核心问题也随之变化：当系统中存在多个专业 Agent 时，任务应该交给谁？如果一个任务需要多个 Agent 共同参与，它们又应该如何协同工作？

2. 专业 Agent 的能力拆分

Multi-Agent 的第一步不是协作，而是分工。只有先明确谁负责什么、谁拥有哪些 Tool、谁解决哪类问题，后续的协作才有意义。

2.1 基于业务边界的能力划分

在传统软件架构中，经常会按照业务领域划分模块。例如电商系统通常会拆成商品、订单、支付、物流等模块，每个模块都有自己的职责范围。Agent 系统也可以采用类似思路。

以旅行助手为例，原来的单 Agent 同时负责景点查询、路线规划、天气查询、酒店预订和民宿查询。现在可以拆分为两个专业 Agent：

  • Travel Agent：负责旅游相关信息，如景点、路线、天气。
  • Accommodation Agent：负责住宿相关信息，如酒店、民宿、房态、价格。

这种拆分并没有减少系统能力，只是把原来集中在一个 Agent 身上的职责，分散到多个专业 Agent 身上。

2.2 专业 Agent 的工具集合管理

拆分 Agent 之后，Tool 也会跟着拆分。例如 Travel Agent 维护景点搜索、天气查询、路线规划等工具；Accommodation Agent 维护酒店数据库、民宿查询 API、房态查询等工具。

整体结构变成：

1
2
Travel Agent → Travel Tools
Accommodation Agent → Accommodation Tools

此时每个 Agent 只需要了解自己的工具。Travel Agent 不需要知道酒店数据库如何工作，Accommodation Agent 也不需要关心天气接口。相比单 Agent 管理所有 Tool，这种方式的职责边界更加清晰。

2.3 外部能力的工具化封装

无论底层是数据库、API、搜索引擎还是文件系统，对 Agent 来说都应该表现为统一的 Tool。

例如住宿 Agent 可以通过工具层访问酒店数据库。数据库中保存酒店名称、房型、价格、库存状态等信息，但 Agent 并不会直接操作数据库。结构如下：

1
Database → Tool → Agent

Agent 只需要知道“查询酒店”和“返回结果”，不需要知道底层是 SQL、SQLite 还是其他数据库。

外部服务也是一样。例如民宿预订服务本质上可能是 REST API，需要处理 HTTP 请求、JSON 解析和异常情况。但对 Agent 来说，check_bnb_availability() 只是一个普通 Tool。这就是 Tool Calling 的重要价值：屏蔽底层系统差异，让 Agent 可以使用统一方式访问各种外部能力。

3. Router Pattern：多 Agent 的任务分流机制

当系统中只有一个 Agent 时，不存在任务分配问题，所有请求都会进入同一个 Agent。但当系统被拆分成多个专业 Agent 后，一个新问题出现了：

1
用户问题 → 应该交给谁处理？

Router Pattern 正是为了解决这个问题而出现的。

3.1 Router 的任务分流职责

Router 可以理解为整个系统的入口。用户不会直接和 Travel Agent 或 Accommodation Agent 对话，而是先把请求发送给 Router。Router 根据问题内容判断它属于哪个领域、需要哪个 Agent，然后将请求转发给对应 Agent。

整体结构如下：

1
User → Router → Specialized Agent → Answer

例如用户问：

1
苏州有哪些值得去的景点？

Router 会判断这是旅游领域，随后转发给 Travel Agent。

如果用户问：

1
本周末还有哪些酒店空房？

Router 会判断这是住宿领域，随后转发给 Accommodation Agent。这个过程与传统系统中的请求路由非常相似。区别只是过去路由的是服务，现在路由的是 Agent。

3.2 基于 LLM 的路由决策

Router 可以用规则实现，例如通过关键词判断是否包含“酒店”“景点”“航班”等词。但随着 Travel Agent、Booking Agent、Flight Agent、Weather Agent、Restaurant Agent 等 Agent 数量增加，规则会迅速变得复杂。

因此实际项目中，Router 往往也是一个 Agent。它利用大模型理解用户意图，然后完成路由决策：

1
用户问题 → Router Agent → 选择目标 Agent

此时 Router 不再依赖硬编码规则，而是依赖模型推理能力。

3.3 Router Pattern 的适用边界

Router 解决的是“任务应该交给谁”的问题，但它没有解决“多个 Agent 如何一起完成任务”的问题。

例如下面这个请求：

1
推荐一个适合周末度假的海边小镇，并查询当地双人房价格。

这个问题同时包含旅游信息和住宿信息。按照 Router 的工作方式，它通常只能选择一个 Agent 执行。如果交给 Travel Agent，它能找到旅游地点，却无法查询住宿；如果交给 Accommodation Agent，它能查询住宿，却无法推荐景点。

所以 Router 适合任务归属明确的场景，但不适合需要多个 Agent 共同完成的复合任务。这也是 Supervisor Pattern 出现的原因。

4. Supervisor Pattern：从分流到协作

Router Pattern 解决了任务分流问题，但现实中的用户需求很少严格属于某一个领域。例如：

1
2
推荐一个适合周末度假的海边小镇，
顺便查询当地双人房价格和空房情况。

这个问题实际上包含多个子任务：

1
寻找旅游目的地 → 查询天气情况 → 查询住宿价格 → 查询房间库存 → 生成推荐方案

其中旅游信息可以交给 Travel Agent，住宿信息可以交给 Accommodation Agent。此时 Router 遇到的根本限制是：它只能选择 Agent，却无法协调 Agent。

4.1 Supervisor 的协调职责

Supervisor 并不负责具体业务。它更像整个系统的调度中心，主要职责包括理解需求、拆解任务、选择 Agent、组织执行顺序，以及整合执行结果。

整体结构变成：

1
2
3
        ↗ Travel Agent
Supervisor
        ↘ Booking Agent

此时用户面对的不再是 Router，而是 Supervisor。

4.2 从任务分流到任务编排

Router 与 Supervisor 最本质的区别，在于是否具备任务编排能力。

1
2
Router：判断 → 转发 → 结束
Supervisor：分析任务 → 拆分任务 → 调用 Agent → 获取结果 → 继续调用 Agent → 整合答案

例如用户请求：

1
推荐一个适合周末度假的海边小镇，并查询当地酒店价格。

Supervisor 可能会按“调用 Travel Agent → 获取推荐地点 → 调用 Accommodation Agent → 查询住宿价格 → 汇总结果”的顺序规划。整个过程已经具备工作流特征。

4.3 Supervisor 作为上层调度者

在单 Agent 阶段，系统抽象层级是：

1
Agent → Tool → External System

进入 Supervisor 阶段后，结构变成：

1
Supervisor → Agent → Tool → External System

此时 Supervisor 不再直接管理 Tool，而是管理 Agent。换句话说，Agent 本身开始成为一种更高级别的能力单元。对于 Supervisor 来说，Travel Agent 已经是一个完整能力。它不需要知道 Travel Agent 内部用了哪些 Tool、调用了多少次 Tool、如何完成任务，只需要知道这个 Agent 能解决什么问题，以及调用后会返回什么结果。

因此很多框架会把 Supervisor 称为 Agent of Agents，也就是“管理 Agent 的 Agent”。

4.4 分层调度结构的扩展性

如果继续沿用单 Agent 思路，未来新增航班查询、餐厅推荐、签证信息、当地活动等能力时，都必须塞进同一个 Agent。最终形成：

1
一个 Agent + 几十个 Tool + 大量 Prompt

而在 Supervisor 架构下，新增能力通常只需要增加新的 Agent，例如 Flight Agent、Restaurant Agent、Visa Agent，再挂到 Supervisor 下面。原有 Agent 不需要大幅修改。

这就是 Multi-Agent 最大的工程价值之一：

新增能力变成增加模块，而不是修改模块。

4.5 Supervisor 对模型能力的要求

Router 的工作相对简单，本质上是“这个问题属于哪个 Agent”的分类问题。Supervisor 面对的是规划问题，需要完成“理解需求 → 拆分任务 → 确定执行顺序 → 选择 Agent → 整合结果”。

例如用户请求：

1
2
推荐一个适合周末度假的海边城市，
并查询当地酒店价格和天气情况。

Supervisor 需要推理出：

1
先查询旅游地点 → 获取目的地 → 查询天气 → 查询酒店 → 生成最终建议

这种推理过程明显比 Router 更复杂。因此在实际项目中，Router 可以使用较轻量模型，Supervisor 通常需要能力更强的模型。

5. Multi-Agent 协作流程示例

理解 Supervisor 最好的方式，不是继续看概念，而是看一次任务如何在多个 Agent 之间流转。

5.1 任务理解与拆解

假设收到这样一个请求：

1
2
推荐一个适合周末度假的海边小镇，
并查询当地双人房价格和空房情况。

Supervisor 首先不会直接调用工具，而是先完成任务分析：寻找旅游目的地、查询当地天气、查询住宿价格、查询房间库存，并整合最终方案。

5.2 Travel Agent 处理旅游信息

任务拆分完成后，Supervisor 会发现寻找目的地和查询天气属于旅游领域，于是调用 Travel Agent。Travel Agent 收到任务后，使用自己的 Search Tool、Weather Tool、Route Tool 等工具完成查询。

执行过程可以概括为：

1
Travel Agent → 查询海边小镇 → 获取候选地点 → 查询天气 → 返回结果

最终返回：

1
2
3
4
{
  "location": "St Ives",
  "weather": "Sunny"
}

随后任务重新回到 Supervisor。

5.3 Accommodation Agent 处理住宿信息

获得旅游地点之后，Supervisor 发现下一步需要查询酒店、价格和库存，于是调用 Accommodation Agent。Accommodation Agent 内部可以使用 Hotel Database Tool 和 BnB API Tool。

执行过程如下：

1
Accommodation Agent → 查询 St Ives 酒店 → 获取房型 → 获取价格 → 获取库存

最终返回：

1
2
3
4
5
{
  "hotel": "Harbour Hotel",
  "price": 180,
  "available": true
}

然后再次回到 Supervisor。

5.4 结果整合与最终回答

当所有 Agent 完成任务后，Supervisor 已经获得了旅游结果和住宿结果。此时进入最后一步：结果整合。

最终回复可能是：

1
2
推荐前往 St Ives。未来几天天气晴朗。
Harbour Hotel 当前有双人房，价格约 180 英镑每晚。

从用户角度看，似乎只进行了一次对话。但系统内部已经经历了多次任务分发与结果汇总：

1
User → Supervisor → Travel Agent → Supervisor → Accommodation Agent → Supervisor → Final Answer

这就是 Router 与 Supervisor 的关键区别。Router 选择一次、执行一次、结束；Supervisor 则会经历规划、执行、再规划、再执行、整合和输出，因此具备多轮调度能力。

5.5 Agent 间的低耦合关系

在这个过程中，Travel Agent 并不知道 Accommodation Agent 的存在。Accommodation Agent 也不知道 Travel Agent 的存在。它们只接收任务、执行任务、返回结果。

整个协作过程由 Supervisor 统一管理，这样可以避免 Agent 之间形成复杂依赖。否则系统很容易演变成：

1
Agent A → Agent B → Agent C → Agent A

最终变成难以维护的网状结构。因此在 Supervisor 模式中，Agent 负责执行，Supervisor 负责协调。

6. Multi-Agent 架构设计原则

Multi-Agent 的价值不在于 Agent 数量，而在于系统能否通过合理分工与统一调度处理复杂任务。设计时需要特别注意以下几点。

6.1 Agent 职责的单一性

Agent 的职责必须足够清晰。Travel Agent 负责旅游信息，Accommodation Agent 负责住宿信息，这样的边界比较稳定。

相反，如果 Travel Agent 同时负责旅游和酒店，Booking Agent 又同时负责酒店和机票，Assistant Agent 还负责所有事情，职责就会高度重叠。此时 Supervisor 很难判断到底应该调用谁，路由错误率也会随之上升。

一个简单原则是：每个 Agent 都应该有明确且稳定的职责边界。

6.2 Agent 能力描述的明确性

Supervisor 负责调度 Agent，前提是它了解每个 Agent 的能力。这些描述信息通常会写入 Supervisor 的 Prompt，本质上类似于 Tool Description。

在 Tool Calling 中，Tool Description 告诉模型 Tool 的用途；在 Multi-Agent 中，Agent Description 告诉 Supervisor Agent 的用途。

如果描述不清晰，Supervisor 很容易出现错误判断。例如酒店问题被转给 Travel Agent，或者景点问题被转给 Accommodation Agent。因此 Agent 描述本身也是 Prompt 工程的重要组成部分。

6.3 结构化数据优先原则

Agent 之间的信息传递，本质上属于系统内部通信。这时自然语言并不是最佳选择。

例如下面这种表达，人容易理解，但另一个 Agent 处理起来并不方便：

1
2
3
我找到一个天气不错的小镇，
名字叫 St Ives，
未来三天天气晴朗。

更合理的方式是传递结构化数据：

1
2
3
4
{
  "location": "St Ives",
  "weather": "Sunny"
}

结构化数据更容易解析、校验、扩展和追踪。尤其是在 Agent 数量增加之后，结构化数据的重要性会越来越明显。

6.4 控制 Agent 数量与系统复杂度

刚接触 Multi-Agent 时，经常会产生一种误解：Agent 越多，能力越强。实际上并非如此。每增加一个 Agent，系统都会增加新的 Prompt、维护成本、调度成本和上下文开销。

如果一个能力只是简单查询，例如天气查询、汇率查询、时间查询，通常更适合作为 Tool，而不是独立 Agent。只有当一个能力需要独立决策、独立知识和独立工作流时，才值得升级为 Agent。

6.5 系统可观测性

单 Agent 调试已经不容易，Multi-Agent 会进一步放大问题。例如：

  • 为什么调用了这个 Agent？
  • 为什么没有调用另一个 Agent？
  • 为什么执行时间变长？
  • 为什么结果错误？

如果没有完整执行链路，这些问题几乎无法排查。因此在 Multi-Agent 系统中，可观测性非常重要。通过执行轨迹可以清晰看到：

1
用户问题 → Supervisor → Travel Agent → Accommodation Agent → 最终答案

这样才能快速定位问题到底发生在 Router、Supervisor、某个 Agent，还是某个 Tool。

7. 小结

从单 Agent 到 Multi-Agent，本质上不是为了增加 Agent 数量，而是为了管理不断上升的复杂度。

最开始，大模型只能直接回答问题；Tool Calling 让模型可以访问外部能力；ReAct Agent 让模型可以在 Reason、Act、Observe 之间循环，形成动态决策；当工具和业务领域继续增加，单 Agent 开始变得臃肿，于是系统拆出多个专业 Agent。

Router Pattern 解决“请求应该交给谁”的问题：

1
User → Router → One Agent

Supervisor Pattern 解决“多个 Agent 如何协作”的问题：

1
User → Supervisor → Multiple Agents → Final Answer

整个演进过程可以概括为：

1
Tool Calling → ReAct Agent → Router Pattern → Supervisor Pattern → Multi-Agent System

Multi-Agent 的核心价值不在于拥有更多 Agent，而在于通过职责拆分、能力封装和统一调度，让复杂任务能够被稳定地分解、执行和管理。

需要注意的是，无论是单 Agent 还是 Multi-Agent，底层依然依赖大模型推理，因此仍然可能出现幻觉、错误规划或工具误调用等问题。尤其在涉及真实业务场景时，看起来真实的内容并不等于真实存在的事实，关键数据仍然需要依赖数据库、API 或人工校验进行验证。

从工程实践角度看，Multi-Agent 并不是终点，而是 Agent 系统从单体结构走向模块化、组织化的重要一步。