榨干 MCP Tax：Agent 效率与基础设施三篇

2026-08-13 · 工具层 / 上下文层 / 多模态层的三层降本

Agent 落地最大的隐性成本，不是模型贵，而是token 在无效地方膨胀。MCP 每轮把几百个工具的完整 schema 塞进上下文；长上下文 Agent 反复重读同一份代码库；GUI Agent 每步灌一张高分辨率截图——三处膨胀，恰好对应三篇 2026 论文的切入点。它们分别解决「工具描述膨胀」「上下文检索/缓存」「多模态 token 膨胀」，而且三者正交、可叠加。本文速读这三篇，并给出我的落地优先级判断。

一、Tool Attention：消除 MCP Tax

《Tool Attention Is All You Need》（arXiv 2604.21816，2026-04）把「对 token 的注意力」泛化成「对工具的门控注意力」。先说清楚 MCP Tax 是什么：MCP 是无状态、eager 注入的——每轮把全部已注册工具的完整 JSON schema 注入上下文。实测每轮 10k–60k token，疯狂膨胀 KV-cache；上下文利用率逼近 ~70% 时推理质量会断裂式退化（lost-in-the-middle）。

方法分三步：

• ISO 分数：用 all-MiniLM-L6-v2 编码用户意图与工具摘要（≤60 token）的余弦相似度；
• 状态感知门控 g = 1[ISO≥θ]·1[precondition]，最优阈值 θ*=0.28，取 top-k（k=10）；
• 两阶段懒加载：常驻摘要池（可 prompt-cache 命中），仅对 gated 工具按需拉全 schema；附幻觉门拒绝越权调用。

实测数字（120 工具 / 6 服务器模拟）：每轮工具 token 47.3k → 2.4k（−95.0%）；有效上下文利用率 24% → 91%（×3.8）；30 轮缓存命中率 84%（朴素 22%）。下游为投影估算：P50 延迟 ≈2.0s（−52%）、成本 ≈$0.03/任务（−86%）、成功率 ≈94%。

我的观点：这篇最讨喜的地方是几乎零改造即可落地——它本质是 MCP gateway 上的一个中间件，已经有开源实现。但我要泼点冷水：论文的延迟/成本/成功率都是「投影」而非活体实测，且核心是模拟环境；它依赖摘要质量（模糊查询占失败的 48%），还是能被对抗性释义绕过门控。我的判断：工具层是性价比最高的第一刀，但别把它当银弹，配合 prompt-cache 稳定前缀才能吃到那 84% 的缓存命中。

二、PEEK：把「对上下文的定向知识」缓存下来

《PEEK: Context Map as an Orientation Cache》（arXiv 2605.19932，2026-05）解决的是另一处浪费：长上下文 Agent 反复处理同一份语料/代码库，但现有方案只保留对话轨迹、原始材料或任务策略，独缺「这份上下文本身是什么、怎么组织、哪些实体/常量有用」的复用知识。

PEEK 维护一张常驻 system prompt 的 context map：Roadmap + Understanding 为必需项，Constants / Reusable Results / Parsing Schema 为可选项，硬预算 B=1024 token。三个模块协作：Distiller 从执行轨迹提取可迁移知识；Cartographer 转成 Add/Delete/Replace 的局部编辑；Evictor 按分数优先级驱逐（保护 Roadmap/Understanding 到最后）。

数字（对比 SOTA ACE）：

• 长上下文推理 OOLONG 上：质量 +6.3%–34.0%、迭代少 93–145 次、成本 低 1.7–5.8×；
• 上下文学习 CL-bench：solving rate +6.0%–14.0%、rubric +7.8%–12.1%、成本低 1.4×；
• 维护开销仅占总成本 6.2%–17.9%；跨 GPT-5.5 / Qwen3-Coder / Codex 泛化。

我的观点：PEEK 的洞察很妙——它缓存的不是「聊了什么」，而是「我对该上下文的方位感（orientation）」。这跟 RAG 是互补的：RAG 管「检索什么」，PEEK 管「我已经理解了什么」。我的落地建议是：对固定代码库/文档的反复任务（比如每天跑的仓库分析），维护一张 context map，收益立竿见影。注意它和模型级 KV 缓存正交，可以叠加——但 B=1024 没调优，真实任务里这个值值得自己测。

三、AQuaUI：免训练压缩 GUI 视觉 token

《AQuaUI: Visual Token Reduction with Adaptive Quadtrees》（arXiv 2605.19260，2026-05）专攻多模态 Agent。GUI Agent 每步注入高分辨率截图，但大块背景同质、文字图标集中——现有方法要么要重训，要么忽视结构化布局。AQuaUI 用自适应四叉树做推理期压缩：按面积加权灰度方差分裂，每叶子只留中心块作代表 token，全程保留原始合并坐标以维持位置编码一致；还加了条件四叉树借相邻帧连续性（static / shifted / replaced）保时间一致。

vLLM 实测（GUI-Owl-1.5-32B）：加速 13.22%、视觉 token −29.52%、保住 99.06% 全 token 性能；Qwen3-VL 系列约 −30% token、精度掉 <1pt；AndroidWorld 上 UI-Voyager SR 70.69% → 68.10%。

我的观点：这是三篇里唯一免训练、且保留空间结构的方案，工程友好。但它有锁定：需改模型特定位置编码，目前只实现 Qwen2/3-VL on vLLM，迁移要工程；小模型上预处理开销甚至可能反升延迟。我的判断：多模态层按需上——只有当你真的在跑 GUI/视觉 Agent、且主干够大时，四叉树压缩才划算；纯文本 Agent 别碰。

四、三层优化与我的落地优先级

我的总体判断：

• 优先级：工具层 → 上下文层 → 多模态层。工具层零改造、收益一个数量级，先上；上下文层对固定语料任务收益大，接上；多模态层按场景。
• 三者都依赖稳定前缀。Tool Attention 的摘要池、PEEK 的 map 都要靠 prompt-cache 命中——缓存边界要协同设计，否则互相抢命中率。
• 与「原生长上下文」的关系？有人会问：模型原生支持百万 token 时，这套「省 token」是否还有必要？我的答案是短期仍极有必要：KV-cache 成本、推理延迟、多租户并发限制，不会因窗口变长而消失；长上下文是「能装下」，省 token 是「跑得起、跑得快」。

参考

• Tool Attention Is All You Need — arXiv 2604.21816
• PEEK: Context Map as an Orientation Cache — arXiv 2605.19932
• AQuaUI: Visual Token Reduction with Adaptive Quadtrees — arXiv 2605.19260