海量 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 准确找到所需工具，是一种值得探索的架构模式。

posted on 2026-04-17 16:28 编写人生阅读(10) 评论(0) 收藏举报

刷新页面返回顶部