过去访问 pi.dev 会看到派（Pi）骄傲声明不支持模型上下文协议（MCP）。在我们的播客里也不止一次轻视 MCP，包括马里奥（Mario）的文章。但升级派（Pi）后，MCP 已是受支持的功能。世界并非静止，过去一年我们关注 MCP，今日的 MCP 已非昔比。派（Pi）本有扩展生态，MCP 曾作为扩展存在，但它现在进入核心源于重新思考。

如果你以前访问过 pi.dev，会看到一条自豪的声明：Pi 不支持 MCP。如果你听过我们聊 Pi 的播客，会发现我们不止一次对 MCP 表示不屑，包括 Mario 写的一篇相关文章。但只要你升级 Pi，就会看到 MCP 现在已是受支持的功能。发生了什么？

变化是常态

首先要记住，世界不是静止的。过去一年我们一直在关注 MCP，今天的 MCP 已不是过去的 MCP。但仅凭这点还不足以把它放进核心。Pi 有很好的扩展生态，MCP 本可以是扩展——事实上它确实曾是。MCP 如今进入核心，是我们一起重新思考后的结果。

到底变了什么？

把 MCP 纳入核心，不只是因为 MCP 变了，还因为我们发现它所需要的改动普遍有用。比如我们为 MCP 做的改动，也让 Jev 在 Pi 中更容易使用。Pi 需要的东西和 MCP 需要的东西很像：一个可玩的沙箱，形式就是解释器。

MCP 有很多地方变好了，但也有不少没变。最大的问题依然是难以组合。即便有 codemode——一个用来组合工具调用的小沙箱——MCP 也没能完全解决这点。不过到这一步，问题与其说在 MCP，不如说在现有的 MCP 服务器，以及各个 harness 与它们协作的不同方式。

许多 MCP 服务器仍是给那种把工具直接倒进上下文的 harness 构建的，靠返回文本来优化 token 效率。我们现在对 MCP 的理解是，它应该更接近带智能工具发现的 OpenAPI：工具应返回结构化数据，并且能通过文档和描述被发现。

CLI 之所以好用，是因为 agent 和模型用高效的 bash 手法把东西串起来。但没有根本理由说 MCP 做不到这点。Pi 里的 MCP 就是把这些工具暴露给 JavaScript 沙箱，Codex 等其他 harness 也是这么做的。

现代 LLM 中的 MCP

这引出一个问题：为什么不干脆只做 Codemode，不做 MCP？部分答案与 Pi 今天表达工具的方式有关。近几个月我们做了很多工作，让 Pi 能配合支持延迟工具加载、对话中途系统消息和推理等级变化的新模型。但我们还没升级工具配置，让它更好地适应这些新能力。

在 Codemode 的世界里，必须决定某个工具是对 LLM 可用，还是只对 LLM 的 codemode 部分可用。普通的 MCP 扩展从 Pi 的工具配置里拿不到足够元数据，无法让这个体验良好运作。所以我们需要确保工具可以配置为延迟加载，或者专属于 Codemode。

我们本可以只把元数据接好来支持更好的 MCP 扩展，但我们也认为 MCP 加上 Codemode 能解决它传统上的不少问题。我们相信，积极影响一件事的最好方式就是拥抱它。虽然我们认为现代 MCP 处于前所未有的好位置，但服务器和模式仍有改进空间。我们想参与这场对话，帮助它在小 harness 中良好运作，而不是站在场边看着。

Codemode 是什么？

说了这么多 Codemode，值得解释一下它到底是什么。harness 执行工具时大多有两个侧面：可以在 bash 运行的地方执行，也可以在 harness agent 循环运行的地方执行。两边的信任级别差别很大。harness 循环往往运行在受信任的环境中，而它执行的工具往往运行在不那么受信任的沙箱里。

Codemode 的特殊之处在于它运行在 harness 运行的地方。最好把它理解为一种编排和协调工具调用的机制。它是一个沙箱，让 agent 以更灵活的顺序发出这些调用，并允许用 JavaScript 把它们组合起来。由于 Codemode 也运行在 harness 这一侧，它的状态也是作为会话记录的一部分维护，而不是存在文件系统里。

理论上任何语言都行，但 JavaScript 很有吸引力，因为小体积的 JavaScript 可以作为 WASM 二进制发布，并提供合理程度的保护。

在 Pi 里，配置 MCP 时 Codemode 会自动加载，也可以作为默认工具加入配置。直接让 pi 重新配置自己来启用 codemode 就行。之后你可以用它做很多有意思的事，不只是 MCP。比如当你登录的提供商提供「Jev」时，可以这样做：

