Pi开发团队Earendil曾在官网和播客中多次公开表示不支持MCP（Model Context Protocol），如今却在最新版本中将MCP正式纳入核心功能。团队在博文中解释了态度转变的原因：MCP在过去一年持续演进，如今的MCP已与早期版本大不相同；更关键的是，为支持MCP所做的架构改造本身具有普遍价值，例如让Jev等能力更容易在Pi中使用。团队坦承MCP仍有明显短板——可组合性差，许多MCP服务器仍为’直接将工具塞入上下文’的传统harness设计，靠返回文本优化token效率。他们认为MCP的理想形态应接近’带智能工具发现的OpenAPI’，工具应返回结构化数据并可按文档描述被发现。为此，Pi将MCP工具暴露到JavaScript沙箱中，推出Codemode机制：它运行在可信的harness侧，作为工具调用的编排协调层，允许Agent用JavaScript灵活组合调用顺序，会话状态保存在对话记录而非文件系统中；JavaScript因其可编译为WASM二进制并获得沙箱保护而被选用。文中演示了通过Codemode组合Linear MCP与Jev，自动分析issue跟踪器中167条开放问题的情绪倾向，其中156条被判定为中性、11条为轻度不满、无高度不满。团队表示，拥抱MCP正是为了亲身参与并塑造其发展方向，而非站在旁观者位置。
事件分析
技术层面，本文展示了Agent工具调用架构的演进方向：将编排逻辑从不可信的工具沙箱迁移到可信的harness侧，用轻量JavaScript沙箱实现灵活的调用组合，并配合模型的延迟工具加载、会话中途系统消息、推理级别切换等新能力扩展工具规模。产业层面，MCP的可组合性短板长期存在，Pi的实践表明症结不在协议本身，而在服务器返回结构化数据与智能工具发现的生态共识尚未形成。’拥抱以影响’的策略也不同于此前纯对抗性的协议竞争，Codemode加MCP的组合或将成为中小型Agent harness的参考架构，后续值得关注的还有Jev这类专用分类模型的实际落地，以及MCP服务器规范向结构化返回演进的速度。
核心观点：MCP的胜负手不在协议本身而在可组合性，谁先把工具编排变成写代码，谁就掌握Agent生态的话语权。
原文链接：Hacker News
