我读完 zerolang 的第一反应是：Vercel 在做一件比"造一门新语言"更根本的事——他们在重新定义"编程语言的用户画像"。
这个判断的冲击力，不亚于当年 iPhone 重新定义"手机的用户画像"（从商务人士到普通人）。
第一，为什么说这是"前提转换"而非"功能优化"
传统编程语言也有"机器可读"的格式——AST、字节码、LLVM IR。但这些是编译器的内部表示，不是给 Agent 用的。Agent 面对的源代码，仍然是人类可读的文本。
zerolang 的颠覆在于：它把"机器可读"推到了源代码层。编译器输出的 JSON 诊断、修复计划、结构化图——这些不是编译器的内部调试信息，而是Agent 的工作接口。
换句话说，zerolang 的编译器不是"给人类看错误消息"，而是"给 Agent 提供行动指令"。这是根本不同的设计目标。
第二，能力型 I/O 的深层含义
world: World 这个设计表面上是安全——函数不能偷偷做 I/O。但深层含义是：Agent 获得了对代码行为的证明性推理能力。
在传统语言中，Agent 读到一个函数 foo()，它不知道这个函数会不会删文件、发请求、改环境变量。它只能读函数体，如果函数体很长或者调用了其他函数，Agent 就陷入递归的推理困境。
在 zerolang 中，Agent 读到 fun foo(x: i32) -> i32，它立刻知道这个函数是纯的——因为签名里没有 World，编译器保证了它不能做 I/O。这种"零成本证明"是 Agent 推理的加速器。
我预测：如果这个设计被证明有效，能力型 I/O 会成为下一代语言的标配。不是作为安全特性，而是作为Agent 推理的基础设施。
第三，结构化 JSON 工具链的真正价值
zero fix --plan --json 输出的是修复计划，不是修复后的代码。这个区别很重要：
- 修复后代码 = Agent 无法验证修复是否正确，只能信任编译器
- 修复计划 = Agent 可以读计划、理解意图、决定接受/修改/拒绝
第四，标准库闭环的野心
zerolang 想要一个"足够广博的标准库"，让 Agent 不需要搜索外部依赖。这个野心很大——Rust 的标准库被称为"最小主义"，Go 的标准库被称为" batteries included "，zerolang 想走 Go 的路线但走得更远。
但这里有个悖论：标准库越广博，学习成本越高。Agent 需要知道 std.http 里有什么函数、什么参数、什么错误类型。如果标准库太大，Agent 的"即学即用"优势就被削弱了。
我猜测 zerolang 的解法可能是版本匹配的 Agent 指导（zero skills）。标准库文档不放在外部网站，而是直接编译进编译器。Agent 查询的是它正在运行的那个版本的确切文档，不会遇到"文档过时的"问题。
第五，zerolang 与 Harness 工程的关系
读这篇文章时我想到前几篇 CLI Agent Harness 的深度解读。Harness 工程的核心是：中等模型 + 硬性 Hook ≈ 强模型无约束。
zerolang 可以被视为一种语言级别的 Harness。它不是给 Agent 加外部约束（如测试覆盖、类型检查），而是把约束内化到语言设计本身——能力型 I/O、显式效果、结构化输出。Agent 在这个语言里写代码，本身就受到"正确性"的引导。
这是一个更优雅的解法：不是后加约束，而是前设结构。
最后，关于"Agent-First 语言"的未来
zerolang 可能不是最终答案。它的语法还在变，生态还在早期，稳定性还不存在。但它提出的问题——"如果 Agent 是主要读者，语言应该长什么样？"——是所有语言设计者接下来五年必须回答的问题。
我的判断是：zerolang 的方向是对的，但实现还远。它更像一个概念验证（proof of concept），而不是生产工具（production tool）。
值得跟踪，不值得押注。
除非你是 Vercel Labs 的人——那你可以押注。因为如果这个方向对了，Vercel 就从"前端基础设施"变成了"Agent 基础设施"。这个跃迁的战略价值，远大于 zerolang 本身的成败。