Pi.dev：你说没有 MCP

如果您过去访问过 pi.dev，您会发现一个自豪的声明：Pi 不支持 MCP。如果您收听我们谈论 Pi 的播客，您会发现我们不止一篇关于 MCP 的轻蔑言论。包括 Mario 的一篇关于它的帖子。然而，如果您升级到 Pi，您会发现 MCP 现在是受支持的功能。发生了什么？事物在变化 首先要记住的是，世界并不是一成不变的。去年我们一直在关注MCP，今天的MCP已经不是去年的MCP了。然而，仅此一点并不足以成为将其放入核心的理由。如您所知，Pi 拥有一个出色的扩展生态系统，MCP 肯定可以成为一个扩展吗？甚至可能是埃仁迪尔认可的延期。是的，你确实是正确的，MCP 本来可以是一个扩展，就像它一样。 MCP 现在成为核心的一部分是我们集思广益并重新思考的结果。到底改变了什么？我们将 MCP 引入核心的原因不仅在于 MC​​P 发生了怎样的变化，还因为我们发现它所需的更改通常是有用的。例如，我们对 MCP 所做的更改也使 Jev 在 Pi 中的使用更加容易。最终 Pi 需要的东西与 MCP 需要的东西非常相似：一个以解释器形式运行的沙箱。虽然 MCP 在很多方面都得到了改进，但也有不少方面没有改进。 MCP 的最大问题仍然是它难以创作。即使使用 codemode（它只是一个允许编写工具调用的简洁小沙箱），MCP 也无法完全实现这一点。但此时的问题不是 MCP 的问题，而是 MCP 服务器的问题以及与它们一起工作的不同方法。许多 MCP 服务器仍然是为仅将工具转储到上下文中的工具而构建的，并尝试通过返回文本来优化自身的令牌效率。目前我们对 MCP 的看法是，它应该更接近具有智能工具发现功能的 OpenAPI。这意味着工具应该返回结构化数据，并且工具应该可以通过其文档和描述来发现。 CLI 如此实用的原因是代理和模型只是通过高效的 bashism 将东西连接在一起。但也没有根本原因说明您无法使用 MCP 做到这一点。 Pi 中的 MCP 只是建立在将这些工具暴露给 JavaScript 沙箱的基础上，就像 Codex 等其他工具一样。现代 LLM 中的 MCP 这会提出一个问题，为什么我们不直接在没有 MCP 的情况下进行 Codemode。这个问题的部分答案与当今 Pi 中工具的表达方式有关。近几个月来，我们做了很多工作，让 Pi 能够理解新模型，这些模型允许延迟工具加载、对话中系统消息和推理级别更改。然而，我们尚未升级我们的工具加载以更好地扩展这些新功能。在 Codemode 世界中，人们需要决定该工具是否适用于法学硕士或仅适用于法学硕士的代码模式部分。普通的 MCP 扩展无法从 Pi 的工具加载中获得足够的元数据来使该体验良好运行。因此，我们需要确保工具可以配置为延迟或特定于 Codemode。虽然我们可以连接元数据来实现更好的 MCP 扩展，但我们也认为带有 Codemode 的 MCP 解决了很多传统上存在的问题。我们相信积极影响某事的最佳方式就是拥抱它。虽然我们认为现代 MCP 比以往的 MCP 更好，但服务器和模式仍然有改进的空间。因此，我们希望成为这种对话的一部分，并帮助它在小型安全带中发挥良好作用，而不是站在场边袖手旁观。什么是代码模式？现在我们谈论了很多关于 Codemode 的内容，也许有必要解释一下它到底是什么。当harness执行工具时，在大多数情况下它有两个方面：它可以在bash运行的地方执行，或者可以在harness代理循环运行的地方执行。双方的信任程度相差很大。线束循环通常在受信任的环境中运行，而它执行的工具通常在不太受信任的沙箱中运行。 Codemode 的特殊之处在于它在线束运行的地方运行。最好将其理解为一种编排和协调工具调用的机制。它是一个沙箱，允许代理以更灵活的方式发出这些工具调用，并允许其使用 JavaScript 将它们组合在一起。由于 Codemode 也在线束端运行，因此其状态也作为会话记录的一部分而不是文件系统进行维护。现在理论上任何语言都可以做到，但 JavaScript 非常有吸引力，因为 JavaScript 的小版本可以作为 WASM 二进制文件提供，并提供合理级别的保护。在 Pi 中，配置 MCP 时会自动加载 Codemode，也可以将其作为