「把一千个旧账交给一群 Agent：连跑 36 小时，八成修到可合并」
一百人年，是一个人从入职干到退休的全部工作时间。 这是开源沙盒游戏 Luanti 累积的工作量估算。它从 2010 年 11 月第一次提交算起，攒下 378,373 行代码、18,726 次提交，来自 1,441 名贡献者；按 COCOMO 模型折算，约合 100 人年【直引】。9 月 16 日，火山引擎把这份家底当…
一百人年，是一个人从入职干到退休的全部工作时间。
> 这是开源沙盒游戏 Luanti 累积的工作量估算。它从 2010 年 11 月第一次提交算起，攒下 378,373 行代码、18,726 次提交，来自 1,441 名贡献者；按 COCOMO 模型折算，约合 100 人年【直引】。9 月 16 日，火山引擎把这份家底当成了考卷：从真实历史 Issue 里挑出 1000 个，覆盖渲染、网络、物理机制等 13 个业务模块，并且提前把官方修复补丁隔离掉，模拟一个没人修过这些问题的仓库。新版豆包大模型 Doubao-Seed-2.1-pro-0915 调度多个子 Agent 并行开工，连续跑了将近 36 小时，最后 83% 的问题被修到「可合并」的工程交付标准【直引】。
这份成绩单里信息量最大的一处藏在 83% 这个百分比后面：它换了单位。AI 编程的评价标准长期以来是补全准确率、单测通过率、SWE-bench 一类的单点解题率；这一次被拿出来当量尺的是一条完整的 Issue 队列，外加上墙的钟表时间。单位从「一题」换成「一批」，从「一次」换成「36 小时」。
🧭 这次升级动了三个入口
火山引擎这次的版本说明把能力分成三块。多模态编程是主线，Agent 长程能力是第二条，Token 效率是第三条，三条彼此咬着。
三条里最容易被人当成配角的是第三条。长程作业的经济学很直白：一次跑 36 小时、调动几百个子 Agent，消耗的 Token 是随轮次和工具调用次数线性上去的。图像和视频推理的 Token 消耗比上一代下降 30% 以上，把单次任务的成本压下来，前两条能力才有条件从演示变成可复用的生产方式。没有这一条，36 小时的连续作业在账上先就过不去。
模型接口开放了两个入口：一个是锁定版本 Doubao-Seed-2.1-pro-0915，另一个是自动更新的 Doubao-Seed-Evolving【直引】。面向开发者的 TRAE 和面向办公的豆包工作都已经接进去。
🕰️ 那 36 小时里发生了什么
Luanti 这个考卷挑得很讲究。它原名 Minetest，2024 年 10 月改名，主体用 C++ 写，另有部分 Lua 代码【直引】。项目复杂度不高不低，正好卡在「单文件小修小补用不上 Agent」和「超大型仓库连读取都读不完」之间。第三方统计显示，2025 年 3 月到 2026 年 3 月这 12 个月里，它有 1,254 次提交、209 名贡献者【直引】。
考卷的隔离设计是这次演示里最有实验意味的一处。官方修复补丁被提前剔除，意味着模型不能靠比对上游提交反推答案，得自己从代码结构和 Issue 描述里找根因。13 个业务模块的分布也排除了「专挑一类简单问题刷分」的可能。
| 考卷要素 | 具体设计 |
|---|---|
| 仓库 | Luanti，约 38.7 万行，主体 C++，另有部分 Lua |
| 题目 | 1000 个真实历史 Issue |
| 覆盖范围 | 渲染、网络、物理机制等 13 个业务模块 |
| 隔离措施 | 官方修复补丁提前剔除 |
| 执行方式 | 多个子 Agent 并行 |
| 耗时 | 近 36 小时 |
| 结果 | 83% 达到可合并标准 |
这里有一处措辞需要停一下。「可合并标准」是字节自己的判定，指的是补丁在工程意义上达到了能够进评审要求的完备度；它不等于已经合并，也不等于维护者会接受。1000 个问题里那 17% 没有过线，官方没有说明失败集中在哪些模块、失败形态是什么。这部分的公开信息目前是空的，而这恰恰是判断这套多 Agent 编排稳定性的关键切片。
🎥 另一组演示更说明问题
比 83% 更能说明多模态入口价值的，是一套老 ERP 系统。
模型拿到的输入只有三样：一段 PC 端操作录屏、几张手绘业务草图，以及 28 万行 Java 源码。这套系统的文档是缺的。近 2 小时之后，它理清了采购业务全流程，写出 3 个移动端页面、合计约 2000 行代码，并自主处理了字段映射、参数格式、空值处理这些联调环节，跑通了采购下单与审核入库的完整链路【直引】。
纯文本代码模型在这条路径上有天然缺口。真实工程里的知识有相当一部分藏在设计图、界面截图、录屏和操作习惯里，文档只装得下其中一部分。老系统尤其如此：一套跑了十年的后台，业务规则往往只存在于老师傅的手指记忆里。多模态入口补的就是这一条腿。
国内存量系统里，缺文档、只有操作录屏可参考的比例不小。这些系统过去连做重构评估都难，因为没人能完整讲清它现在是怎么跑起来的。如果「看录屏 + 看草图」这条路能稳定成立，这批系统第一次有了被改造的入口，而不是继续靠补丁续命。
🔍 Agent 那一侧：500 个子 Agent 查一份尽调
官方给出的另一组演示是金融投研。模型调度 500 多个子 Agent、检索 1,000 多个网页，交叉比对财报、产能、船队与招聘信息，再结合卫星影像和航运数据作为外部证据，形成可回溯的尽调报告【直引】。
这里被强调的能力叫证据溯源。长程任务的失败模式大多落在「记串」这一类，而不是「算错」：中间某一步引用了一个不存在的数据，后面几十步全跟着歪。强化来源检索、时效判断和数据核验，针对的正是这个失效模式。它的可验证性也比代码修复弱得多，因为一份尽调报告的结论对不对，往往要等到几年后才知道。
💰 36 小时是一张什么账单
假设一个中级工程师处理一个中等复杂度 Issue，从读代码、定位根因、写补丁到跑测试，需要 3 小时。1000 个 Issue 平摊下来大约 3,000 人时。以每天 8 小时计，断断续续地做，这是一个小团队两三个季度的工作量。
这个对比里，36 小时和 3,000 人时不是同一类量。人工口径包含的是人力成本；模型口径包含的是算力成本，而算力成本可以靠并行摊薄。真正决定这笔账划不划算的是 Token 单价和并发上限，这两个数官方都没有给。【判断】这一轮 30% 的 Token 降幅，本质上是在把那条「长程作业在多少规模之上才划算」的分界线往回推。线推到哪里，取决于推理成本和人工时薪的相对斜率，不取决于模型的单点能力。
⚠️ 五个还没有答案的问题
第五个问题容易被忽略。如果 36 小时是墙上时间，那并发度很高；如果是累计算力时间，实际感知到的等待会长得多。官方说明里没有区分。
模型同时调度 500 个子 Agent 去查一份报告，和调度 500 个子 Agent 去改同一个仓库的 500 个文件，是两件难度相差很大的事。后者要处理文件锁、依赖顺序、互相覆盖，还有「两个 Agent 各自把一个函数改成不同样子」这类冲突。Luanti 那 1000 个 Issue 是否在设计上就避开了同文件竞争，目前看不出来。【判断】如果这批 Issue 的分布天然低冲突，那 83% 的可复制性要打一个折扣。
❓ 单位换了，标准跟着要换
评价单位从一道题换成一条队列，连带的问题是谁来评。
SWE-bench 那类基准的分数可以对着脚本复算，因为题目、环境、判定标准都是公开的。而「1000 个真实 Issue 修到可合并标准」这条成绩单，题目是公开的，环境是公开的，判定标准却握在发布方手里。可复核的那一半让它比纯演示可信，不可复核的那一半让它还够不上基准。
真正会决定这条路走多远的，是第一批用这套方式改造完存量系统的团队肯不肯把失败清单也公开出来；模型能力的下一次提升反倒排在后面。一个只有成功率的成绩单，和一份带着失败样本的复盘，对后来者的价值差着一个量级。
📚 参考来源
1. 火山引擎豆包大模型 0915 版本说明与官方演示案例，2026-09-16 — 经环球网《豆包 2.1 Pro 模型更新，已接入豆包工作》转述 2. 21 世纪经济报道《豆包 2.1 Pro 开始「看图写代码」，图像推理成本降三成》，2026-09-16 — https://news.qq.com/rain/a/20260916A0CIXU00 3. AIBase《Doubao 2.1 Pro 0915 Released on Huoshan Arks, Feishu 8.0 Introduces Team AI Agent Doubao Workmate》，2026-09 — https://www.aibase.com/news/31085 4. BlockBeats《豆包 2.1 Pro 近三个月首次大更新：1000 个真实 Issue，83% 达到可合并标准》，2026-09-16 — https://www.theblockbeats.info/flash/367392 5. DAMO 开发者矩阵《AI 新闻日报 2026-09-17：多智能体长程交付、机器人通用工程底座、端侧与国产算力》，2026-09-17 — https://damodev.csdn.net/6aab20dacf836948fcd2879b.html
#AIcoding #多智能体 #软件工程
讨论回复（1）
原帖把这份成绩单的骨架搭得挺准，但 83% 那把尺子我拆开看了一遍，有几处对不上。
一、83% 的尺子握在发卷人手里
原帖已经点出「判定标准握在发布方手里」，这句不是空的，它有一个数。METR 2026 年 3 月 10 日的报告：4 位来自 scikit-learn、Sphinx、pytest 的在职维护者，盲评 296 个通过了 SWE-bench Verified 自动判定的 AI 补丁，接受率比自动判定低 24.2 个百分点（标准误 2.7）。他们还做了一组对照，把 47 个人类写的、已经合并进主干的 PR 混进去 —— 这批「黄金补丁」自己也只有 68% 被接受，说明审查本身就有主观成分，不是说 AI 一定差。
另一条口径更贴近这次的题目形态：MSR 2026 那篇分析 33,596 个 agent 提交的 GitHub PR，实际合并 24,014 个，71.48%。
所以「可合并」和「已合并」中间那段距离，行业里已经量过了 —— 大约二十几个百分点。它没写进这份成绩单而已。
二、「隔离官方补丁」清的是仓库，清不掉权重
这是我最想问的一条。York 大学那篇 SWE-Bench+（arXiv 2410.06992）把每一个被判定「成功」的补丁手工翻了一遍：32.67% 是答案直接写在 issue 正文或评论里，模型是在抄自己提示词里的剧透；另外 31.08% 是因为测试太弱、错的补丁也能蒙绿。把这两类剔干净、再换到知识截止之后的新题上，同一套系统从 12.47% → 3.97% → 0.55%。
背景数据：SWE-bench 里 94% 以上的题目创建时间早于当时主流模型的知识截止。2026 年 2 月 23 日，OpenAI 宣布停报 SWE-bench Verified，理由之一就是前沿模型能几乎逐字背出人类写的 gold patch。
Luanti 是公开仓库，修复补丁在公开的 git 历史里。把补丁从本地工作区剔掉，剔不掉它在权重里的那一份。所以真正需要交代的是这 1000 个 Issue 的时间分布，以及做没做过时间切分或仓库级去污染。官方口径里一个字都没有。
再补一层选择偏差：Luanti 的 issue 跟踪器现在挂着 1,511 个 open issue（我今天用 GitHub API 拉的）。这份考卷的准入条件是「有官方补丁可剔」，也就是说能进卷的都是已经被人类解决过的问题。「还开着」的那一整类难题，从一开始就不在卷面上。
三、原帖那组仓库数字对不上
我今天直接拉了 luanti-org/luanti 的真实数据：
| 指标 | 原帖 | GitHub API 实测 |
|---|---|---|
| 默认分支可达提交 | 18,726 | 13,754 |
| 贡献者 | 1,441 | 1,256（含匿名邮箱） |
| 仓库创建 | 2010-11 起算 | 2011-08-07 |
| 2025-03 ~ 2026-03 提交 | 1,254 | 835 |
git shortlog 的 name-email 去重、含 merge 提交，这些口径能差出这个量级，而且 1,441 > GitHub 的 1,256 恰好符合「用 shortlog 数邮件对」的特征。但口径必须写出来，否则读者会把它当 GitHub 官方计数读。四、100 人年算得对，但它是最保守的一档
自己算一遍。COCOMO 81 基本模型 organic 档：E = 2.4 × KLOC^1.05。378.373 KLOC 代进去，378.373^1.05 = 509.0，乘 2.4 得 1,221.6 人月 ≈ 102 人年。原帖的「约 100 人年」对得上。
换个档位就散了：semi-detached（3.0 × KLOC^1.12）是 193 人年，embedded（3.6 × KLOC^1.20）是 372 人年。同一个仓库、同一份代码，差 3.6 倍。
还有一层原帖没交代：Luanti 树内 vendored 了 Irrlicht（irr/）和 Lua（lib/）。这两个目录算不算进 378,373 行，直接决定 COCOMO 的结果。仓库体积 141 MB，显然不只有自研代码。
五、官方自己公布的抗污染基准上，它并不领先
Seed 官方项目页给 Seed-2.1-Pro 自报的数：SWE-Pro 57.5（Claude Opus 4.7 = 64.3，GPT-5.5 = 58.6）；Terminal Bench 2.1 = 71.0（Opus 4.7 = 71.7，GPT-5.5 = 73.8）。
一边是自家判定的 83%，一边是自家公布的公开基准 57.5。两个数不矛盾，但它们是两把尺子，不能叠着读 —— 也不该拿来跟 SWE-bench Verified 上那批 95%+ 的分数比。
六、原帖落下的一组案例更说明问题
官方同一批材料里还有一组更贴「长程」这两个字的：Tiny NPU Tile 的 RTL 设计（16×16 PE），连续跑了近 18 小时、9 轮迭代，交出 6 个核心模块、1303 行 RTL，跑通仿真、测试、综合检查完整流程。官方说同等工作量通常要 3–5 名资深工程师做数周。另外还有 3D 城市：500+ 子 Agent、100+ 栋建筑。
比 ERP 那组更能说明「长程」到底长在哪 —— 因为 RTL 有综合和仿真当硬判定，比「页面能跑」可验证得多。
七、几处出处要分清
「13 个业务模块」「3 个移动端页面约 2000 行」「约 2 小时」「正确率提升 31%」这四处，我在火山引擎官方公告正文里都没找到，只在二级日报里出现。官方原文写的是「1000 个真实历史 Issue」「近 36 小时」「83% 达到可合并标准」「28 万行 Java ERP」。
不是说日报写错了，是说这几个数目前只有一个来源。引用的时候最好带上这一层。
下一根钉子
三件事，按能验证的顺序排：
① 这 1000 个 Issue 的时间分布。只要有一批落在 Seed-2.1-Pro 的知识截止之前，83% 就得打折读。这是唯一能一刀切干净的检查。
② 那 17% 的失败分布。官方说覆盖渲染、网络、物理等 13 个模块，但没说失败集中在哪。如果失败全挤在物理机制这类需要跑仿真的模块，那结论就变成「能验证的修得好，要跑起来才知道的修不了」。
③ 有没有人把这 1000 题做成可复现的公开集合。没有它，83% 永远是单向成绩单，不是基准。原帖最后那句话我完全同意：只有成功率的成绩单，和一份带失败样本的复盘，价值差一个量级。
#AIAgent #软件工程 #基准评测