zerolang：当编程语言的首要读者不再是人类

格帕文士 · 深度解读 项目：zerolang — The programming language for agents 出品方：Vercel Labs 开源协议：Apache-2.0 GitHub：github.com/vercel-labs/zerolang 官网：zerolang.ai

一个根本性的前提转换

几乎所有编程语言的设计，都有一个默认假设：主要读者是人类。语法追求简洁优雅，错误消息写成散文以便人类理解，标准库按人类直觉组织。

zerolang 的设计前提完全不同：主要读者是 AI Agent。人类仍在回路中，但从第一天起，Agent 就被视为第一级用户。

这一个前提转换，级联到了语言的几乎每一个可见特征。

AI 编码的四大痛点与 zerolang 的四大解法

痛点一：语法幻觉

传统语言有太多"隐式机制"——类型推断、魔法全局变量、隐式 async、自动装箱拆箱。人类喜欢这些便利，但 Agent 难以推理。当 Agent 写代码时，它必须猜测"这个函数到底做了什么"——这种猜测就是幻觉的来源。

解法：极致显式正则性

zerolang 的非官方口号是"一切显式"。没有强制 GC，没有隐藏分配器，没有隐式 async 运行时，没有魔法全局变量。任何触碰外部世界的操作，必须在函数签名中显式声明。

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

world: World 是能力对象（capability object），没有它，函数无法执行任何 I/O。raises 声明函数可能传播错误。check 处理可能失败的操作。所有这些信息都在签名里，Agent 不需要读函数体就能知道它的行为边界。

对人类来说这很啰嗦；对 Agent 来说，这是礼物。

痛点二：外部依赖地狱

Agent 写代码时，经常需要引入外部依赖。但依赖管理对 Agent 是噩梦：版本冲突、API 变化、文档过时、安全漏洞。

解法：闭环标准库

zerolang 的长期目标是一个足够广博、一致的标准库，让大多数程序不需要离开官方 API 就能完成。std.crypto、std.http、std.net 等模块直接内置，Agent 不需要搜索 npm/crates.io/pip 来寻找"哪个包做这个事"。

这不是说 zerolang 不支持外部依赖，而是说默认路径是标准库。Agent 的第一步不是"搜索依赖"，而是"查阅标准库文档"。

痛点三：错误修复的文本解析

传统编译器的错误消息是人类可读的散文——"expected '{' before block"。Agent 看到这些消息时，必须用 NLP 能力推断问题所在，然后再推断修复方案。这个过程慢、易错、不可预测。

解法：结构化 JSON 工具链

zerolang 的编译器默认输出 JSON，不是散文。

{
  "code": "NAM003",
  "message": "unknown identifier 'message'",
  "expected": "visible local, parameter, function, or builtin",
  "actual": "no matching visible symbol",
  "repair": { "id": "declare-missing-symbol" }
}

每个诊断有稳定代码（如 NAM003）、人类可读消息、期望/实际对比、修复元数据。Agent 不解析散文，它读取结构化字段。

更深一层：

• zero explain NAM003 → Agent 直接查诊断代码的含义
• zero fix --plan --json broken.0 → Agent 获得机器可读的修复计划

完整的修复闭环：编译 → 诊断 → 解释 → 修复计划 → 应用修复 → 重新编译。全部结构化，无需人类翻译。

痛点四：代码安全失控

Agent 写的代码可能访问不该访问的资源——文件系统、网络、环境变量。在传统语言中，这些能力通常是隐式的全局状态，Agent 可能"不小心"就调用了危险操作。

解法：严格沙盒化与能力型 I/O

zerolang 的能力型 I/O 在编译时强制执行：如果一个函数没有收到 World 对象（或其派生能力），它证明性地不能触碰外部世界。这不是运行时检查，是编译时保证。

// 这个函数不能做 I/O
fun pure_computation(x: i32) -> i32 {
  ret x * 2
}

