Cursor 多智能体自主编码技术分析
一、概述
1. 技术背景
A. 问题定义
当前的单个 AI 智能体擅长处理聚焦型任务，但在复杂项目中效率低下。如何通过多智能体并行协作，完成通常需要人类团队数月才能完成的大型项目，是本次技术探索的核心问题。
B. 探索目标
- 理解多智能体自主编码的扩展能力边界
- 实现数百个智能体在单个项目上的协同工作
- 观察智能体编写超过一百万行代码和数万亿 token 的过程
C. 技术意义
这项技术探索为 AI 辅助软件开发提供了新的范式，展示了多智能体系统在长期自主运行中的潜力。
2. 实验规模
A. 代码规模
- 超过 100 万行代码
- 跨越 1000 个文件
- 数万亿 token 消耗
B. 运行时长
- 接近 1 周的连续运行
- 3 周以上的代码迁移任务
C. 并发规模
- 数百个工作者智能体同时运行
- 推送到同一分支，冲突极少
二、技术演进历程
1. 单一智能体的局限性
A. 性能瓶颈
- 聚焦任务表现良好
- 复杂项目处理缓慢
- 缺乏并行处理能力
B. 扩展挑战
- 任务分配不明确
- 协调机制缺失
- 进度跟踪困难
2. 扁平化协调尝试
A. 初始设计理念
采用动态协调机制，智能体根据其他智能体的当前状态自主决定做什么，而非预先规划。
B. 实现机制
- 所有智能体地位平等
- 通过共享文件进行协调
- 智能体检查他人工作，认领任务，更新状态
- 使用锁机制防止任务冲突
C. 失败原因分析
问题 1：锁机制的低效
- 智能体持有锁的时间过长
- 部分智能体忘记释放锁
- 即使锁正常工作，也成为性能瓶颈
- 20 个智能体的吞吐量降至 2-3 个的水平
问题 2：系统脆弱性
- 智能体可能在持锁期间失败
- 尝试获取已持有的锁
- 未获取锁就更新协调文件
- 乐观并发控制虽更简单稳健，但深层问题仍存在
问题 3：责任分散
- 无层级结构导致智能体风险规避
- 避免困难任务，倾向于小而安全的改动
- 无智能体对困难问题或端到端实现负责
- 工作长期空转而无实质进展
3. 规划者-工作者架构
A. 架构设计
采用角色分离的管道式架构，将智能体分为规划者和工作者两类：
graph TB
subgraph 规划层
P1[主规划者]
P2[子规划者-领域A]
P3[子规划者-领域B]
end
subgraph 任务队列
T1[任务1]
T2[任务2]
T3[任务3]
end
subgraph 执行层
W1[工作者1]
W2[工作者2]
W3[工作者N]
end
subgraph 评审层
J[评审智能体]
end
P1 --> P2
P1 --> P3
P2 --> T1
P3 --> T2
P1 --> T3
T1 --> W1
T2 --> W2
T3 --> W3
W1 --> J
W2 --> J
W3 --> J
J -->|继续| P1
J -->|完成| End[结束]
B. 角色职责
规划者（Planners）
- 持续探索代码库
- 创建和分解任务
- 可为特定领域生成子规划者
- 规划过程本身可并行和递归
工作者（Workers）
- 认领任务并专注完成
- 不与其他工作者协调
- 不关注整体大局
- 完成任务后推送更改
评审者（Judge）
- 每个循环结束时评估进展
- 决定是否继续下一轮迭代
- 确保项目方向正确
C. 协作流程
sequenceDiagram
participant P as 规划者
participant T as 任务队列
participant W as 工作者
participant R as 代码库
participant J as 评审者
P->>T: 创建任务
P->>T: 分解子任务
W->>T: 认领任务
W->>R: 执行任务
W->>R: 推送更改
W->>T: 标记完成
J->>R: 评估进展
alt 需要继续
J->>P: 触发下一轮规划
else 完成
J->>J: 结束项目
end
D. 架构优势
- 解决了大多数协调问题
- 避免单一智能体的隧道视野
- 支持超大规模项目
- 新智能体仍能理解代码库并取得进展
三、实际应用案例
1. 从零构建浏览器
A. 项目规模
- 运行时间：接近 1 周
- 代码量：超过 100 万行
- 文件数：约 1000 个
B. 技术挑战
从零构建浏览器极其困难，涉及：
- HTML/CSS 解析和渲染
- JavaScript 引擎
- 网络协议栈
- 安全沙箱机制
C. 成果展示
源代码已在 GitHub 上公开，可供探索。尽管代码库庞大，新智能体仍能理解并做出有意义的改进。
2. Solid 到 React 迁移
A. 项目背景
在 Cursor 代码库中进行原位迁移，将 Solid 框架替换为 React。
B. 项目规模
- 运行时间：超过 3 周
- 代码变更：+266K/-193K 行
C. 技术难度
- 需要保持功能等价
- 大规模代码重构
- 复杂的状态管理迁移
D. 当前状态
已进入测试阶段，团队认为可以合并此变更。
3. 视频渲染性能优化
A. 优化目标
改进即将发布产品的视频渲染性能。
B. 优化成果
- 使用 Rust 重写，性能提升 25 倍
- 添加平滑缩放和平移功能
- 实现自然弹簧过渡和运动模糊
- 跟随光标的动态效果
C. 实施状态
代码已合并，即将投入生产环境。
4. 其他进行中的实验
| 项目 | 提交数 | 代码行数 | 状态 |
|---|---|---|---|
| Java LSP | 7.4K | 550K | 进行中 |
| Windows 7 模拟器 | 14.6K | 1.2M | 进行中 |
| Excel | 12K | 1.6M | 进行中 |
四、技术洞察与经验总结
1. 模型选择的重要性
A. 长期运行任务的模型特性
对于极长周期的自主任务，模型选择至关重要：
GPT-5.2 模型在扩展自主工作中表现更优
- 更好地遵循指令
- 保持专注
- 避免偏离
- 精确完整地实现功能
Opus 4.5 的特点
- 倾向于更早停止
- 在方便时走捷径
- 快速交回控制权
B. 角色适配性
不同模型在不同角色上表现各异：
- GPT-5.2 更适合作为规划者
- GPT-5.1-codex 虽专为编码训练，但规划能力不如 GPT-5.2
- 需要根据角色选择最佳模型，而非使用通用模型
2. 简约性原则
A. 复杂度的陷阱
许多改进来自移除复杂度，而非增加复杂度：
- 最初设计了集成者角色进行质量控制和冲突解决
- 发现这创造的瓶颈比解决的问题还多
- 工作者本身已具备处理冲突的能力
B. 结构适度性
正确的结构量介于两者之间：
- 结构过少：智能体冲突、重复工作、偏离目标
- 结构过多：系统脆弱性增加
C. 系统设计启示
最佳系统往往比预期更简单。起初尝试从分布式计算和组织设计中建模系统，但并非所有模式都适用于智能体。
3. 提示工程的关键作用
A. 提示词的影响
系统的行为惊人地依赖于提示词设计：
- 协调效果
- 避免病态行为
- 长期保持专注
B. 实验需求
达到理想状态需要大量实验：
- 提示词的细微差别会显著影响结果
- 需要持续迭代和优化
- 没有通用的最佳实践
C. 三大要素排序
提示词 > 模型 > 框架
五、技术挑战与未来方向
1. 当前局限
A. 效率问题
- 系统尚未达到完美效率
- 但效果远超预期
- 仍有优化空间
B. 规划响应
- 规划者应在任务完成时唤醒
- 规划下一步行动
- 当前机制仍需改进
C. 运行时长控制
- 部分智能体运行时间过长
- 需要更好的终止机制
D. 偏离与视野狭窄
- 仍需定期重新开始
- 对抗偏离目标和视野狭窄
- 保持全局视角的挑战
2. 核心问题的答案
A. 可扩展性验证
核心问题"能否通过投入更多智能体来扩展自主编码"的答案比预期更乐观：
- 数百个智能体可以协同工作
- 在单个代码库上运行数周
- 在雄心勃勃的项目上取得实质性进展
B. 技术路径
- 多智能体协调虽仍是难题
- 当前系统已证明可行性
- 但远未达到最优状态
3. 未来应用
A. Cursor 产品集成
正在开发的技术最终将应用于 Cursor 的智能体能力：
- 更强大的多智能体协作
- 更长期的任务自主处理
- 更大规模的项目支持
B. 人才需求
若对 AI 辅助软件开发的最难题感兴趣，可通过 hiring@cursor.com 联系。
六、架构总结
1. 从失败中学习
graph LR
A[单一智能体] --> B[扁平化协调]
B --> C[锁机制失败]
C --> D[乐观并发控制]
D --> E[责任分散问题]
E --> F[规划者-工作者架构]
F --> G[成功扩展]
2. 关键设计原则
A. 角色分离
- 规划者负责宏观协调
- 工作者专注微观执行
- 评审者把控整体方向
B. 结构适度
- 足够的结构以避免混乱
- 不过度结构导致脆弱
- 在两者间找到平衡
C. 简约至上
- 移除不必要的复杂度
- 让最简单的机制发挥作用
- 提示词比框架更重要
3. 技术启示
A. 分布式系统的借鉴
部分分布式系统模式适用于多智能体：
- 任务队列模式
- 工作者池模式
- 乐观并发控制
B. 智能体特有的挑战
某些分布式系统模式不适用：
- 人类的组织层级假设
- 传统的通信协议
- 固定的责任边界
C. 新范式的诞生
多智能体自主编码是一种新的软件工程范式：
- 不同于传统的人力协作
- 不同于单一 AI 辅助
- 需要全新的设计思维