Vercel Zero 语言观察：Agent 时代，编译器也得会给机器读

Vercel Labs 做 Zero，表面上是又一门系统编程语言。真值得看的不是“它要不要挑战 Rust、Go、Zig”，而是另一个问题：如果代码的主要生产者、调试者、修复者越来越多地变成 Agent，编程语言和编译器该不该换一套默认设计。

Zero 的答案很直接：让能力显式，让诊断结构化，让内存和依赖可预算，让修复动作可以被机器读懂、再由人决定是否执行。

这不是一门现在就该拿去写生产服务的语言。仓库自己也写得很清楚：pre-1、unstable、安全漏洞应被预期，不适合生产系统、敏感数据或可信基础设施。但它提供了一个很好的观察窗口：AI 编程不是只给现有语言套一层 Copilot，底层工具链本身也可能开始按 Agent 的工作方式重做。

Zero 的关键不是新语法，而是新读者

传统语言默认读者是人。错误信息要人能看懂，标准库要人能记住，工具链输出要人能在终端里扫一眼。

Zero 的假设更激进：读代码、读错误、决定修复方案的，可能是 Agent。这个假设会倒逼语言设计发生变化。

几个设计目标在 README 里写得很明确：

Agent-first learnability：语言表面要小、规则要稳定，Agent 能靠示例、文档和编译器反馈快速学会；
deterministic tooling：诊断、依赖图、大小报告、解释和修复计划要结构化；
standard-library depth：常用能力尽量放在标准库，不让 Agent 每写一个小程序就先全网找依赖；
regularity over syntax：宁可显式一点，也不要为了人类手感藏太多魔法。

这套取舍会让人写起来不一定最爽，但对 Agent 很友好。Agent 不怕多写几行，它怕隐式副作用、模糊错误、不可预测依赖和“你自己猜”的工具输出。

第一眼该看 World：I/O 不是全局魔法

Zero 的 hello world 长这样：

ZERO

pub fun main(world: World) -> Void raises {
    check world.out.write("hello from zero\n")
}

这里最重要的不是 main，而是 world: World。

程序没有从全局 stdout 写东西，而是通过传入的 World capability 写输出。换句话说，一段代码能不能碰 I/O，不是藏在运行时里，而是可以从接口上看出来。

这对 Agent 很关键。Agent 在修改代码前，需要判断一段函数会不会写文件、发网络请求、访问环境变量、启动进程。传统项目里，这些能力可能藏在全局对象、隐式 import、框架 hook 或第三方库里。Zero 试图把能力边界变成语言和工具链可以检查的事实。

在目标能力文档里，Zero 把 host capability 列得很清楚：args、env、fs、memory、net、proc、rand、stdio、time。非 host target 只暴露目标声明支持的能力。比如网络能力 net 不是所有目标都有，工具链会在 target 不支持时给出明确诊断。

这类设计对嵌入式、WASM、沙箱、Agent 工具调用都很有价值。它不只是“更安全”，更重要的是“更可审计”。

错误处理：让失败路径变成接口的一部分

Zero 没有靠隐藏异常来传播错误，而是用 raises 和 check 把失败路径写出来。

一个最小例子可以这样理解：

ZERO

fun validate(input: String) -> i32 raises { InvalidInput } {
    if input == "" {
        raise InvalidInput
    }
    return 42
}

函数声明里写明可能 raise 哪些错误；调用 fallible 操作时，需要用 check 或 rescue 处理。漏掉错误处理，编译器会报 ERR003 这类诊断。

这和 Rust 的 Result、Zig 的 error set 有亲缘关系，但 Zero 的重点不是“新发明错误处理”，而是把错误信息做成 Agent 可消费的合同。

它的诊断文档里，一个未知变量会报 NAM003。纯文本输出给人看，JSON 输出给工具看。JSON 包里有 severity、code、message、path、line、column、expected、actual、help、fixSafety、repair 等字段。

这就把“编译器报错”变成了“可编排的修复输入”。Agent 不必从彩色终端输出里抠字，也不必猜这个错误能不能自动修。fixSafety 会告诉它：只是格式问题、保持行为、局部编辑、API 变更，还是必须人工复核。

这点比很多“AI 编程工具”更底层。很多工具是在 IDE 层面猜怎么修，Zero 则想让编译器直接给修复决策提供结构化事实。

