20年没写完的编程语言，现在被拆成了一张任务图

Luke Hutchison在X上更新了Zed的进度。这门语言他做了20多年，之前一直没真正写完。原帖

Zed的设计目标很硬。它基于范畴论，核心目标包括：自动并行到Amdahl极限，也就是受串行部分限制的理论上限；自动内存管理，不用GC，也不用手动malloc/free；大量使用部分求值来增强语言能力；单位进入类型系统，比如 accel = 5 with units("m s^-2")。

Luke把200页设计笔记和已经写好的代码交给Opus，让Opus整理成一份连贯、详细的计划。然后他让Claude、ChatGPT、Gemini多轮交叉评审，互相做元批评，再把批评合并成改进计划，直到收敛。接下来，他让agents对规格做全对比较，检查不一致和缺口，再把规格拆成一长串微小增量步骤，做拓扑排序，得到底层依赖的DAG。

他还让Opus做了一个可视化器，实时显示DAG里每个任务的状态。进行中、已完成，都能看到。Luke建议别人让Opus做大型复杂任务时也用这个办法，因为能看清它到底在做什么。

有人问，这么长的DAG，agent之间怎么协调、避免冲突。Luke说，orchestrator会在work tree里启动agent，agent要合并回main时创建一个lock file，拿锁。必要时orchestrator让agent rebase。他只允许DAG的一层同时处理，所以同一时间运行的agent理论上不应该冲突。这个DAG结构来自对所有节点的深度全对分析。理论上，两个任务之间没有明确有向路径，就可以并行。但Luke的orchestrator更严格，只允许单个fan-out和fan-in同时跑。Luke说，这还不完美，有时orchestrator得rebase代码，但效果“shockingly well”。

社区反馈里有个细节很有意思。有网友Flower根据Zed仓库里已有的代码，做了一个zed-testgen。它调用Zed编译器自带的backward solver，对每个if分支问一个问题：有整数输入能到达这个分支吗？如果有，就生成一行测试；如果没有，就尝试证明它是死分支。工具会独立确认每个witness，再用小范围暴力搜索交叉检查死分支声明。示例里，classify的x > 5和x < 3同时成立的分支被证明是死的。限制也很明确：只处理参数全是int的函数，只处理if分支，调用的是Zed内部求解器模块，不是稳定公开API，提交被pin在a3c52bf。Luke回复说，会让agents看看这个工具。

另一个回复里，Christian Findlay说要把Zed插件包在Osprey的LSP上。Osprey是一个函数式语言，强调algebraic effects、Result和LLVM原生编译。Luke回了一句“nice work”。

还有人问Zed怎么补训练缺口。Dart式语法有帮助，但语义是新的。是靠编译器错误教agent，还是生成语料？这条串里Luke没展开。PLDB的Breck Yunits邀请Luke做采访，Luke说先让他完成并发布语言，首个真正发布大概还要一两个月。

Luke还提到，文档阶段想让文档站内嵌编译器，每个代码示例都能在浏览器里改、直接跑。这个目标比“写文档”具体得多。

看这套流程，LLM在这里承担的是评审、拆解和调度，agent负责按DAG施工。20年没写完，缺的可能不只是想法，还有单脑加24小时的带宽。但并行有代价，锁、rebase、单层DAG都是代价。Zed还没发布，等第一版出来，再看这套任务图能不能撑住语言长大后的复杂度。