原文参考：Adam Jones & Conor Kelly, “Code execution with MCP: Building more efficient agents”。本文为原创解读，不是翻译。

MCP 改变的不是工具接入，而是 Agent 的成本结构

如果你最近几个月一直在看 MCP 相关讨论，会发现有一种说法特别流行：MCP 的意义在于统一工具接入标准。

这话不算错，但它太浅了。浅到足以让很多团队在真正搭系统时走偏——他们会把 MCP 当成一层协议适配器，忙着统计”我们接了多少 server""我们现在能调用哪些工具”，却没有意识到 MCP 真正改变的，其实不是工具目录，而是agent 整个运行时的成本结构。

Anthropic 那篇《Code execution with MCP: Building more efficient agents》最值得读的地方，不在于它再一次解释 MCP 是什么，而在于它把视角从”协议正确性”推进到”运行时经济学”。

它提醒我们：当 agent 面对大量工具、复杂流程、大型中间结果和多步控制流时，真正昂贵的往往不是工具本身，而是这些东西如何进出 LLM 循环。

从这个角度看，MCP 的意义就完全变了。它不再只是”接得更标准”，而是”能不能让更多原本要靠模型反复参与的工作，迁移到更便宜、更稳定、更可编排的运行时中去完成”。

这才是我认为 MCP 在 2026 年真正值得重视的地方。

一、为什么”统一工具协议”这个说法会误导人

把 MCP 理解成工具接入标准，最大的问题不是表述错误，而是它会把团队注意力带到次要矛盾上。

因为一旦这么理解，最自然的优化方向就会变成：接更多工具、维护更多 schema、搭更完整的工具 catalog、强化 server discoverability、统计接入数量。

这些事情当然都有价值，但它们解决的只是”能不能连上”，不是”连上之后整体系统会不会更高效”。

而 agent 系统真正的成本黑洞，经常发生在另一个层面：工具定义太多，光注入上下文就很贵；工具结果太大，中间结果反复进出模型；控制流被迫放在模型回路里，导致一轮轮冗余推理；大量本可程序化处理的事情，被交给模型来回 orchestrate。

换句话说，今天很多 agent 不是缺工具，而是缺一个能把”工具使用的中间层工作”从 LLM loop 里剥离出去的 runtime 结构。

如果从这里出发，你会发现 MCP 的真正价值，不在”更多工具”，而在”更合理的工作分配”。

二、direct tool-calling 为什么在真实系统里会越来越贵

很多 agent 系统默认走的是 direct tool-calling 路线：把工具定义给模型、模型选工具、工具执行、把结果塞回上下文、模型继续决定下一步。

这个流程在小规模 demo 场景里通常没问题，甚至很好用。因为：工具少、结果短、路径浅、人也容易盯着看。

但一旦进入真实生产环境，问题很快就会出现，而且不是某一种 bug，而是系统性成本上升。

1. schema injection 会变成上下文税

工具数量一多，光是把这些 schema、描述、参数定义灌给模型，就已经开始消耗大量上下文预算。工具越多，这笔税越高。

2. 中间结果会产生上下文 churn

工具 A 结果回给模型，模型再决定调用 B，B 的结果再回来；结果很多本来可以在运行时内部继续加工的数据，被迫一次次进 prompt、出 prompt、再进 prompt。

这不仅贵，还容易污染工作记忆。

3. 控制流被迫放进模型回路

像这些事情：重试、轮询、等待、分页处理、批量过滤、join / aggregate、中间值脱敏——本来更适合代码执行，但在 direct tool-calling 模式里，往往都要通过模型一轮轮来驱动。于是原本程序化的任务，被包装成昂贵的推理过程。

我越来越觉得，这是很多 agent runtime 今天最不必要、也最昂贵的浪费。

三、MCP + code execution 的真正价值，是把程序化中间层迁出模型

Anthropic 这篇文章真正重要的地方，在于它不是只谈 MCP，而是在谈 MCP 和 code execution 组合之后，会怎样改变责任分工。

这个变化可以概括成一句话：

模型负责决定”要做什么”，执行环境负责完成”怎么批量、怎么循环、怎么过滤、怎么组织中间结果”。

一旦这样分工，整个系统的成本结构就变了。

原来的模式：模型不仅要做高价值判断，还要反复参与很多机械中间步骤。

新的模式：模型规划与生成代码；代码在运行时里调用 MCP-backed APIs，完成大量本可程序化的工作，最后只把真正必要的关键信息带回模型。

这意味着：大量中间结果可以留在 runtime 内部、大量控制流不必每一步都经过 LLM、隐私处理可以前移、大结果可以先聚合/筛选后再反馈、工具使用可以更像程序，而不是更像对话。

这不是一个小优化，而是把 agent 运行方式从”高频人脑手动盯控制台”变成”有自动化中间层的执行系统”。

四、progressive disclosure 为什么是 MCP 在大规模工具环境里的现实价值

如果只用一句最务实的话来总结 MCP 的大规模价值，我会说：它让按需暴露工具这件事更自然。

这就是 progressive disclosure 的意义。

在一个真正大的工具生态里，最不合理的事情，就是假设模型一开始就应该看到全部工具定义。那不是给它能力，那是在给它制造认知债务。

更合理的方式应该是分层：先知道有什么 server / 能力域、真正有需要时再搜索相关工具、确认调用前再读更详细 schema、真正执行时让 runtime 去承担机械步骤。

这种分层带来的收益很实际：降低上下文占用、减少 irrelevant capability noise、降低工具描述互相干扰、让 agent 更容易聚焦当前任务。

