海量 MCP 工具场景下的上下文隔离选择方案
本文探讨一种针对大型 ERP 系统接入 MCP 工具时的架构设计思路，核心目标是：在工具数量极多的情况下，既让 AI 能准确找到合适的工具，又不污染主对话的上下文窗口。
背景：MCP 工具多了会怎样
MCP（Model Context Protocol）让 AI 能够调用外部工具。但有一个固有成本：AI 每次对话都需要知道”有哪些工具可以用”，这意味着所有工具的描述都要塞进 prompt。
对于小型系统，十几个工具问题不大。但对于大型 ERP 系统，情况完全不同：
- 销售、采购、库存、生产、财务……每个模块都有大量单据
- 每张单据都有新增、编辑、查询、审批、关闭等操作
- 大量报表、基础资料维护工具
- 工具总数轻松达到数百甚至上千
把这些全部塞进每次请求，token 开销巨大，而且大量描述高度雷同（”支持新增、编辑、查询销售订单”和”支持新增、编辑、查询采购订单”几乎一样），信噪比极低。
业界常见方案及其局限
方案一：向量检索动态召回
将工具描述向量化，每次请求前用用户意图检索最相关的 Top N 个工具，只把这些带入 prompt。
局限：向量检索基于语义相似度，但工具选择有时需要逻辑推理。”关闭采购单”和”删除采购单”语义很近，但含义完全不同，容易误召回。
方案二：全量摘要索引常驻上下文
每次请求携带所有工具的摘要索引（名称 + 一句话描述）。
局限：对于 ERP 这种规模，即使是摘要索引也非常庞大，且每轮对话都要携带，累积成本高。
新方案：上下文隔离的工具选择
核心思路
把”选择工具”这件事，做成一次独立的、不污染主上下文的子调用。
主对话上下文中不存放任何工具描述，只有一个简短提示告诉 AI：”当你需要调用工具时，先发起一次工具查询。”
执行流程
用户请求
↓
主 Agent 循环（上下文干净，无工具描述）
↓ AI 判断需要调用工具
触发 function call: search_mcp_tools(query)
↓ Agent 执行此特殊 function
├─ 将海量工具摘要索引发送给 AI（独立请求，不在 Agent 循环中）
├─ AI 决策：返回所需工具的完整描述
└─ Agent 拿到完整描述后，将其注入当前轮次上下文
↓ AI 使用完整描述调用实际工具
↓ Agent 执行完毕后，主动抛弃工具完整描述
继续 Agent 循环（上下文恢复干净）
关键设计点
1. 工具选择请求独立于主上下文
那次携带海量摘要索引的请求是一次独立调用，结果只返回”选中的工具完整描述”，不会进入主对话历史。后续轮次的请求不会携带这些信息。
2. 完整描述用完即抛
Agent 在执行完工具调用后，主动从上下文中移除工具完整描述。主上下文始终保持轻量。
3. 工具选择请求可用低成本模型
这次独立请求的任务是”从大量摘要中选出合适的工具”，逻辑并不复杂，但需要大上下文窗口。可以选用便宜的大窗口模型，而不必使用最强的模型，控制成本。
解决”AI 不知道自己需要工具”的问题
上述方案有一个潜在风险：如果 AI 误以为自己能直接回答，就不会触发工具查询，结果是产生幻觉而非报错。
解决方式：结构化模块总结
利用 ERP 工具描述高度同构的特点，提前让 AI 将所有工具摘要压缩成一份结构化的模块地图，常驻主上下文。
ERP 工具描述的冗余规律：
- 销售订单、采购订单、生产订单的描述模式几乎一样
- 大量报表工具都是”支持查询和导出”
- 基础资料维护都是”支持增删改查”
压缩后的结构化总结示例：
销售：订单/退货/发货/对账，各支持增删改查+审批
采购：订单/退货/收货/对账，各支持增删改查+审批
库存：入库/出库/调拨/盘点，各支持增删改查
报表：销售/采购/库存/财务，各支持查询/导出
基础资料：客户/供应商/物料/仓库，各支持增删改查
200 字以内覆盖 80% 的场景。AI 看到用户说”帮我查上个月的销售报表”，能准确判断”我需要去查报表类工具”，带着精准的查询语义触发工具选择请求，而不是盲猜。
完整三层架构
┌─────────────────────────────────────────┐
│ 结构化模块总结（~200字，常驻主上下文） │
│ 作用：让 AI 知道有哪些模块，往哪里找工具 │
└────────────────┬────────────────────────┘
│ AI 判断需要工具，带精准查询触发
┌────────────────▼────────────────────────┐
│ 独立工具选择请求（海量摘要，用完即弃） │
│ 作用：从全量工具中精确定位，返回完整描述 │
│ 模型：低成本大窗口模型即可 │
└────────────────┬────────────────────────┘
│ 完整描述注入当前轮次，执行后抛弃
┌────────────────▼────────────────────────┐
│ 实际工具调用 │
│ 主上下文始终干净 │
└─────────────────────────────────────────┘
方案对比
| 全量索引常驻 | 向量检索 | 本方案 | |
|---|---|---|---|
| 主上下文 token 开销 | 高（每轮携带） | 中（召回 Top N） | 极低（仅模块总结） |
| 工具数量扩展性 | 差 | 中 | 好 |
| 选择准确性 | 高 | 中（语义相似≠逻辑正确） | 高（AI 推理决策） |
| 额外 LLM 调用 | 无 | 无 | 有（工具选择独立请求） |
| 适用场景 | 工具少 | 工具中等 | 工具极多（ERP级别） |
总结
这个方案的本质是：将”元认知”（我需要什么工具）和”执行”分离，并用独立上下文隔离选择过程的噪音。
对于工具数量适中的系统，这个方案引入了额外的调用步骤，不一定划算。但对于大型 ERP 这种工具极多、描述高度同构的场景，它能在保持主上下文干净的同时，让 AI 准确找到所需工具，是一种值得探索的架构模式。