通过 codemode 使用 typesafe/jev，找出我们问题追踪器上最沮丧的 20 位评论者

它会巧妙地结合 Linear MCP 和 Jev 来完成这项分析，全程都在 Pi 内，完全不浪费上下文。

以下是 Pi 中这样一次会话的精简回放。

关于 Jev 和 Codemode，我们以后还会说更多，但希望这篇帖子能作为一个例子，说明我们如何随着世界不断演变，继续有思考地调整和更新 Pi。

讨论整体偏质疑：多数人认为这篇文章答非所问、Codemode 的立论站不住脚，少数人则为 MCP 的实用性辩护。分歧主轴是——MCP 的价值到底来自协议本身，还是仅仅来自一个大家都愿意接的公共生态；以及模型本来就擅长用 shell 组合工具，为什么还要再套一层 Codemode。

认为 MCP 的缺陷可以被生态兼容性抵消

• 把 MCP 类比成 USB-C、NVMe、HDMI：都不完美，但因为广泛兼容、对最终用户足够简单而胜出，与其要七八种各自"最优"的 LLM 接入方式，不如要一个虽然粗糙但会逐步变好的统一生态（较多人）
• 有人坦言自己也不喜欢 MCP，但在公司环境里接上内部 MCP 之后，日常工作的可用性提升极大（少数人）
• 有刚上手 Pi 的用户表示根本没意识到它不支持 MCP，还一直以为维护这些连接是自己的责任，读到文章才发现"无 MCP"就写在首页第一个图标上（少数人） > 它可能性能、健壮性和一致性都不行，但会随着时间变好，我宁愿要现在这个广泛的 MCP 生态（@_fw）

认为 Codemode 是在解决一个不该存在的问题

• 模型早就有组合多个操作的最佳工具，那就是 bash 或任何系统 shell；真正的问题是 MCP 没被暴露给这个工具，而不是缺一个 Codemode（较多人）
• Codemode 本质上只是让模型运行一段脚本去调用载体自己的工具，而 coding agent 本来就能靠 shell、Python、Node 脚本拼出任意逻辑，放进核心完全没必要（较多人）
• 模型对链式调用 bash 和 Unix 工具的训练已经好到不可思议，不用这个能力很奇怪；唯一说得通的理由是不想让模型直接用 shell 时的权限管理（少数人） > 模型已经被训练得很擅长串联 bash 和常见 Unix 工具，为什么反而要绕开这个能力？难道只是权限问题？（@raincole）

与其做 MCP 协议，不如按需生成 CLI 工具

• 在他们看来 MCP 无非是"终于把 API 文档写成了程序可读的形式"，那么更直接的做法是从 MCP server 按需生成带文档的 CLI 工具（少数人）
• 有人用 skills 加 CLI 工具替代 MCP 和 tools，通常直接让 coding agent 生成这个 CLI，好处是更容易调试，而且自己也能手动验证它是否正常工作（少数人）

认为文章本身含糊、答非所问

• 标题写的是 MCP，正文却几乎没有一行讲清 MCP 到底是什么（较多人）
• 文章还把 Codemode 和 MCP 混着讲，解释方式很怪，而这两者看起来都是最新版本才引入的东西；Pi 用户不如直接让 agent 去读那个 PR（较多人）
• 有人直接判定这是一篇假装回应标题、实则全程绕圈子的文章（较多人） > 一篇假装回应标题、实则一直在绕圈子的文章（@Sha1rholder）

担心 Pi 正在偏离原有路线、堆砌插件

• 有人觉得 sub-agents 支持属于基础设施级别的功能，不该当作可选项；聪明的模型调度多个弱模型干活、再让同一强模型做对抗性审查，会成为常见模式（少数人）
• 把大部分能力做成插件让人联想到 Eclipse 那种松散拼装的混乱，因此转向开箱即用的 OpenCode；也有人感叹 Pi 也开始积累 cruft 了（少数人） > Pi 也开始积累 cruft 了（@Phemist）

有价值的补充

• Codemode 与 HuggingFace smolagents 的思路相似：模型写出调用工具的代码，而不是每一轮用 JSON 描述工具调用；区别在于 Codemode 被包装成模型按需调用的一个工具，用来一次组合多个工具调用
• MCP 至今没有公认的文件上传方案，实践中可能得绕开协议、直接用 HTTP 上传
• 一个冷知识：文章里提到的"无 MCP"标识其实就挂在项目首页最显眼的位置，但新用户很容易先入为主地忽略它