扩展长时自治编码：先分清规划与执行

先说结论

并发 Agent 不是越多越快。扁平协作容易把时间耗在抢锁、更新共享状态和做安全小事上。更稳的起点是让 planner 对整体目标负责，让 worker 只完成边界清楚的任务，并由独立判定决定是否进入下一轮。

原文解决什么

单 Agent 擅长聚焦任务，却难以独自完成持续数周的大项目。Cursor 先尝试让同级 Agent 通过共享文件和锁自行认领任务，结果出现锁遗留、等待瓶颈、状态绕过，以及没人愿意承担困难端到端问题。之后改成 planner-worker 流水线，减少横向协调。

核心机制

• Planner 持续探索代码库、拆任务，并对覆盖范围和下一轮负责。
• Worker 不互相协调，只拿到自包含任务，完成后交付实际变更与证据。
• 每轮结束由 judge 判断目标是否仍有缺口；下一轮用新上下文开始，降低隧道视野。
• 结构保持在中间：无结构会冲突和漂移，过多锁、integrator 与共享协议会形成新瓶颈。
• 不同角色可以选择不同模型，但选择应来自固定任务对照，不来自品牌印象。

原文报告了数百 Agent、数周运行、大量代码与 token 等实验规模，也列出迁移和性能优化案例；这些是 Cursor 的项目报告，本站未独立复现，代码量本身也不等于正确性。

和 Zero-to-AI 现有实践如何接上

本站已经用任务范围、文件所有权、worktree 和验证命令保护并发改动。对内容仓库，最小可迁移方案不是“上百 Agent”，而是一个 planner 只读拆分两份互不重叠的教程任务，两个 worker 各自写文件，主线程检查 diff 和 npm run verify。共享导航、schema 等文件仍应由单一 owner 处理。

并发的前提是任务真的独立；如果两个 worker 都要等待同一个设计决定，提前启动只会把等待伪装成吞吐。

一个低成本实验

输入： 两篇彼此独立的教程草稿，以及统一 frontmatter 和章节契约。

步骤：

1. Planner 只生成两份自包含任务：文件所有权、输入来源、验收命令、禁止项。
2. 两个 worker 在独立文件或 worktree 工作，不编辑共享索引，也不互相发消息。
3. 主线程检查两份 diff，运行精确格式检查，再运行一次统一验证。
4. 记录冲突、返工和等待时间，并与顺序完成两篇的基线比较。

成功证据： 零文件重叠、两份局部检查通过、主线程能用同一契约验收，且总等待没有高于顺序基线。

停止线： 任一任务依赖尚未确定的共享 schema，或协调成本超过实际写作时间；立即退回串行，不为保留“多 Agent”形式继续拆分。

常见误区

• 用 Agent 数量当进度：只有可验收的外部变更才是进度。
• 让 worker 自己抢共享任务：失败时会留下锁和不一致状态。
• 把自动合并当成正确：CI、人工审查和产品行为仍是独立证据层。

原文与证据边界

原文的规模、模型角色差异、迁移状态和性能收益均是厂商报告，部分项目仍待审查。本文只提炼角色分工与协调失败模式；普通仓库是否提速，必须通过小规模对照实验判断。

本文是原创中文实践解读，不是逐句翻译。阅读英文原文。