AI 写代码编译器却只给人看，Zero：一门给 Agent 设计的系统编程语言，让一切副作用显式可见

Vercel 的实验室最近放出一个叫 Zero 的东西一门自称给 Agent 用的系统编程语言2026 年 5 月刚发布 v0.1.1编译器用 C 写的文件后缀是 .0。单凭这个后缀就知道这是一门不肯对任何既有生态妥协的新语言。我翻了翻它的文档和仓库觉得这件事值得说一说。现在 AI Agent 写代码已经不算新鲜事了Claude、GPT 这些模型能替人读代码、改代码、甚至从零搭出一个能跑的小工具但有一个问题一直没人认真处理——Agent 需要的语言工具和人需要的不一样。人读编译器的报错看到一行英文提示就能改Agent 要的是结构化的、机器可直接消费的信息JSON 格式的错误码可解析的修复建议精确的类型约束和副作用边界。Python 和 JavaScript 的工具链是为人类终端设计的print 调试也好堆栈跟踪也好都是给人看的散文不是给程序解析的数据。显式还是显式Zero 的设计原则只有一句话一切副作用都显式声明。在 C 里你可以在任何函数里调用 open()、write()、malloc()编译器不管你碰了什么外部资源运行时出了错再说。Rust 试图用所有权和借用检查来约束内存安全但对 I/O 能力的管控仍然比较松散。Zero 走得更极端一个函数如果要写输出必须在参数里接收一个 World 对象通过 world.out.write() 来执行函数签名里还得标上 raises 关键字告诉编译器这个函数可能失败。你没办法悄悄访问文件系统或网络因为能力是通过参数传递的没有全局变量兜底。pubfunmain(world:World)-Void raises{check world.out.write(hello from zero\n)}这段代码看上去和 Rust 差不多但有几处关键差异。World 不是全局单例是运行时显式注入的raises 标记在签名上调用方必须用 check 处理可能的错误否则编译直接报错没有隐式 GC内存分配全部由程序员自己控制该在栈上的就在栈上该用 std.mem 的手动分配就手动分配。Agent 拿到一个函数签名不用读完整个函数体就能判断它会不会碰文件、会不会分配内存、会不会抛出异常。静态分发没有虚函数表没有运行时反射泛型在编译期直接单态化连函数名的特化结果都是确定的identity 直接变成 z_identity_i32。编译器要懂机器的语言现有的编译器无论 GCC、Clang 还是 Rustc错误输出都是给人看的文本偶尔带点颜色高亮格式从不稳定每个版本的措辞都可能变。Agent 要解析这种输出只能靠正则匹配或者让 LLM 再做一轮理解既不靠谱又不经济。Zero 的 CLI 提供了 --json 标志zero check --json 会吐出一个结构化 JSON里面有稳定的错误码如 NAM003 表示未知标识符有行号列号甚至有一个 repair 字段直接给出修复建议的元数据。zero graph --json 输出模块依赖图zero size --json 输出二进制体积分析Agent 可以直接拿来做出决策不需要先读懂一段自然语言。把编译器输出结构化的想法并不新鲜。Clang 早就有了机器可读诊断的尝试Language Server ProtocolLSP本身也是为了让编辑器能程序化地消费语言服务信息。Zero 的做法是把这种思路推到了更彻底的位置默认输出就考虑机器消费而不是事后加一层适配。专给小工具用的语言Zero 的目标场景很明确小型原生程序。它没打算取代 C 写浏览器也没打算取代 Rust 写操作系统瞄准的是那些几十 KB 到几 MB 的小型命令行工具、WebAssembly 模块、嵌入式组件。这类东西用 C 写手动内存管理是老生常谈的麻烦用 Rust 写学习曲线又足够吓退一批人Zero 想在两者之间找一个位置。编译目标列表也印证了这个定位。除了常见的 darwin-arm64、linux-musl-x64、win32-x64 之外它直接支持 wasm32-web编译成浏览器里跑的 WebAssembly。一个没有隐式运行时的语言编译成 WASM体积可以压得很小这对需要在前端跑原生代码的场景是有吸引力的。不过 Zero 目前还是实验阶段v0.1.1语言规范说变就变Vercel 自己也在文档里写了不建议用于生产。编译器本身用 C 语言写了大约 65%剩下是 JavaScript 负责的 CLI 和测试框架一门新语言的工具链自己有一部分用另一种语言实现这在早期阶段倒也正常Rust 最早也是用 OCaml 写编译器的。能力系统好不好使Zero 的能力系统其实就是 capability-based security 在编程语言层面的实现。World 对象是能力的载体函数签名声明了它需要什么能力编译器在编译期就检查能力是否可用。这种设计在操作系统领域早有先例seL4 微内核就是基于能力的安全模型进程之间传递能力令牌来授权资源访问。好处是显式和可审计一个函数能不能碰文件看签名就知道不需要读实现。代价是写起来啰嗦每个需要 I/O 的函数都得在参数列表里带上 World即使写一个 hello world 也不能省。短期来看这会劝退一部分习惯快速原型的开发者但在 Agent 场景里这种啰嗦恰恰有价值——Agent 不需要猜测一个函数的副作用签名里写得清清楚楚。当然Zero 的能力系统还比较粗糙。目前的 World 对象只有 out 和 err 两个主要接口文件系统访问还是实验性的只有 host 目标支持 std.fs网络能力几乎还没开始做。它更像是一个骨架具体能力还得一个个往上填。Zero 试图回答一个问题当 AI Agent 变成代码的主要生产者之一时编程语言应该长什么样。目前的答案是让一切显式让函数签名成为一份完整的契约声明返回类型、声明可能的错误、声明需要的外部能力。现有语言是为人类终端设计的把它们的工具链直接交给 Agent 用中间的摩擦不会小。https://github.com/vercel-labs/zeroAI Agent 到底需不需要一门专属的编程语言这事现在下结论还太早但方向摆在那里了。你怎么看欢迎在评论区聊聊。