骂了 MCP 一整年的 Pi，把它装进了核心——这不是打脸，而是 Agent 行业最诚实的一次认错
AI飞行客 骂了 MCP 一整年的 Pi，把它装进了核心——这不是打脸，而是 Agent 行业最诚实的一次认错
2026 年 10 月，Pi 发了一个更新。
核心内容一句话：它把 MCP（Model Context Protocol）装进了自己的核心。
而就在一年多前，Pi 的作者 Mario Zechner 把 MCP 称为”不必要的东西”。
一家公司、一个创作者，公开骂了一整年的协议，然后 180 度掉头把它请进自家架构的核心。这事如果只看表面，像一次打脸。但如果你真懂 Agent 生态在发生什么，你会明白——这是这个行业近期最诚实的一次认错，而且认错的方向，值得每个做 Agent 的人抄下来。
先把事实摆清楚
Pi 是谁？一句话：一个以”极简”为信仰的 AI 编码 Agent。它不是 Claude Code 那种开箱即用的成品，它更像”毛坯房”——只提供最基础的 Agent 循环、状态管理、会话和上下文管理、工具调用，其余一切按需扩展。
它的哲学很清楚：minimalism and malleability（极简与可塑性）。你给它什么就有什么，不给就什么都没有。
而 MCP 是 Anthropic 主推的开放协议，作用是把大模型和外部工具、数据源之间的上下文传递标准化。业内的比喻是”AI 应用的 USB 接口”。它一度是 2026 年最火的标准，几乎所有主流工具都在接。
所以当初 Zechner 骂它”不必要”，是有底气的——因为 Pi 的整个世界观就是”我不需要标准化的重工具接口，我只要轻量的 CLI 就够了”。
那为什么转头就”真香”了？
收购 Pi 的公司 Earendil（Armin Ronacher 和 Colin Daymond Hanna 创办）给出的解释很克制：”事情会变（things change）。”
具体是两件事：
第一，MCP 本身变好了。 它不再是最初那个笨重的样子。
第二，Pi 的开发者自己对 MCP 做了改造，让集成其他能力变得更容易。
但更真实的答案，藏在技术细节里。
核心矛盾：MCP 到底是”便捷”还是”包袱”
要理解 Pi 的转向，得先理解 MCP 最大的争议点——它到底省事，还是费钱。
MCP 有一个被点名批评了很久的毛病：很多 Agent 客户端会把发现的 MCP 工具描述和出入参结构，一股脑全塞进上下文。 哪怕你一次会话最多只用其中一两个工具。
这带来什么后果？初始上下文开销不菲。
有人吐槽过：”谁说 DeepSeek API 省钱，我发了一句’你好’就花了几毛钱！”——罪魁祸首很可能就是 Coding Agent 的初始上下文被 MCP 工具定义撑爆了。你还没干活，token 就先烧了一堆。
这正好戳中了 Pi 这种”极简派”的痛点。所以当初 Pi 的立场是：我为什么不能为这类应用配一个 CLI 工具？就像 tavily 的 `tvly` 一样，依赖不多，用文档描述用法让模型远程调用就行。（事实上真有人写了把 MCP 封装成 CLI 的工具，比如 `mcporter`。）
但这里有个反方论点也很硬，而且我认为是 Pi 最终低头的关键：
MCP 最大的优势，是”能及时把最新的接口告知 Agent”。
想象一个场景：远程接口发生了破坏性变更，而你本地的 CLI 工具还没更新——那就调用失败了，你甚至不知道错在哪。而 MCP 服务每次可以把最新的接口模式定义递给 Agent，这本质是一套”标准化的能力发现和同步机制”。
再进一步：在 CLI 不可用的场景下，你也就只能用 MCP 来调用外部能力。
这就是 Pi 认输的技术逻辑。它骂的不是”MCP 这个协议”，它骂的是”早期 MCP 实现那种粗暴的上下文填充方式”。当 MCP 实现了延迟加载、按需披露，而 Pi 自己也把集成做得更聪明之后——原本的冲突就不存在了。
这次更新，Pi 到底加了什么
Pi 这次的更新不止一个 MCP。它还端出了一套东西：
– Pi Durable：一个新的 Agent Harness（框架），官方定位是”不替代 Pi coding agent，而是一个用来构建任何 Agent 应用的框架”——包括编码 Agent。 – Codemode：一个 harness 侧的沙箱，帮助 Agent 发出工具调用，支持 MCP、决策模型和图像模型。 – 延迟工具加载（deferred tool loading）：这正是解决上下文膨胀的关键。 – Anthropic 模型的缓存预热（cache warming）。 – 对话中途的系统消息（mid-conversation system messages）、虚拟模型扩展、新 TUI 主题、默认全屏模式。
注意 Pi Durable 的自我定位——它共享的不仅是代码（比如 pi-ai），还有 Pi 的原则：极简与可塑性。
翻译一下：Pi 没有变成它讨厌的那种重工具。它在保持极简内核的同时，把”标准化接口”作为一层可选的、聪明的扩展接了进来。 这是妥协，但不是投降。
我的判断
第一，这不是打脸，这是”务实派”的胜利。
一个以极简为信仰的项目，愿意承认”标准化的能力发现机制是刚需”，这需要的不是勇气，是清醒。它的原话是”things change”——但真正变的不只是 MCP，而是它终于分清了”协议的哲学”和”协议的实现”。骂一个协议的糟糕实现，不等于要否定这个协议存在的必要。 这个区分能力，很多技术人一辈子学不会。
第二，延迟加载才是这次更新真正的关键，别被”MCP”这个标题带偏。
MCP 从被嫌弃到被接纳，转折点不是协议本身变神圣了，而是上下文问题有了工程解法。Pi 这次加的是”延迟工具加载”——也就是说，工具定义不再无脑塞进上下文，而是按需披露。
这背后是 Agent 行业一个更普适的教训：任何”标准化接口”如果处理不好上下文成本，都会变成负债。 反过来，任何”轻量方案”如果解决不了能力同步，都会变成技术债。两者从来不是非此即彼。
第三，对整个 Agent 生态来说，这是好事。
当连最”轴”的极简派都开始接 MCP，说明一件事：标准化已经赢了。 不是赢在强制，而是赢在”你最终会发现不接它的成本更高”。这对开发者是好消息——接口统一意味着迁移成本降低、工具复用率提高。
给实操的建议： 如果你在做 Agent 应用，Pi 这次的思路可以直接抄——保持内核极简，把重能力做成”可选的、按需披露的扩展层”。 不要为了接标准而牺牲内核的干净，也不要为了内核干净而拒绝标准。Pi Durable 就演示了这两种立场怎么共存。
最后说一句：一个骂了 MCP 一年的项目转头接了它，我不觉得丢人。真正该被嘲笑的，是那些明明知道自己错了、却为了面子和立场硬扛到底的人或项目。
Pi 这次，把面子放下来了，把架构做对了。