从拒绝到拥抱：Pi为何支持MCP

背景：从拒绝到支持

Pi 团队曾公开声明不支持 MCP（模型上下文协议），甚至在其官网和播客中多次表达否定态度。然而，随着最新版本更新，MCP 已成为 Pi 的核心功能。这一转变并非一时冲动，而是基于对协议本身和 Pi 自身需求的重新思考。

改变的原因

首先，MCP 在过去一年中发生了显著变化，不再是早期不成熟的版本。但仅凭这一点不足以将其纳入核心——Pi 拥有强大的扩展生态，MCP 完全可以作为扩展存在。真正促使团队改变的是：他们发现 MCP 所需的基础设施与 Pi 自身的发展方向高度一致。例如，为了更好支持 MCP，Pi 需要引入一个沙箱环境来执行工具调用，而这个沙箱恰好也能让 Pi 更轻松地使用 Jev 等模型。

此外，Pi 团队认为，与其站在场外批评，不如主动拥抱并影响 MCP 的发展方向。当前 MCP 服务器和模式仍有改进空间，尤其是在工具组合方面。许多 MCP 服务器仍为简单的上下文填充而设计，缺乏结构化数据和智能发现能力。Pi 希望推动 MCP 更接近 OpenAPI 风格，让工具返回结构化数据，并通过文档和描述实现智能发现。

Codemode：工具调用的沙箱

Codemode 是 Pi 实现 MCP 支持的关键组件。它本质上是一个运行在代理循环侧的 JavaScript 沙箱，用于编排和协调工具调用。与传统的工具执行方式不同，Codemode 允许代理以更灵活的顺序调用工具，并使用 JavaScript 将它们组合起来。由于 Codemode 运行在可信的代理环境中，其状态会作为会话记录的一部分持久化，而非依赖文件系统。

Codemode 的另一个优势是它支持延迟工具加载和中间对话系统消息，这正好适配现代大语言模型的新特性。在 Pi 中，当配置 MCP 时，Codemode 会自动加载；用户也可以手动将其添加为默认工具。

实际应用示例

文章展示了一个生动的例子：用户要求 Pi 通过 Codemode 使用 Jev 模型找出问题跟踪器中最沮丧的评论者。Pi 自动调用 Linear MCP 列出所有开放问题，然后使用 Jev 对每个问题的评论进行情绪分类（中性、轻度沮丧、高度沮丧）。整个过程通过 Codemode 的 JavaScript 沙箱协调，并发处理多个问题，最终返回统计结果和标记的问题列表。

这个例子展示了 Codemode 如何将 MCP 工具（如 Linear）与模型能力（如 Jev）无缝结合，无需浪费上下文空间。Pi 团队强调，这种模式不仅适用于 MCP，还可以用于其他需要复杂工具编排的场景。

总结

Pi 对 MCP 的态度转变反映了技术世界的动态性。通过将 MCP 纳入核心并引入 Codemode，Pi 不仅解决了自身工具编排的痛点，也为 MCP 生态的改进提供了实践参考。团队表示将继续关注 Codemode 和 Jev 等新功能，并期待与社区共同塑造更智能的工具调用模式。

原标题：You said no MCP。 HN 原始发布时间：2026年9月30日星期三。当前记录为 619 分、348 条评论。

阅读原文 · 查看 HN 讨论