结构化诊断才是 Agent 工具链的硬通货

Zero 默认诊断不带 ANSI 颜色、粗体、超链接、终端控制序列。看着朴素，但理由很实在：这些字节对 Agent 是噪音，会污染上下文，也让日志比对更麻烦。

需要机器消费时，用：

BASH

zero check --json examples/hello.0

典型输出会是版本化 diagnostics packet。它不是一句“unknown identifier”，而是带定位、规则、期望值、实际值和修复元数据的结构。

Zero 还提供：

BASH

zero explain NAM003
zero explain --json NAM003
zero fix --plan --json examples/hello.0

这意味着 Agent 可以先拿到解释，再拿到修复计划，而且 --plan 可以只输出方案不改文件。这个工作流很重要：Agent 可以提出修复，人类或外层 harness 决定是否应用。

成熟的 Agent 编程系统，最后都绕不开这件事：不能只让模型“看起来会修”，必须让工具链告诉它哪些修复是安全的、哪些会影响 API、哪些只能人工看。

内存和依赖：不是越自由越好，而是越可预算越好

Zero 的另一个方向是让资源行为更可预测。它不假设有一个全局堆，内存通常通过显式 allocator capability 或固定缓冲区来处理。

固定容量结构可以像这样表达：

ZERO

shape FixedVec<T, static N: usize> {
    len: usize,
    items: [N]T,
}

static N 表示容量是编译期参数。这会让某些写法变啰嗦，但它也带来一个好处：资源上限更容易被检查和报告。

Zero 的标准库文档里，模块是 pay-as-used 和 capability-aware 的。导入 std.mem 不会顺手把 std.fs 拉进来。工具链可以用 JSON 告诉你程序实际保留了哪些能力、哪些 helper、哪些目标支持信息。

几个命令值得关注：

BASH

zero graph --json examples/systems-package
zero size --json examples/point.0
zero mem --json examples/memory-package

这些输出对人也有用，但对 Agent 更有用。Agent 做代码改动后，可以检查“这次是不是引入了 fs 能力”“是不是把一个 target-neutral 工具变成 host-only”“是不是多拉了一堆标准库 helper”。

这类信息如果只靠模型读 diff 猜，肯定不稳。由编译器和标准库元数据给出，才有机会进入可靠的自动化工作流。

目标平台：能跨平台，但别误解成熟度

按当前文档和仓库状态，Zero 已经有直接 emitters 和目标表，常见目标包括 Linux、macOS、Windows、WebAssembly 等方向。它也提供了 target capabilities 的 JSON 输出，用来解释某个程序为什么能或不能在某个目标上跑。

但这里要克制一点。Zero 不是成熟替代品。它的价值不是“今天拿它替代 Rust 写系统组件”，而是它把跨目标能力、标准库副作用、诊断和修复计划都做成机器可读接口。

仓库 CHANGELOG 也能看出它还在快速变化：0.1.1 加了 install、zero run、文档和 zero skills；0.1.2 重做 borrow provenance；0.1.3 又扩展 HTTP client runtime、import diagnostics、target-readiness facts、BOR001 borrow trace 等。

这说明项目推进很快，但也说明语法、标准库、工具链行为都还可能变。现在最适合的用法是学习、观察、写小例子、跑 conformance，不是进生产。

快速上手：先别写大项目

安装命令很简单：

BASH

curl -fsSL https://zerolang.ai/install.sh | bash
export PATH="$HOME/.zero/bin:$PATH"
zero --version

检查第一个文件：

BASH

cat > hello.0 <<'EOF'
pub fun main(world: World) -> Void raises {
    check world.out.write("hello from zero\n")
}
EOF

zero check hello.0

运行一个小程序：

BASH

cat > add.0 <<'EOF'
fun answer() -> i32 {
    return 40 + 2
}

pub fun main(world: World) -> Void raises {
    let value = answer()
    if value == 42 {
        check world.out.write("math works\n")
    } else {
        check world.out.write("math broke\n")
    }
}
EOF

zero run add.0

如果要体验 Agent 友好的部分，不要只看运行结果。重点跑这些：

BASH

zero check --json hello.0
zero graph --json hello.0
zero size --json hello.0
zero explain NAM003

再故意写一个错误，比如把 message 当成未声明变量传给 world.out.write，观察 JSON 诊断里 expected、actual、fixSafety、repair 怎么描述。这个体验比跑 hello world 更能说明 Zero 的方向。

