“你不是说不支持 MCP 吗！”
原文： “You Said No MCP!” — Earendil 作者： Earendil Engineering · 原文发布日期： 2026 年 9 月 29 日 翻译说明： 本文根据原文 PDF 译为中文，翻译由 AI 完成。正文保留作者的第一人称表述，文中的“我们”指 Earendil 团队。产品行为与判断以原文发表时为准；文末演示已根据补充的会话记录完整呈现，交互式回放请访问原文。 如果你过去访问过 pi.dev，就会看到一条颇为自豪的声明：Pi 不支持 MCP。如果你听过我们谈论 Pi 的播客，也会发现我们不止一次对 MCP 表达过不以为然的态度。Mario 还专门写过一篇文章。然而，现在升级 Pi 后，你会发现 MCP 已经成为受支持的功能。发生了什么？ 事物会变 首先要记住，世界并非一成不变。过去一年，我们一直在关注 MCP，而今天的 MCP 已经不是过去的 MCP 了。不过，单凭这一点，还不足以成为把它纳入核心的理由。你也知道，Pi 拥有很出色的扩展生态，MCP 完全可以做成一个扩展，对吧？甚至可以是一个得到 Earendil 官方认可的扩展。 没错，MCP 确实可以作为扩展存在，而且之前就是如此。如今 MCP 成为核心的一部分，是我们坐下来共同讨论、重新思考后的结果。 到底发生了什么变化？ 我们把 MCP 纳入核心，不只是因为 MCP 本身发生了变化，还因为我们发现，为支持它而需要做出的改动具有普遍的价值。例如，我们为 MCP 做的改动，也让在 Pi 中使用 Jev 变得更加容易。归根结底，Pi 所需要的东西与 MCP 所需要的相当接近：一个以解释器形式提供、可供操作的沙箱。 尽管 MCP 在很多方面都有了改善，但也有不少问题依旧存在。MCP 最大的问题仍然是难以组合。即使有了 Codemode——一个用来组合工具调用的精巧小沙箱——MCP 在这方面也还没有完全兑现承诺。不过，到了现在，这更多是现有 MCP 服务器，以及不同 Agent 运行框架（harness）与这些服务器交互方式的问题，而不完全是 MCP 本身的问题。 ...