当 AI 编码代理从单次会话扩展到持续数周、生成百万行代码的复杂项目时，系统架构面临根本性挑战。Cursor 团队在《Scaling long-running autonomous coding》中分享了运行数百个并发代理数周的经验，揭示了从平等协调到分层架构的演进路径，以及状态管理、错误恢复和资源分配的关键工程实践。
长时间运行系统的核心挑战
传统 AI 编码代理设计针对单次会话或短期任务，当任务周期延长至数天甚至数周时，系统必须解决三个核心问题：
状态持久化与恢复：代理在运行过程中积累的上下文、任务进度和决策历史需要可靠存储。Cursor 团队发现，简单的文件锁机制在长时间运行中会失效 —— 代理可能持有锁数小时不释放，或在崩溃后忘记释放锁，导致整个系统停滞。
错误传播与隔离：在数百个并发代理的环境中，单个代理的错误可能迅速传播。早期实验中，一个代理的错误编辑可能被其他代理作为 "正确" 参考，导致错误放大。系统需要建立错误检测和隔离机制，防止局部故障影响全局进度。
资源分配与优先级：不同任务对计算资源的需求差异巨大。构建浏览器渲染引擎需要密集的算法实现，而 UI 组件可能更依赖设计决策。系统需要动态分配计算预算，避免资源浪费在低优先级任务上。
架构演进：从平等协调到分层模型
Cursor 团队的实验揭示了 AI 代理协调的复杂性。他们尝试了三种架构模式：
1. 平等自协调模式（失败） 初始设计让所有代理地位平等，通过共享状态文件协调工作。每个代理读取当前任务状态，声明一个任务，更新状态。为防止冲突，他们实现了文件锁机制。结果发现：
- 20 个代理的有效吞吐量降至 2-3 个代理水平，大部分时间花在等待锁上
- 代理可能崩溃后仍持有锁，或尝试获取已持有的锁
- 系统脆弱，小错误导致全局停滞
2. 乐观并发控制（部分成功） 改用乐观并发控制：代理自由读取状态，但写入时检查状态是否变更。这简化了协调逻辑，但暴露了更深层问题：没有层级结构时，代理变得风险规避，避免困难任务，只做安全的小改动。没有代理愿意承担端到端实现的责任。
3. 规划者 - 工作者分层架构（成功） 最终成功的架构分离了角色：
- 规划者：持续探索代码库，创建任务，可生成子规划者处理特定领域
- 工作者：专注于完成任务，不协调其他工作者，不关心全局视图
- 评审者：每个周期结束时评估项目完成度，决定是否继续
这种分层结构解决了协调问题，允许扩展到大型项目，同时避免单个代理陷入隧道视野。
工程实现：状态管理与并发控制
状态持久化策略
长时间运行系统需要多级状态管理：
任务状态存储：使用版本控制的 JSON 文件存储任务分配、进度和依赖关系。每个任务包含：
{
"task_id": "render-engine-parser",
"assigned_to": "worker-42",
"status": "in_progress",
"started_at": "2026-01-20T08:30:00Z",
"last_heartbeat": "2026-01-20T10:45:00Z",
"checkpoint_frequency": 300, // 每5分钟检查点
"estimated_completion": "2026-01-20T12:00:00Z"
}
上下文检查点：每 5-10 分钟保存代理的完整上下文，包括：
- 当前思考过程
- 已考虑但未采用的方案
- 代码变更历史
- 遇到的错误和解决方案
分布式锁替代方案：避免文件锁，改用基于 Redis 的分布式锁，设置自动过期时间（默认 30 分钟），防止死锁。
并发控制参数
基于 Cursor 的经验，以下参数在实践中表现良好：
代理数量与吞吐量关系：
- 10-50 个工作者：线性扩展，冲突率 < 5%
- 50-200 个工作者：次线性扩展，冲突率 5-15%
- 200 + 个工作者：边际收益递减，需要更细粒度分区
任务粒度优化：
- 小任务：1-5 个文件修改，预计完成时间 < 30 分钟
- 中任务：5-20 个文件，预计完成时间 30 分钟 - 2 小时
- 大任务：20 + 个文件，需要分解为子任务
心跳与健康检查：
- 工作者心跳间隔：60 秒
- 健康检查超时：300 秒（5 次心跳）
- 自动重启阈值：连续 3 次健康检查失败
模型选择策略
Cursor 发现不同模型在长时间运行任务中表现差异显著：
GPT-5.2 vs Opus 4.5：
- GPT-5.2：更适合长时间自主工作，能保持专注、避免漂移、精确完整地实现功能
- Opus 4.5：倾向于提前停止，在方便时走捷径，快速交回控制权
角色专用模型：
- 规划者：GPT-5.2 表现优于专门训练的 GPT-5.1-Codex
- 工作者：根据任务类型选择，算法密集型任务用 GPT-5.2，UI/UX 任务用 Opus 4.5
- 评审者：需要综合判断能力，使用混合模型投票机制
可落地参数与监控指标
运行时长配置
基于实际项目经验，建议以下配置：
短期项目（1-3 天）：
- 最大连续运行时间：8 小时
- 强制重启间隔：每 4 小时
- 状态检查点频率：每 15 分钟
- 内存限制：8GB / 代理
中期项目（1-2 周）：
- 最大连续运行时间：24 小时
- 强制重启间隔：每 12 小时
- 状态检查点频率：每 5 分钟
- 内存限制：16GB / 代理
- 磁盘状态存储：100MB / 代理 / 天
长期项目（2 周 +）：
- 最大连续运行时间：48 小时
- 强制重启间隔：每 24 小时
- 状态检查点频率：每 2 分钟（关键任务）
- 内存限制：32GB / 代理
- 磁盘状态存储：500MB / 代理 / 天
- 版本控制分支策略：每 24 小时创建新分支
错误恢复机制
分级恢复策略：
- 瞬时错误：自动重试，最多 3 次，间隔指数退避（1s, 2s, 4s）
- 任务级错误：回滚到最近检查点，重新分配任务
- 代理级错误：重启代理，从共享状态恢复
- 系统级错误：暂停所有代理，人工干预后继续
错误检测阈值：
- 代码质量下降：测试通过率 < 80% 持续 2 小时
- 进度停滞：连续 4 小时无有效提交
- 资源异常：CPU 使用率 > 90% 持续 30 分钟，或内存泄漏 > 1GB / 小时
- 协调失效：任务冲突率 > 20%
监控仪表板关键指标
构建监控系统时，应跟踪以下核心指标：
效率指标：
- 有效代码行 / 小时（排除重复、回滚的代码）
- 任务完成率（完成数 / 分配数）
- 冲突解决时间（从冲突检测到解决的平均时间）
质量指标：
- 测试通过率（单元测试、集成测试）
- 代码审查通过率（自动 + 人工）
- 技术债务增长（复杂度、重复度变化）
资源指标：
- 代理利用率（活跃时间 / 总时间）
- 内存使用趋势
- API 调用成本 / 千行代码
实际案例：FastRender 浏览器项目
Cursor 团队用分层架构运行了近一周的浏览器构建项目，生成了超过 100 万行代码、1000 多个文件。关键工程决策包括：
规范内嵌：将 WhatWG 和 CSS-WG 规范作为 Git 子模块包含在仓库中，确保代理能访问参考材料。
渐进验证：每完成一个核心模块（HTML 解析器、CSS 引擎、渲染管线）就运行简化测试，而不是等待完整实现。
并行探索：对关键算法（如 CSS 选择器匹配）让多个工作者实现不同方案，最后选择最优实现。
项目结果显示，虽然渲染存在明显缺陷（按钮样式错误、引号显示问题），但页面基本可读，证明架构的有效性。
未来方向与待解决问题
尽管当前架构已能支持数周运行，但仍存在挑战：
动态规划唤醒：规划者应该在任务完成时自动唤醒，规划下一步，而不是固定周期。
漂移检测与纠正：需要更精细的机制检测代理是否偏离原始目标，自动纠正或重启。
跨项目知识迁移：一个项目中学到的架构模式应能迁移到其他项目。
效率优化：当前系统 "远非完美效率"，但比预期更有效。下一步需要减少协调开销，提高资源利用率。
工程实践建议
基于 Cursor 的经验，构建长时间运行 AI 编码系统时：
- 从简单开始：先实现平等协调，理解失败模式，再引入复杂性
- 模型差异化：不要对所有角色使用相同模型，根据任务特点选择
- 定期重启：即使代理运行正常，也应定期重启对抗漂移
- 监控先行：在扩展前建立完整的监控体系
- 人工监督：完全自主仍不现实，保留关键决策的人工干预点
长时间运行 AI 自主编码系统的核心洞察是：正确的架构往往比预期更简单。过度复杂的协调机制可能适得其反，而适度的分层结构配合精心设计的提示词，能支持数百个代理协同工作数周，完成传统上需要人类团队数月的项目。
随着模型能力的提升和工程实践的成熟，AI 自主编码将从辅助工具演变为可独立承担复杂软件项目的协作系统，重新定义软件开发的规模与速度边界。
资料来源：
- Cursor Blog - "Scaling long-running autonomous coding" (https://cursor.com/blog/scaling-agents)
- Simon Willison - "Scaling long-running autonomous coding" (https://simonwillison.net/2026/Jan/19/scaling-long-running-autonomous-coding/)
- FastRender GitHub 仓库 - AI 生成的浏览器实现 (https://github.com/wilsonzlin/fastrender)