27. 解决 MCP 带来的上下文过长问题如果不启用代码执行(Code Execution),该如何缓解 MCP 带来的上下文和 token 过长问题?本周 Anthropic 发布了一篇文章,讲述了 Code Execution 能够解决 MCP 引发的两大痛点。确实,代码执行机制在提升效率、降低 token 消耗上有明显优势。但在很多企业环境中,出于安全、合规或运维限制,并不具备开放代码执行的条件。那么,在无法使用 Code Execution 的情况下,如何依然有效解决 MCP 带来的上下文冗长问题?我们先看原文提到的两个核心问题:1. 工具定义过多导致上下文窗口被占满;2. 工具中间结果消耗了大量 token。下面我们分别分析应对思路。一、避免“工具定义占满上下文”总体思路是:延迟加载 + 结构化查询。1. 分层加载工具定义不要在初始化阶段就把所有 MCP 工具定义一次性加载进上下文。可以先让模型仅了解“有哪些服务器”以及“每个服务器下的工具名称和简短描述”。例如:可用服务器:google-drive(文档相关)salesforce(CRM 相关)notion(知识库相关)当模型真正需要操作 google-drive 时,再通过类似 get_tool_definition(server="google-drive", tool="getDocument") 的调用获取完整定义。这样可以避免模型在初始化时被大量工具定义占满上下文。2. 基于搜索的按需加载构建一个 search_tools 接口,让模型能通过关键词(如 “email”、“lead”、“calendar”)搜索工具,并按需返回信息。返回粒度可分为:(1)仅返回工具名称;(2)名称 + 简介;(3)仅当模型明确请求时才返回完整 schema。这样 MCP 层就像一个“工具搜索引擎”,而不是一次性暴露全部内容。3. 缓存与复用策略对于高频使用的工具,可以将其定义缓存到短期上下文或系统记忆中,而非每次都重新加载全部定义。这种做法能在多轮交互中平衡上下文长度与调用效率。二、降低“中间结果占用上下文”可以通过在 MCP 客户端层面对中间结果进行压缩或引用处理,减少 token 消耗。1. 结果摘要当工具返回结果时,客户端先生成“摘要版”结果再返回给模型。例如,在获取会议记录后,不直接返回全文,而仅传递:已获取会议记录,共 12 页,主题:Q4 目标。样例前 5 行:……如需全文,请再次请求 getDocument(full=true)。模型若确实需要全文,再发起请求。这样可显著减少 token 消耗。2. 分页与数据采样对于表格或列表类数据(如 Google Sheet 或数据库查询),可以让 MCP 接口支持分页或条件参数,让模型每次仅获取部分内容(如前 100 条或满足过滤条件的数据)。3. 服务端数据操作尽可能在服务端完成数据筛选,而不是返回整批数据后再由模型过滤。例如 getSheet(sheetId, filter="Status='pending'"),直接在服务端筛选结果,避免中间数据占用上下文。4. 结果引用对于体量大或敏感的数据,可以采用“结果引用”的方式。模型只接收结果 ID(如 result_ref_12345),当需要时再通过 MCP 客户端获取对应数据。这种方式相当于在“无代码执行”的环境下,模拟“数据保留在外部,模型按引用访问”的机制。通过以上方法,即使不启用代码执行,也能在 MCP 架构下显著降低上下文开销,提升响应速度与 token 利用效率。#ai创造营##科技#