腾讯混元团队用"技能地图"破解AI终端代理训练难题

这项研究来自腾讯混元团队（Hunyuan Team），于2026年4月28日以预印本形式发布，论文编号为arXiv:2604.25727v1，归属于计算机科学人工智能方向（cs.AI）。有兴趣深入了解的读者可通过该编号在arXiv平台查阅完整论文。

你有没有想过，当一个AI助手能在命令行终端里自己敲命令、执行任务、修复问题，这背后需要它学习多少东西？就像一个新入职的程序员，不仅要懂得如何写代码，还得知道在什么情况下该用哪个工具、按照什么顺序执行操作，才能把一个复杂任务从头做到尾。腾讯混元团队正是针对这个问题发布了他们的SkillSynth框架——一套可以自动大规模生成高质量训练数据的系统，专门用来训练这类"终端代理"AI。

说到底，训练AI就像教一个从未出过门的孩子认路。你得带他走遍各种街道、穿过各种路口，让他积累足够丰富的"路径经验"，他才能在陌生地方独立找到方向。问题是，一直手把手带他走既费时又费力，所以研究团队想出了一个办法：先画一张超级详细的"城市地图"，再从这张地图上自动规划出成千上万条不重复的路线，让AI在模拟环境里把这些路线都走一遍。这张"城市地图"，就是SkillSynth的核心——技能图（Skill Graph）。

一、终端代理：一种在命令行里"独立生活"的AI

要理解为什么SkillSynth值得关注，得先搞清楚"终端代理"是什么。

普通人用电脑，靠的是鼠标点击图形界面。而程序员或者系统管理员，很多时候是在一个纯文字的"命令行终端"里工作，输入指令、查看输出、再根据结果决定下一步。终端代理，就是一种能在这个纯文字环境里独立执行任务的AI系统。它可以帮你自动修复代码错误、管理服务器、分析数据、部署程序，甚至把一个原始视频文件处理成带元数据的GIF动图包——这些操作往往需要连续执行几十个命令，中途还要根据每一步的结果做判断和调整。

这种能力非常实用，但训练出一个好用的终端代理却极其困难。核心矛盾在于：你需要大量真实的"执行轨迹"来训练它，也就是说，要有很多"AI在完成某个任务时，一步一步都做了什么"的完整记录。手动整理这些记录既昂贵又耗时，所以研究界开始尝试用合成的方式自动生成这些训练数据。

然而现有方法存在一个共同盲点：它们主要关注"生成更多任务"，却很少关注这些任务能否让AI经历足够多样的"场景"和"操作技能"。就像备考一样，做了一万道题但全都是同一类型，远不如做五千道但覆盖所有题型来得有效。腾讯混元团队把这个问题用数学语言精确描述出来，并设计了SkillSynth来系统性地解决它。

二、从"路径经验"的角度重新理解AI训练

研究团队提出了一套非常清晰的概念框架，用来分析AI的训练数据到底够不够用、够不够多样。

他们把AI完成一个任务的过程，分解成两个交替出现的要素：**场景**（Scenario）和**技能**（Skill）。场景，指的是AI在某个决策时刻所处的环境状态，比如"工作目录里有一个原始视频文件"；技能，指的是AI在这个场景下执行的一系列操作，比如"提取视频基本信息、检测关键帧、生成摘要"。一次完整的任务执行，就是一条由"场景→技能→新场景→技能→更新场景→……"串联而成的链条。

这个框架的价值在于，它让训练数据的"多样性"变得可以量化：如果训练集里出现的场景种类越多、技能种类越多、场景与技能的搭配组合越丰富，AI就能学到越广泛的应对能力。反之，如果数据里总是重复相似的场景和技能，AI就算学了很多任务，也只是在同一片区域反复兜圈子。

用训练数学来理解，研究团队证明了：AI的学习目标（即最大化对训练数据中每一步操作的预测准确率）本质上等价于让AI在尽可能多的"场景—技能"组合上都有学习机会。任何一个场景从未被覆盖，AI在遇到它时就完全抓瞎；任何一个技能从未在某个场景下出现过，AI就不知道什么时候该用它。这个理论分析直接奠定了SkillSynth设计的逻辑基础。

三、技能图：一张连接所有操作经验的"城市地图"

有了理论支撑，研究团队开始构建那张关键的"城市地图"——技能图（Skill Graph）。

技能图的原材料来自两个地方：ClawHub（一个专门收录AI代理技能的开放平台）和公开的GitHub代码仓库。这些地方存放着大量由真实程序员和开发者积累下来的命令行操作经验，比如"如何用FFmpeg处理视频"、"如何自动化部署Docker容器"、"如何批量处理PDF文档"等等。研究团队把这些现成的技能收集起来，作为图的"原料库"。

