多 Agent 系统的三个隐形工程问题，以及一个基于 MCP 的解法

一、从一个真实场景说起

假设你在构建一个通用 AI 助理，它需要覆盖外卖点餐、日历管理、邮件处理、数据查询四个领域。

你打开代码，开始注册工具：外卖域 10 个、日历 8 个、邮件 12 个、数据查询 15 个，加上每个域的 prompt 和 skill 文件……

第一周还好。第二周新增一个电商域，你开始在代码库里找该改哪几个文件。第三周有人反馈 Agent 回答质量下降，你意识到上下文里塞了 4 万 token 的工具定义。第四周安全团队告诉你，有几个从网上下载的 skill 文件行为可疑。

这不是极端案例。这是多 Agent 系统规模稍大之后的常态。

二、三个被低估的工程问题

问题 1：工具上下文膨胀

多工具 Agent 系统最直接的问题：所有域的工具定义被一次性注入主 Agent 的上下文。

每个 tool 定义通常消耗数百 token。50 个工具轻松吃掉 3-5 万 token，而用户的实际请求可能只涉及其中 1 个域的 8 个工具。大量无关工具定义占据上下文，推理质量下降，成本上升，这两件事同时发生。

用户："帮我点个午饭"

主 Agent 的上下文：
- 外卖工具 ×10
- 日历工具 ×8       ← 完全无关
- 邮件工具 ×12      ← 完全无关
- 数据查询工具 ×15  ← 完全无关
= 45 个工具定义，实际用到 10 个

这个问题在 Anthropic 的 Claude Code 开源社区 issue #4476 中有 182 个 upvote，有用户反馈单次对话 MCP 工具定义就消耗了 4 万 token，强需求，官方尚未解决。

问题 2：Agent 定义碎片化，业务方无法主动提供标准化能力

创建一个领域 Agent，通常需要准备三类内容：

Prompt：角色定义和行为规范
Tools：可调用的接口能力
Skills：领域知识、操作指南、业务规则

在现有框架下，这三类内容分散在代码库各处——prompt 在某个字符串变量里，tools 在另一个注册文件里，skill 文件在某个目录下。用户需要自己组装，业务方想主动提供完整的 Agent 能力包，几乎没有标准化的方式。

更麻烦的是：每次接入新领域，都需要修改框架代码，重新注册工具，更新 prompt，调整路由逻辑。

如果麦当劳想为开发者提供一个"标准麦当劳 Agent"——包含它自己维护的点餐流程、菜单查询逻辑、优惠券规则——现在没有一个通用的方式让它发布这个能力，让任何 Agent 框架开箱接入。

问题 3：Skills 来源混乱，安全性和业务适配性难以保证

随着 Agent Skill 生态的兴起（OpenClaw 的社区 skill 市场已有 5700+ 插件），开发者面临新的问题：从哪里获取 skill，质量和安全性如何保证？

Cisco AI 安全研究团队近期测试了一个第三方 OpenClaw skill，发现其在用户无感知的情况下执行了数据外泄和 prompt 注入。skill 仓库缺乏有效审核机制，恶意 skill 可以伪装成普通功能。

更实际的问题是业务适配性：从社区下载的通用 skill 往往和具体业务的逻辑、术语、数据格式不匹配，开发者需要二次修改，反而增加维护成本。

三、一个洞察：MCP Server 本身就是完整的 Agent 定义

解决以上三个问题，我们需要重新看待 MCP（Model Context Protocol）。

一个 MCP Server 天然包含三类信息：

MCP 能力	Agent 角色
Prompts	定义 Agent 的角色和行为规范
Resources	提供领域知识和 Skills
Tools	暴露可执行的接口能力

这意味着，一个 MCP Server 本身就是一个完整的领域 Agent 定义。

IBM 在《MCP Architecture Patterns for Multi-Agent AI Systems》中明确写道："each MCP server acts as one AI agent"。MCP 2025-11 规范新增的 Sampling with Tools (SEP-1577) 也在协议层面支持了 MCP Server 作为 Agent 执行 multi-step 推理的能力。

这个洞察，直接给出了一种新的 multi-agent 构建方式：MCP 地址即 Agent，配置即接入。

四、解法：MCP Server as Agent

基于上述洞察，我设计了 MCP Server as Agent，核心是一个通用 Plugin 层，动态将 MCP Server 实例化为域 Agent。

架构

┌──────────────────────────────────────┐
│  配置层                               │
│  [MCP-A地址, MCP-B地址, ...]         │
└────────────────┬─────────────────────┘
                 │ 启动时读取各域能力摘要
                 ▼
