一个MCP服务器尚未执行任务就占用1.8万个token，Pi给出变通方案

在过去一年的大部分时间里，尽管MCP协议已成为各类开发者工具的标准，编程智能体Pi始终没有将其纳入。Pi的创建者马里奥·泽希纳有明确的理由：他测量了热门浏览器自动化服务器的上下文开销，发现仅Chrome DevTools MCP一项就占用约1.8万个token，约为20万token上下文窗口的9%，而此时智能体还未做任何有用的事。去年11月，泽希纳详细阐述了这一问题：Playwright MCP描述其21个工具需要约1.37万个token，占20万token窗口的6.8%，每增加一个服务器都会带来更多开销。他还对工具调用之后的情况感到困扰，指出MCP服务器不可组合，其返回的结果必须经过智能体的上下文，才能保存到磁盘或与其他结果合并。他给出的方案是使用Bash和少量脚本，因为模型本就熟悉这些工具，没有必要再教它一套庞大的工具接口。他基于命令行的浏览器工具只需一份225个token的说明文档，输出还可以通过管道传给其他命令、进行过滤或保存到磁盘，而无需先经过模型。在MCP成为Pi 1.0的原生功能之前，pi-mcp-adapter等扩展已为Pi提供了MCP支持。如今MCP已内置于Pi，但连接服务器并不会把其全部工具都呈现给模型。Pi不会把这些工具定义放入提示词，而是借助Codemode按需查找工具，通过JavaScript调用，并只返回有用的输出。今年早些时候收购Pi的Earendil表示，MCP已足够成熟，值得重新审视，但其解释更偏向实际考量：将MCP纳入核心，不仅是因为MCP本身的变化，也是因为它所需的改动总体上具有普遍价值。Pi此前已在Jev上采用同样的思路，把Codemode这一代码模式实现置于模型与工具之间，MCP得以沿用这一架构，而不必把每个工具直接暴露给模型。