pi 为什么突然又准备加 mcp 了？我记得原来pi说可以用cli实现的就没有必要加mcp，所以砍掉了。我还观察到一个现象：api/mcp，cli，gui 基本上可以说是 agent 调用工具的三个层级。能在上级解决的都不要往下级走。比如说一个查询信息的例子：websearch/webfetch，browser use，computer use，越往下走的代价越大。说说你的看法

【回复 群友 3892】 先纠正一个事实：pi 并不是“专门为了 MCP 又把它加回来”。官方文档里，MCP 是以内置扩展（built-in extension）的形式提供的，默认的 exposure（工具暴露方式）是 codemode，也就是模型写 JS 脚本，在沙箱里调用工具；deferred（延迟加载）交给 tool_search，direct（直接暴露）只留给少量高频工具。它并没有回到“把所有工具塞进上下文”的老路。当初砍掉 MCP，反对的是“每个工具占一个 schema、塞爆上下文”这种形态；这次回来的是协议层，调用形态仍然是“用代码组合工具”。所以这不算自相矛盾，因为判断标准变了：问题在于上下文预算够不够，工具能不能用、成本高不高已经不再是重点。 你提的三层，我的看法是： 它是一条“代价递增”的连续谱，但不是严格的上下级。api/mcp 和 cli 其实属于同一档：确定性高、可组合、结果结构化，差的是接口的形态；gui 和 cu 是另一档：不确定性来自视觉和坐标，任何一步都可能失败。真正该按层级往上走的，是从 bu 到 cu 再到 api 这一段，你这点判断对。 但“能在上级解决的都不要往下级走”不能走极端。纯按严格层级来，很多任务注定做不了：登录态、验证码、只有前端能触发或才能完成的操作，API 根本不存在。更实际的原则是：默认从上往下试，往下走要有明确理由，并且要能验证结果。也就是说，能确定就不要猜，能结构化就不要靠像素。 而一旦决定要往下走，代价就不只是 token 或延迟，还有可靠性和验证成本：cu 的结果很难验证，因为它没有“返回码”，只有“看起来对了”。所以往下走之前，先问一句“结果怎么确认”。这也是 pi 那套 codemode 思路的价值：工具调用能写成代码，就能顺便完成过滤、重试和断言；而 bu 和 cu 的每一步都要靠模型重新看图判断，验证成本会高得多。 还有一层常被忽略：越往下，可观测性和权限越差。API 有日志、有 rate limit、有 scope；cu 走的是“以人为单位”的账户权限，出事就是全权限误操作。所以往下不是能力升级，是安全性降级。 结论：你的层级直觉是对的，但更适合作为“成本梯度”来用，而不是严格的执行顺序。默认自上而下，往下要留退路；判断标准是该用哪层把事办成、并且能证明事情办成了，而不是必须用最上层。