小墨同学札记 · 文章导读
Pi 为什么又接纳了 MCP
如果你更早接触 Pi，大概记得它的官网曾经明确写着“不支持 MCP”，作者在播客和文章里也不止一次表达过对 MCP 的怀疑。可升级到 0.99.0 之后，你会发现 MCP 已经成了 Pi 的内置功能。2026 年 9 月 29 日，Earendil 发表了《“You Said No MCP!”》，专门回答这个转变。
这篇导读用我自己的话梳理文章的四个要点。想看原文论证，请读英文原文。
一、不是突然改口，是 MCP 和 Pi 都变了
文章的出发点很朴素：世界不是静止的。团队过去一年一直在观察 MCP，今天的 MCP 已经不是当初那个样子。
但仅仅“MCP 变好了”并不足以让它进入核心。Pi 本来就有成熟的 Extension 生态，MCP 早就可以、也确实以 Extension 的形式存在过。真正让团队决定把它放进核心的，是重新思考之后发现：支持 MCP 所需的那些改动，本身对 Pi 也普遍有用。
二、到底变了什么
我把文章里的判断归纳成三层：
| 层面 | 文章的判断 |
|---|---|
| Pi 自己需要的 | 一个可以“玩耍”的沙箱，也就是一个解释器。这恰好也是 MCP 需要的。同一套改动还让 Pi 更方便调用 Jev 这类分类模型。 |
| MCP 仍然没解决的 | 最大的问题依旧是难以组合。不过作者认为，这更多是现有 MCP 服务器和各家 Harness 用法的问题，而不是协议本身。 |
| 理想中的 MCP | 更接近“带智能发现能力的 OpenAPI”：工具返回结构化数据，并能靠文档和描述被找到，而不是一股脑塞进上下文、靠返回纯文本省 token。 |
文章还给了一个对比：CLI 好用，是因为模型能用简洁的 Shell 写法把命令串起来。MCP 没有理由做不到这一点。Pi 的做法是把 MCP 工具暴露给一个 JavaScript 沙箱，让模型像写脚本一样组合它们。
三、为什么不只做 Codemode，不做 MCP
这是文章预料到的追问。回答分两部分：
- Pi 的工具配置需要升级。 新一代模型支持延迟加载工具、对话中途插入系统消息、切换推理强度，Pi 前几个月已经为这些能力做了大量适配，但工具的“装配方式”还没跟上。在 Codemode 里，每个工具都要决定：是直接给模型用，还是只在 Codemode 脚本里可见。普通的 MCP Extension 拿不到足够的元数据来做好这件事。
- 主动参与比旁观更有影响力。 团队认为 MCP 加上 Codemode，能解决 MCP 过去的不少毛病，而现有服务器和使用模式仍有改进空间。与其站在场外看，不如参与进来，推动 MCP 在小巧的 Harness 里也好用。
这一点对应 0.99.0 更新记录里的工具暴露方式（直接、仅模型、Codemode、延迟、隐藏），可以在版本档案里对照查看。
四、Codemode 是什么
文章用“信任边界”来解释。Harness 执行工具大致有两个位置：
- Shell 运行的地方：通常在不太可信的沙箱里。
- Harness 自身的 Agent 循环运行的地方：通常是可信环境。
Codemode 特别之处在于它运行在 Harness 这一侧。最好把它理解成编排工具调用的机制：模型可以用 JavaScript 决定调用顺序、并行调用、把多个工具的结果组合起来。因为它运行在 Harness 侧，它的状态保存在会话记录里，而不是文件系统里。
为什么选 JavaScript？文章的解释是，小型 JavaScript 运行时可以打包成 WASM，体积小，也能提供合理的隔离。按 0.99.0 的更新记录，Pi 用的是 QuickJS 沙箱。
文章最后演示了一个例子：在 Pi 里用一句话，让 Codemode 通过 Linear 的 MCP 拉取 issue，再交给 Jev 分类模型逐条判断评论语气，最后汇总出情绪最激动的几条。整个过程中，大量中间数据留在 Codemode 脚本里处理，而不是灌进对话上下文。
对蓝皮书读者意味着什么
- 新手不需要因此改变学习顺序。 固定流程和检查标准仍然优先写成 Skill；已有 CLI 能做好的事，仍然先用 CLI。参考手册的 Skill 和 MCP 怎么选 已按 0.99.0 更新。
- 配置了 MCP，Codemode 会自动加载；没配置 MCP 也可以把 Codemode 加为默认工具。原文建议直接让 Pi 自己改配置来启用它。
- MCP 进入核心，不等于“装得越多越好”。 每接入一个服务器，都要承担工具说明、认证和维护成本；先确认它解决了什么具体问题，再接入。