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 关键字，告诉编译器这个函数可能失败。你没办法悄悄访问文件系统或网络，因为能力是通过参数传递的，没有全局变量兜底。

pub fun main(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 Protocol（LSP）本身也是为了让编辑器能程序化地消费语言服务信息。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/zero

AI Agent 到底需不需要一门专属的编程语言，这事现在下结论还太早，但方向摆在那里了。你怎么看？欢迎在评论区聊聊。