Vercel Labs 在 GitHub 上开源了实验性编程语言 Zero。它最值得关注的地方，不是项目获得了多少 star 或 fork，而是它试图回答一个更基础的问题：如果代码主要由 AI Agent 生成、查询和修改，编程语言还应该继续以文本文件为唯一源头吗？
Zero 的定位非常明确：它不是优先为人类程序员设计的语言，而是面向 AI Agent 的编程语言。传统开发依赖一条熟悉的链路：人写代码，编译器解析代码，人阅读错误信息，再修改代码。Zero 尝试把这条链路中的“源代码”从文本换成图结构，让 Agent 可以直接查询程序中的节点、关系和依赖。
从文本源代码转向程序图
传统语言通常把程序表示成一组文本文件。文本适合人类阅读、版本控制和 diff，但对 Agent 来说，很多常见操作都并不直接：
- 找出某个函数真正影响的调用链；
- 判断修改一个字段会破坏哪些流程；
- 在多个文件中同步更新同一个概念；
- 区分语法相似但语义不同的代码片段；
- 根据编译错误定位需要改变的结构。
Agent 可以通过解析器、语言服务器、索引器和测试结果建立自己的程序模型，但这些模型往往是代码之外的附加层。模型过期、索引不完整或工具输出不一致时，Agent 就可能在错误的上下文中继续修改文本。
Zero 的核心方向是让图成为程序的第一等表示。一个程序不再只是文件、字符串和行号的集合，而可以被理解为由模块、函数、数据、条件、调用关系和依赖关系组成的图：
订单服务
├── create_order()
│ ├── validate_user()
│ ├── calculate_total()
│ └── save_order()
└── cancel_order()
├── load_order()
└── refund_payment()
在这样的模型里，Agent 查询的不是“第 82 行附近有什么代码”，而是“所有写入订单状态的节点有哪些”“修改支付接口后，哪些路径可能受到影响”。这类查询更接近 Agent 实际需要完成的任务。
Agent 为什么需要结构化的修改接口
大语言模型擅长生成文本，但文本编辑并不等于可靠的程序修改。让 Agent 直接改字符串，通常会遇到几个问题：
- 上下文依赖强：同一段文本放在不同文件或作用域中，含义可能完全不同。
- 修改粒度不稳定：模型可能为了增加一个参数，重写一整个函数。
- 关系容易遗漏：调用方、类型、测试和配置不一定同步更新。
- 错误反馈偏晚：许多问题只有在编译、测试或运行时才暴露。
图结构允许工具把操作提升到语义层。例如，Agent 可以执行“给函数增加一个参数”“把节点连接到某个错误处理分支”“查找所有依赖某类型的模块”等操作。系统可以在应用修改前检查图的约束，并返回受影响的节点集合。
这并不意味着文本会立刻消失。对人类开发者来说，文本仍然是审查设计、讨论实现和进行版本对比的重要媒介。更现实的方向是：图作为 Agent 操作和验证程序的内部源头，文本作为人类阅读、审查和协作的投影。
一个可运行的最小实验
下面的 Python 示例不是 Zero 的真实语法，而是一个可以直接运行的“图式 Agent 编程”小实验。它用有向图表示函数调用关系，并让 Agent 风格的查询找出某个节点的所有下游影响。你可以把它保存为 agent_graph.py 后运行。
from collections import defaultdict, deque
def build_program_graph():
graph = defaultdict(set)
graph["create_order"].update({"validate_user", "calculate_total", "save_order"})
graph["cancel_order"].update({"load_order", "refund_payment"})
graph["save_order"].add("write_order_status")
graph["refund_payment"].add("write_order_status")
return graph
def downstream_nodes(graph, start):
"""Return every function reachable from start."""
visited = set()
queue = deque([start])
while queue:
node = queue.popleft()
if node in visited:
continue
visited.add(node)
queue.extend(graph[node] - visited)
visited.remove(start)
return sorted(visited)
def callers_of(graph, target):
"""Return direct callers of target."""
return sorted(node for node, children in graph.items() if target in children)
if __name__ == "__main__":
program = build_program_graph()
print("Impact of changing write_order_status:")
print(downstream_nodes(program, "create_order"))
print("Direct callers of write_order_status:")
print(callers_of(program, "write_order_status"))
运行命令：
python agent_graph.py
这个实验只覆盖了调用关系，真实的 Agent 编程系统还需要表示类型、数据流、权限、错误路径、测试覆盖率和外部服务依赖。它展示的重点是接口形态：Agent 查询的是结构化关系，而不是依赖自己从大量文本中恢复关系。
Zero 可能改变哪些开发环节
如果 Zero 的实验方向能够成熟，它影响的可能不只是语法设计，还包括整个开发工具链。
代码生成
Agent 可以根据图中的现有节点和约束生成新功能，而不是每次从文件内容中猜测项目结构。生成前可以先检查目标模块、可复用的能力以及已有的错误处理路径。
错误定位
编译器或运行时可以返回图上的错误节点和关系。例如，某个节点输出的类型与下游输入不匹配，错误信息可以直接指出这条边以及受影响的路径，而不只是给出一个文件行号。
影响分析
在修改公共数据结构、API 或权限规则时，Agent 可以获得结构化的影响范围。系统也可以要求它为所有受影响节点生成测试或迁移操作。
多 Agent 协作
多个 Agent 操作同一份文本时，很容易产生覆盖和冲突。如果修改对象是图中的节点和边，系统有机会根据依赖关系检测冲突，并限制互相不兼容的修改同时提交。
还需要观察的边界
“给 Agent 用的语言”并不自动等于“更好的语言”。Zero 仍然是实验性项目，真正的价值需要在实际开发任务中验证。至少有几项问题值得持续观察：
- 图结构是否足够表达复杂的控制流、元编程和动态行为；
- Agent 操作图时是否会产生难以审查的隐式变化；
- 人类如何阅读图的文本投影，并进行稳定的代码评审；
- 图的序列化、合并和版本控制是否能达到 Git 工作流的可靠性；
- 当模型理解错误时，结构化接口是否只是让错误修改执行得更精准；
- Zero 与现有语言、编辑器、调试器和构建系统如何互操作。
图表示解决的是“程序如何被机器理解和操作”的问题，不会自动解决需求错误、架构错误或权限边界不清的问题。结构化表示甚至可能放大错误，因为 Agent 能够更快、更大范围地修改程序。
采用时可以先做什么
目前不必急于把生产代码迁移到实验性语言。更稳妥的实践是把 Zero 的思想拆开验证：
- 为现有项目建立调用图、依赖图和数据流索引；
- 给 Agent 提供查询影响范围的工具，而不是只提供文件读写工具；
- 让代码修改通过结构化操作和验证步骤完成；
- 在合并前展示受影响节点、测试结果和回滚范围；
- 保留人类可读的文本 diff，作为审查和审计依据。
Zero 的真正意义，可能不在于它是否成为下一门主流语言，而在于它把一个经常被忽略的前提摆到台面上：当 Agent 成为主要的代码生产者时，面向人类阅读优化的文本表示，未必仍然是最合适的程序接口。未来的编程工具很可能同时维护两种视图，一种供 Agent 查询和修改，一种供人类理解和决策。