这篇最值得看的，不是一句「能省 98.7% token」，而是一个工程转向：
过去我们让模型一轮轮直连 tool call；现在越来越多团队在做另一件事——让模型先写一段程序，在执行环境里把 MCP 当 API 用，再把结果摘要给模型。[1]
如果你在做多工具 Agent，这个转向很可能会变成默认做法。原因不复杂：工具一多，schema 会先吃掉上下文；中间结果一长，链式调用会反复搬运大文本，成本和不稳定性一起上来。[1]
一、先讲背景：MCP（Model Context Protocol）规模化后的老问题
MCP 本来是好事：把外部系统接进来，让 Agent 有真实世界的执行能力。
但当工具规模从几十走到几百、上千，常见痛点会同时出现：[1]
- 全量工具定义进上下文：模型在理解任务之前，先被大量 schema 淹没。
- 大结果反复过模型：一次 tool call 的长输出，下一轮又被拼回去，重复消耗 token。
- 控制流越来越啰嗦：轮询、过滤、聚合这些本该在程序里做的事，被拆成多轮对话。
这也是 Anthropic 这篇文章要回答的问题：当工具很多时，调用形态要不要变。[1]
二、演进思路：从「模型直连工具」到「代码编排 MCP」
核心变化一句话：把 MCP 从“对话里的工具”变成“代码里的库”。[1]
在可执行代码环境里，模型可以这样做：[1]
- 按任务只加载需要的 MCP 封装（而不是一次塞满全量工具定义）；
- 在执行环境里处理大结果（过滤、聚合、join）；
- 最后只把小摘要回传给模型继续推理。
原文 TypeScript 结构是 servers/... 封装 + callMCPTool，示例链路是 GDrive 读纪要、再写 Salesforce。[1]
三、原理拆解：这条路到底省在什么地方
1）渐进披露（Progressive disclosure）
工具定义按文件组织，模型只读当前任务相关模块；如果配合 search_tools，还可按“仅名称/名称+描述/全 schema”逐级展开。[1]
2）结果先在代码里算，再交给模型
比如 1 万行表格，程序先筛出 5 行，再交给模型判断。
这一步其实决定了成本上限：大文本是否在模型上下文里反复出现。[1]
3）控制流还给程序
轮询、分支、重试、等待，程序天然比“对话 + tool + sleep”稳定；也减少首 token 延迟。[1]
4）隐私与状态更好落地
原文给了 PII tokenization 的思路：模型看到的是占位符，真值在后续 MCP 调用再还原；中间状态可写文件，支持断点续跑。[1]
四、数字怎么看：能看见趋势，但别把示例当常数
原文的 150k→2k（约 98.7%）是具体语境示例，结论不是“任何场景都省这么多”。[1]
更稳妥的读法是看变量：
- 你的工具定义是否本来就很大；
- 你的中间结果是否真有大文本搬运；
- 你的任务是否需要大量过滤/聚合这类“程序强项”。
换句话说，这个方法不是神奇开关，而是当任务满足条件时，收益很大；不满足时，收益有限。
五、代价与边界：省 token，不等于白拿
要跑代码，就要承担额外工程成本：[1]
- 沙箱与权限边界（网络、文件系统、配额）；
- 监控与审计（日志脱敏、调用链追踪、失败回放）；
- 稳定性治理（超时、重试、幂等、副作用回滚）。
所以它更像是「用工程复杂度换上下文效率」，不是免费午餐。
六、放回系列里看：它和 advanced tool use / Skills 是什么关系
这篇和第 3 篇 advanced tool use 其实在同一条线上：都在解决“工具很多时，怎么不把上下文塞爆”。
区别在于实现重心：[1]
- advanced tool use 更偏平台级工具管理（如搜索/延迟披露）；
- code execution with MCP 更偏执行层编排（程序吞中间结果）。
与第 7 篇 Skills 的关系也清楚：把跑通的调用逻辑沉淀为函数/脚本，再抽成可复用技能。
结论：这篇真正的新意是什么
我自己的结论是：这篇不是在炫一个更低 token 的小技巧，而是在给 Agent 工程一个更长期的默认形态——
模型负责规划与写代码，执行环境负责大计算与状态，模型只消费被整理过的上下文。
如果你的场景是“多工具 + 大结果 + 可脚本化流程”，这条路值得优先尝试；
如果只是少量工具、短结果直查，直连 tool call 仍然更省工程心智。
