Pi.dev：你们曾说不支持 MCP
Hacker News 摘要这是一篇来自 Earendil 工程团队的技术公告，解释了为什么开发工具 Pi 从最初明确反对并拒绝支持 MCP（Model Context Protocol，模型上下文协议），转变为如今将其直接集成到核心功能中。
转变的原因与背景
过去，Pi 团队曾多次公开表示不支持 MCP。如今团队改变了立场，主要原因包括：
• 技术环境的变化：过去一年中 MCP 本身发生了很大演进，不再是最初的状态。
• 通用底层需求：为了更好地支持 MCP 所做的架构调整，对 Pi 的其他功能同样非常有价值，例如能够让 Jev 等工具更容易在 Pi 中运行。它们共同的需求是一个基于解释器的沙盒环境。
• 直接集成的必要性：虽然 MCP 最初可以作为插件存在，但要配合现代大语言模型的新特性（如延迟加载工具、对话中途插入系统消息、动态调整推理级别等），工具系统需要更细粒度的元数据控制，决定工具是直接暴露给大语言模型，还是仅在代码执行环境中可用。普通插件架构无法很好地提供这些元数据，因此团队选择将其内置到核心系统中。
• 积极参与生态建设：团队认为影响技术的最佳方式是亲自接纳并参与其中，而不是站在一旁观望，他们希望帮助改进现有的 MCP 服务端模式与实践。
MCP 目前的局限与 Pi 的设想
团队指出，MCP 目前最大的问题仍然是难以进行灵活组合：
• 很多现有的 MCP 服务端仍然是针对“直接把工具描述硬塞进上下文”的旧架构设计的，往往只返回纯文本来勉强优化标记（Token）效率。
• Earendil 团队认为，理想的 MCP 应该更接近带有智能工具发现机制的 OpenAPI 规范，工具应返回结构化数据，并通过清晰的文档和描述供模型发现。
• 传统的命令行界面（CLI）之所以高效，是因为智能体和模型可以通过简单的脚本语法自由组合工具。MCP 也应该做到这一点，Pi 的做法就是将这些工具暴露给 JavaScript 沙盒来执行。
核心机制：什么是 Codemode？
Codemode 是 Pi 解决工具组合与调用安全问题的关键机制：
• 运行位置与信任级别：传统的工具调用通常直接运行在底层的 Bash 环境中，沙盒信任度较低；而智能体的运行循环往往处于更受信任的环境。Codemode 正好运行在智能体循环这一侧。
• 工具编排与协调：它是一个沙盒，允许智能体使用 JavaScript 来自由编排、决定调用顺序并组合多个工具调用。
• 状态维护：由于运行在框架层，Codemode 的状态会直接保存在会话记录中，而不需要依赖文件系统。
• 轻量与安全：系统选用 JavaScript 是因为可以通过轻量级的 WebAssembly（WASM）二进制文件来分发运行，兼顾了灵活性与安全性。
实际应用场景
在 Pi 中，配置 MCP 时会自动加载 Codemode，用户也可以将其作为默认工具开启。启用后，模型不仅能使用 MCP 工具，还能跨工具协同分析。例如，结合 Linear 的 MCP 和 Jev，智能体可以直接在 Pi 内部编写逻辑筛选出问题追踪系统中情绪最沮丧的前 20 位评论者，并在沙盒内完成计算，避免将大量无用数据倾倒进上下文从而浪费标记。