Pi编码Agent一年唱衰MCP后拥抱：工程决策复盘

Pi.dev 首页曾经骄傲地声明：Pi 不支持 MCP。不是遗漏，不是 TODO，是一种立场声明。创作者 Mario Zechner 在博客和播客里批判 Model Context Protocol 超过一年。他的论点具体而有力：一个流行的 Playwright MCP server 在每次会话里往模型上下文塞入 21 个工具定义和 13,700 个 token，而一个 README 完善的 CLI 工具在智能体真正需要它之前零成本。

2026 年 9 月 29 日，Pi 发布 0.99.0 版本。MCP 现在是一项受支持的核心功能。团队发布了一篇自嘲的公告，标题叫"You Said No MCP!"，几小时后就登上了 Hacker News 榜首，收获数百个点赞和数百条讨论，争论这究竟意味着什么。

关键在于：这不是失败。这可能是今年关于智能体工具走向最有价值的信号。

首先，"不用 MCP"的立场为何合理

Pi 是一个极简编程智能体，建立在一条简单规则上：不需要的东西就不做。开箱即用，模型只有四个工具：read、write、edit 和 bash。其他一切，包括子智能体、plan 模式、权限弹窗和 MCP，都刻意留给扩展去添加。发布时，整个系统提示词加上工具定义不到 1,000 个 token，而竞品的 harness 携带数万 token。

反对 MCP 的论点是 token 消耗论。MCP 的标准做法是：每个连接的 server 在你的上下文窗口里预先加载所有工具的完整 schema 定义。每个工具定义根据复杂度不同，消耗 550 到 1,400 个 token 不等。连接三个 server，你的智能体在做任何实际工作之前就会烧掉一大块窗口。

最常被引用的数字来自 Perplexity。他们的 CTO 在 2026 年 3 月的一个会议上说，三个 MCP server 消耗了他们 200,000 token 上下文窗口中的 143,000 个。这意味着在智能体回答第一个问题之前就有 72% 的税。Perplexity 之后在内部弃用了 MCP。有段时间，整个行业似乎都在跟进：2026 年初最响亮的声音宣称 MCP 已死，CLI 工具才是赢家。

Pi 团队没有屈服于压力。他们的公告列出了具体条件，值得理解，因为同样的条件适用于几乎所有智能体 harness。

MCP 本身在演进。2026 年 7 月的规范修订将无状态操作作为主要关注点，移除了让生产部署痛苦的 initialize 握手和会话层。该协议在 2025 年 12 月被捐赠给 Linux 基金会，但采用数字仍在攀升：超过 17,000 个公共 server、数亿次月度 SDK 下载，以及大量企业 AI 团队在生产环境运行基于 MCP 的智能体。反对一个潜在用户已经在生产环境中运行的协议，无论技术优劣，都是失败的立场。

成本问题得到了真正的解决。Pi 没有简单粗暴地添加 MCP 支持。他们发布了一个叫 Codemode 的东西，这部分值得研究。

对他们来说集成几乎零成本。Pi 的 harness 本来就需要一个 JavaScript 沙箱来运行 Codemode。有了这个之后，MCP 支持只是一小步而非重写。正如团队所说：积极影响一件事的最好方式就是拥抱它。

Codemode 实际上做了什么

旧模式：模型预先看到每个工具的完整 schema，选一个，输出一个 JSON 工具调用，等待结果回到上下文，选下一个工具，重复。每个中间结果都成为上下文窗口的永久居民。

Codemode 模式：模型直接写 JavaScript。那个脚本在 Pi harness 内运行的 QuickJS 沙箱中执行，沙箱可以访问 MCP 工具。模型通过文档发现工具而不是预先加载的 schema 块，从代码中调用它们、串联它们，只有最终结果才回到上下文。

三个具体收益，反映了任何开发者写脚本而非点击按钮时发生的事情：

更少的往返次数。 十个工具调用的链式执行是一次沙箱执行而非十次模型轮次。这是真实的延迟差异，不是跑分虚荣数字。

更少的 token。 中间结果留在沙箱内。只有最终值进入上下文。72% 的税变成了舍入误差。