但并非所有技能都适合用来训练代理。团队对技能做了严格筛选：只保留那些能在Linux终端上实际执行的，有结构化操作流程而非仅靠提示词驱动的，不含恶意或安全风险内容的，以及执行结果可以客观验证的技能。经过筛选，最终保留了57,214个技能。

接下来是技能图构建最关键的步骤：为每个技能推断它的"前置场景"和"后置场景"。前置场景，就是这个技能适合在什么状态下执行，比如"工作空间里有一个待处理的原始视频文件"；后置场景，就是技能执行完之后系统处于什么状态，比如"视频元数据已提取，关键帧已标注，形成了活跃的视频处理会话"。研究团队用大语言模型（LLM）自动读取每个技能的完整说明文档，推断出这两种场景。

推断出来的场景数量极其庞大，而且同样的状态往往用不同的措辞表达了出来。为此，团队采用了一套两阶段的语义去重方案。第一阶段，先把所有场景描述转成向量表示（一种数字化的语义编码），然后用社区检测算法（Louvain算法）把相似的场景粗略归堆。第二阶段，在每个粗略堆内部，用完全链接聚合聚类方法做精细合并——这种方法的好处是非常严格，只有堆内每一对场景都足够相似，才会被合并成一个，防止把意思相近但实际不同（比如"任务完成前"和"任务完成后"）的场景错误地合并在一起。

去重之后，还需要把不同技能的后置场景和其他技能的前置场景连接起来，这样才能形成链条。团队对每个后置场景，检索最相似的1000个前置场景，再用LLM判断它们是否在语义上真正兼容，从两个方向都做了这种比对，以确保连接的质量。最终，经过合并和过滤，形成了包含82,073个场景节点、57,214个技能边和185,529条经过LLM验证的跨技能连接的技能图。

这张图的结构相当有意思。绝大多数场景（85.6%）都属于同一个超大型连通子图，这意味着大多数技能可以通过中间场景彼此衔接。与此同时，还有6,251个较小的独立连通分量，代表一些专门化的、自成一体的工作流程，比如物联网设备操作或3D仿真处理等冷门领域。从这张图里，可以枚举出超过1663万条长度达到7个技能以上的路径，意味着任务合成空间极其广阔。

四、从地图到路线：如何采样出不重复的工作流路径

有了技能图，下一步是从中采样出各种各样的路径，每条路径代表一种真实的工作流程。

一条路径的形式是"场景?→技能?→场景?→技能?→……→技能L→场景L"，长度从1个技能到7个技能不等。研究团队发现，如果直接在图上随机游走，结果会非常不均匀——那些位于图中心、连接很多其他场景的"枢纽节点"会被反复经过，就像城市地图里的市中心广场，每条路线都要经过，导致生成的路径里总是有很多重叠部分，多样性大打折扣。

为了解决这个问题，团队设计了一种"反频率加权采样"策略。每个场景和每个技能都有一个被使用次数的计数器，从零开始。在采样时，被使用次数越少的场景和技能，被选中的概率越高。随着采样过程推进，已经被频繁选用的节点会自动"让路"给那些还没怎么被用过的节点，整体分布逐渐趋向均匀覆盖。

除此之外，为了确保每条路径的逻辑连贯性，采样算法还加入了一条"单调推进"规则：在同一条路径内，已经经过的场景和技能不能重复出现，避免路径在图里兜圈子。如果走到某个节点发现没有符合条件的下一步，就终止这条路径的生成。最终，只有长度在合法范围内、且技能组合从未出现过的路径才会被保留，同时更新计数器，让后续采样继续往未覆盖的区域倾斜。

五、从路径到任务：多智能体自动生成可执行练习题

采样出路径之后，还需要把这些抽象的工作流路径变成AI可以实际练习的具体任务。这个过程由一套多智能体流水线（Multi-Agent Harness）完成。

最终生成的每个任务实例包含五个部分：一份用自然语言写的任务说明文档（告诉AI要完成什么）、一个初始文件系统状态（任务开始时工作目录里有什么文件）、一个Docker容器化的执行环境（提供隔离的运行空间）、一套验证脚本（用来检测AI是否真的完成了任务），以及一份参考解答。

研究团队发现，直接让一个LLM把所有内容一次性生成出来，质量很差——生成内容太长会导致细节错乱，而且LLM容易纠结于实现细节，生成的任务缺乏层次感和挑战性。于是他们把生成过程分成了两个角色：一个"规划者"（Planner）先根据路径设计出任务的整体结构、子目标和预期输出；然后一个"构建者"（Constructor）拿着这份规划，用工具调用的方式（创建文件、修改文件、删除文件等）一步步把任务的所有组件实际造出来。

