海量 MCP 工具场景下的上下文隔离选择方案海量 MCP 工具场景下的上下文隔离选择方案本文探讨一种针对大型 ERP 系统接入 MCP 工具时的架构设计思路核心目标是在工具数量极多的情况下既让 AI 能准确找到合适的工具又不污染主对话的上下文窗口。背景MCP 工具多了会怎样MCPModel 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级别 海量 MCP 工具场景下的上下文隔离选择方案
海量 MCP 工具场景下的上下文隔离选择方案海量 MCP 工具场景下的上下文隔离选择方案本文探讨一种针对大型 ERP 系统接入 MCP 工具时的架构设计思路核心目标是在工具数量极多的情况下既让 AI 能准确找到合适的工具又不污染主对话的上下文窗口。背景MCP 工具多了会怎样MCPModel 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级别