AI 编码代理的隐形开销：每装一个工具，你都在给它发工资

2026-11-14 中文长文存档 AI 提效

先给结论：你觉得代理变慢、变笨、变贵，很多时候源于工具声明在替你付账单，而非模型本身退步。

一、这笔税怎么收的

大模型不会后台挂着工具、需要时再查。它靠什么知道该调哪个工具？靠宿主应用把每一个已注册工具的完整 JSON schema，塞进每一次 API 请求的上下文里。

这意味着三件事：

1. 工具是配置时声明的，费用是每轮结算的。装 30 个工具，不是某天集中付一次，而是每一轮对话都付一次
2. 一个全功能 MCP 服务器往往一口气挂 30 到 60 个端点，单个工具说明书大约 180 到 220 token
3. 代理是循环工作的：读文件、跑命令、看报错、再改。10 步的循环，这笔税交 10 轮

一个真实案例（dev.to，46 赞 39 评，作者自测数据）：接了 7 个 MCP 服务器后，输入一个两个词的空提示，单轮消耗约 28,400 input token，其中约 25,000 是工具 schema。没有附件，没有历史，纯说明书。

二、比钱更贵的三件事

1. 选错工具。80 个以上工具挤在一个上下文里，参数张冠李戴、反复重试是常态
2. 注意力稀释。每个你从来用不到的筛选条件，都在跟你真正的代码抢注意力
3. 输出倒灌。大而不当的工具把整坨原始 API 响应直接吐回上下文，你只需要 3 行结论，它给你 15,000 token 的 JSON

同一位作者把工具栈从 52 个砍到 4 个，跑了 50 次调试会话：首轮选对率 78% 到 99%，首字时间 3.4 秒到 1.1 秒，单轮 schema 开销 24,600 到 640 token。注意这是作者自测，不是第三方复现。

三、可执行的清单

1. 全局默认不挂任何 MCP 服务器，按项目、按会话开
2. 活跃工具数超过 15 个就做一次审计，一周没触发过的直接关
3. 写操作端点默认关：它们既烧上下文又带安全风险
4. 只是包了一层 REST 或本地命令的，换成几十行的 CLI 脚本，零 schema 开销

四、从 Claude Code 那边借三个省 context 的动作

Zenn 上一篇收藏 106 的月报（11-10 发布）给了同方向的对照：

1. /btw 旁路提问：只读当前会话回答问题，不进主上下文，适合放养时查进度
2. prompt-cache-control 插件：提示缓存 TTL 只有 5 分钟（订阅用户 1 小时），缓存断了下一轮要重写全量，看到提示就先压缩再发
3. 子代理隔离：让子代理去读脏文件、跑长检索，只把结论带回来，主上下文不沾灰

五、落到我们自己这条流水线上

我们自己的自动化流水线，本质上就是 agent 在一轮一轮调工具：采集脚本、闸门脚本、出图引擎、回读校验，每一步都是一次工具调用。这笔账放到 2026年11月14日 对我们同样成立，只是规模小、体感弱。

有三件事可以直接抄：

1. 我们的脚本大多是几十行的 CLI，本来就是文章里最推崇的零 schema 开销那一路。这算是对的地方，要守住：新增能力优先写成小脚本，而不是再挂一个大而全的服务
2. 真正该盯的是模型侧的上下文。采集脚本每轮吐回的日志越长，喂给判断模型的有效信息占比就越低。日志和中间产物尽量落盘，只把结论行交给模型
3. 一周没触发过的就关，这条对应到我们：不再用的闸门和检查项，别让它一直挂在自检里空转

有一个数字我标未核实：文章说的 15 个工具上限，是作者单点经验值，我这边没找到第二个来源的实测，不能直接当硬阈值用。

六、一个没闭环的问题

现在各家的做法都是少而专。但工具注册有没有按需加载的可能？比如代理自己判断该调哪类工具，宿主才临时拉那份 schema？方向是显然的，截至 2026年11月14日 我没有找到官方落地方案，标注：未核实。以上判断代表本次发稿的检索口径，不替后续结论背书。

如果哪家把工具注册改成懒加载，本文第三节清单里最重的第 1、2 条就能省掉。

以上为技术科普，不构成投资建议。