一个终端里的编程 agent，只带四个基础工具：读文件、写文件、编辑文件、跑终端命令。没有内置子 agent，没有计划模式，没有权限弹窗，扩充功能全靠运行时加载 TypeScript 扩展。这个叫 Pi 的开源项目，2026 年 5 月并入 Earendil 公司，五个月后 GitHub star 攒到了 11.2 万。
2026 年 10 月 1 日，Earendil 发布 Pi 1.0，Hacker News 上的发布帖拿到 1618 分、552 条评论。讨论里让人意外的一点是：Pi 原生支持了 MCP（Model Context Protocol）。
为什么意外？因为十个月前的 2025 年 11 月 30 日，Pi 的创建者 Mario Zechner 还在自己的博客上写道：“pi does not and will not support MCP”。他的理由是，MCP 服务器上下文开销大而且没法组合，agent 直接用命令行和代码，才是组合性最好的工具界面。
官网记录过这个承诺。互联网档案馆 Wayback Machine 的 pi.dev 2026 年 5 月 31 日快照里，“What we didn’t build” 清单写着 “No MCP”。到 2026 年 10 月 2 日的快照，同一位置变成了 “No MCP Now with MCP+Codemode”。
曾经坚决反对 MCP 的项目，在 1.0 里把 MCP 发进了核心。表面上看，这像是一次立场反转。但看代码实现会发现，Mario 当年拒绝的 MCP 和最终收编的 MCP 是不同的东西。要理解这个转向，得先看清 MCP 在 2024 年做了什么样的假设。
2024 年 11 月 25 日，Anthropic 发布 MCP，首版规范标注为 2024 年 11 月 5 日。当时开发 agent 的一大难题是接口碎片化：OpenAI、Anthropic 和 Google Gemini 对工具调用的格式各不相同，为一个平台写好的工具，换到另一个平台往往要重写一遍适配层。MCP 想解决的问题就是提供统一标准，写一次工具服务器，任何客户端都能接。我们在 2025 年 3 月的统一工具协议的诱惑里，曾把这种愿景类比为 agent 世界的通用物理接口。
但在抹平接口差异的同时，MCP 也固化了一套来自实验室的技术假设：模型必须是一切交互的唯一中心。这套协议由 Anthropic 研究员为探索模型与大量工具的交互而建，模型自然处在每一次交互的中心：每个工具的定义、调用参数、返回结果，都必须全量进入模型的上下文窗口。上下文窗口因此同时干两件事：当工具目录，列出每个工具能干什么、参数长什么样；当运输通道，工具调用的中间数据都从它面前过。早期 MCP 用本地 stdio 管道通信，认证机制也是后加的，这些选择在实验室里都成立。
挂载两三个简单工具时，这套机制运转顺畅。放到实际工程里，工具定义本身就先成了负担。Anthropic 在 2025 年 11 月 24 日的高级工具使用技术分析里披露：GitHub 官方 MCP 服务的 35 个工具定义占用约 26,000 token，5 个服务共 58 个工具占用 55,000 token，内部测试中甚至达到过 134,000 token。模型还没开始推理，数万 token 已经花在接口描述上。
更严重的瓶颈在数据传输阶段。工具返回长报表、日志或代码文件时，协议要求这些原始内容全数经过模型的注意力机制，推理费用与延迟随之上去，琐碎细节还干扰模型的推理焦点。
所有数据都要经过模型的注意力，这个假设在工程里撞了墙。分流的路径是工程实践自己找到的：让代码充当第二条通道。三个独立来源交叉验证了这个转向。
第一个验证来自 Anthropic 自己。2025 年 11 月 4 日，Anthropic 工程团队发布用 MCP 做代码执行一文：让 agent 写代码调用工具，token 用量从 150,000 降到 2,000，降幅 98.7%。Cloudflare 发表过类似发现，把这种做法称为 Code Mode。
第二个验证来自终端原生 agent。Claude Code、Cursor 和 Codex 直接在终端里工作，原生调用 git 或 GitHub CLI，不依赖协议封装。我们在 2026 年 3 月的飞书和钉钉发 CLI里指出过：企业平台提供命令行接口，能让终端 agent 以最小摩擦组合能力。
第三个验证是 Pi 1.0 的 Codemode 模块，它换了调用者的位置。传统 MCP 用法里，调用者是模型：它发起每一次工具调用，每次往返的参数和完整返回值都过一遍它的注意力。Pi 把调用者换成了主模型写的脚本：模型只负责写一段代码，说清楚调哪几个工具、按什么顺序串；脚本随后在 Pi 的沙箱里自己跑，循环、并发、批量都不再经过模型。
沙箱是把 QuickJS 引擎编译成的 WebAssembly（codemode
包文档），随 harness
一起运行，拿不到网络和系统能力，唯一出口是挂进来的 MCP
工具。这些工具默认不进主模型的工具声明，在 Pi 里的标记是
exposure: "codemode"（源码），写脚本时用
searchTools() 搜目录、按名字直接调。同样是接 MCP，Anthropic
是在一篇文章里示范 code 通道怎么做，Pi 把它设成了默认：挂进来的 MCP
工具默认走这条通道，主模型声明列表里看不到它们。Earendil 在 2026 年 9 月
29 日的博文《你说过不用
MCP！》里给了个典型场景：脚本把 Linear 工单逐条交给分类器 API Jev
判情绪、四次并发，回到主对话的只有一份统计汇总，几十条工单原文一次都没进过上下文。
组合在注意力之外完成，脚本也少了逐轮概率性路由的偏差。我们在 2025 年 10 月的Apps SDK 危机文里指出的矛盾随之化解：不必用私有方言绕过规范，沙箱代码本身就是干净的数据边界。
代码成了第二通道之后，回头再看 Earendil 在《你说过不用 MCP！》里的论述，取舍就清楚了。博客写道，MCP “should be much closer to OpenAPI with intelligent tool discovery”，更接近带智能工具发现的 OpenAPI，工具应该返回结构化数据。
取舍之后，MCP 的职责范围收缩了：它退出运输通道，留作工具目录。工具怎么找、参数长什么样、能返回什么，这些描述机器照着读就行；数据本身不再从它这里过。MCP 官方也在朝这个方向更新自己的协议，2026 年 7 月 28 日的规范修订移除了初始化握手和长期会话状态，卸下了运行时的状态包袱。
这种演变在分布式通信的历史上并不陌生。回顾 Sun RPC、CORBA 到 gRPC 的四十年，核心路径始终是：接口描述语言编译成各语言原生的调用桩代码，数据在业务代码之间直接流动，不绕道协议本身的控制进程。MCP 正在补上这份作业。
转向的时机，Hacker News 上的评论者 hhh 点破过：Jev 这类工具火起来还不到一个月，MCP 发展了近两年，现在才得到支持？Armin Ronacher 的回答是：“we look at what the models are doing”，模型在各自的 harness 里训练出来，他们无意对抗模型的行为。模型的行为习惯已经偏向用代码调工具，靠协议搭建厚重的交互中间层随之变得多余；顺着模型的行为做工程决策，把数据传输与组合交还给代码。
这并非退步。留在目录这一层的价值随模型能力提升不断增值：工具目录越全、描述越准，模型和脚本越容易取用；硬把中间数据压进模型注意力的运输通道则不断贬值。MCP 的存活方式，恰好写在它的这次降级里。
让 agent 在后台跑个长任务，比如整理一个大仓库。跑到一半终端一关、进程一崩，重开之后 agent 两眼一抹黑：上次干到哪了、哪些干了一半，全都不知道，任务只能从头再来。工具怎么接的问题刚有了答案，一个新的麻烦接着浮出来，Earendil 在发布 Pi 1.0 的同一天给出的回应是框架 Pi Durable，Hacker News 发布帖拿到 474 分、65 条评论。官方给 harness 下的定义是一套存储，加上跑对话所需的全部机器。它不替代 Pi 编程 agent，任何 agent 应用都能拿它当基础设施用。落到使用者的感知上，是三件事。
第一件事等于游戏里的存档（durable
包文档）。每推进一步，先存这一步的档：任务跑到第 40
步进程崩了，重开后从最近一次存档接着走，崩在半路的请求自动重发，已完成的历史都还在。工具调用崩在半路，重不重跑由工具自己声明：声明
replay: "safe"
的工具（比如只读的搜索）可以重跑，没有声明重跑资格的，模型带着提示继续跑：“Tool
${call.name} was interrupted and may have partially
run”。哪些动作能安全重来，哪些不能，这个决断留给了写工具的人。
第二件事是历史随时能分岔。从转录的任意一步可以直接拉出一条平行分支：新分支持有截至那一步的全部历史，不复制任何数据文件，配置也沿用那一步的快照。想试另一条路线，开个分支去试，试废了就扔，原来的对话原样留在原地。
第三件事是人可以随时插进来。对话跑在哪，客户端就能接到哪：新客户端先取当前状态的快照，再订阅之后每一步的增量操作流，看到的世界和现场一致；对话跑着的时候照样能插话，带
whenBusy: "steer"
标记的插话会在当前这轮工具跑完后插队处理，不必等一轮跑完才改主意。
这一层问题，同一周里不止 Pi 一家在回答。DeepSeek Harness 让代码组合批量工具调用，会话接管只做收养，连接断了当场报错、不假装什么都没发生；Claude Code 的插件系统开放修改底层行为，但 mods 没有沙箱。工具层上，各家已经收敛到同一套组合：CLI 加代码。而进程死了对话怎么办，还没有标准答案；Pi Durable 拿出来的东西之所以有分量，在于它把三件事拆成三个可以单独评审、单独借用的框架层，而不是捆在一个黑盒里。
边界同样如实交代：Pi Durable 标注 experimental，接口后续可能变更；检查点只覆盖沙箱内的状态，虚拟机和容器里的东西不在存档范围；存储同一时刻只归一个进程所有，不支持跨进程并发写入。发布刚一天，还没有独立的生产应用记录。
新协议和新框架还会不断出现，评估它们可以用两个朴素的问题。第一个：底层模型的推理能力提升十倍之后，这个设计还成立吗？它的核心价值会随之升值还是贬值？第二个：它当下解决的是哪个具体工程问题？这个问题在你的系统里还在吗？
2024 年大模型应用探索初期，MCP 靠统一接口规范，确实缓解了多模型适配的麻烦；与此同时，它也带来了一套对 agent 系统的想象：模型是信息交流和指挥调度的中心。随着模型逐渐能写代码，这套中心化的通道假设失去了最初的合理性，通道这一层职责交还给代码，协议留下目录和发现机制。
这给系统构建者留下一条工程原则：不要从任何协议的形而上学假设出发。设计早期不必急于把系统绑定在某一种协议上，这种克制省下上下文损耗和通信复杂度，也为将来接入现成生态目录留下最小代价的可能。回头看 Mario 当年的拒绝和今天的收编，两次选择并不矛盾：他拒绝的是把数据强行塞进模型注意力的运输通道，接纳的是一份机器能查、脚本能用的工具目录。
任何协议想在 agent 生态里长期存续，出路在于跟着模型能力演进主动收缩职责，把具体的执行权交还给代码。守住最初的绝对控制权，做不到这一点。