MCP 工具输出太大怎么办？先别截断，正常路径 Token 减少 76%

Agent 只是想从一段日志里找一个错误码。

它先收到了十几个工具的名称、描述和参数 schema。工具调用结束，又迎面撞上一整份日志。那个错误码也许只占十几个字符，为了找到它，模型却要先读完几万行上下文。

MCP 用久以后，这笔开销很难忽略。工具还没开始工作，目录先占一遍；工具已经做完，结果又占一遍。

直接截断最省事，可模型发现后半段不够用，往往会再问一次。上游只是搜索或读文件，代价可能只是变慢；上游会发邮件、创建工单、写数据库，第二次调用就可能变成第二次现实动作。

处理 MCP Token 时，需要同时守住三件事。

工具只在需要时交付完整 schema。
一次请求最多执行一次上游工具。
首次结果可以缩短，原始结果仍能精确取回。

MCP Slim Guard 把工具发现、上游执行和结果交付拆开处理，紧凑结果来自原始结果的可恢复视图，不依赖模型猜测一段摘要。

MCP 工具输出过大，应该先优化哪一段

可以先按任务习惯判断。

工具很多，每次只用一两个，先做渐进式发现，避免整张 schema 目录提前进入上下文。
结果很大，任务通常只看局部，先保存原始结果，再交付紧凑视图，需要时局部恢复。
任务必须读完全部数据，直接交付往往更省，没有必要额外分页。
工具会产生副作用，恢复原文不能依赖再次执行上游工具。

收益取决于这次任务最终要读多少原始信息。压缩比例只是结果。

一次 MCP 调用，Token 花在两个地方

MCP 的调用流程很直接。

Host 先通过 tools/list 取得工具定义。模型根据名称、描述和 input schema 选择工具，再通过 tools/call 执行。MCP 官方 Tools 规范允许工具返回文本或结构化内容，也允许 Server 提供 output schema，帮助客户端验证结果。

工具数量增加以后，两笔开销会变得明显。

模型还没选工具，目录已经进来了

三个工具时，把 schema 全放进上下文很方便。三十个、三百个工具时，这张目录会变成每轮对话的固定成本。

在 Slim Guard 的 24 任务公开夹具里，一个任务只需要搜索产品目录并返回三条结果。Baseline 仍然先交付 12 个工具定义。那次 tools/list 响应有 5,909 个字符，使用 o200k_base 计算为 1,380 个 Token。

最后只调用了一个工具，另外 11 份 schema 也一起进入上下文。

模型只要一个答案，结果却整包返回

工具选对以后，日志、搜索结果、长文档和大型 JSON 可能一次返回几万行。模型也许只需要状态为 failed 的三条记录，完整结果已经成为会话历史的一部分。

两笔开销都来自“以后可能会用，现在先全部给模型”的默认方式。调整交付时机后，当前需要的内容先出现，其余内容等任务真的需要时再取。

减少 MCP Token 的四条路解决不同问题

不同方法处理的是不同层，适合叠加使用。

少连接一些 Server

一场会话只需要文件和 Git 时，可以先关掉不相关的系统。这是最便宜、最容易回滚的优化。

它也依赖人工预判。通用 Agent、企业工作台和长期会话很难提前知道下一步会用哪个工具。

让模型按需发现工具

Anthropic 在 Code execution with MCP 中给出过两类办法。可以把工具映射成可探索的代码文件，也可以提供 search_tools 一类入口，让模型只加载当前需要的定义。

Slim Guard 的 Compact 和 Extreme 模式采用渐进发现。Host 最初只看到 find_tool、call_tool 和 read_result。Agent 搜索工具时，最多拿到三个匹配项，以及匹配工具的完整原始 schema。

schema 仍然完整，只在任务需要时出现。

在代码执行环境里过滤结果

Agent 有安全的代码沙箱时，可以让大结果先留在执行环境中，只把筛选、聚合后的内容交给模型。处理一万行表格时，这通常比让模型逐行阅读更自然。

团队也要承担沙箱、资源限制、权限隔离和监控。模型上下文缩小了，Harness 的运行复杂度会增加。

