🏗️ 报告：在大型语言模型中构建 C 编译器

发布日期: 2026-02-06

Anthropic 研究员 Nicholas Carlini 在其最新的工程博客中分享了一项具有里程碑意义的实验：利用名为 “Agent Teams”（代理团队） 的新方法，驱动 16 个 Claude 实例并行工作，从零开始编写了一个基于 Rust 的 C 编译器。该编译器的最终目标是能够编译整个 Linux 内核。

核心突破与实验概述

实验结果令人震惊：在耗资近 20,000 美元（API 成本）和进行了近 2,000 次 Claude Code 会话后，这个 Agent 团队成功产出了一个 **100,000 行代码** 的编译器。它能够在 x86、ARM 和 RISC-V 架构上构建 **Linux 6.9 内核**。

本文的重点不仅在于编译器本身，更在于设计这种 **“长期运行的自主 Agent 团队”** 所学到的宝贵经验，包括如何设计测试来保持 Agent 的方向、如何结构化工作以实现并行进度，以及该方法的局限性。

二、实现长期运行和并行工作的机制

1. 启用持续自主进度 (Sustained Progress)

为了让 Claude 实现自主、持续的工作，研究员构建了一个简单的 **Shell 循环（类似于 Ralph-loop）**。这个循环的核心逻辑是：当一个 Claude Code 会话完成当前任务后，它会立即启动下一个会话来接手下一项任务。通过在提示词中明确要求 Claude 将问题分解为小块、跟踪当前进度、决定下一步工作，并持续推进，模型被强制保持工作状态。

2. 实现并行化与同步 (Parallelism and Synchronization)

实验运行了 16 个 Claude 实例并行工作。每个 Agent 在独立的工作区中克隆共享 Git 仓库。为了防止多个 Agent 同时解决同一个问题，系统采用了一种简单的 Git 同步算法：

任务锁定： Agent 通过在 current_tasks/ 目录中创建文本文件来“锁定”任务。Git 的同步机制会强制后来的 Agent 选择其他任务。
合并与推进： Agent 完成任务后，会从上游拉取、合并其他 Agent 的更改，推送自己的更改，并删除锁文件。Agent 能够自行处理常见的 Git 合并冲突。

这种早期原型并未实现 Agent 之间的复杂通信或高级目标编排，而是 **完全依赖于每个 Claude Agent 自主决定如何行动**。

三、代理团队编程的经验教训

1. 编写高质量的测试是成功的基石

Agent 会自主解决你给它的任何问题，因此 **任务验证器必须近乎完美**。随着项目接近尾声，Agent 频繁破坏现有功能，研究员通过构建一个严格的 **持续集成（CI）流水线**，强制 Claude 更好地测试其工作，确保新的提交不会破坏现有代码。

2. 站在 Agent 的角度设计环境

必须站在 Agent 的角度设计测试环境，考虑到语言模型的固有局限性：

上下文窗口污染： 测试运行器应避免打印大量无用信息，只打印几行输出，并将所有重要信息记录到易于检索的文件中。日志文件应易于机器处理（例如，错误信息放在同一行，方便 grep 查找）。
时间盲区 (Time Blindness)： LLM 无法感知时间，会耗费数小时运行完整的测试。解决方案是引入 --fast 选项，使其运行 **1% 或 10% 的随机子样本测试**，既能快速识别回归，又能节省 API 成本。
入职指导： 要求 Agent 维护详细的 READMEs 和进度文件，并频繁更新状态，帮助新 Agent 快速定位项目上下文。

3. 简化并行化的挑战

当面临编译 Linux 内核这种 **“巨型单一任务”** 时，Agent 容易卡在同一个 Bug 上并互相覆盖更改。解决方案是：

使用 GCC 作为神谕（Oracle）： 研究员编写了一个新的测试工具，随机地使用 **已知正确的 GCC 编译器** 编译大部分内核文件，只让 Claude 的 C 编译器编译剩余的文件。这有效地将一个巨型任务分解为多个 Agent 可以并行处理的独立小任务。

4. 启用多重 Agent 角色（Specialization）

并行化允许 Agent 具备专业角色，从而提升代码质量和功能。研究员分配了不同的 Agent 承担专业角色，例如：代码清理 Agent (合并重复代码)、性能 Agent (提升编译器运行性能)、代码质量 Agent (从 Rust 开发者角度评估设计)、**文档 Agent** (专注于维护项目文档)。

四、压力测试 Agent 团队的极限

这项实验是针对 **Claude 4.6 模型** 的能力基准测试。尽管总成本接近 20,000 美元，但研究员认为其产出价值远超人力成本。该项目是 **“洁净室实现”（Clean-room implementation）**，模型没有互联网访问权限。

编译器的能力

代码量达 100,000 行。
能够构建可启动的 **Linux 6.9 内核**（x86/ARM/RISC-V）。
可编译 QEMU、FFmpeg 等真实项目，通过率高达 99%。
可编译并运行《毁灭战士》（Doom）。

编译器的局限性

尽管成就巨大，该编译器仍存在明显的局限性：

缺乏 16 位 x86 编译器： 启动 Linux 引导所需的 16 位实模式代码生成能力不足，超出了 32KB 的代码限制，因此在 x86 架构上，它必须 **调用 GCC 来作弊**（但在 ARM 和 RISC-V 上，可完全独立编译）。
生成代码效率低： 即使启用了所有优化，其输出的代码效率仍低于 **未启用优化** 的 GCC。
代码质量： Rust 代码质量合理，但未达到 Rust 专家程序员的水平。

五、展望与风险

Agent 团队展现了实现完整、复杂项目的可能性，极大地拓宽了我们使用 LLM 的想象力。

然而，研究员也表达了对 **全自主开发风险** 的不安。自主系统容易通过测试而掩盖潜在缺陷。在缺乏人类实时验证的情况下，大规模部署 Agent 生成的软件是一个值得警惕的安全问题。

原文链接： https://www.anthropic.com/engineering/building-c-compiler

返回首页