聊聊 Agent 架构 – Single Agent / MCP / Multi-Agent

2025-3-16

近期在业务中尝试落地 Agent，有一个架构设计问题，应该用单 Agent 架构，还是多 Agent 架构？

Single Agent

先来看看单 Agent 架构，在之前的文章里，OpenHands 这里的架构是典型的单 Agent 架构，依赖一个模型，组织多个工具调用，做好 ReAct 和上下文管理，整个过程很简单。

  1. Tools 是一个个函数，定义和调用都是在当前程序里进行。Tools的函数定义会作为 System Prompt 的一部分让 LLM 理解当前可用工具
  2. Memory 分两部分：
    1. 当前 Session 数据流，包括每一步执行了什么，结果是什么，在当前 Session 内存中保存，随时全量输入 LLM，让 LLM 判断下一步应该做什么。
    2. 用户的长期数据、知识库，例如用户在平台的偏好数据、领域内容、多轮对话上下文等，这些内容会从向量数据库召回。
  3. Router 中心化程序调度整个过程，拿用户 Prompt / System Prompt / Memory 输入 LLM，LLM 进行深度思考和给出具体执行的任务，Router 去调用对应的 Action 函数。

这是简单通用的单 Agent 架构，实现 Agent 中 Thought – Plan – Action – Reflection(Thought) 的循环，一个模型负责所有事情。

MCP

上述架构里，Tools 模块有一些小问题：工具函数可维护性和可扩展性不太好，多了后难管理，要加函数得更新主程序，另外得自己定义一个 Function call 规范，对外部的一些会用到的工具服务都需要自己封装一遍。

对这些小问题，这个架构可以有一个优化：Tool 模块从 Agent 剥离出来，用 MCP 协议统一管理和实现。

附：MCP是什么？

MCP 是 Anthropic 24年11月推出的协议，近期 Cursor / windsurf / cline 等一众 AI Coding 产品支持了 MCP 后出圈，众多开源框架也开始支持 MCP，大有统一的趋势。

MCP 的概念很简单，就是统一了工具调用的接口规范，这几张图可以帮助理解：

  1. MCP 统一了各工具能力接入的接口调用定义，原先一个服务(例如slack）要对接多个用户端产品（例如cursor）定义的 Function call 格式，现在服务和客户端统一对接同一种格式就行，两边都只需要实现一次。
  1. MCP Server 独立运行在任意服务器上，也可以有自己独立的数据库信息/资源，不与 Agent 服务器绑定，可复用、易于插拔。

把原先 Tool 几个工具函数调用用 MCP Server 封装，架构变成这样：

跟原先纯 Function call 的区别在于架构上更灵活，包括：

  1. 聚类，对零散的一个个函数可以统一放到一个服务，便于管理。
  2. 解耦：调用实际发生在各自 MCP 服务端，而不是 Agent 服务直接去调用，部署扩展工具与 Agent 工程上解耦。
  3. 内聚：MCP Server 本身可以内聚做一些事，包括独立的资源管理、独立上下文等。
  4. 复用：通用协议，Tool 能力便于在多个 Agent 间接入复用，外部生态有较多现成 MCP Server 可直接接入。
  5. 统一：客户端、云端的工具调用，都可以用统一的 MCP 协议去实现。

这个架构似乎已经可以满足大部分场景下对 Agent 的诉求，为什么还需要考虑 Multi-Agent？

Multi-Agent

考虑 Multi-Agent 最主要的问题是上下文过长。

如果一个 Agent 能力足够强，它应该能完成需要非常多轮调用完成各种任务，这些任务的制定和执行结果全部塞在一个上下文里，可能会超出当前模型能理解和处理的范围。

这时候，计算机工程的典型解决思路就是：分治模块化。把整体 Agent 能力拆分成解决一个个独立复杂任务的子 Agent，让这些 Agent 在它的范围内能有自主思考和自主行动能力。

从 Agent 的组成来说，必不可少的部分包括：

  1. 模型：独立的处理模型，可以跟其他 Agent 不同，称为专家模型。也可以相同，看需要。
  2. 上下文：独立的多轮 ReAct Loop 上下文管理，完成自己特定的任务
  3. System Prompt：对应任务制定特定的 System Prompt

而 Tools 可以不是 Agent 专用的，这个 Agent 需要什么 Tools，就注册什么 Tools。长时记忆/知识库也可以是多个 Agent 共用的。

架构会变成这样：

这样 Plan Agent 只专门制定计划，它需要知道的上下文是其他几个 Agent 能完成什么大的任务，至于他们调了什么工具怎么完成不用管，只需管它要结果，整个任务的上下文就被分出多个部分，每个 Agent 的上下文对另一个 Agent 可以是黑盒。每个 Agent 也可以有自己对应的模型，做独立的训练和 Prompt 调优。

这样是不是一个更优的架构？

  1. 它的好处是解决了上下文过长，模型处理不好的问题。
  2. 但坏处也是很明显：整个架构是复杂化了，而效果也不一定好。多个 Agent 需要协同，Plan Agent 能获取的上下文信息变少了，它没有了更细粒度统筹规划整个任务的能力，变成一个偏项目管理的角色协调各方的工作，多人协作带来信息熵增大，组织效率低。

AI 的范式，可能不应该这样分治，可能大模型在对上下文的支持、细节信息的理解上会越来越好，能统筹把握好各项细节，把一个复杂任务完成，而不是像人类社会一样分工协作。这样对大模型来说，有足够的信息量能做规划/决策/反思，也更便于端到端的模型训练。

从号称泄漏的 Manus Prompt 来看，Manus 也没有 Multi Agent，所有能力包括工具函数都在一个上下文中定义，看起来目前也能跑得起足够复杂的任务。

所以如果项目在早期，没有遇到很明显的瓶颈，并不需要用 Multi-Agent 架构，用 Single Agent 简单的架构足够能做好。工程架构越简单，后续基础模型升级带来的增益越大。

基于 MCP 的(伪)Multi-Agent

再探讨下，如果在应用过程中已经发现上下文处理不过来的问题，或者某个任务的内部实现细节对整个任务无影响，或者三方都实现好了，那采用另一种伪 Multi-Agent 架构，也是可以考虑的方案：

例如对接 browser-base 实现更深度的 research 能力，需要多轮打开不同网页、判断资料收集是否完成、整理资料，有自己的 loop 、上下文和模型。但这个完全可以封装在一个 MCP 服务上，自行闭环完成多网页搜索和整理，不需要与原 Agent 流程上有更深入的交互。

跟上面的 Multi-Agent 架构的区别在于，并没有改变原来单 Agent 架构，不会增加架构复杂度。Agent 不需要感知 MCP 调用背后是 Agent 还是一个普通的函数调用，没有区别。

MCP 协议本身也是 SSE 流式输出，对这个背后是 Agent 的 MCP 调用，要输出多少上下文信息给原 Agent，也是可以非常方便地调控。

以上是近期的一些想法，Agent 是新东西，后续实践有认知的更新再分享。

分类:技术文章 Tags:
评论