Cursor 发布“自动驾驶代码库”：千 Agent 协同构建浏览器引擎
Cursor 近日在其官方博客上披露了一项名为“自动驾驶代码库”（Self-Driving Codebases）的前沿研究项目。该项目展示了 Cursor 在长时间运行自主编码（Long-running Autonomous Coding）领域的最新突破：通过编排数千个 Agent，系统能够连续运行一周，几乎无需人工干预地构建出一个完整的 Web 浏览器引擎。
研究背景与挑战
这项研究最初源于 Cursor 内部对模型极限的探索。团队选择构建一个“不含 JavaScript 的浏览器”作为评测基准，旨在利用其高复杂度和多子系统协同需求，暴露当前 AI 模型的局限。
早期的尝试仅依靠单个 Agent 或简单的并行任务分配，效果并不理想。模型往往在复杂实现细节上停滞，或者过早宣称完成任务。核心问题在于任务过于庞大，缺乏动态的协同机制。
从单 Agent 到多 Agent 架构的演进
Cursor 经历了一个从简单测试框架到复杂多智能体系统的迭代过程：
- 初步尝试与瓶颈：最初尝试让多个 Agent 共享状态文件进行协调，但很快发现锁机制（Locking）导致了严重的资源争用。Agent 之间缺乏结构化分工，导致吞吐量极低，大部分时间都在等待锁。
- 引入角色与职责：团队重新设计了架构，明确了规划器（Planner）、执行者（Executor）和工作者（Worker）的角色。规划器负责拆解任务并生成子规划器，执行者全权负责特定范围的落实，而工作者则专注于具体任务的执行，互不干扰。
- 持续执行器（Continuous Executor）：最终设计移除了独立的规划器，由执行者同时负责规划和实现。系统不再依赖静态计划，而是动态调整方向，确保代码库的“新鲜度”。
核心架构设计亮点
1. 递归式的规划与委派
最终系统采用了一种递归的规划机制：
- 根规划器（Root Planner）：理解用户指令的整体范围，生成具体任务，但不编写代码，也不直接执行。
- 子规划器（Sub-Planners）：当任务可拆分时，递归生成子规划器，全权负责被委派的小块范围。
- Worker：领取任务并在本地代码副本上工作，完成后提交交接说明（包括已完成事项、备注、偏差等）。
这种设计模拟了现代软件团队的运作方式，既保证了吞吐量（通过并行拉起 Worker），又确保了责任归属（每个规划器对分配的任务负全责）。
2. “新鲜度”机制与动态调整
为了防止 Agent 在长时间运行中偏离预期或陷入死循环，Cursor 引入了“新鲜度”机制：
- 定期重写：鼓励 Agent 接近上下文上限时自动总结，并经常从头重写
scratchpad.md。 - 自我反思：在 System Prompts 中加入反思指令，鼓励 Agent 质疑既有假设。
- 移除 Judge：由于系统具备自我纠错能力，团队移除了独立的审查者（Judge），以保持系统简单和动态性。
3. 权衡与容错策略
在追求极致吞吐量的过程中，Cursor 做出了有意的取舍：
- 接受可控错误率：不要求每次提交前达到 100% 正确，允许错误出现但相信其他 Agent 会迅速修复。这避免了因微小错误导致的系统停摆。
- 简化同步开销：接受偶发的文件冲突（“乱流”时刻），让系统自然收敛，而非引入复杂的分布式锁机制。
性能指标与启示
- 吞吐量：在一周运行中，系统峰值吞吐量约为每小时 1,000 次 Commit，基于 1,000 万次工具调用。
- 稳定性：系统能够连续运行一周，无需人工干预。
这项研究不仅展示了技术可行性，更对开发者提出了深刻启示：
- 指令的重要性：即使拥有强大的算力，模糊或次优的指令也会导致灾难性后果。明确的目标、超时配置和防御性编程至关重要。
- 基础设施限制：在单体机器上运行数百个 Agent 会导致磁盘 I/O 成为瓶颈，提示未来需要更高效的并发存储机制。
Cursor 表示，部分用户将有机会试用这项研究成果，标志着多 Agent 协同开发正式从实验走向应用探索。