建议隔离环境跑，别在主力机乱试

Zero 自己的 README 和 AGENTS.md 都强调：安全漏洞应被预期，不要用于生产系统、敏感数据或可信基础设施。这个提醒不是客套。

新语言、新编译器、新 runtime，尤其还涉及直接发射目标代码、文件系统、HTTP、C interop、WASM 目标时，最好在隔离环境里跑。别拿主力项目、客户数据、生产密钥直接试。

顺手提一嘴，如果你要长期折腾 Zero 这类新语言、编译器、Agent 工具链、WASM 沙箱或 conformance 测试，最好单独起一台实验机。环境能随便删，端口和权限也好管。需要临时或长期 Linux 机器，可以看雨云的云服务器方案：

给新语言、编译器和 Agent 工具链准备一台独立实验机

适合跑 conformance、WASM、Playwright、模型网关和长期自动化任务，把主力电脑和生产环境隔离开。

查看雨云服务器方案 →

它和 Rust、Zig、Go 的关系

别急着问 Zero 会不会替代 Rust。现在问这个没啥意义。

Rust 解决的是内存安全、并发安全和大型生态问题；Zig 把 C 互操作、交叉编译、显式控制做得很干净；Go 在工程简单性、部署和服务端生态上依然务实。Zero 当前没有成熟生态，也没有生产稳定性。

它真正可能影响的是工具链设计。

Rust 的错误诊断已经很强，但主要仍是面向人；Zig 的显式性很高，但 Agent repair contract 不是核心目标；Go 的简单性适合 Agent 读写，但副作用和依赖边界并不天然结构化。

Zero 把“Agent 是一等用户”作为出发点。这会带来一些不同的默认值：

诊断从一开始就要求 JSON；
修复建议要有安全等级；
标准库 helper 要暴露 effects、allocation behavior、target support、error behavior；
graph、size、mem 都要能让机器检查；
语言宁可显式，也不把副作用藏起来。

即使 Zero 最后不成为主流语言，这些模式也可能被成熟工具链吸收。

适合谁现在关注

第一类是做 AI 编程工具、Agent IDE、自动修复系统的人。Zero 的诊断、fixSafety、fix plan、graph facts，很适合作为参考模型。

第二类是做 WASM、嵌入式、沙箱运行时的人。显式 capability、固定内存预算、target support 这些设计，和资源受限环境天然契合。

第三类是语言设计爱好者。Zero 把“AI 时代语言怎么变”从口号落到了命令行、标准库和诊断结构上，这比泛泛讲 Agent-first 更值得看。

不适合的人也很明确：如果你现在要写生产 Web 服务、CLI、基础设施组件，先用 Rust、Go、Zig。Zero 更适合作为实验对象和设计样本。

真正值得记住的是这个方向

过去几年，AI 编程的大部分讨论都在模型层：谁会写代码、谁修 bug 更准、谁上下文更长。但真正落地到工程里，模型只是其中一层。语言、编译器、标准库、包管理、诊断、CI、权限和运行时，都得配合。

Zero 提醒我们：Agent 编程不是让模型去适应所有历史包袱，也可以反过来设计更适合 Agent 读写和修复的工具链。

副作用可见，错误可结构化，修复可分级，资源可预算，目标能力可查询。听起来不花哨，但这可能比“AI 自动写一万行代码”更接近工程现实。

现在的 Zero 还早，甚至很粗糙。但它提出的问题不早：当 Agent 不只是代码补全，而是真正进入 build、test、fix、deploy 的循环时，我们还要不要继续把编译器输出当成一坨终端文本，把能力边界藏在运行时，把修复安全性交给模型猜？

这个问题，值得跟踪。

Vercel Zero 语言观察：Agent 时代，编译器也得会给机器读

Zero 的关键不是新语法，而是新读者

第一眼该看 World：I/O 不是全局魔法

错误处理：让失败路径变成接口的一部分

结构化诊断才是 Agent 工具链的硬通货

内存和依赖：不是越自由越好，而是越可预算越好

目标平台：能跨平台，但别误解成熟度

快速上手：先别写大项目

建议隔离环境跑，别在主力机乱试

它和 Rust、Zig、Go 的关系

适合谁现在关注

真正值得记住的是这个方向

文章目录

评论