Armin 长文《What is Codemode》解读
Pi 1.0 用 Codemode 把 MCP 工具编排搬进 WASM 沙箱，文中贴出让 Jev 驱动游戏引擎连跑 30 步决策的实测代码。
Armin Ronacher 昨天发了篇长文《What is Codemode》，系统解释了为什么在 Pi 1.0 里通过 Codemode 支持 MCP。他一年多前在博客呼吁《Code Is All You Need》，反对往模型上下文塞一堆 custom tools，现在这套设计演进成了一个更底层的架构划分：把系统明确切成 Brain 和 Hands Brain 是宿主层的编排引擎（harness），属于高信任区；Hands 是运行工具的执行环境（比如跑 bash 的沙箱），属于低信任区。两者信任级别不同，也在完全不同的文件系统上。很多工具无法做成普通 CLI 程序。读取图片塞进多模态协议、生成和调度子代理，都属于 harness 内部的原生能力，跑在 Hands 里的普通 bash 脚本无法直接调用 Codemode 跑在 harness 内部专门的受限沙箱里（Pi 选的是 WASM 里的 QuickJS，无网络、无磁盘文件系统、无计时器）。模型在这里写 JavaScript 专门做工具编排。比如 bash 输出了几千行，传统 tool call 要么被硬截断到 2000 行，要么挤爆上下文；在 Codemode 里，模型可以用 JS 先探查前 5 条看结构，再做并发过滤；中间状态还能调 store() 直接存入会话 transcript，跨 turn 接着读，数据不落地到执行机磁盘 常规的单步分类器（比如 Typesafe Jev）或者生图模型，直接当 tool 暴露给大模型极其浪费上下文。Pi 把这些 API 挂进 Codemode，让代码在沙箱里自己跑循环调分类器判状态，只把最后的结果送回主模型。Armin 在文章里贴出了让 Jev 驱动游戏引擎连续跑 30 步做决策的实测代码 对现在的 MCP 生态，Armin 直接用了「A Fight」来形容。因为大部分 harness 之前不支持 Codemode，像 Cloudflare 只能在 MCP server 内部跑 Codemode；现在放到 Pi 这种客户端里，直接演变成了「Codemode in Codemode」，在 JS 脚本里拼接另一段 JS 再发给 MCP execute，产生双重 JSON 转义，小模型极易写崩 目前阻碍 Codemode 普及的还有 MCP 本身的几个缺口：缺少规范的 structured content（outputSchema 普及慢）、缺乏大二进制数据支持、工具搜索无法跨 server 组合 把 Agent 交互从「逐个调 API」推进到「沙箱内写调度脚本」，能大幅压缩上下文浪费，但代价也摆在明处：对小模型的代码生成与嵌套转义要求极高，而且一旦执行中断，必须依赖类似 Durable Workflow 的工作流引擎来做状态快照