最近总有人问，Pi 怎么又把 MCP 加回来了。
简单说，MCP 是让 AI 工具连上你其它工具的接口标准。这条之前收过一次，不重复。真正值得讲的是他们加回来的理由。
早先翻 pi.dev，官网上写着不打算支持 MCP。播客里聊过，Mario 还专门写过一篇解释为什么不加。这周发了篇新文章，标题直接把"你说过不要 MCP"这句话摆在自己脸上。
这期就这一件事，拆成几张卡片。
团队承认以前反对过，给的理由是世界不是静止的
点评：这话放在公关稿里是废话，放在这里反而是这期最实在的一句。他们说自己盯了 MCP 一年，今天的 MCP 和一年前不是一回事。你可以不同意这个判断，但它至少是个具体的判断，不是"顺应用户呼声"那种谁都能说的话。改口不丢人，丢人的是改了口还装作一直如此。
真正推动这次改动的，是顺便做出来的别的改动
点评：这条值得记。他们说这些改动的价值不限于 MCP 本身，改完之后 Jev 在 Pi 里用起来更顺了。判断一个功能该不该进核心，标准不是它流不流行，是你为它做的那些改动能不能被别的地方复用。普通人挑工具时也可以用这个尺子。
他们说 MCP 到现在最大的短板还是难以组合
这条是我这期最想讲的。
codemode，一句话讲清楚：它是跑在 harness 一侧的一套机制，用 JavaScript 把工具调用编排起来，让智能体在调用顺序上有更大自由度，用代码把几次调用串成一件活。
为什么重要。MCP 工具有个老毛病，就是难以组合。早先的做法基本是把工具直接塞进上下文，用一次占一块地方，很难连起来用。CLI 之所以高效，是因为模型能用 bash 把几条命令拼起来干一件事。他们的判断是，用 MCP 做到同样的事没有根本障碍。
Pi 的做法是把这些 MCP 工具暴露给一个 JavaScript 沙箱。Codex 等 harness 也是类似的路子。
他们把一部分原因算在外围服务器的实现方式上
点评：很多 MCP 服务器到今天还是按"把工具直接塞进上下文"那种 harness 设计的，靠返回文本来省 token。团队觉得方向不对，MCP 应该更接近 OpenAPI 加智能工具发现：工具返回结构化数据，靠文档和描述被找到。
老实说这条我只看懂一半。MCP 该长成什么样，和服务器眼下怎么实现，这两件事我还没理清，先放在这里，搞明白了再补一句。
他们说 Pi 和 MCP 的底层需求，其实是一回事
点评：两边都需要一个以解释器形式存在的沙箱环境。技术上是解释为什么接得顺，判断上是另一回事。两个东西的底层需求要是重叠，先做自己的、再接纳别人的，成本比想象中低。这也顺带解释了他们为什么不是一年前就加。
MCP 本来在 Pi 里也能用，只是以扩展的形式
点评：他们把"从扩展挪进核心"这个动作单独拎出来讲。意思很明确，不是"我们终于做了"，而是"我们决定把它放到更重的位置"。挪位置比加功能贵，因为挪进去就得长期维护。看一个团队重视什么，别听他们说什么，看他们愿意把什么放进默认配置。
一个示例：167 个未关闭 issue，11 条轻度沮丧
他们让 Pi 通过 codemode 调自家工具，接上 Linear 的 MCP，去给 issue 里评论者的情绪打分。
167 条未关闭 issue 里，156 条中性，11 条轻度沮丧，0 条高度沮丧。结果按条存在 codemode 的 frustration 下面，下次要查不用重新抓一遍。
那 11 条是这样的：README 缺安装章节的请求、按 Esc 之后卡在 Working 状态的 bug、想要一个 /update TUI 命令、macOS 长会话下 CPU 占用过高。
点评：这个示例比任何跑分都有说服力。11 条"轻度沮丧"里没有一条是"这软件真烂"，全是具体的小毛病。也就是说这套东西抓的是能改的事，不是情绪本身。
他们说要进去参与，不站在外面看
原文的说法是，影响一件事的最好方式是接纳它，所以他们想参与到 MCP 的讨论里，推动它在小体积 harness 里跑好。
点评：这句话本身没什么新鲜的。用在一个此前公开说不支持的团队身上，就有分量了。嫌一个东西不好，进去改它比站在外面骂它有用，前提是你有那个功夫。没有的话，也犯不上硬参与。
还提一句工具装填。团队说最近为适配新模型做了不少工作，支持延迟工具加载、对话中途插系统消息、调推理等级这些，但工具装填还没跟上。codemode 模式下还要决定某个工具是给大模型，还是只给沙箱用。这块我没吃透，先不展开。
本周就这些。
上面哪一条你试过、或者觉得我讲错了，欢迎告诉我。讲错的我补，没讲清的我改。
下周见。