把已经跑过的智能体聊天记录，重新变成能用的编程练习场

2014 年语音识别领域有一件让所有人挠头的事训练一个能听懂人说话的模型需要成千上万小时的标注音频。可标注音频这东西贵、慢、还容易出错。十年后AI 编程智能体就是那种能在命令行里帮你写代码、修 bug、跑测试的 AI遇到了一个几乎一模一样的麻烦。这些智能体每天都在产生海量的操作记录读了哪个文件、改了哪行代码、跑了什么命令全都留下了痕迹。这些记录堆积如山,但它们几乎没法直接拿来训练更强的模型。这篇来自阿里巴巴通义千问团队和清华大学的论文就是在解决这个看似简单实则棘手的问题。**为什么记录不能直接拿来用**先说清楚一件事智能体的操作记录和能反复使用的练习场根本不是一回事。打个比方你请了一位维修师傅上门修水管全程录了像。这段录像很有用你能看到师傅拧了哪个阀门、换了哪个零件。但如果你想让另一个学徒练手光看这段录像是不够的管道已经修好了水已经不漏了学徒没法在这套水管上重新练习如何修漏水这件事,因为问题已经不存在了。论文里管这种一次性记录叫轨迹trajectory意思是一条走过就消失的路径只能看不能重走。轨迹*AI 智能体执行任务时留下的完整操作记录包括它读了什么、写了什么、运行了什么命令本质上是一次性的历史快照。这就是问题所在轨迹的质量完全取决于当初执行任务的那个模型有多强而且你根本没法验证它当时改的代码到底对不对。相比之下一个能反复使用的环境environment就完全不同了你可以让更强的模型重新解决一遍这个任务可以用自己的测试来验证结果还可以在同一个工作场景上出更难的题。对于训练下一代 AI 智能体来说环境才是真正稀缺又值钱的资源。那能不能人工搭建这些环境呢行业里确实有先例比如 Terminal-Bench 这个基准测试每道题都配了定制的容器、任务说明和自动评分脚本质量非常高。但这种做法完全靠人工一点点搭产出速度慢得让人绝望根本没法满足训练所需要的海量数据规模。**从旧轨迹里考古出新环境**研究团队的思路是与其从零开始造环境不如反过来想:轨迹里其实已经藏着环境的全部线索。智能体在执行任务时调用的每一个工具读文件、写文件、编辑文件都会暴露出它当时所在的那个工作空间长什么样。既然线索都在为什么不把它倒推回去把整个环境给复原出来这就是这篇论文提出的核心框架叫 Terminal-Universe。它做的事情用一句话概括就是把死的轨迹变成活的、可以反复练习的编程环境。这个复原过程分成两步走。第一步叫确定性回放deterministic replay。系统会按时间顺序把轨迹里所有的读、写、编辑操作重新过一遍找出每个文件在智能体动手改之前的原始样子。这里有个细节很关键智能体自己新建的文件还有它做出的所有改动全部被排除在外。为什么要这么做因为你要复原的是任务开始前的状态如果把智能体的答案也一起复原进去那这个环境就没法再拿来出题了,答案已经写在黑板上了还练什么。这一步的结果只是一个部分工作空间因为轨迹只暴露了智能体碰过的文件没碰过的东西自然无从得知。第二步叫智能体补全agentic completion。这一步派出一个专门的补全智能体去把第一步留下的空白填上,创建缺失的文件、补全残缺的代码、恢复项目需要的依赖库。但有一条铁律补全智能体绝对不能顺手把任务给解决了也不能暴露解决方案应该改在哪里。这就好比你请了两位不同的师傅。第一位负责把损坏的水管恢复到漏水前的原始状态,他只做这一件事绝不多手去把漏洞焊死。第二位师傅负责把整套水管系统周围该有的配件都装齐,阀门、接头、说明书,让这套系统看起来是个完整能用的房子但绝对不能把那个漏水点顺手补上。如果第一位师傅手滑把漏洞焊了或者第二位师傅心急把漏洞也堵了那这套系统就废了没法再拿来给学徒练手了。数据证明了这两步分工的必要性。仅靠第一步回放能达到任务可用标准的工作空间只有 40.2%针对终端类轨迹和 20.1%针对软件工程类轨迹。加上第二步补全之后这个比例跳到了 93.5% 和 77.1%。补全前后的对比也很直观终端类工作空间的平均文件数从 2.9 个暴涨到 22.4 个涨了 7.7 倍。补全之后系统还会用一个专门的充分性判断智能体去检查每个工作空间判断它是否真的具备足够的项目背景信息可以支撑一个任务。只有通过这一关的环境才会被留下来用于后续生成任务。整个流程最终从 35.9 万条原始轨迹里筛选出了 3.73 万个任务充分的可用环境。**光有环境不够还得会出题**有了可复用的环境接下来的问题是怎么在这些环境里出题而且出得像真实的软件开发场景论文提出了四种再提问re-querying方式覆盖了从最简单到最复杂的场景。第一种叫意图恢复Intent Recovery说白了就是把原始轨迹里用户真正想要什么给还原出来整理成一个独立完整的任务描述。这一步的价值在于它能作为一个干净的对照组如果直接拿原始轨迹去训练模型效果是 36.7 分但如果用意图恢复出来的任务让一个更强的老师模型重新解决一遍再拿去训练效果直接跳到 52.1 分涨了 15 个百分点。这个差距说明了什么说明单纯模仿一段旧轨迹里那个可能能力有限的智能体的行为价值远不如让一个更强的模型在同一个场景里重新做一遍。这也印证了本文标题里那句话的分量:轨迹是死的环境是活的。第二种是单工作空间任务合成Single-WS一个探索型智能体会去逛这个复原出来的工作空间自己发现里面可以出的题,比如某个配置文件有打包问题、某个函数缺少边界检查。第三种是跨工作空间合成Cross-WS这是这篇论文比较有巧思的一个设计。真实世界里的程序员经常需要参考别的项目来写代码比如看看另一个仓库是怎么实现某个功能的然后把这个能力搬到自己的项目里。论文用 TF-IDF一种衡量文本相似度的经典算法先粗筛出可能相关的项目对再用一个大模型去判断这两个项目之间是不是存在依赖关系也就是一个项目缺的能力另一个项目正好有。举个论文里的真实例子有两个用 C 语言写的 RSA 加密工具包其中一个只有密钥生成、加密和签名功能唯独少了解密程序另一个工具包却把完整的加解密流程都实现了。系统就据此生成了一个任务要求在缺解密功能的那个仓库里新建一个解密程序同时明确规定只能参考另一个仓库的挂载路径,不能直接把具体的实现细节告诉解题的模型逼着它自己去读代码、理解、再动手实现。这种跨仓库任务比单一仓库任务难得多。数据显示跨工作空间任务的平均对话轮数是单工作空间任务的 1.6 倍工具调用次数是 1.9 倍而老师模型的一次通过率从 72.3% 直接掉到 49.2%。这不是任务变复杂的偶然结果而是必须读两个仓库、还要在两者之间做协调这个要求本身带来的难度。如果不做跨仓库这道题只在单一仓库里出题会怎样论文的对比实验给出了答案单独用跨工作空间数据训练终端基准测试成绩是 55.4 分把它和单工作空间数据混合训练成绩涨到 58.4 分。而且分类别看模型训练类任务涨了 15 分调试类任务涨了 10 分,这些恰恰是最需要跨项目类比迁移能力的场景。第四种是多轮用户查询Multi-Round这一种在我看来是最贴近真实工作状态的设计。现实里几乎没有人会一次性把需求说清楚往往是先提一个初步要求等看到结果之后再补充、再纠正、甚至改主意。论文为此设计了一个用户智能体在编程智能体完成第一轮任务之后接着扮演用户根据当前的执行结果继续提要求。这个用户智能体背后维护着一份需求清单会记录哪些要求已经满足、哪些还在等待、哪些被更新了。每一轮结束后系统会用一个自动化的验证器去跑测试检验这一轮的结果对不对。这里有个设计我觉得特别巧妙编程智能体本身是看不到测试代码和报错细节的它只能通过用户智能体转述的自然语言抱怨来了解哪里出了问题。这就非常接近真实场景,普通用户报 bug 的时候说的从来不是第 47 行断言失败而是这个功能好像坏了能不能修一下。论文里有个具体案例很能说明这套机制怎么运作。一个传感器数据处理任务第一轮是让智能体支持自定义输入输出路径。第二轮用户要求增加断点续传式的增量处理能力,不用每次都从头处理全部数据。第三轮实现之后系统检测出聚合结果不稳定原来是引入了未固定随机种子的缩放逻辑用户智能体没有暴露测试失败这种技术细节而是转述成这个平均值算出来不对而且每次跑结果还不一样让智能体自己去定位问题、修正。后面几轮又陆续加了阈值告警、把告警从每次覆盖改成追加历史记录、加报表功能、最后加上试运行式的自动修复能力。这一整套需求演变从路径配置到断点续传从告警到历史追溯再到自动修复,几乎就是一个真实项目从雏形长成生产系统的缩影。数据上看加入多轮数据之后衡量能连续完成多少轮需求的指标 MT4 从 18.4 分涨到 21.0 分如果去掉每轮的验证反馈机制这个数字反而掉到 18.8 分比不加多轮数据时还低。这说明单纯堆更多轮对话没有意义关键是每一轮都要有确实做对了这个反馈信号在支撑不然智能体只是在瞎猜用户接下来会说什么。**规模化之后效果到底怎样**把这套流程铺开之后团队总共产出了 3.73 万个任务充分的环境最终筛选出 3.2 万条可用于训练的完整对话记录涵盖了大约 14.2 亿个训练 token。用这批数据对 Qwen3.5-27B 模型做微调之后在单轮编程测试 Terminal-Bench 2.1 上的表现从 46.2 分涨到 58.1 分提升了 11.9 个百分点在多轮迭代式编程测试 EvoCode-Bench v2 上MT4 指标从 6.3 分涨到 20.1 分提升了 13.8 个百分点。更有意思的是一个预算怎么花最划算的实验。研究者固定了训练数据的总规模然后分别尝试三种扩充方式:增加更多不同的环境、给同一个环境出更多道题、给同一道题生成更多个解法。结果只有增加环境数量这一种方式带来了实打实的提升从 53.2 分涨到 56.0 分另外两种方式几乎原地踏步。这个结果其实回应了整篇论文最初的立论稀缺的从来不是题目或者答案而是不同的、真实的执行场景本身。就像一个学生刷题把同一道题做十遍收获远不如做十道不同的题。环境的多样性才是真正决定训练效果的那个变量。论文还测试了这套方法能不能跨领域迁移。他们把这套流程用在软件工程类的轨迹上而不是终端操作类的结果同样能给终端基准测试带来提升从 47.0 分涨到 50.0 分。这说明这套从轨迹里复原环境的思路本身具备一定的通用性不是只能在某一个特定领域里生效的窄招数。当然这套方法也不是万能的。论文自己也坦承了几个局限所有复原出来的工作空间都跑在标准的 Ubuntu 24.04 容器里而不是针对每个项目单独定制的专属环境这在遇到需要特殊系统依赖或者复杂编译步骤的边缘情况时可能会打些折扣。另外复原出来的环境在语言、领域、工具链上的分布天然受限于收集到的原始轨迹本身有什么,巧妇难为无米之炊。还有一点是整个流程里出题、写答案、写验证脚本用的都是同一个老师模型如果这个模型本身有能力盲区那这些盲区很可能会被系统性地遗漏。写在后面读完这篇论文我印象最深的其实不是那些漂亮的分数提升而是那个看似朴素的洞察:被丢弃的东西往往比被精心制作的东西更值钱。这些散落在各处的智能体操作日志原本大家可能觉得它们的使命已经完成了任务跑完了日志存档了事情就结束了。但这篇论文告诉我们日志里藏着的不是过去发生了什么而是当时那个世界长什么样。这两者的区别恰恰是历史学家和考古学家工作方式的区别:前者读文献里写了什么后者从残片里重建整个文明的样貌。还有一处细节让我反复琢磨:补全智能体被明确要求不能顺手把任务解决了。这条规则听起来简单但它其实在提防一种很隐蔽的数据污染,就像监考老师明明知道某道题的答案却必须忍住不能在改卷子的时候顺手把答案写在草稿纸上留给下一个学生。AI 系统里的这种知道答案但要装作不知道的克制本身就是一件挺反直觉的事情因为大部分时候我们训练 AI 都是希望它尽可能展示自己知道的东西而不是刻意隐藏。论文里那个跨仓库合成 RSA 解密程序的例子我觉得比任何抽象论述都更能说明跨项目学习这件事的价值:一个模型如果只在单一项目的边界里打转永远学不会读别人的代码、理解别人的设计、再把这套逻辑迁移到自己的项目里这种真实程序员每天都在做的事。而这恰恰是当前很多训练数据集里缺失的一环。这套方法目前测试的方向是从软件工程类轨迹迁移到终端操作类任务上效果不错。那反过来呢用海量的终端操作日志去反哺更复杂的软件工程任务会不会同样有效论文里没有做这个实验留了个悬念。QAQ1Terminal-Universe是什么ATerminal-Universe是阿里巴巴通义千问团队和清华大学联合提出的一个框架它能把AI编程智能体已经跑过的操作记录轨迹重新复原成可以反复使用、能验证结果的编程练习环境。Q2为什么不能直接用智能体的操作记录来训练模型A因为操作记录是一次性的死档案质量完全取决于当初执行任务那个模型的水平而且没法验证改动是否真的正确。而复原出来的环境可以让更强的模型重新解答还能用测试来验证结果价值完全不同。Q3这套方法训练出来的模型效果提升有多少A用这套方法产出的数据微调Qwen3.5-27B模型后单轮编程测试Terminal-Bench 2.1提升了11.9个百分点多轮迭代编程测试EvoCode-Bench v2的MT4指标提升了13.8个百分点。