在最新博客《Towards self-driving codebases》中，Cursor 团队披露了他们如何让上千个智能体持续一周为一个浏览器项目提交代码，并总结了多轮架构演进。本文用中文快速解读这篇文章的要点，并加入一些个人理解。

1. 研究背景：高吞吐的长跑型智能体

• 目标：探索“长期运行、自动提交代码”的多智能体系统能否自驱式推进复杂项目（例如浏览器）。
• 基础设施：在单台高配 Linux VM 上运行 Rust 版调度器，记录所有消息与命令，便于回放和分析。
• 结果：稳定运行一周、每小时 ~1000 次提交、累计 1000 万次工具调用，几乎无需人工介入。

2. 方案演进：从共享锁到角色分工再到递归规划

1. 共享状态文件的平行代理：所有代理抢占锁写进度，导致锁冲突、误操作、吞吐骤降，失败。
2. 角色分工（Planner/Executor/Workers/Judge）：规划者负责拆解，执行者总责并派工，法官收尾；缓解了争抢，但 rigid，受最慢 worker 拖累。
3. 持续执行者（无独立 Planner）：执行者一体化规划+派工+审查，灵活但负担过重，出现“随机睡眠、少派工、未合并”等病态行为。
4. 最终设计：递归规划者 + 独立工人：根规划者拆任务，必要时再分出子规划者；工人只拿到局部任务，在自己仓库完成后产出 handoff；规划者持续接收反馈、滚动决策，无全局锁、无集中集成者。

这一版兼顾了“全局所有权”与“局部自主扩散”，是文中认为目前最稳且线性扩展的形态。

3. 取舍：为吞吐放宽“零错误”执念

• 错误容忍：强制 100% 正确会导致串行化，甚至多人踩同一小错误“拥堵”。接受小而稳定的错误率，让系统在后续迭代自然收敛。可能需要独立“绿分支”做发布前快修。
• 同步开销：多代理触同一文件、重复重构在所难免，与其过度防御，不如允许短暂“乱流”后自然收敛。
• 角色简化：移除集中式 integrator（瓶颈门），避免“红线审批”拖慢整体。

4. 基础设施观察：单机、多副本下的新瓶颈

• 运行在单机高配环境已足够支撑数百代理，便于观测与复制状态。
• 软肋从内存转向磁盘：大量并行编译导致 GB/s 级读写，提示项目结构与开发体验会直接影响 token/提交吞吐。
• Git/Cargo 等工具的共享锁在多代理场景下显得笨重，或许可借鉴数据库式并发控制、写时复制、去重存储。

5. “指令即规格”：高质量提示的重要性

文章强调，智能体像“超时长的新同事”，吞吐放大了指令质量的影响：

• 需明确性能、依赖哲学、禁止库、资源守护等，否则模型会“按字面但偏题”执行。
• 避免只给 checklist，更多写意式意图与约束；给出范围数字（如“生成 20-100 个任务”）能传达期望规模。
• 约束往往比冗长指令更有效：“禁止 TODO”“禁止半成品”胜过“记得完成”。

6. 研究原则与启示

文章总结的三条设计原则——反脆弱、经验驱动、显式为吞吐设计——说明他们更重视可演化的简单性，而非复杂的全局协调。对团队的启示：

• 大规模多智能体不是“加人就快”，需要架构与指令让系统能自洽收敛。
• 适度的错误容忍和“发布前快修”流程，可能比单次完美更高效。
• 重新思考开发工具链的并发友好度，才能支撑智能体的工程化规模。

7. 个人观点

• 递归规划者+独立工人的模式，和现实组织的“任务分解-异步交付”类似，易理解也易落地。
• 真正的难点在“信息汇聚与再规划”，hand-off 的质量决定收敛速度。可以尝试模板化 handoff、加自动对齐测试。
• 基建与规格同等重要：如果编译、依赖安装占用大头，即便最聪明的模型也被 I/O 限速。

原文链接：https://cursor.com/blog/self-driving-codebases