// 这个函数可以做 I/O
pub fun main(world: World) -> Void raises {
  check world.out.write("I can touch the world\n")
}

Agent 可以安全地调用 pure_computation，因为它在类型系统层面被证明是无副作用的。这种"证明"不需要运行时开销，它是编译器的静态分析结果。

统一单二进制工具链

传统语言生态的工具链是碎片化的：编译器、包管理器、格式化工具、Linter、文档生成器各自独立。Agent 必须知道每个工具的职责和调用方式。

zerolang 把所有工具链压缩进一个二进制：zero。

每个命令都支持 --json，Agent 可以用管道串联它们，不需要为每个工具学习不同的 CLI 接口。

微小但锋利的二进制

zerolang 的目标二进制尺寸：< 10 KiB。

它通过直接发射器（direct emitters）生成 ELF/Mach-O/PE/WebAssembly，不依赖 LLVM。没有隐藏的运行时税、没有强制 GC、没有隐式事件循环。

这对 Agent 有什么意义？Agent 写的代码编译快、启动快、运行时延迟低。Agent 的反馈循环变短了——写代码 → 编译 → 测试 → 修复，全部在秒级完成。

范式转换：从 Human-First 到 Agent-First

zerolang 的真正意义不在于任何单一技术特性，而在于它代表的方向：编程语言设计的用户假设正在从"人类开发者"转向"AI Agent"。

这类似于印刷术出现后的文字演变——手写时代追求书法美感，印刷时代追求字体清晰易读。读者变了，设计目标就变。

zerolang 的设计哲学可以概括为几个原则：

• 规则胜于巧妙：用少数规则覆盖大多数场景，不追求语法糖的多样性
• 标准库胜于语法：新能力优先放入标准库 API，而不是新增语法
• Agent 可读的输出：诊断、图、尺寸报告、修复元数据都结构化
• 显式效果：外部世界访问、失败可能、资源使用对读者和工具都可见
• 无历史包袱：当 Agent 友好的设计胜出时，可以直接替换旧行为

局限与边界

zerolang 目前处于 v0.1.3，明确标记为实验性。README 直接说：

"Security vulnerabilities should be expected. zerolang is not ready for production systems, sensitive data, or trusted infrastructure."

具体问题：

• 不稳定：API 和语法可能 Breaking Change
• 无包注册表：生态尚在早期
• 跨编译目标有限：目前只支持文档列出的目标子集
• 无 stdin API（v0.1.3）：输入只能通过 std.args 和 std.env
• 社区极小：GitHub 4.3k+ stars，但主要是关注者而非贡献者

这意味着 zerolang 现在不适合生产项目，但非常适合作为方向信号和实验平台来观察。

对比：zerolang vs Rust vs C

zerolang 的差异化不在性能或内存安全（Rust 已做得很好），而在机器可读的编译器输出和结构化的 Agent 工具链作为语言的一等特性。

结语

zerolang 的名字本身就是一种宣言：Start from Zero。

从零点出发，没有历史包袱；一切显式，人类和 Agent 在同一起跑线；面向未来，承认编程的主要读者正在变化。

它可能永远不会成为主流语言。但它提出的问题是所有语言设计者都必须面对的：如果你的代码主要由 AI Agent 读写，语言应该长什么样？

zerolang 是目前最系统的回答之一。

参考来源：

• GitHub: github.com/vercel-labs/zerolang
• 官网: zerolang.ai
• Coddy Docs: coddy.tech/docs/zero/what-is-zero
• Marktechpost: marktechpost.com/2026/05/17/vercel-labs-introduces-zero
• Kalinga AI: kalinga.ai/zero-programming-language-ai-agents
• WeFound: wefound.cc/p/2516.html
• NeedHelp: needhelp.icu/blogs/zerolang-vercel-ai-agent-language
• Online Playground: coddy.tech/playground/zero

#zerolang #VercelLabs #AgentFirst #AI编程 #编程语言 #格帕文士 #深度解读