MCP引发上下文爆炸，Anthropic 提出解决方案

本期播客

Anthropic 又引领潮流了

AI Agent 包含三大核心组件: 大模型负责推理和执行任务, 数据库负责记忆和大模型未知领域的外部知识存储, MCP Tools 负责感知外部环境及互动.

然而 AI Agent 接入大量 MCP tools 后, 将导致上下文暴增(因为要告诉模型有哪些mcp server, 能调用哪些tools, 以及每个tools的说明), 有什么方式优化, 减少管理 MCP tools 带来的上下文暴增? 市场上会不会诞生类似 switch/route 的产品, 专门做 MCP tools 的选择和路由?

随着 Model Context Protocol (MCP) 生态的爆发，Agent 挂载数十个服务器（每个服务器带几十个工具）已成常态。如果将所有工具的 JSON Schema 全量塞进 Prompt，不仅浪费 Token（成本上升），更会导致 LLM 的“注意力集中度”下降，出现幻觉或无法精准选具。

针对“上下文暴增”的优化方案以及你提到的“路由/开关”市场趋势，目前行业内已有以下几种核心演进方向：

1. 现有的技术优化方案

目前开发者主要通过以下四种模式来减少 MCP 带来的上下文负担：

A. 动态发现与按需加载 (Dynamic Context Discovery)

这是目前 Cursor、Claude Code 等顶尖 Agent 采用的策略。

• 做法： 不在初始化时加载所有工具的 Schema。Agent 初始只持有一个“工具目录”或 search_tools 工具。
• 效果： 只有当 Agent 认为需要某类能力（如“数据库操作”）时，它才会调用搜索工具获取该分类下的具体 Schema，实现 90% 以上 的 Token 削减。

B. 两级路由/分级管理 (Hierarchical Routing)

• 做法： 引入一个“管理层” MCP。例如，你只给 Agent 接入一个 Switchboard（拨号盘）工具。
• 逻辑： 1.  Agent 第一步先问 Switchboard：“我要改代码，给我相关的工具”。

1. Switchboard 返回 GitHub 和 File-System 的工具定义。
2. Agent 再进行实际操作。

C. 代码执行化 (Code Execution as Tool Interface)

这是 Anthropic 最近极力推荐的模式。

• 做法： 将 MCP 服务器视为“代码库（Library）”而非“工具集”。
• 逻辑： Agent 只要知道有哪些库可用，然后写一段 Python/JS 代码来 import 并调用它们。代码执行环境负责处理数据，只将最终结果返回给 LLM，极大地减少了中间过程的上下文占用。

D. 自动压缩与上下文缓冲区 (Auto-compacting)

• 做法： 当上下文达到阈值（如 80%），系统自动对之前的工具调用记录、长 JSON 返回结果进行摘要化（Summarization），只保留关键结论，清理冗余的参数定义。

2. 市场趋势：会不会出现 Switch/Router 产品？

答案是：肯定会，而且已经在路上了。

这种产品在架构上通常被称为 "MCP Gateway" 或 "MCP Router" 。

为什么市场需要它？

1. 权限与安全 (Auth & Security)： 企业级 Agent 不能让所有工具都裸奔。需要一个 Router 来控制：哪些用户能用 Production-DB 工具，哪些只能用 Read-only。
2. 跨平台统一控制： 你可能在 Cursor 里用一套 MCP，在本地命令行用一套，在生产环境 Agent 用一套。Router 可以作为单一事实来源（Single Source of Truth）。
3. 智能调度： 类似于负载均衡。如果 Agent 任务是“发邮件”，Router 会自动屏蔽掉“气象查询”相关的 MCP 上下文。

目前已有的雏形：

3. 总结与建议

如果你正在开发 Agent，为了应对上下文暴增，建议采取以下演进路线：

1. 短期： 采用 “懒加载” 。手动将 MCP 分组，只有用户提到相关场景时再加载对应的 Server。
2. 中期： 接入或自建一个 MCP Router。让 Agent 通过一个“元工具”去发现其他工具，而不是一次性全量注入。
3. 长期： 关注 Serverless MCP。让工具调用变成无状态的云端函数调用，由网关层负责上下文的注入和清理。