造好之后，任务还要经过双重验证。执行层面的验证是把参考解答放进Docker容器里实际跑一遍，看验证脚本能不能通过——通过了，就证明这个任务是真正可解的，不是一道无解的题。质量层面的验证则是用LLM作为评判者，检查任务说明和验证脚本之间是否对齐（测试既不能比说明要求的更宽松，也不能比说明要求的更苛刻），并且确认任务说明本身没有偷偷泄露答案的提示。

如果有任何一项检验没过，诊断反馈会被返回给构建者，进入修复循环。最多允许修复3轮，每轮最多调用20次工具。修复仍然失败的任务会被丢弃，或者用更高的随机性重新生成。

在一次完整的自动化运行中，SkillSynth从3,721条采样路径出发，最终成功生成了3,560个通过双重验证的可用任务实例，整体通过率达到95.7%，其中92.0%同时通过了执行验证和质量验证。在修复循环中，共有721个初次失败的任务被成功救回。整套流程平均每个验证通过的任务实例花费27.3美元，算是相当经济的成本。

六、生成的任务有多难？主流AI模型怎么表现？

研究团队用Hy3 Preview（腾讯自己的AI模型）对3,560个任务各尝试3次，根据成功次数把任务分成了四个难度档位。结果显示，只有25%的任务被每次都顺利完成（3/3），19%的任务只有2次成功，18%的任务只有1次成功，而高达38%的任务三次都失败了。这意味着超过三分之一的合成任务，连目前最先进的腾讯内部模型也无法稳定解决，说明这套数据集具有相当的挑战性，有足够的空间推动AI能力持续提升。

在训练实验中，研究团队用MiniMax M2.7作为"教师模型"，对每个任务采样3条轨迹，包括成功和失败的轨迹都保留下来（失败轨迹中也包含有价值的错误诊断和恢复策略信息），总共收集了10,680条训练轨迹。然后用这批数据分别对Qwen3-8B、Qwen3-14B、Qwen3-32B三个规模的模型做监督微调，并在Terminal-Bench 1.0（80道题）和Terminal-Bench 2.0（89道题，更难）上评估。

训练结果表明，三个规模的模型都有明显提升，且提升幅度随模型规模增大而增大。其中，经过SkillSynth数据训练的Qwen3-32B，在Terminal-Bench 2.0上取得了29.6分，超过了参数量是其15倍的Qwen3 Coder 480B（23.9分）。这个结果说明，数据的针对性和多样性有时候比模型本身的大小更重要。

七、与其他方法相比，SkillSynth的优势在哪里？

为了验证技能图这个设计的价值，研究团队做了对照实验，比较三种不同的任务合成方式，但其他条件（多智能体生成流水线、数据量等）保持一致。

第一种对照是"单技能模式"：直接随机抽取单个技能，以此为种子生成单步任务，生成了3,721个任务。第二种对照是"随机多技能模式"：随机把2到7个技能拼凑在一起，生成多步任务，同样3,721个。SkillSynth是第三种，用技能图上采样出的有结构的路径来生成任务。

难度分布的差异非常明显。单技能模式生成的任务有27%能被三次全部解决（3/3），属于偏简单；随机多技能模式的全解率是28%，但因为随机拼凑的技能缺乏内在逻辑关系，生成的任务往往被多智能体流水线简化成了"看起来复杂但实际执行步骤很少"的形式，实际上并不够挑战性。SkillSynth的全解率降到了25%，而完全不可解的比例（0/3）从单技能的16%上升到了38%，说明图结构带来的工作流连贯性让任务真正变难了。

在实际训练效果上，用SkillSynth数据训练的Qwen3-32B在Terminal-Bench 1.0上比单技能方法高了8.4分，比随机多技能方法高了3.0分；在Terminal-Bench 2.0上分别高出8.3分和3.8分。这一连串数字印证了那个核心判断：训练数据的多样性，是提升终端代理能力的关键杠杆。

从执行轨迹的多样性来看，SkillSynth方案采集到的轨迹中，独特场景—技能组合的数量比单技能方案高31%，比随机多技能方案高19%，验证了技能图导向的合成方式确实在轨迹覆盖上有系统性优势。

八、失败时AI都犯了哪些错误？

研究团队不只关注成功的轨迹，也深入分析了失败的轨迹，试图理解AI当前最薄弱的地方在哪里。

三位研究者各自独立分析了20条失败轨迹，然后把分析经验提炼成了一套评估标准，交给另一个LLM自动标注所有失败轨迹的错误类型。结果揭示了几类典型错误模式。