┌──────────────────────────────────────┐
│  主 Agent                             │
│  · 意图识别                           │
│  · 多域任务编排                       │
└────────────────┬─────────────────────┘
                 │ 识别到目标域
                 ▼
┌──────────────────────────────────────┐
│  Plugin（子 Agent 工厂）              │
│  MCPLoader → ResourcesParser → 实例化 │
└────────────────┬─────────────────────┘
                 ▼
┌──────────────────────────────────────┐
│  子 Agent（上下文完全隔离）           │
│  prompt:  来自该 MCP 的 Prompts      │
│  skills:  来自该 MCP 的 Resources    │
│  tools:   仅含该 MCP 的 Tools        │
└──────────────────────────────────────┘

接入新领域，只需一行配置：

mcp_servers:
  - name: food
    url: https://mcp.mcdonalds.cn
  - name: calendar
    url: https://mcp.calendar-service.com
  - name: new_domain      # ← 新增领域，仅此两行
    url: https://mcp.new-service.com

三个问题的对应解法

问题 1 → 工具上下文隔离：子 Agent 仅加载自己域的 tools，主 Agent 只持有各域能力的轻量摘要。用户说"帮我点外卖"，进入上下文的只有外卖域的 10 个工具。

问题 2 → 业务方可以主动发布标准化 Agent：业务方只需部署一个 MCP Server，将自己的 prompt、skill 文件（作为 resources）、tools 一并封装进去。任何接入 MCP Server as Agent 的系统，通过配置 MCP 地址即可获得完整能力。麦当劳、滴滴、美团可以各自维护自己的 MCP Server，开发者不需要了解任何内部细节。

问题 3 → Skills 来自 MCP Server，安全可信：skill 文件由 MCP Server 的业务方直接提供，不经过第三方社区，来源可验证，内容与业务强适配，避免了平台 skill 市场的安全风险。

五、场景演示

场景 A：单域任务

用户："帮我点个午饭，30 块以内"

主 Agent → 意图识别：外卖域
  ↓
Plugin → 加载 mcd-mcp（麦当劳 MCP Server）
  · prompt: 麦当劳点餐助手行为规范
  · skills: 菜单选择指南、优惠券使用说明
  · tools: query-meals, calculate-price, create-order
  ↓
子 Agent 执行：查菜单 → 查券 → 计算价格 → 下单
  ↓
返回主 Agent："已创建订单：麦辣鸡腿堡套餐，预计 30 分钟送达"

上下文中只有 3 个相关工具，而不是整个系统的 45 个。

场景 B：多域协作

用户："查一下今天下午有没有空，有空帮我约个牙科"

主 Agent 拆解任务：
  ① 日历域 → 子 Agent A："14:00-17:00 有空"
  ② 预约域（携带时间约束）→ 子 Agent B："已预约 15:00 牙科"

主 Agent 汇总输出

子 Agent 之间不直接通信，由主 Agent 编排，链路清晰。

场景 C：业务方发布标准 Agent

某 SaaS 公司想让自己的企业客户在任意 Agent 框架里使用自家的工单系统：

# 他们只需要部署一个 MCP Server，包含：
Prompts:
  - name: init
    content: "你是工单助手，负责创建、查询、更新工单..."

Resources:
  - uri: skill:///ticket-guide
    content: "工单创建规范：优先级定义、SLA 要求..."

Tools:
  - create_ticket
  - query_ticket
  - update_status

接入方在配置里加一行 MCP 地址，自动获得完整的工单 Agent 能力，无需了解内部实现。

六、与现有方案对比

方案	工具加载	新域接入	Agent 定义	Skills 来源
LangGraph	全量加载	改代码	散落代码库	自行管理
CrewAI	全量加载	改代码	散落代码库	自行管理
AutoGen	全量加载	改 prompt	散落代码库	自行管理
mcp-agent	按 agent 分配	改配置	部分标准化	自行管理
MCP Server as Agent	按域隔离	加一行配置	MCP Server 自包含	业务方直接提供

七、当前进展与开放问题

MCP Server as Agent 目前已完成核心组件原型（MCPLoader + MCPAgentLinker），集成测试通过，持续推进中。

还有一些开放问题值得探讨：

子 Agent 实例的生命周期管理：复用 vs 每次新建，如何权衡延迟和内存？
意图误路由的处理：主 Agent 识别错域时如何优雅降级？
MCP Resources 作为 Skills 的约定：是否需要推动形成社区规范？

项目地址：mcp-broker

欢迎交流，如果你也在做 MCP 相关的工程，非常想听你的想法。

多 Agent 系统的三个隐形工程问题，以及一个基于 MCP 的解法