可重复性。 如果智能体明天需要重复一个工作流，它复用已经写好的脚本。脚本成为制品，而非被丢弃的工具调用。

Cloudflare 早些时候用他们的 Code Mode 工作描述了同样的模式：暴露一个极小的搜索和执行面，让模型针对类型化 SDK 写代码，在沙箱中运行。他们的主张是，你可以为固定约 1,000 token 的成本把整个大型 API 交给智能体。

一个架构细节值得关注。早期的 Codemode 风格实现在可组合性上存在问题：每个想要代码执行的 MCP server 都自带沙箱，沙箱之间无法相互调用。Pi 把沙箱放在 harness 里而非 server 里。一个沙箱，所有配置好的 MCP 工具都在其中可用，跨厂商组合正常工作。在 HN 帖子里 Pi 维护者确认了这是设计，有评论者注意到较新的前沿模型越来越针对这种工具使用形态进行训练，这比任何单一实现都重要。

那么是 MCP 赢了，还是大家都累了？

两种解读都有支持，诚实的报道应该同时呈现。

屈服解读： 2025 年和 2026 年初每个著名的 MCP 怀疑者现在都在出货 MCP。OpenAI、Google、Microsoft、AWS、Cloudflare 和 GitHub 都参与了该协议的治理。当连首页上嘲讽该协议的团队都加入时，争论就被生态系统的引力解决了，而非哪一方论点更优。HN 帖子里大量这种论调：人们注意到 2026 年 3 月"MCP 已死"的观点在几个月内就严重过时了。

演进解读： Pi 采纳的 MCP 确实不是被批评时的 MCP。无状态规范修订、延迟工具加载、返回结构化数据而非文本倾倒、harness 级沙箱——这些修复正是怀疑者提出的具体抱怨。批评者没有输。他们的反馈变成了路线图。

HN 讨论中最有趣的观点来自企业开发者：在企业环境中，MCP 实际上已经成为第三方智能体访问公司数据的安全和认证边界。在那个层面上"写一个带 README 的 CLI 工具"不是严肃的替代方案，无论它对个人开发者的终端工作流多么优雅。

如果你现在在构建智能体，这意味着什么

如果你认真对待了 2026 年 3 月的讨论，并把 MCP 从技术栈中移除，这周会很尴尬。实践要点：

停止预加载工具 schema。 无论你使用什么协议，延迟发现优于预先倾倒。暴露文档而非完整定义，让模型按需拉取细节。

把组合逻辑移出模型循环。 多步骤工具链属于只运行一次的代码中，而非十次顺序推理轮次中。那段代码是 bash 脚本、Python 图还是沙箱中的 JavaScript，不如这个原则重要。

返回结构化数据，而非散文。 MCP server"倾倒文本"的抱怨对太多 server 仍然成立。如果你编写工具，让它们返回脚本可以串联的类型化数据。

关注模型的训练方向。 Codemode 形态设计的最强论据是前沿模型提供商正在按照这个形态训练模型。与工具调用模式匹配训练数据的智能体表现更好，就像模型更擅长写 bash 而非发明 shell 语法一样。

Pi 花了一年时间对 MCP 提出了一个技术上有见识的论点，但最终还是输了。这不是一个关于"错了"的故事。这是一个关于"赢得争论"和"赢得生态系统"之间差异的故事。MCP 赢了，因为它成为了智能体与一切之间交互的默认接口，而默认值不需要是最好的设计，只需要足够好且无处不在。

对开发者来说真正的好消息是，这种趋同迫使 MCP 变得更好。Token 税、无状态传输、沙箱化组合：这些修复存在是因为响亮而明智的批评者拒绝让缺陷溜过去。现在正确的做法不是在已定案的争论中选边站。而是借鉴架构：延迟工具发现、代码优先的编排、结构化返回。你的上下文窗口会感谢你。

我每周写关于 AI 工程和开发者工具的文章。订阅，免费。

你的智能体技术栈里还保留着 MCP 吗，还是在"MCP 已死"的浪潮中把它删掉了？是什么推动你做出选择？