---
layout: post.njk
source: https://yage.ai/share/mcp-demotion-survival-20261004.html
speaker: yage.ai
title: 说不用 MCP 的人把 MCP 发进了核心：协议靠降级存活
date: '2026-10-04'
summary: 文章解析Pi项目从拒绝到原生支持MCP的转变，指出MCP通过降级为工具目录、将数据传输交还给代码执行（Code Mode）以解决上下文瓶颈。同时介绍Pi Durable框架解决长任务进程中断后的状态恢复问题，强调协议设计应顺应模型能力演进，避免形而上学假设。
area: tech-engineering
category: ai-application
tags:
  - mcp
  - code-mode
  - agent-architecture
  - context-window
  - durable-execution
people:
  - Mario Zechner
  - Armin Ronacher
companies_orgs:
  - Earendil
  - Anthropic
  - Cloudflare
products_models:
  - Pi
  - Pi Durable
  - MCP
media_books: []
draft: true
status: evergreen
---

## 说不用 MCP 的人，把 MCP
发进了核心

一个终端里的编程
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”。

博客写于 2025 年 11 月的这句拒绝，在
pi.dev 项目页上一直挂到 2026 年 5 月末，10 月的同一位位置写上了 No MCP
Now with MCP+Codemode。

曾经坚决反对 MCP 的项目，在 1.0 里把 MCP
发进了核心。表面上看，这像是一次立场反转。但看代码实现会发现，Mario
当年拒绝的 MCP 和最终收编的 MCP 是不同的东西。要理解这个转向，得先看清
MCP 在 2024 年做了什么样的假设。

## MCP
的祖宗之法：模型是一切交互的中心

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 已经花在接口描述上。

更严重的瓶颈在数据传输阶段。工具返回长报表、日志或代码文件时，协议要求这些原始内容全数经过模型的注意力机制，推理费用与延迟随之上去，琐碎细节还干扰模型的推理焦点。

工具定义与数据都先进模型窗口，代码接管之后绕开模型，回到模型的只剩结果。

## 第二通道：code

所有数据都要经过模型的注意力，这个假设在工程里撞了墙。分流的路径是工程实践自己找到的：让代码充当第二条通道。三个独立来源交叉验证了这个转向。

第一个验证来自 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
危机文里指出的矛盾随之化解：不必用私有方言绕过规范，沙箱代码本身就是干净的数据边界。

同一个 agent
的两种工具接法：左边所有调用都穿过模型，右边脚本绕开模型直连工具。

## 协议靠降级存活

代码成了第二通道之后，回头再看 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
生态里长期存续，出路在于跟着模型能力演进主动收缩职责，把具体的执行权交还给代码。守住最初的绝对控制权，做不到这一点。