这和今天 skills、retrieval、context compaction 里的很多趋势，本质上是同一个方向：

不是所有能力都该在一开始被注入；很多能力应该在真正需要时才进入工作记忆。

MCP 让这个模式更容易系统化。

五、执行环境在 MCP 时代的重要性，远比协议层更高

我认为现在很多团队在 MCP 讨论上还有一个明显偏差：过度关注协议定义，低估 runtime design。

但一旦你真的接受 code execution + MCP 这种模式，你会发现最关键的问题其实都跑到运行时上去了：从执行环境——代码在哪跑、跑多久、有哪些权限、连接哪些 MCP server；到状态管理——中间结果如何持久化、大输出怎么留在 runtime、敏感信息怎么避免回流进上下文；再到容错机制——失败了怎么重试或恢复。

也就是说，真正决定系统体验的，不再是”是否遵循 MCP”，而是”MCP 如何被一个合适的运行环境消费”。

这就是为什么我越来越把 MCP 理解成 runtime substrate，而不只是 interoperability protocol。

协议当然重要，但协议本身不会自动产生好系统。好的 runtime 才会。

六、不是所有工具都适合直接暴露给模型

这篇文章让我特别认同的一点，是它隐含地挑战了一个当前很常见的默认假设：只要某种能力存在，最好就直接作为 tool schema 暴露给模型。

我认为这件事在大规模 agent runtime 里并不成立。

当能力具备这些特征时，直接暴露通常不是最好方案：工具数量很多、结果体量很大、需要长控制流、需要多步聚合、中间结果并不值得模型逐条看、涉及敏感信息处理。

这类能力更适合先进入运行时代码层，再通过更高层、压缩过的形式返回给模型。

换句话说，真正成熟的 agent runtime 会做分层：简单、短路径、低结果量任务用直接 tool-calling；复杂、多步、大结果量任务用 code execution + MCP；更大流程级任务用 workflow-level orchestration。

这不是”削弱模型”，而是在把模型从低价值机械环节里解放出来。

七、MCP 真正改变的，是 agent 的上下文经济学

我一直觉得这才是整篇文章最值得带走的概念：上下文经济学。

因为今天很多人仍然把上下文当作一个可以不断往里塞东西的容器。但上下文其实是一种昂贵、稀缺、会腐烂的工作记忆资源。任何进入上下文的东西，都会带来机会成本。

从这个角度看，MCP 的真正价值不是”多连几个工具”，而是帮助系统重新分配以下问题：什么必须进上下文、什么可以留在 runtime、什么应该先被代码压缩后再回来、什么应该被完全外部化、什么只在按需时才暴露给模型。

这是一种非常典型的系统设计思路：

让贵的资源只承载高价值信息，让便宜的资源承接机械工作。

如果你从这个视角理解 MCP，就会意识到它改变的不是工具目录，而是整个 agent 系统的成本曲线。

八、skill 会因此发生什么变化：从 prompt bundle 走向 executable module

文章里还提到一个很值得展开的方向：可复用代码模块和 skills。

我觉得这件事的意义其实很大。因为一旦 agent 能在 runtime 里写出稳定的中间模块、把 MCP 调用逻辑封装起来，并在后续任务中复用，skill 的边界就会发生变化。

过去很多 skill 更像：一套 instructions、一段策略提示、一组注意事项。

但往后看，越来越多 skill 可能会变成：指令 + 可执行代码、语义描述 + 调用封装、策略模板 + runtime asset。

也就是说，未来 skill 不是只告诉 agent”怎么想”，而会越来越多地告诉 agent”已经有哪些中间执行骨架可以直接拿来用”。

这会让 skill 从 prompt asset 向 execution asset 演化。

九、一个更实用的判断框架：什么时候该选本地 runtime，什么时候该选远程 runtime

如果让我给团队一个很实操的选择框架，我会希望他们至少先问这几件事：

适合远程 runtime 的信号：任务天然会生成可复用工件、中途很可能需要人接手、过程可见性本身有价值、计算负载偏重本地不是理想执行面、输出不只是结论而是一个要继续工作的空间。

适合本地 runtime 的信号：反馈回路必须极短、强依赖本地仓库与长期进程、需要大量 CLI 细粒度组合、人类开发者本身就是主要操作者、结果工件不需要长期保留为协作空间。

这套框架的意义不在于让每次选择都绝对正确，而在于提醒团队：runtime 不是默认值，应该是任务匹配结果。

十、真正成熟的 agent runtime，不是把所有事情都交给模型，而是越来越清楚哪些事情应该坚定地不交给模型

如果我必须把整篇文章再浓缩成一句更狠一点的话，那会是：

真正成熟的 runtime，不是让模型控制一切，而是越来越清楚哪些中间环节应该被坚定地从模型手里拿回来。

这件事表面上看像节流，实际上是在做更重要的事：把模型从无意义的中间劳动里释放出来，让它把推理预算花在最值钱的判断上。

也正因为如此，我觉得 MCP 最终真正值钱的地方，不在于它让系统拥有更多能力名词，而在于它让系统终于知道哪些能力该待在哪一层。

---

谁应该读这篇

这篇适合下面几类读者：

• 正在做 MCP server / client / runtime 设计的工程团队
• 在 agent 系统里已经感受到工具多了但更乱的人
• 想把 code execution、tool use、runtime orchestration 重新分层的人
• 正在设计 skills、执行环境、policy layer 的平台团队
• 对”为什么 agent 很贵、很慢、很容易被大结果拖死”有切身体感的人