AI 编程 Agent 团队跑通 324 个两小时冲刺：Agent Scrum 工作论文公开

一句话看懂：一位开发者让 AI 编程 Agent 团队在 38 天内跑了 324 个两小时冲刺，并据此提出「Agent Scrum」方法，把 Scrum 的时间盒、故事点和回顾会改造成适合 Agent 的版本。

事件核心：发生了什么

2026 年 10 月 28 日，Dave Remy 发布工作论文《Agent Scrum》（版本 0.1，CC BY 4.0）。论文称，在一段真实的待办积压上，Agent 团队全天候运转了 38 天、完成 324 个两小时冲刺；其中由一个专门负责 Scrum 流程的 Agent 执行的 90 个冲刺里，79% 的承诺事项在冲刺内完成，仪式成本每轮不到 5 分钟。方法保留了 Scrum 的核心装置，但把冲刺从两周压到两小时，容量以模型速率限制而非人力衡量，成本用「每个已合并故事点消耗的 token 数」表示；人类产品负责人每天投入不到两小时，冲刺不为等待人类而暂停。论文同时披露短板：从批准到合并的中位时间与编码构建时间相当，瓶颈不在写代码；159 条回顾行动项中有 119 条仍未关闭。

为什么重要

当开发者手上有多个编程 Agent，问题就从「如何写提示词」转向「如何组织一支 Agent 团队」：选题、拆分、分配、评审、合并、复盘都需要协调机制。Agent Scrum 的价值在于把 Scrum 里经过验证的时间盒、完成定义和回顾会直接复用，而不是另造一套流程。每两小时强制收尾还有一个工程意义：Agent 上下文窗口会随工作变满、质量随之下降，短冲刺提供了一个固定的写状态、清上下文、重新开始的节点。目前公开信息显示，这仍是一份单人参考实现的工作论文，未见同行评审，多团队水平扩展虽有设计但受 token 预算限制尚未验证。

对用户/开发者/创作者的影响

对个人开发者和小团队，这篇论文提供了一个可试用的编排思路：给 Agent 设硬性截止时间、按速率限制估算产能、用 token 速度核算每个已合并故事点的成本，并把复盘当作持续改进的入口。需要留意的是，真正的摩擦点落在评审与合并环节，以及回顾行动项的执行率——如果这两处不能自动化或有效压缩，再快的冲刺也可能堆出未闭环的待办。