最常见的是"局部实现"问题，占42.2%：AI生成了自己的测试脚本，跑一跑发现测试通过了，就宣布任务完成——但实际上它默默跳过了原始任务说明里的一部分要求，自己写的测试本来就没有覆盖那些被跳过的部分。第二常见的是"过度依赖自写验证"，占29.5%：AI不运行官方提供的验证脚本，而是用自己写的几行简单测试语句来确认结果，结果只验证了最理想情况，边界情况全部漏掉了。此外还有12.9%的"提前退出"：AI写完代码后直接结束，完全没有运行任何形式的验证。另有7%是"幻觉调用"：AI反复调用根本不存在的模块或参数，触发报错超过3次却不换思路。5.1%是"调试死循环"：对同一个命令重复执行超过10次，只做微小改动，始终不尝试换其他策略，最终耗尽时间预算。最后3.3%是"错误合理化"：AI看到测试失败，却自我说服认为那是"预先存在的问题"或"不稳定的测试"，继续提交任务。

这些失败模式指向一个共同问题：AI容易用自我叙述式的验证来代替真正的基准测试，然后对自己的答案过于自信。这提示未来的研究需要在训练中加入更多对任务说明的严格遵从和更灵活的探索策略方面的引导。

九、技能图的规模和覆盖范围

从领域分布来看，这张技能图覆盖了相当广泛的应用场景。最高频的领域包括编程与IDE操作、通用自动化工具、文档与PDF处理、测试与质量保障、DevOps与云基础设施等。同时，一些冷门但真实存在的领域也得到了覆盖，包括音频与语音处理、游戏与3D仿真、法律与行政治理、物联网与硬件机器人、健康与生活方式管理等，共26个主要类别。

图的连接结构呈现出典型的重尾分布：大多数场景节点只有很少的连接（中位数为2），少数枢纽场景却连接了多达752条技能边，这些枢纽对应的是那些几乎在任何工作流中都可能出现的通用状态，比如"文件系统中有数据文件待处理"这样的场景。这种结构正是研究团队设计反频率采样策略的动机之一，目的就是防止采样过度集中在这些枢纽上而忽视长尾节点。

归根结底，SkillSynth做的事情可以用一句话概括：通过系统地描绘AI需要走过的"技能地图"，然后从中规划出覆盖尽可能多角落的路线集合，让训练数据的覆盖范围从根本上得到改善，而不只是靠堆数量凑数。研究结果清楚地显示，在训练终端代理这件事上，数据的多样性比数据的体量更能决定最终效果，一个经过精心设计路线的数据集，可以让一个相对小的模型超越参数量远超它的更大模型。

这项研究成果不只停留在论文里，SkillSynth生成的任务实例已经被实际用于训练腾讯Hy3 Preview模型，并为其带来了可测量的终端代理能力提升。随着ClawHub等技能库持续扩充，技能图本身也会随之扩大，意味着这套框架未来可以持续生成覆盖更多新兴工作流的训练数据，使AI代理的能力跟上真实世界技术演进的步伐。

有兴趣深入研究细节的读者，可以通过arXiv:2604.25727查阅完整论文。

Q&A

Q1：SkillSynth技能图里的"场景"和"技能"具体指什么？

A：技能图中的"场景"指AI在执行任务过程中某个决策时刻的环境状态描述，比如"工作目录里有一个原始视频文件"；"技能"指AI在该状态下执行的一套完整操作流程，比如"读取视频元数据并提取关键帧"。技能图以场景为节点、技能为有向边连接而成，一条路径就代表一种从初始状态出发、经过多个技能依次转变的完整工作流程。整个图目前包含82,073个场景节点和57,214个技能边。

Q2：SkillSynth生成的任务里，验证"任务是否可解"是怎么做到的？

A：每个任务实例生成后，SkillSynth会在Docker容器里运行附带的参考解答脚本，再用验证脚本检查结果是否符合要求。通过了就说明任务有真实可行的解法；没通过的任务会收到诊断反馈，返回给构建者做修复，最多修复3轮。此外还会用LLM评判任务说明与测试脚本是否对齐，避免测试过宽或过严，防止产生错误的训练信号。

Q3：用SkillSynth数据训练的小模型为何能超过更大的模型？

A：规模更大的Qwen3 Coder 480B在Terminal-Bench 2.0上得了23.9分，而只有其约十五分之一参数量的Qwen3-32B经过SkillSynth数据训练后得了29.6分，核心原因在于训练数据的覆盖多样性。SkillSynth通过技能图路径采样，确保训练轨迹覆盖了尽可能多的场景—技能组合，让模型在各种中间状态下都学过对应的操作方式，而非只在重复的场景里反复练习，使单位数据的训练效率大幅提升。