在 MCP 成为 AI 工具链集成热词之后，开发者社区围绕它的争议并未减少。近期，Hacker News 上一篇题为《You Said No MCP!》的文章引起关注。文章作者来自 Pi 的开发团队 Earendil Engineering，核心问题很直接：Pi 曾公开表示不支持 MCP，如今却把 MCP 做成了核心功能，这一转变意味着什么？
这篇文章的价值不只在于解释一次产品路线调整，也折射出当前 AI 编程工具在处理外部协议时的普遍矛盾：开发者既希望模型能连接更多工具，又担心协议被过度接入后带来上下文膨胀、工具编排失控和边界模糊。
从拒绝到支持，Pi 给出的理由并不是“跟风”
根据文章披露，如果用户早期访问 pi.dev，会看到 Pi 明确声明不支持 MCP。团队在播客等场合也曾多次表达对 MCP 的保留态度。但在升级后的 Pi 中，MCP 已成为官方支持的功能。
团队给出的第一个理由是，MCP 本身在过去一年中发生了变化，“今天的 MCP”已经不同于早期版本。不过文章也承认，仅凭这一点还不足以把 MCP 放进核心。因为从技术上说，MCP 完全可以作为扩展存在，甚至可以作为 Earendil 官方推荐的扩展接入。
真正促使团队改变决策的，是他们在重新评估后发现：为支持 MCP 所需的一些底层改造，对 Pi 自身也有普遍价值。例如，这些改动也能让 Jev 更容易在 Pi 中使用。文章称，Pi 所需的能力与 MCP 所需的能力高度相似：本质上都需要一个解释器形式的沙箱环境。
MCP 的问题没有完全消失：组合性仍是短板
虽然 Pi 团队选择接纳 MCP，但文章并没有转向全面乐观。作者指出，MCP 当前最大的问题仍然是“难以组合”。即便引入 Codemode 这样用于编排工具调用的沙箱机制，MCP 在这一目标上仍未完全达到预期。
文章进一步把问题指向现实生态：并不是 MCP 协议本身单独造成所有困难，许多 MCP server 的设计方式也放大了问题。相当多 MCP server 仍然面向那种“把工具全部塞进上下文”的 harness 设计，为了优化 token 消耗，倾向于直接返回文本结果。
Pi 团队认为，更理想的方向是让 MCP 更接近“带智能工具发现能力的 OpenAPI”。也就是说，工具应返回结构化数据，并通过文档和描述被模型发现与调用，而不是依赖把所有工具说明一次性倒入上下文。
Codemode 成为关键：让工具调用更像可编程编排
文章中反复出现的一个关键词是 Codemode。按照解释，harness 执行工具时通常有两类运行位置：一类在 bash 所在环境，另一类在 harness 的 agent loop 中。两者的信任级别差异很大：harness loop 往往运行在相对可信的环境里，而被执行的工具则经常位于信任级别较低的沙箱中。
Codemode 的特殊之处在于，它运行在 harness 一侧。它更像一个用于组织和协调工具调用的沙箱，允许 agent 使用 JavaScript 把多个工具调用组合起来，并更灵活地决定调用顺序。由于它运行在 harness 侧，其状态也会作为会话记录的一部分保存，而不是依赖文件系统。
文章提到，理论上任何语言都可以承担类似角色，但 JavaScript 较有吸引力，因为小型 JavaScript 运行时可以以 WASM 二进制形式分发，并提供相对合理的保护能力。在 Pi 中，当用户配置 MCP 时，Codemode 会自动加载，也可以作为默认工具加入配置。
为什么不是只做 Codemode，而要把 MCP 拉进核心
既然 Codemode 能解决部分问题，为什么不绕开 MCP 直接做自己的方案？Pi 团队给出的解释与“工具表达”有关。过去几个月，他们为适配新模型做了大量工作，包括延迟加载工具、会话中途插入系统消息、调整推理级别等，但 Pi 现有的工具装载方式还没有完全升级，以更好匹配这些新能力。
在 Codemode 场景中，开发者必须决定一个工具是直接暴露给大模型，还是只暴露给 Codemode 部分。普通 MCP 扩展无法从 Pi 的工具装载中获得足够元数据，因此很难良好支持这类体验。为了让工具可以配置为“仅延迟加载”或“仅 Codemode 使用”，团队选择把相关能力纳入核心。
换句话说，Pi 并不是简单宣布“MCP 很重要”，而是认为：MCP 与 Codemode 结合后，有机会缓解 MCP 长期存在的一些问题。与其站在外部批评，不如进入协议生态，参与塑造它如何适配小型 harness。
对开发者意味着什么：MCP 正在进入“适用边界”讨论阶段
从这篇讨论看，MCP 的热度已经推动行业进入下一阶段：从“要不要接”转向“怎么接、接多少、在哪里接”。
- MCP 不再只是模型连接外部工具的统一答案，其实际效果高度依赖 server 的设计方式。
- 把所有工具说明塞入上下文的粗暴做法，正在被更强调结构化返回和按需发现的方案挑战。
- 沙箱、权限、状态保存和调用编排，正在成为 AI 工具链集成中无法绕开的工程问题。
- 开发者真正关心的不是协议名称，而是工具是否可控、可组合、可维护。
Pi 的态度变化说明，MCP 正在从一种被迅速传播的概念，变成需要在真实产品中接受检验的基础设施。它仍然有吸引力，但也暴露出组合性不足、生态实现参差、上下文成本高等现实问题。
对于正在构建 AI 编程助手、agent 平台或工具链集成方案的团队来说，Pi 这次转变提供了一个观察样本：MCP 的价值不在于无条件接入，而在于能否与沙箱执行、工具发现、延迟加载和代码式编排结合起来。若只是把工具堆给模型，MCP 并不能自动解决复杂性；只有当协议、运行时和工具生态一起成熟，它才可能成为稳定的集成层。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/cong-gong-kai-ju-jue-dao-yuan-sheng-zhi-chi-pi-jiang-mcp-na
