「把一千个旧账交给一群 Agent：连跑 36 小时，八成修到可合并」

一百人年，是一个人从入职干到退休的全部工作时间。

这是开源沙盒游戏 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 个业务模块的分布也排除了「专挑一类简单问题刷分」的可能。

这里有一处措辞需要停一下。「可合并标准」是字节自己的判定，指的是补丁在工程意义上达到了能够进评审要求的完备度；它不等于已经合并，也不等于维护者会接受。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 #多智能体 #软件工程