并行Claude团队写出C编译器大型Agent研发真正难的是反馈系统摘要Anthropic Engineering 在《Building a C compiler with a team of parallel Claudes》中披露了一个很强的工程实验让 Opus 4.6 通过并行 Agent 团队从零实现一个 Rust 编写的 C 编译器。实验使用 16 个并行 Claude Code Agent累计近 2000 个 Claude Code 会话约 20,000 美元 API 成本最终得到一个约 100,000 行的编译器可以构建 Linux 6.9并支持 x86、ARM、RISC-V。这件事容易被解读成“模型已经能自动写大型软件”。但对研发团队更有价值的结论是真正的关键不是多开几个 Agent而是围绕 Agent 构建一套能持续反馈、能并行拆分、能防止回归、能让模型快速定位问题的工程系统。换句话说大型 Agent 研发的瓶颈正在从“模型是否会写代码”转向“团队是否会设计反馈环境”。背景从单个编码助手到并行 Agent 团队传统 Claude Code 或类似编码 Agent 的交互假设是用户给出一个任务模型运行一段时间返回结果然后等待用户继续指令。这适合修复单个 bug、实现一个接口或生成局部模块但不适合持续数天、跨大量文件、需要不断修复回归的大型软件工程。Anthropic 的实验采用了更极端的方式把 Claude 放进一个持续循环中。每个会话结束后下一轮会继续运行读取任务提示、检查代码仓库状态、选择下一步工作。多个 Agent 被放入独立 Docker 容器中每个容器克隆同一个上游 Git 仓库在自己的工作区修改代码完成后再推送回上游。这个设计看起来简单但它解决了一个核心问题Agent 不再是一次性回答器而是变成了持续贡献者。它能在测试失败、文档更新、代码重构、性能优化之间来回切换只要环境持续给出明确反馈。技术要点并行不是数量问题而是同步问题并行 Agent 最直接的收益是多个实例可以同时处理不同问题。但如果没有同步机制结果很快会变成互相覆盖。Anthropic 的原型使用了一个非常朴素的任务锁Agent 通过在 current_tasks 目录写入文本文件来声明正在处理的问题例如 parse_if_statement 或 codegen_function_definition。如果两个 Agent 试图拿同一个任务Git 同步会迫使后者换一个任务。这个机制并不复杂但很关键。它说明 Agent 团队不一定一开始就需要大型调度平台最小可用的协作协议可以落在 Git、文件锁和测试脚本上。对研发团队来说重要的是让“谁在做什么”变成仓库中的显式状态而不是只存在于模型上下文里。第二个关键点是测试 oracle。编译器项目早期有大量独立失败测试Agent 可以自然并行每个 Agent 选一个失败样例修复。但当目标变成“编译 Linux kernel”时任务从许多小问题变成一个巨大问题16 个 Agent 会同时撞到同一个 bug然后互相覆盖修改。Anthropic 的解决方法是引入 GCC 作为已知正确的 oracle随机选择部分文件由 GCC 编译其余由 Claude 的编译器编译通过二分式替换定位失败文件。这样一个巨大任务重新被切成许多可并行诊断的小任务。第三个关键点是上下文污染控制。Anthropic 明确提到测试 harness 不应该向模型打印几千行无用输出。错误应被写入日志摘要输出要短关键错误行最好包含 ERROR 这类可 grep 标记。模型不是人类 IDE 用户它没有无限注意力。测试系统如果把上下文填满Agent 会更难判断下一步。研发视角Agent 工程师要设计“给模型用的 CI”这篇文章最有实践价值的部分是它把 CI 从“给人看的质量门禁”扩展成了“给 Agent 使用的反馈接口”。传统 CI 输出可以很长因为人会打开日志、搜索关键栈、结合经验定位问题。Agent 需要更结构化的反馈失败类型、最小复现、相关文件、最近回归点、推荐检查路径。Anthropic 在实验后期发现Claude 在实现新功能时会频繁破坏已有功能于是加入更严格的持续集成让新提交不能轻易打破既有测试。这对企业内部 Agent 平台很重要。许多团队现在让 Agent 直接改代码但没有把测试和验收结果设计成模型友好的形式导致 Agent 只能盲目试错。另一个研发信号是“把自己放到 Claude 的位置”。每个 Agent 会在新容器中启动初始上下文有限需要重新理解项目。因此项目必须维护清晰 README、进度文件、已知失败列表、设计决策记录。对人类团队来说这些文档可能是锦上添花对长任务 Agent 来说它们是继续工作的入口。这也解释了为什么近期很多 Agent 工程实践都强调 structured artifacts。Anthropic 在 long-running application harness 文章中也提到长时间自主开发需要 planner、generator、evaluator 等角色以及可跨会话传递的结构化产物。模型上下文可以压缩但工程状态必须落在文件、测试、Git 历史和明确协议里。实践建议如何把并行 Agent 用在真实研发中第一从可验证任务开始。并行 Agent 最适合有明确测试、明确构建、明确回归检查的任务。例如迁移 API、补测试、修复 lint、扩大兼容性、批量处理失败用例。不要一开始就让 Agent 做高度主观、验收不清的重构。第二把任务拆分标准写进仓库。可以建立 current_tasks、done_tasks、known_failures、progress.md 之类的目录或文件让 Agent 通过文件系统协调而不是依赖聊天记录。任务粒度要小到单个 Agent 能在一轮内完成并验证。第三测试输出要面向模型优化。失败摘要应短详细日志写文件错误行要稳定可搜索构建脚本要提供 fast 模式长测试应支持采样或分片。Anthropic 的经验是模型存在“时间盲区”如果测试太慢它可能长时间等待而没有实质进展。第四引入已知正确 oracle。不是每个项目都有 GCC 这样的权威对照但很多研发场景可以构造 oracle旧系统输出、新旧接口对比、生产样本回放、黄金数据集、静态分析规则、契约测试。oracle 的作用是把模糊大任务切成可定位的小问题。第五给并行 Agent 分配角色而不是只复制同一个提示词。一个 Agent 负责功能一个负责去重一个负责性能一个负责文档一个负责代码结构审查。Anthropic 的实验中专门的代码质量、性能和文档 Agent 能减少重复实现和结构漂移。风险与限制这个实验仍然不是“无人监督生产软件”的证明。Anthropic 明确指出产出的编译器还不是 GCC 的替代品缺少自己的 assembler 和 linker部分 x86 16 位启动阶段依赖 GCC生成代码效率也明显不如 GCC。Rust 代码质量可以接受但远不到专家级。成本也是现实限制。近 2000 个会话、2B 输入 token、140M 输出 token、接近 20,000 美元 API 成本不适合大多数日常研发任务。企业采用类似方法时应优先用于高价值、可验证、可并行的大型迁移或缺陷收敛而不是常规小需求。更大的风险是信任错位。测试通过并不代表软件可靠Agent 可能学会满足测试而不是满足真实需求。并行 Agent 会扩大代码产出速度也会放大未审查代码进入系统的风险。因此最终合并前仍需要人类工程师审查架构、安全边界和关键逻辑。参考来源Anthropic Engineering - Building a C compiler with a team of parallel Claudes: https://www.anthropic.com/engineering/building-c-compilerAnthropic Engineering - Harness design for long-running application development: https://www.anthropic.com/engineering/harness-design-long-running-apps