Pi.dev MCP 集成及 Codemode 的引入

Pi.dev 已正式将其核心功能中集成 Model Context Protocol (MCP)，逆转了此前对协议的公开反对立场。这一转变源于 MCP 的演进以及对更强大工具调用编排机制的需求，Pi 通过引入「Codemode」——一种基于 JavaScript 的沙箱环境，来解决这一问题，实现工具协调。

将 MCP 集成至核心

Pi 已将 MCP 从可选扩展升级为核心功能，因为支持该协议所需的架构变更被发现对整个系统普遍有益。具体而言，集成使得在 Pi 中更轻松地使用 Jev 成为可能，并提供了 MCP 和 Pi 所需的解释器沙箱环境。

尽管 Pi 承认 MCP 仍面临挑战——尤其是组合性方面的问题——但团队认为当前协议状态相比早期版本已显著改进。Pi 对 MCP 的处理方式类似于 OpenAPI，强调智能工具发现，即工具返回结构化数据，并可通过文档和描述进行发现。

Codemode：新的编排层

Codemode 是一种运行在 harness 侧（即代理循环所在位置）而非工具侧（即 bash 或其他外部进程运行位置）的 JavaScript 沙箱。它作为协调和编排工具调用的机制，允许代理使用 JavaScript 以更大的灵活性组合多个工具，实现更灵活的执行顺序和流程控制。

Codemode 的关键技术特性

• 执行环境：在 harness 所在位置运行，意味着其状态作为会话转录的一部分被维护，而非存储在本地文件系统中。
• 实现方式：使用作为 WASM 二进制文件分发的小型 JavaScript 版本，以在安全性和性能之间取得平衡。
• 自动加载：当配置 MCP 时，Codemode 会自动加载，但也可通过 Pi 的配置默认启用为工具。
• 目的：它在直接的 JSON/XML 工具调用（安全但功能有限）与 Bash 执行（功能强大但缺乏内在安全性和类型检查）之间提供了一个中间地带。

解决组合性问题

引入 Codemode 与 MCP 的主要原因之一，是为了解决 MCP 传统上存在的组合性问题。通过使用 JavaScript 沙箱，Pi 使模型能够更有效地串联工具。例如，用户可请求 Pi 使用「通过 Codemode 的 typesafe/jev 来找出我们问题追踪器中情绪最激动的 20 位评论者」，系统将自动结合 Linear MCP 与 Jev 完成分析，而不会浪费上下文。

社区观点与技术争论

该公告在开发者社区中引发了关于 MCP 与传统基于 CLI 的工具使用孰优孰劣的技术争论。

支持 MCP 与 Codemode 的观点

• 互操作性：一些开发者认为，MCP 提供了一个广泛兼容的生态系统，类似于 USB-C，广泛采用的价值远超少数“最优”但碎片化的专有解决方案。
• 迭代开发：MCP 允许开发者更快地迭代工具接口，因为代理通常比硬编码脚本更能容忍接口变更。
• MCP 作为配置工具：用户报告称，他们使用 MCP 通过自然语言配置复杂的 macOS 应用程序，利用现有应用逻辑，而非要求模型从零开始编写复杂代码。

反对意见与替代方案

• Codemode 的冗余性：一些批评者认为，Codemode 是不必要的，因为 LLM 已经非常擅长使用 Bash 或 Python 脚本串联工具。
• 协议批评：部分用户认为，MCP 本质上只是 REST API 或 OpenAPI 的替代品，质疑为何不从标准 HTTP 协议开始。
• 复杂性问题：有人担忧，向核心集成会为原本简洁且可扩展的 harness 带来“臃肿”问题。

"人们犯下的关键错误是，他们只从自己的工作流和本地栈出发思考，而不是从团队的工作流和团队的运营栈出发。" — @CharlieDigital