Vercel Labs 发布了实验性系统编程语言 Zero。它不是先把人类开发者当第一用户，而是把 AI agent 放在前面设计：工具链契约更明确，错误信息更结构化，还能编译成主流操作系统上的原生二进制。到 0.3.4 这个版本，它已经不是概念稿，而是一条开始能落地试验的语言路线。
这门语言为什么要“先考虑 Agent”
Zero 的核心卖点，不是再造一门“更好写”的通用语言，而是让 agent 更容易稳定地产出可执行代码。对 AI 来说，语言的可解析性、错误回传的结构化程度、工具链边界是否清晰，往往比语法糖更重要。
从摘要里能看出的方向有三点：
- 工具链契约更具体。也就是编译、链接、运行这些步骤，不再只依赖隐含约定，而是更像可预测的协议。
- 错误信息更结构化。对 agent 而言，能否把“失败原因”拆成字段，直接决定它能不能自动修复。
- 目标明确：小、快、能出原生二进制。系统编程语言如果最终只是解释执行的玩具，agent 用起来很难真正进入部署链路。
这类设计的意义在于：当代码不是由人一行行敲出来，而是由模型生成、修补、再生成时，语言本身就要充当一层“约束接口”。
Zero 适合拿来试什么
Zero 目前还是实验阶段，所以更适合拿它做三类验证，而不是直接替换现有生产语言：
- 生成代码后的自动修复链路：看结构化错误能不能让 agent 少走弯路。
- 轻量系统工具：例如 CLI、转换器、代码生成器这类对体积和启动速度敏感的程序。
- 编译器/工具链研究：如果你在做 LSP、静态分析、构建系统，语言级的契约会直接影响上层工具质量。
它不太适合一上来就承担重业务系统。原因很简单：实验语言的生态、调试工具、第三方库和长期维护能力，通常都还在补课阶段。对团队来说，最大风险不是语法学不会，而是边界条件和生产责任没法托住。
可以这样做一个最小验证
如果你想评估“结构化错误 + agent 修复”这条路线，可以先用一段伪项目流程模拟，不必等完整生态成熟。
下面这个例子展示了一个典型工作流：构建失败后，把错误整理成机器可读格式，再交给 agent 做修复建议。这里的 JSON 是示意结构，你可以把它替换成 Zero 工具链实际输出的格式。
#!/usr/bin/env bash
set -euo pipefail
# 1. 编译项目，捕获错误输出
zero build ./examples/hello.zero 2> build.err || true
# 2. 提取结构化错误（示意：你可以换成实际的 zero tooling 输出）
python3 - <<'PY'
import json, re, sys
err = open('build.err', 'r', encoding='utf-8').read()
match = re.search(r'(?P<file>[^:]+):(?P<line>\d+):(?P<col>\d+): (?P<msg>.+)', err)
if match:
payload = {
'file': match.group('file'),
'line': int(match.group('line')),
'col': int(match.group('col')),
'message': match.group('msg'),
'raw': err[:2000],
}
else:
payload = {'raw': err[:2000]}
print(json.dumps(payload, ensure_ascii=False, indent=2))
PY
如果你在做 agent 集成，接下来要改的不是“让模型更聪明”，而是把修复回路做成稳定输入：
- 编译器输出最好有固定字段，而不是自由文本。
- 错误定位最好能直接指向文件、行、列。
- 工具链最好能区分语法错、类型错、链接错、运行时错。
这也是 Zero 这类语言路线真正值钱的地方：它不是单纯给人用的语法，而是给自动化写代码系统提供一个更可控的接口面。
你该怎么判断它值不值得跟进
可以用一个很现实的检查表来判断：
- 你是否真的在做 agent 写代码，而不是只是在用 AI 辅助补全。
- 你是否愿意接受实验语言早期的生态不完整。
- 你的任务是否对二进制体积、启动速度、跨平台原生编译敏感。
- 你是否能把编译错误、测试失败、运行日志做成结构化输入。
如果这些问题里有两个以上答案是“是”，Zero 值得放进试验池里观察。否则，它更像一个值得关注的研究方向，而不是马上迁移的目标。
对团队来说，最稳妥的做法是：先挑一个可以扔掉的工具，拿 Zero 做一轮端到端试验，再决定是否扩大使用范围。实验语言最怕的不是“能不能跑”，而是团队在它身上投入了超出收益的维护成本。