山月刀岚月刀1. 为什么挑编译器来测试AI Agent协作
这个实验我前前后后跑了六周，账单停在两万美元出头的时候，账户监控弹了余额提醒。16个AI agent，从零开始协作写一个C语言子集的编译器，用的编排底座是Claude Agent Teams那一套多Agent工作流。今天这篇就当复盘：为什么选编译器、账烧在哪、过程中最崩溃的瞬间，以及这笔钱到底证明了什么。
普通业务代码允许"大体正确"。编译器不行。一段C代码运行结果是错的，你很难分清是前端语法分析错了、中端IR生成错了、后端指令选择错了，还是某个优化pass把语义改坏了。编译器是少数几个"错误传导链极长"的软件，前端一个不起眼的AST节点丢失，可能到后端生成汇编时才炸，错误信息还完全对不上。用AI来写这种软件，本质上是在测试概率模型在确定性系统上的极限。
我选择的策略是把编译器按经典流水线切成16个独立模块，每个模块由一个agent负责：词法分析、语法分析、语义分析、符号表、IR生成、若干优化pass、后端代码生成、集成测试。选择C语言子集，是因为C的语法密度够高，指针、类型转换、结构体布局这些特性，对前中后端都会产生连锁压力；又不至于真的去实现一个完整C23，那工程量烧2万美金怕是不够。
1.1 编译器是"错误传导链"最长的软件之一
很多看似合理的AI编程实验选错了测试对象，比如让AI写个CRUD接口、写个爬虫、写个自动化脚本，这类任务测试反馈非常直接：接口调一次就知道对不对。编译器完全不是这个节奏。词法分析器如果漏掉一个token边界，语法分析器可能给你报一个完全无关的行号；语义分析器的类型推导错了一个节点，优化器可以把错误的中间表示堂堂正正地折叠成一个常量，最后生成的机器码还是"正确执行"的——只是执行的是错误语义。
这意味着多Agent协作模式下，错误来源被进一步放大。16个agent，任何一个模块的commit都在向上游或下游传导不可见的影响。我在实验中反复经历"测试用例红了一大片，但没有任何一个agent承认是自己的问题"。这跟真实团队里推诿扯皮是一个味道，只是AI不会辩解，它只会诚恳地写一封"已修复，请再试一次"的总结，然后给出一个仍然错误的新commit。
1.2 为什么是16个，而不是4个或40个
一开始我也想过用4个agent，每个负责一大块：前端、中端、后端、测试。但实测发现单个agent上下文窗口会被迅速塞满，尤其后端代码生成涉及ABI、指令选择、寄存器分配，复杂度超出单agent稳定处理的范围。切成16个，是为了让每个agent的职责边界足够窄、上下文足够可控——有点像软件工程里的"模块内聚"。但你很快会发现，模块多了以后，人与人之间的沟通成本转移成了agent与agent之间的接口对齐成本，这个问题我后面专开一章讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 2万美金烧在哪：16个Agent的分工与成本账单
2.1 16个角色的分工
| 编号 | 角色 | 负责内容 | 交付物 |
|---|---|---|---|
| A1 | 架构监理 | 维护全局spec、接口版本、任务排期 | central-spec.md |
| A2 | 词法分析 | token定义、lexer实现、字面量解析 | token.h, lexer.cpp |
| A3 | 语法分析 | 递归下降parser、AST节点定义 | ast.h, parser.cpp |
| A4 | AST校验 | AST一致性检查、源位置追踪 | ast_validate.cpp |
| A5 | 符号表 | 作用域链、符号插入与查询 | symb |