从“拒绝”到“拥抱”：一场基础设施的务实转身
曾经，Pi团队在多个场合高调声明其工具不支持MCP（Model Context Protocol），甚至发表过质疑其必要性的文章。然而，如今MCP已悄然成为Pi的核心功能之一。这种180度的大转弯并非单纯的妥协，而是技术演进下的理性选择。正如工程团队所言：“世界不是静止的。”MCP在过去一年中发生了显著变化，而Pi在重新评估后，发现支持MCP所要求的技术改造，恰好与自身需求高度契合。
核心痛点：组合性难题与沙箱机制
虽然MCP有所改进，但其最大短板依然是“难以组合”。许多现有的MCP服务器仍沿用旧思路，将大量工具直接抛入上下文以优化Token效率，导致灵活性不足。Pi团队认为，理想的MCP应更接近OpenAPI，通过智能工具发现和结构化数据返回来提升效率。
为了解决这一问题，Pi引入了“Codemode”概念。它不仅仅是一个运行在信任环境中的解释器沙箱，更是一个工具编排机制。传统的工具调用往往发生在不可信的文件系统层面，而Codemode允许智能体在可信的Harness层通过JavaScript逻辑来协调、顺序化并组合多个工具调用。这种机制让AI能够像人类程序员编写Bash脚本一样灵活地“串联”各种功能。
为什么不能只做“纯代码”模式？
有人可能会问：既然有了强大的Codemode，为何不直接抛弃MCP？答案在于现代LLM的新特性。随着模型支持延迟工具加载、对话中途系统消息及推理级别动态调整，工具元数据的精细配置变得至关重要。仅靠传统的MCP扩展无法提供足够的元数据来支撑这些高级特性，而将MCP与Codemode结合，正好填补了这一空白，使得工具可以被配置为仅延迟加载或特定于代码模式。
“我们认为，影响某样事物最好的方式就是拥抱它。”
结语：参与塑造标准
Pi团队指出，目前的MCP服务器和调用模式仍有很大优化空间。他们选择不再站在 sidelines（旁观者）上，而是通过深入集成来参与对话，推动协议在小型Harness环境中更好运作。这提醒我们，在AI基础设施领域，坚定的立场可能因技术迭代而需灵活调整，真正的进步往往发生在不同理念的碰撞与融合之中。
