迈向自动驾驶代码库
核心要点：本文介绍如何构建能够自主完成大部分代码提交的多 Agent 系统，分享从单 Agent 到多 Agent 协作的演进历程和关键设计经验
研究背景
我们对关于扩展长时间运行自主编码 Agent 的研究反响感到兴奋。
这项工作始于内部研究，旨在 push the limits of current models。作为研究的一部分，我们创建了一个新的 Agent 协调系统来编排数千个 Agent 并观察其行为。到上个月，我们的系统已经稳定到可以连续运行一周，为我们的研究项目（一个 Web 浏览器）提交了绝大部分代码。这个浏览器并非为外部使用而设计，我们也预期代码存在不完善之处。
然而，尽管有各种小问题，成千上万个 Agent 能够协同工作以产生几乎完全无需人工干预即可运行的成果，这一事实感觉像是一个值得分享的里程碑。自那时起，我们继续了研究，希望更深入地介绍这个协调系统是如何构建的。
我们还向部分用户开放了这项研究的试用。
项目起源
我们的研究项目始于我（作者）的一个个人副业。
浏览器是一个有趣的基准测试。它足够复杂以揭示前沿模型的局限性，而且有许多不同的子系统需要协同工作。
我最初的计划是支持渲染不含 JavaScript 的网页。我开始提示 Opus 4.5，要求它为构建浏览器引擎写一个详细的计划。我会反复催促它"继续推进"，看看它能在计划上走多远。
这很快就失败了。模型失去了对它正在做的事情的跟踪，经常停下来宣布成功，尽管离成功还很远，并在复杂的实现细节上卡住。但它显示出深度知识和智能的一面。它可以在小块中写出好的代码。
核心问题是浏览器任务太 overwhelming，需要分解成子任务。接下来，我让 Agent 规划出 Agent 可以并行处理的主要工作依赖图。任务被手动生成，当它们停止时会得到推动。这增加了吞吐量，但结果并没有好多少。Agent 之间无法相互沟通或提供整个项目的反馈。系统需要更加动态。
同时，GPT-5.1（以及后来的 GPT-5.2）在精确遵循指令的能力方面开始显示更好的结果。这似乎很适合长时间运行的 Agent，因此我们根据这些实验更新了协调系统以使用 OpenAI 模型。
此时，协调系统可以构建一个不含 JavaScript 的简单版本浏览器，但用单个 Agent 构建完整的浏览器引擎将 prohibitively slow。
这开始了我们下一轮研究。我们能否花费 10 倍的计算成本来获得 10 倍有意义的吞吐量？
从单 Agent 到多 Agent
我们用一个简单的基于 Rust 的协调系统启动了一个新仓库。
我们没有处理分布式系统的复杂性，而是在具有大量资源的单个大型 Linux 虚拟机（VM）上运行协调系统。为了控制协调系统，我们会 SSH 到 VM 并使用简单的终端界面。
我们在系统可观测性上投入了更多前期时间。我们记录了所有 Agent 消息、系统操作和命令输出，并带有时间戳，以便我们可以分析和重放会话。这不仅有助于我们手动审查，也有助于将其接入 Cursor 以筛选大量数据并快速找到模式。
自我协调
我们第一个多 Agent 的想法最简单：让具有相同角色的 Agent 使用共享状态文件来查看其他人正在做什么，决定要处理什么，并更新文件。
工作流程：Agent 通过共享协调文件进行自我协调
我们尽可能少地规定要做什么，而是让 Agent 弄清楚如何自我协调。这很快失败了。
协调文件 quickly created more problems。Agent 持有锁时间过长，忘记释放它们，试图在非法时锁定或解锁，而且总体上不理解持有协调文件锁的重要性。锁定很容易出错且 narrowly correct，更多提示没有帮助。
锁定 also caused too much contention。20 个 Agent 会减慢到 1-3 个的吞吐量，大部分时间花在等待锁上。我们尝试给 Agent 一个显式等待另一个 Agent 工作的工具，但它们很少使用。我们还尝试了无锁的乐观并发控制方法，减少了开销但没有消除混乱。
Agent 之间缺乏结构意味着没有单个 Agent 承担大型复杂任务。它们避免争用和冲突，选择更小更安全的更改，而不是为整个项目负责。
添加结构和角色
接下来，我们分离角色以赋予 Agent 所有权和责任：
系统架构：Planner（规划者）、Executor（执行者）、Workers（工作者）和 Judge（裁判）的管道
规划者首先 laying out exact approach and deliverables 以取得用户指令的进展。这交给执行者，成为负责确保计划完全完成的唯一主导 Agent。执行者可以为工作者生成任务，提供线性扩展和吞吐量。
为了持续推进和责任，独立裁判在执行者完成后运行，判断它是否完成以及是否应该运行另一次迭代。这解决了很多协调问题。拥有专门的角色来拥有和监督执行允许工作者 narrow 专注于他们的任务，而整个系统仍然交付。
观察与爬山
达到这个设计需要对系统进行 close observation。
如果有一个重大问题，它往往会在许多 Agent 和工具调用中重复发生。例如，我们注意到争用过多，因为许多 Agent 同时运行 git restore。我们使用 Cursor 分析日志并将它们与我们的提示进行比较，以了解为什么行为与预期不符。
最终，我们发现这个系统被最慢的工作者瓶颈。太 rigid 了。
预先完成所有计划也使系统难以动态地随着发现的新问题重新调整。一些 Agent 最终会走向 counterproductive 的方向，无法自我纠正，直到下一次循环迭代。
持续执行者
下一个版本移除了独立的规划者。
执行者现在还可以规划如何交付目标以及生成任务。因为它是唯一的 Agent，它不需要在任何地方写计划，坚持一个静态不变的计划，或 rigidly 等待所有工作者。
确保新鲜度
为了确保所有角色中的 Agent 不会在长时间内漂移，我们引入了新鲜度机制：
- scratchpad.md 应该经常重写而不是追加
- Agent 被鼓励在任何时候 pivot 并挑战假设
系统现在高度动态和灵活：它可以主动探索代码，重新考虑决策，管理工作者，交织任务，并持续反映最新信息。我们发现 Agent 相当擅长遵循指令完成，因此移除了裁判以保持系统简单。
系统设计：具有工作者的无限执行者循环
病态行为
尽管有这些改进，持续执行者开始表现出病态行为。它会随机停止，停止运行 Agent，自己做工作，拒绝计划并生成超过几个 narrow focused 的任务，不正确地合并工作者更改，并声称过早完成。
我们发现它被同时赋予了太多角色和目标，包括：计划、探索、研究、生成任务、检查工作者、审查代码、执行编辑、合并输出，以及判断循环是否完成。回想起来，它被淹没是可以理解的。
最终系统设计
最终设计整合了我们所有的经验：
- 根规划者拥有用户指令的整个范围。它负责理解当前状态并交付将推进目标的特定定向任务。它自己不做编码。它不知道它的任务是否被选取或由谁选取。
- 当规划者认为其范围可以细分时，它生成完全拥有委托窄片的 subplanners，以类似的方式完全拥有，但仅限于该切片。这是递归的。
- 工作者获取任务并 sole 负责将它们推向完成。它们不知道更大的系统。它们不与任何其他规划者或工作者通信。它们在 repo 的自己的副本上工作，当完成时，它们写出系统提交给请求任务的规划者的单个交接。
有趣的是，这确实代表了今天一些软件团队如何运作。
最终架构：递归规划者、工作者和 git
Subplanners 通过快速向工作者扇出同时确保整个系统仍然完全由 Agent 拥有和负责来增加吞吐量。这也有助于大型项目和任务，否则单个规划者会变得不知所措并产生隧道视野。
交接不仅包含完成的内容，还包含重要的笔记、担忧、偏差、发现、想法和反馈。规划者将其作为后续消息接收。这保持系统持续运动：即使规划者"完成"，它继续接收更新，pull 最新的 repo，并可以继续规划和做出后续决定。
所有 Agent 都有这种机制，这允许系统保持令人难以置信的动态和自洽，将信息沿链向上传播给拥有越来越全局视图的所有者，没有全局同步或交叉通话的开销。
移除集成者
我们最初添加了一个集成者，用于 central globally-aware quality control，并移除太多工作者同时尝试 push、rebase、解决冲突和合并的争用。
它很快成为明显的瓶颈。有数百个工作者和一个所有工作必须通过的 gate（即"繁文缛节"）。我们尝试了提示更改，但最终认为它是不必要的，可以移除以简化系统。
吞吐量与权衡
系统峰值达到约每小时 1000 次提交，在一周内超过 1000 万次工具调用。系统启动后，不需要我们任何干预。
性能数据：峰值约 1000 commits/hour
实现这个吞吐量有 intentional tradeoffs。
提交正确性
当我们要求每次单个提交 100% 正确时，它导致 effective throughput 的 major serialization 和 slowdown。即使是一个小错误，如 API 更改或拼写错误，也会导致整个系统 grinding to a halt。工作者会超出范围开始修复不相关的事情。许多 Agent 会 pile on 并互相 trample 试图修复同一个问题。
这种行为没有帮助或必要。允许一些 slack 意味着 Agent 可以相信其他问题会很快被其他 Agent 修复，因为系统确实对整个代码库有有效的所有权和委托。错误 then arise 然后很快被修复。错误率保持很小和恒定，也许很少完全干净，但稳定和可管理，不会爆炸或恶化。
这可能表明理想的高效系统接受一些错误率，但需要一个最终的"green"分支，其中 Agent 定期拍摄快照并在发布前做快速 fixup pass。
同步开销
有时多个 Agent 触及同一个文件或重构相同的代码。我们没有试图完全 stamp 这些 out 或 overengineer a solution，而是接受一些 turbulence moments 并让系统自然地 converge 并在短时间内 settle。
这花费一些额外的 tokens 并产生 local contention，但保持系统总体更简单：更容易对齐模型而不是让它们不堪重负，更容易管理和观察，更少摩擦，以及更好的全局生产力。它也避免了过于复杂的方法。
基础设施经验
每个多 Agent 运行在其自己的大机器上运行，具有充足的系统资源，以避免围绕分布式系统的过早复杂性。这是很好的契合，因为大多数运行峰值在数百个 Agent，这通常会 saturate 但不会 overprescribe 这些机器。这种架构更容易观察系统指标，并在必要时共享和复制状态。
在限制 Agent 的 RAM 使用后，磁盘成为热点。特别是对于 monolith 项目，数百个 Agent 同时编译会导致许多 GB/s 的读写构建 artifact。这对协调系统的整体吞吐量有重大影响，这是一个有趣的教训：项目结构、架构决策和开发者体验会影响 token 和提交吞吐量，简单因为处理代码库（如编译）支配时间，而不是理想地思考和编码。
开发和环境中也有约束和低效：对单个用户工作区有意义或不显著的东西，在数百个 Agent 在一台机器上做同样的事情时会凸显出来。解决这个的一个 trivial 方式是给每个 Agent 自己的机器。但仅仅通过重新思考和重新设计一些这些原语和工具，就有机会获得显著效率收益。
例如，许多工具如 Git 和 Cargo 使用共享锁 largely as a simple concurrency control mechanism。能否将数据库中已建立的机制引入，使它们在多 Agent 系统中表现同样好？所有 Agent 都有 repo 的自己的副本，但大多数文件和 artifact 是相同的；能否添加简单的写时复制和去重功能，found in more sophisticated production storage systems，带来类似的轻松收益，而无需构建单独的基础设施？
向 Agent 指定意图
给这个多 Agent 系统的指令非常重要。
最初，我们没有将它们作为主要目标，而是 aiming for a stable and effective harness。但指令的重要性很快变得明显。我们基本上是在与一个典型的编码 Agent 交互，只是有 orders of magnitude 更多的时间和计算。这放大了一切，包括 sub-optimal 和 unclear 的指令。
在初始指令上投入更多时间是 ultimately 合理的。Agent 仍然是 Agent：训练来严格遵循你的指令，走那些路径，不改变或覆盖它们，即使它们不好。
我们想在研究项目中看到成功，所以我们随着项目和协调系统的发展改变了我们的初始指令。我们在学习如何构建浏览器的同时学习如何操作这个新多 Agent 系统，并且可以看到糟糕或 underspecified 的规范反映在输出质量中，这并不是由于协调系统本身。协调系统只是精确地遵循我们的指令。
来自浏览器项目的一些例子：
最初，指令专注于实现规格和 squash bugs。像"spec implementation"这样的指令足够模糊，Agent 会深入 obscure rarely used features 而不是 intelligent prioritizing。 我们假设隐含地存在用户友好范围内的性能期望。但需要显式指令和 enforced timeouts 来强制 Agent 平衡性能与其他目标。 对于系统的复杂部分，Agent 可能会写出有内存泄漏或导致死锁的代码。人类会注意到，但不一定对 Agent 明显。需要显式的基于过程的资源管理工具来允许系统 gracefully recover 并更加 defensive。 我们第一个不含 JavaScript 的简单浏览器版本 converge on 一个不适合进化为完整浏览器的架构。这是初始规范的失败。 同样，虽然 Agent 被告知项目是一个从头开始的浏览器，它们仍然 pull 了一些它们本可以自己实现的依赖，或用作临时脚手架，而 proper implementation 正在进行中。这是指令中的 oversight。后来的运行明确 laid out 依赖哲学和哪些库必须不能使用，纠正了这一点。 那次运行 also did a major restructuring into many self-contained crates，搬离 monolith。仓库处于严重 broken 状态，但多 Agent 系统在几天内 converge 到工作的代码。这表明系统具有强大的协作和 intelligent 工作能力 holding across totally broken states 而不是进一步 degradation 或卡住。那次运行也花费更少的时间等待编译，以 multiple times 更多的吞吐量运行比以前。
架构和指令很重要。Agent 有巨大的工程技能但会 good or bad 地遵循指令。找到过于狭隘的指标和无结构自由之间的平衡是棘手的，知道什么是 obvious versus what needed explicit mention 也是如此。
所有这些都表明了 eliciting、specifying 和理解意图的重要性，这在这种规模下变得更加重要。Steerability 和可观察性将是继续探索的有趣研究领域。
优化提示
提示是 evolution 过程的重要部分。
我们发现最好不为模型知道如何做的事情做指令，只为它不知道的事情（如多 Agent 协作）或与相关领域特定的事情（如如何运行测试、你的部署管道）做指令。把模型当作一个知道工程但不知道你特定代码库和流程的聪明新员工。
约束比指令更有效。"No TODOs, no partial implementations" 比 "remember to finish implementations" 更好。模型通常默认做好的事情。约束是定义它们的边界。
避免 checkbox mentality for higher-level or deeper tasks。给出关于你意图的详细 instructions，但记住给出具体的事情去做 tend to make the model focus on achieving those rather than the wider scope。你也隐式地 deprioritize unlisted things。通常，最好让模型使用它的判断力和能动性。
我们确实发现在讨论数量范围时给出具体数字和范围很有用。"generate many tasks" 这样的指令 tend to produce a small amount: conservative default, playing it safe, technically still following instructions。"Generate 20-100 tasks" 传达了意图是更大范围，它应该是有雄心的，我们观察到非常不同的更广泛行为。
系统设计经验
我们从研究中确立了一些原则：
- 系统应该是反脆弱的：随着我们扩展同时运行的 Agent 数量，我们也增加了个体失败的概率。我们的系统需要能够承受个体 Agent 失败，允许其他人恢复或尝试替代方法。
- 经验胜于假设驱动：我们想用数据和观察进行调整，而不是根据人类组织或现有系统设计如何运作的假设来进入。
- 明确为吞吐量设计：这意味着 trade off 编码的其他方面，比如接受一个 small but stable 的错误率，需要最终的 reconciliation pass，而不是 100% 的时间完美工作代码，这会 dramatically slow down 系统。
这些系统在做得正确时往往是 elegantly simple，但在我们探索许多不同方法之前，不清楚哪种简单方法会起作用。当前系统设计一直在 minimal overhead 下运行，并提供有用的 token 吞吐量的线性扩展。协调系统不需要 further major iterations。
结论
虽然品味、判断和方向来自人类，但 AI 是快速迭代和探索这个研究的 significant force-multiplier。
这与"virtuous"AI 循环有些相似，其中 AI 被用来开发 AI，随着模型和 Agent 和协调系统变得更好，它会 feeding into itself 并越来越快。我们塑造工具，工具塑造我们。
这项研究与今天一些软件团队的运作方式有诗意的相似之处。这些模型没有明确以这种方式训练，这表明它是 emergent behavior，可能是 structuring 软件项目的正确方式。
我们将 continue 研究非常长时间运行的 Agent，我们的发现将 informs 我们产品的未来。
关键经验总结
核心要点：
- 自我协调失败：共享状态文件导致锁争用和混乱，需要结构化角色
- 角色分离：Planner-Executor-Worker-Judge 模式解决协调问题
- 持续执行：移除独立规划者，由执行者同时负责计划和执行
- 错误容忍：接受小而稳定的错误率优于追求 100% 正确性导致的生产力损失
文档来源：Towards self-driving codebases原始作者：Wilson Lin原始发布日期：2026 年 2 月 5 日
本文由 AI 助手整理优化，欢迎关注、分享转载，请注明出处
