夜雨聆风作者：蓝小鲸 | 原创首发
前言
当AI Agent开始写代码，它们面对的工具是为人类设计的。
Rust的编译器报错"cannot borrow x as mutable because it is also borrowed as immutable"——这对人类来说是丰富的上下文，但对机器来说只是需要推理的文本。Go的错误信息更简洁，但同样是非结构化的。Agent需要用LLM推理来解析这些人类友好的错误，然后猜测修复方案。
Vercel Labs在2026年5月发布了Zero——一个实验性的系统编程语言，从第一天起就把AI Agent设为主要用户。不是插件，不是集成层，而是语言、工具链和内存模型都为机器可读而从头设计。
一、项目概述
Zero是一个位于C和Rust同等设计空间的系统编程语言。它编译成原生可执行文件，提供显式的内存控制，目标是低级环境。
核心数据：
- • 当前版本：v0.1.1（实验阶段）
- • 许可证：Apache-2.0
- • 二进制大小：< 10 KiB
- • 24小时内GitHub星标突破900
- • 核心贡献者：Chris Tate & Matt Van Horn（Vercel Labs）
官方网站： https://zerolang.ai\ GitHub仓库： https://github.com/vercel-labs/zerolang
二、为什么需要面向Agent的语言
传统语言的Agent困境
在一个典型的Agent开发循环中：
- 1. Agent编写代码 → 编译器发出非结构化文本错误
- 2. Agent解析文本 → 错误格式在不同编译器版本间可能变化
- 3. 缺乏修复提示 → 没有内置的"修复动作"概念
- 4. 人类介入 → 需要手动干预才能解决错误
现有的编程语言在设计时假设用户是人类。错误消息、警告、文档——全部为人类的阅读习惯优化。AI Agent处理这些信息时被迫进行推理，而不是直接执行结构化指令。
Zero的设计逻辑
Zero从第零天起就为机器设计。它不试图让机器"更像人类"那样读错误信息，而是让编译器输出机器可原生消费的结构化数据。
这不仅仅是"更好的错误消息"，而是一种根本性的范式转变：Agent读取代码、解释诊断信息、修复程序——无需人类翻译。
三、核心特性详解
1. 结构化JSON诊断
运行 zero check --json 时，输出是这样的：
{
"ok": false,
"diagnostics": [{
"code": "NAM003",
"message": "unknown identifier",
"line": 3,
"repair": { "id": "declare-missing-symbol" }
}]
}每个诊断包含：
- • code：稳定代码（如NAM003），Agent可以可靠匹配
- • message：人类可读的错误描述
- • line：代码行号
- • repair：类型化的修复ID，Agent可以直接执行
人类读message，Agent读code和repair。同一个CLI命令同时输出两者——没有单独的模式或辅助工具。
2. 修复命令：zero explain & zero fix
两个CLI子命令完成了Agent修复循环：
zero explain
返回任何诊断代码的结构化解释。Agent直接查询NAM003——无需解析文档。
zero explain NAM003zero fix --plan --json
发出机器可读的修复计划——描述具体需要做什么修改——无需Agent推断。
zero fix --plan --json add.0这就是Agent执行编译器已导出的修复计划和Agent猜测修复方案之间的区别。
3. 零技能：版本匹配的Agent指南
大多数工具要求Agent抓取可能与安装的编译器不同步的外部文档。Zero通过 zero skills 解决——直接从CLI提供版本匹配的指导。
zero skills get zero --full返回聚焦的工作流，涵盖：
- • Zero语法——当前版本的语言基础
- • 诊断——如何解释和执行编译器输出
- • 构建和包——清单结构、目标、输出
- • 测试和Agent编辑循环——验证和修复工作流模式
这意味着与Zero一起工作的Agent不需要抓取外部文档——所有信息都匹配它们实际运行的编译器版本。
4. 基于能力的I/O系统
Zero的核心设计决策之一是效果在函数签名中是显式的。如果函数要写入标准输出、访问文件系统或发起网络调用，它必须通过能力对象声明。
标准入口点：
pub fun main(world: World) -> Void raises {
check world.out.write("hello from zero\n")
}- •
world: World：能力对象，授予I/O、文件系统、网络访问权限 - •
check：处理可失败操作，将失败向上传播 - •
raises：标记函数可以传播错误——签名中可见 - • 编译时强制：未获得的能力在编译时被拒绝，而非运行时
没有隐藏的全局进程对象，没有隐式异步，没有魔法全局变量。当Agent在阅读Zero代码理解代码库时，它可以确定任何函数能做什么和不能做什么——文件系统访问、网络调用、失败模式——无需执行它。信息就在签名里。
四、设计哲学
原则一：规则性优先于语法
Zero偏向显式的功能和标准库API，而不是为每个便利提供语法。有些代码对人类来说可能更冗长，但如果这使得Agent更容易生成、检查和修复，那就是正确的权衡。
"正则性优先于语法。偏好一种明显的方式表达大多数事物，即使这使得代码比人类在另一种语言中选择的更显式。"
— Zero设计原则
原则二：Agent优先的可学习性
一个小的、规则的语言表面，Agent可以从示例、文档和编译器反馈中快速掌握。语言设计避免特殊情况和例外——相同的概念以相同的方式工作，无论上下文。
原则三：标准库深度
通用能力应该存在于文档化、连贯的库API中，而不是分散在依赖栈中。长期目标是标准库足够广泛和一致，以至于大多数程序从文档化API开始，而不是包搜索。
原则四：确定性工具
诊断、图事实、大小报告、解释和修复计划应该足够结构化，Agent可以检查和操作。zero check、zero run、zero build、zero graph --json、zero size --json、zero doctor --json——全部输出结构化数据。
原则五：直接开发者体验
检查、运行、格式化、检查和修复代码应该快速、可复制和可脚本化。整个工具链统一到一个二进制文件：zero 是你需要的唯一工具。
五、快速入门教程
安装
curl -fsSL https://zerolang.ai/install.sh | bash
export PATH="$HOME/.zero/bin:$PATH"
zero --version安装程序从GitHub release下载最新二进制文件并放在 $HOME/.zero/bin/zero。
检查程序
zero check examples/hello.0运行可执行文件
zero run examples/add.0
# 输出：math works构建原生可执行文件
zero build --emit exe --target linux-musl-x64 examples/add.0 --out .zero/out/add
./.zero/out/add
# 输出：math works创建新项目
zero new cli hello
cd hello
zero check . && zero test . && zero run .常用命令
| 命令 | 作用 |
|---|---|
zero check <file> | 检查代码错误 |
zero run <file> | 运行程序 |
zero build --emit exe <file> | 编译为可执行文件 |
zero graph --json <pkg> | 导出依赖图JSON |
zero size --json <file> | 报告二进制大小 |
zero skills get zero --full | 获取完整Agent指南 |
zero doctor --json | 诊断工具链问题 |
zero explain <code> | 解释诊断代码 |
zero fix --plan --json <file> | 生成修复计划 |
六、内存模型与二进制大小
Zero针对二进制大小和内存可预测性重要的环境。没有隐藏的运行时税。
关键数据：
- • 目标大小：< 10 KiB原生可执行文件
- • 无垃圾回收器：没有必需的GC
- • 无隐藏分配器：分配是显式的，代码中可见
- • 无隐式异步：没有魔法全局变量
- • 无LLVM后端：牺牲优化天花板换取构建速度
内存模型更接近Zig而非Rust——显式管理无需生命周期注解复杂性。
交叉编译示例：
zero build --emit exe --target linux-musl-x64 examples/add.0 --out .zero/out/add七、标准库能力
Zero的目标是标准库足够广泛，以至于大多数程序从文档化API开始，而不是包搜索。目前已覆盖：
输入/输出
- •
std.out：标准输出写入 - •
std.fs：文件系统操作（读/写/文件资源） - •
std.args：命令行参数 - •
std.env：环境变量
网络
- •
std.http：HTTP请求（JSON、headers、自定义方法） - •
std.codec：编码解码（varint、CRC-32等）
系统能力
- •
std.time：时间操作 - •
std.rand：随机数 - •
std.proc：进程控制 - •
std.crypto：加密能力 - •
std.parse：解析器谓词
内存
- •
Span<T>：Span视图 - •
Maybe<T>：可选类型 - •
Vec<T>：动态向量 - •
MutSpan<T>：可变Span
八、示例代码解读
基础示例：add.0
pub fun main(world: World) -> Void raises {
let value = answer()
check world.out.write("math works\n")
}
fun answer() -> i32 {
return 40 + 2
}特点：
- •
pub fun main：公开入口函数 - •
world: World：能力参数，访问I/O - •
raises：可能失败的函数 - •
check：处理可失败操作 - •
let value：不可变绑定
能力示例：显式I/O
pub fun main(world: World) -> Void raises {
// world.out 来自能力参数
// 函数签名暴露了它可以写入stdout
check world.out.write("hello\n")
}纯函数示例：
fun pure_add(a: i32, b: i32) -> i32 {
return a + b
}
// 此函数不接受World参数，因此无法执行I/O
// 编译器在编译时强制这一点错误处理：raise与check
pub fun main(world: World) -> Void raises {
let result = might_fail()
check world.out.write("success\n")
}
fun might_fail() -> i32 raises {
if (something_wrong) {
raise MyError
}
return 42
}九、与现有语言的对比
| 特性 | Zero | Rust | Go | Python |
|---|---|---|---|---|
| 面向Agent | ✅ 原生 | ❌ | ❌ | ❌ |
| JSON诊断 | ✅ | ❌ | ❌ | ❌ |
| 修复计划 | ✅ | ❌ | ❌ | ❌ |
| 基于能力的I/O | ✅ | ❌ | ❌ | ❌ |
| GC | 无 | 无 | 有 | 有 |
| 二进制大小 | <10KiB | 较大 | 中等 | 解释型 |
| 稳定性 | 实验性 | 稳定 | 稳定 | 稳定 |
| 包注册表 | 无 | crates.io | go mod | PyPI |
十、关键观点总结
观点一：语言设计范式转变
Zero代表了一种根本性的语言设计思路转变——不是让机器"更像人类"那样工作，而是让机器能够直接消费编译器输出。这是为AI Agent作为主要代码作者的世界而设计的第一步。
观点二：确定性优于灵活性
结构化诊断和修复计划的价值在于确定性。Agent不需要推理，只需要执行。当编译器可以告诉Agent具体做什么时，开发循环变得更加可靠和可预测。
观点三：显式优于隐式
没有隐藏的分配器，没有隐式异步，没有魔法全局变量——这不仅仅是"好的实践"，而是让Agent能够通过阅读签名理解代码行为，而无需执行或追踪调用图。
观点四：工具链统一性
所有工具（check、run、build、graph、size、doctor、explain、fix）都是同一个CLI的子命令。Agent不需要推理"哪个工具做什么"——工具的使用方式是可预测的和统一的。
观点五：实验性但值得关注
Zero是v0.1.1，明确标记为实验性。GitHub星标的快速增长（24小时内900+）反映了开发者对"Agent原生工具链"这一方向的强烈兴趣。无论Zero最终是否成功，其核心思想（结构化诊断、显式能力系统）对整个行业都有参考价值。
十一、适用场景与局限性
适用场景：
- • Agent编写和修复代码的场景
- • 需要小二进制大小的嵌入式/系统级工具
- • 对确定性工具有强需求的自动化流水线
- • 探索Agent原生编程范式
当前局限性：
- • v0.1.1，仍在快速迭代，API不稳定
- • 无包注册表，标准库还在扩展中
- • 交叉编译仅支持文档化的目标子集
- • 无生产级安全保证，不适合敏感数据环境
不适合场景：
- • 生产级系统
- • 敏感数据处理
- • 需要稳定API的关键基础设施
十二、结论
Zero是一个有清晰愿景的实验性项目。它没有试图让现有语言变得"Agent友好"，而是重新思考如果从第一天起就让Agent作为主要用户，语言和工具链应该是什么样子。
结构化JSON诊断、typed repair metadata、基于能力的I/O系统、版本匹配的Agent指南——这些设计决策都是为了让机器能够直接消费编译器输出，而不需要人类作为翻译层。
核心思想总结：
当AI Agent成为主要的代码编写者而非辅助工具时，整个工具链应该被重新架构以适应这一现实。Zero是这一愿景的第一次认真尝试——实验性的，但方向明确的。
值得追踪，不是因为它已经成熟，而是因为它代表了一个值得探索的方向——在Agent越来越成为代码主要作者的背景下，工具链应该如何进化。
参考链接：
- • 官网：https://zerolang.ai
- • GitHub：https://github.com/vercel-labs/zerolang
- • 安装：curl -fsSL https://zerolang.ai/install.sh | bash
本文首发于蓝小鲸AI实验室 | 关注AI与加密货币行业动态
