使用并行 Claudes 团队构建 C 编译器

[jiacai2050]

Building a C compiler with a team of parallel Claudes 这篇文章详细介绍了Anthropic研究员Nicholas Carlini通过开发一种名为“Agent Teams”（代理团队）的新方法来监督和管理大型语言模型（LLM）的实验。

核心实验内容：

• 目标与实现： 作者利用16个并行的Claude实例（Claude Opus 4.6），在没有人类主动干预的情况下，从零开始编写了一个基于Rust的C语言编译器。该编译器最终能够成功编译Linux 6.9内核（支持x86、ARM和RISC-V架构）。
• 规模与成本： 整个过程耗时约两周，进行了近2000次Claude Code会话，花费了约20,000美元的API费用。最终成果是一个包含10万行代码的编译器。
• 主要价值： 实验的重点不是编译器本身，而是从这次长期、自主的代理团队项目中吸取的经验教训，尤其是在设计协调机制（harnesses）方面的发现。

关键技术和设计经验：

1. 实现持续自主进展（Infinite Loop）：

   • 克服了现有LLM代理需要人类持续输入的限制，设计了一个简单的循环机制（类似于Ralph-loop），让Claude在一个任务完成后立即开始下一个任务，实现持续工作。

2. 并行化和专业化（Running Claude in Parallel）：

   • 通过在独立的Docker容器中运行多个Claude实例，实现了任务的并行处理和问题调试效率的提高。
   • 同步机制： 采用基于Git的简单锁机制（写入current_tasks/文件），确保不同代理不会同时处理同一任务。Claude能够解决常见的合并冲突。
   • 角色专业化： 并行允许代理扮演不同角色，例如核心功能开发、代码重复清理、性能优化、文档维护、代码质量审查等。

3. 设计环境与反馈（Designing the Harness）：

   • 高质量测试是关键： 必须编写极其高质量、能自我验证的测试（任务验证器），确保代理解决的是正确的问题。作者为此构建了持续集成流水线（CI）和更严格的测试执行机制。
   • 站在Claude的角度设计： 避免上下文窗口污染（Context window pollution），仅输出少量关键信息，将重要日志存储在易于机器处理的文件中（例如，错误信息与原因在同一行，方便grep）。
   • 解决“时间盲区”（Time blindness）： 引入快速测试（--fast选项），以随机抽样的方式运行小部分测试，避免代理将大量时间花费在重复运行完整测试集上。
   • 解决并行化瓶颈： 在处理单一巨大任务（如编译Linux内核）时，代理团队会陷入重复解决同一问题的困境。解决方案是利用GCC作为“已知良好编译器神谕”（known-good compiler oracle），将内核编译任务分解，让每个代理只负责编译文件的一个子集，从而实现并行修复不同的文件错误。

实验评估与局限性：

• 成功之处： 编译器是一个“白盒”实现（无互联网访问），能成功编译Linux、QEMU、FFmpeg等大型项目，并通过了GCC折磨测试套件（99%通过率），甚至能编译运行Doom。
• 局限性：
  • 缺乏引导Linux所需的16位x86编译器（需调用GCC）。
  • 汇编器和链接器仍在完善中（演示使用GCC的汇编器和链接器）。
  • 无法完全替代现有编译器（仍有部分项目无法编译）。
  • 生成的代码效率低下（比禁用优化的GCC效率还低）。
  • Rust代码质量虽然合理，但不如人类专家。
  • 代理难以解决特定复杂问题，例如实现超过32K代码限制的16位x86代码生成器。

展望与担忧：

“代理团队”展示了自主完成整个复杂项目的潜力，极大地提高了LLM可实现的目标雄心。然而，作者对此表示兴奋的同时也心存不安，因为这种自主开发能力进展迅速，未来需要新的策略来应对缺乏人类实时验证带来的安全风险和质量问题。