在结果交付层保留可逆路径

有些 Host 仍要走普通 MCP 调用，团队也不准备先搭代码执行环境，而大多数任务只读取结果中的局部信息。

Slim Guard 会在有损的首次交付之前保存不可变快照，再返回紧凑视图和 result_ref。需要更多细节时，Agent 使用 read_result 搜索或分页读取本地快照，上游工具不会再次执行。

少接无关 Server 处理配置膨胀，渐进发现缩小工具目录，代码侧过滤适合复杂数据处理，可逆交付则负责先少给、以后仍能精确找回。

压缩之前，调用约束要先成立

只负责缩短结果的代理，很难放心接入写操作。Slim Guard 先给调用过程加了几条限制。

一次 call_tool 只能解析到已经授权的工具。参数先按原始 schema 验证，通过后原样转发，选中的上游工具至多执行一次。参数不合法时，请求在本地失败，上游收不到这次调用。

授权、策略或工具解析失败时，调用路径关闭。系统不能确认工具是否允许执行，就不碰上游。

如果上游已经成功返回，后续的结果投影、快照存储、观测或审计出错，交付层会返回精确的上游结果。优化模块可以退出，合法结果仍会交给 Host。

审计记录不复制凭据、调用参数、结果正文或私有能力引用。它只记录调用经过哪些步骤，避免再生成一份敏感内容副本。

这套约束只覆盖工具访问和结果交付。网络隔离、密钥管理、人工审批、上游权限和代码沙箱仍要由其他层负责。

76% 是怎样算出来的

公开的 2026-08-06 三模式 24 任务证据包含 12 个确定性工具和 24 个中英文任务。

统计使用 o200k_base，计算 prompt，以及所有面向模型的 MCP tools/list、tools/call 请求和响应。24 个任务全部走成功路径，每项任务只执行一次上游工具。

模式	正常路径 Token	相对 Baseline 减少
Baseline	71,388	0
Native	39,521	44.64%
Compact	16,983	76.21%
Extreme	16,478	76.92%

Native 保留 Host 已授权工具的原始名称，主要收紧结果交付，因此目录成本仍然存在。Compact 把工具发现收敛到三个入口。Extreme 会给符合条件的大结果提供更短的首次交付。

标题里的 76% 来自 Compact 相对 Baseline 的正常路径差值。

这是一组确定性的成功路径协议重放，没有让模型自己选择工具。它也没有测试回答准确率，没有计入缓存命中、供应商价格和会话里的其他提示内容。76% 描述的是这组 fixture 的模型可见协议 Token，不能直接换算成账单折扣。

一组反例更能说明适用边界

100 工具、8000 行结果的压力夹具故意放大了目录和输出。直接路径使用 352,157 个 Token。正常路径下，Compact 只用 1,451，Extreme 只用 1,134，减少接近 99.7%。

随后，测试强制 Agent 把 8000 行全部读完。

Compact 需要 50 次 read_result，协议总量升到 687,741 个 Token；Extreme 为 687,424。恢复结果的哈希与原始结果完全一致，上游仍只执行一次，总 Token 却接近直接交付的两倍。

可逆恢复也有成本。任务没有阅读的内容才构成净节省；任务最终必须逐字消费全部原文时，直接交付通常更便宜。

在日志里找错误码、从搜索结果中找三条证据、在大型 JSON 中查一个对象，都适合按需交付。全量迁移、完整审计和逐行转换更适合在代码执行环境里处理，或者直接交给确定性程序。

哪些场景值得试

以下情况比较适合 Slim Guard。

Host 连接的工具越来越多，每次任务通常只用一两个。
工具经常返回日志、长文档、搜索集合或大型 JSON。
大多数任务只读取结果的一小部分。
上游工具带有副作用，读取原文不能导致工具重跑。
团队希望保留授权、原始 schema 验证和审计边界。

工具只有三五个、结果很短，直接 MCP 已经够用。每项任务都要读取完整结果时，分页恢复会增加成本。已有成熟代码执行层的团队，也可以先在沙箱里筛选和聚合数据。当前方案的恢复引用属于当前运行时代，跨运行时持久恢复需要另行设计。