论文：Trace2Skill: Distill Trajectory-Local Lessons into Transferable Agent Skills 作者：Alibaba Qwen Team, ETH Zurich, University of Zurich, Peking University, Zhejiang University 状态：Work in progress

1. 问题再定位：技能文档的“规模敏感性”与演化困境

LLM Agent的性能不仅由模型权重决定，更依赖于它所加载的技能文档——一种结构化的文本，用于编码领域知识、操作步骤以及常见失败模式。Anthropic的开创性工作让我们看到了技能的工程价值，但SkillsBench的系统评估却揭示了两个深层次的矛盾，促使我们重新审视这一领域。

第一个矛盾：参数化知识无法直接生成有效的技能指南。如果仅让模型凭借自身知识来草拟技能，其效果与不使用技能时没有统计上的显著差异（见Table 1 Parametric行）。这意味着，模型内部储备的“知识”并不能自动转化为可用的操作手册。

第二个矛盾，更具破坏性：人类编写的技能对模型规模非常敏感。同一份由专家编写的xlsx技能文档，在Qwen3.5-122B模型上能带来20个百分点的性能提升，然而在35B模型上，使用该技能反而比没有技能指导时低了9.3个百分点（Table 1 Human-Written行，35B Vrf 9.67% vs No Skill 19.00%）。

这一点尤为关键。人类专家在编写技能时，常常会不自觉地嵌入对模型能力的隐性假设——比如“模型能理解复杂的多步指令”或“模型会严格遵循工具使用规范”。当技能被迁移到能力剖面不同的模型上时，这些假设便会失效，技能反而成了干扰信号。技能文档也因此变成了一种难以移植的知识载体，这与“一次编写，处处运行”的工程理想背道而驰。

当前主流的自动化技能演化方法，如EvoSkill、AutoSkill、XSkill和Memento-Skills，大多采用在线顺序更新模式：每获得一条新轨迹，就对技能进行一次增量编辑。从控制论的角度来看，这种范式存在两个结构性问题：

· 上下文漂移：第N次更新后的技能，会成为分析第N+1条轨迹时的上下文。后续的分析者看到的是一个已被之前轨迹“污染”过的技能版本，它提出的补丁会与早期补丁产生不可控的交互。

· 局部过拟合：从单条轨迹中提取的“教训”可能高度特化于该实例的偶然特征，比如某个特定的文件名或行号。直接将这些教训写入主文档，会稀释技能的泛化纯度。

Trace2Skill的设计哲学，正是对这两个问题的系统性回应：它采用并行全局分析替代顺序局部编辑，用归纳推理替代增量修补。

2. 形式化定义与三阶段流水线

2.1 技能的数据结构

在Trace2Skill框架中，技能被建模为一个文件系统子树。根文档是Markdown格式的SKILL.md，它编码了程序性知识。其下挂载了三类辅助资源：scripts/（可执行脚本）、references/（领域参考文档）和assets/（静态资产）。该结构在公式(1)中进行了形式化定义。

2.2 轨迹的数据结构

一条轨迹由以下字段构成：

• task_id：任务实例的标识符
• skill_snapshot：生成该轨迹时使用的技能版本
• react_log：多轮ReAct交互的完整日志
• final_output：智能体提交的最终答案
• ground_truth：任务的标准答案
• success：布尔值，由评测函数计算得出（见公式(2)对成功率的定义）

2.3 演化目标

给定演化集和测试集（它们的分布可能不同），目标是从初始技能出发，输出演化后的技能，使得测试集上的成功率最大化。其中，是参数冻结的智能体模型。

3. Stage 1：轨迹收集与采样策略

Stage 1执行一个批量推理过程（见Figure 2左半部分）。

对于演化集中的每个任务：

1. 将当前技能版本SKILL.md的内容注入系统提示。提示模板如下：

2. 启动ReAct循环，最大轮次为。
3. 记录完整的交互日志及中间文件状态。
4. 调用任务特定的评测函数，生成success标签。

生成后，轨迹被划分为失败轨迹集合 和成功轨迹集合 。在电子表格实验中，论文将SpreadsheetBench-Verified的400个样本对半分为演化集和测试集，各200个。根据Section 4.3的表述推断，大约有70条失败轨迹被送入了错误分析器（Error Analyst）。

**阶段一总结**

自我进化的起点并非逻辑推演，而是真实的执行。在Trace2Skill框架下，智能体会在初始技能（哪怕只是一个简陋的草案）指导下执行任务，产生的每一条操作日志都被称为执行轨迹。

这种基于“真实执行轨迹”的演进方式，其可靠性远超依赖大模型自身参数化知识的方式。它反映了智能体在真实环境（如文件系统、API、物理约束）中交互时遇到的实际阻力。

一旦原始经验经过分类与存储，我们便需要对其进行专业的“诊断”与过滤，以剔除无效的噪声。

4. Stage 2：并行 Analyst 的算法设计

Stage 2是Trace2Skill区别于顺序方法的算法核心（见Figure 2中间部分）。

两类分析器（Analyst）共享相同的输入输出接口，但内部推理协议不同。

4.1 错误分析器 () 的强制验证循环

错误分析器的设计目标是从单条失败轨迹中提取可验证的根本原因。其提示模板如下：

关键流程如下：

算法: 错误分析器 A^-
输入: 失败轨迹 τ, 标准答案 y*, 技能 S0
输出: 补丁 p (差异格式)

1. surface_error <- 对比(τ.final_output, y*)
2. hypothesis <- 无
3. 当 hypothesis 为空 或 未验证时:
4.    如果 hypothesis 为空:
5.        hypothesis <- 追踪失败(τ.react_log, surface_error)
6.    否则:
7.        hypothesis <- 修订假设(τ.react_log, 验证结果)
8.
9.    # 实施最小修复验证
10.   fixed_output <- 应用最小修复(τ, hypothesis, y*)
11.   validation_result <- 评估(fixed_output, y*)
12.
13.   如果 validation_result 正确:
14.       已验证 <- 真
15.   否则:
16.       已验证 <- 假
17.
18.   memory_items <- 提取记忆项目(hypothesis, τ) # ≤3 项
19.   patch <- 生成补丁(S0, memory_items)
20. 返回 patch

ApplyMinimalFix是智能体设计的核心：分析器被授予文件系统写权限，可以直接修改输出文件以匹配标准答案，但修复必须是最小的——仅改变导致失败的具体单元格或字段。这一约束迫使分析器必须识别精确的因果机制，而非做表面修补。

Section 4.3的消融实验证明：缺少此循环的单次LLM分析器在57%的包含解析错误信息的案例中错误归因于“解析失败”，而智能体分析器仅14%出现此类误判。性能对比数据如下：

4.2 成功分析器 () 的频率意识设计

成功分析器的提示包含一条关键约束：频率意识——应优先列出能覆盖更多实例的行为模式。输出为1-3条成功记忆项，随后被转换为对SKILL.md的补丁。

4.3 并行化架构与复杂度分析

Stage 2采用数据并行：每条轨迹被独立分派给一个分析器实例，分析器之间无通信。论文在电子表格实验中为约70条错误轨迹启动了128个并行工作器，所有补丁在同一轮内完成。

时间复杂度： 轮LLM调用（不计分析器内部的迭代轮次）。相比之下，顺序方法需要轮，加速可达1-2个数量级。

**阶段二总结**

在这一阶段，Trace2Skill派出了一支专业的“分析师舰队”。这里采用了“非对称设计”：

- 成功分析师：采用单次工作流，快速提取促成成功的通用模式。

- 错误分析师：这是整个诊断的核心。它不再进行简单的单次思考，而是启动智能体循环。相比于传统的单次调用（往往会将57%的错误肤浅地归咎于“解析错误”），智能体循环通过读取文件、对比标准答案和验证修复方案，将误判率降至14%。它能区分出“偶然的怪癖”与“系统的漏洞”。

这种基于证据的诊断，确保了每一个补丁都指向了任务的系统属性。当成百上千个补丁被并行提出后，就需要一位“总编辑”来解决逻辑冲突了。

5. Stage 3：分层归纳合并算法

Stage 3是Trace2Skill的归纳引擎（见Figure 2右半部分）。

输入为补丁集合，输出为单一合并补丁。

5.1 合并算子的六个显式约束

合并算子的完整提示包含六条指令：

1. 去重：多个补丁提出相同编辑时，保留最佳版本。
2. 冲突解决：对同一段落提出矛盾修改时，选择有更强理由的或综合两者。
3. 保留独特洞察：不同补丁针对不同失败模式的编辑全部保留。
4. 保持简洁：合并后补丁长度 ≤ 输入补丁的独特编辑之和。
5. 行级独立：合并后的编辑不得有重叠的行范围。
6. 原子创建/链接对：在references/中创建新文件与在SKILL.md中插入链接的操作必须同时保留或同时丢弃。

而流行模式偏置则是第七条隐式指令：这一指令将归纳推理操作化为可执行的频率加权策略。

5.2 分层归约算法

补丁集合通过树状归约合并（公式(7)）：

算法: 分层合并
输入: 补丁集 P, 合并批次大小 B, 技能 S0
输出: 合并后的补丁 p*

1. 当前层 <- P
2. 当 len(当前层) > 1 时:
3.    下一层 <- []
4.    对于 i 从 0 到 len(当前层)，步长为 B:
5.        批次 <- 当前层[i : min(i + B, len(当前层))]
6.        p_merged <- M(S0, 批次)
7.        下一层.append(p_merged)
8.    当前层 <- 下一层
9. p* <- 当前层[0]
10. 返回 p*

论文设。若，则层数，总LLM调用轮数约7轮（含每层的合并调用），远小于顺序更新的70轮。并行合并耗时约3分钟，而Seq-需要60分钟。

5.3 程序化护栏

补丁应用前经过三道验证：

1. 存在性检查：引用不存在文件的补丁被拒绝。
2. 行级冲突检测：同一文件相同行范围的编辑被标记并暂缓（Section 2.4）。
3. 格式校验：最终技能通过技能规范校验。

Appendix B.3.2和B.3.3给出了一个实际的最终合并补丁示例，展示了从323个轨迹级补丁经过四层归约后生成的最终差异。

**阶段三总结**

为了处理海量的补丁，Trace2Skill引入了层次化合并机制。其核心逻辑可以用公式描述。

这就像一场多轮淘汰赛：将补丁池按步长Bmerge=32进行分组，每32个补丁合并为一组，递归上升直到顶端，生成一份唯一的全局更新。

核心算子：普遍模式偏见。合并算子非常冷酷，它会无视特定模型的“模型怪癖”。只有在多个独立轨迹中反复出现的修改建议，才会被视为反映“系统任务属性”的真理。

安全护栏：确保手册正确性的三道防线

• 文件检查：物理存在性验证，拒绝任何引用不存在资源的“死链接”。
• 物理冲突检测：确保两个补丁不会修改同一文件中的重叠行，避免内容紊乱。
• 格式验证：强制Markdown语法校验，确保手册可被任何智能体解析。

经过这一层层“归纳与升华”，一份架构无关的“专家手册”最终成型，它将碎片化的教训转化为了具备普适价值的领域知识资产。

6. 实验结果的深层解读

6.1 人类技能的非移植性

Table 1中人类编写基线的跨模型表现：

35B在使用人类技能后出现了显著退步。这说明人类专家编写的技能嵌入了与122B能力相匹配的指令粒度和抽象层级。而Trace2Skill的轨迹驱动演化天然解决了这个问题——因为轨迹由目标模型自身生成，从中提取的补丁的抽象层级会自动对齐该模型的能力边界。

6.2 任务执行与技能创作的能力分离

Table 3的DocVQA结果是论文中最具启发性的发现之一：

数据揭示了一个有趣的现象：任务执行能力上，35B > 122B（无技能时35B表现更优）；但技能创作能力上，122B ≫ 35B（122B创作的技能对两个模型都有效，35B创作的技能对自身都有害）。

这一分离表明，技能创作所依赖的归纳推理能力与任务执行能力是正交的。

6.3 并行 vs. 顺序编辑

Table 4显示：

并行不仅更快，而且性能更优。论文将此归因于无上下文漂移和统计显著性过滤。

6.4 技能文档 vs. 检索记忆库

Table 5显示，Trace2Skill + Combined 显著优于 ReasoningBank（在122B上高出13.8个百分点，在35B上高出9.2个百分点）。原因包括：检索的嵌入空间失配、注意力竞争，以及分层合并带来的主动去重与抽象。

6.5 智能体错误分析 vs. 单次LLM调用

Table 6显示，智能体错误分析器在所有四个实验组合中平均表现均胜出，差距从+0.8到+13.3个百分点不等。定性分析确认，智能体循环通过制品访问和修复验证，成功拒绝了伪阳性归因。

6.6 数学推理与VQA跨域验证

Table 2显示数学推理技能在跨模型迁移上保持了正向增益（122B技能迁移到35B时，DAPO-Math提升5.0个百分点，AIME提升5.0个百分点）。Table 3已在前面分析过。

7. 生成的SOP层级结构

Section 4.4对122B Deepening Combined运行的323个补丁进行了主题分析，提炼出四类高频SOP（括号内为引用频次）：

1. 公式重算与写回验证（178/323）
2. 工具选择：openpyxl 优于 pandas.to_excel()（177/323）
3. 显式读回验证（138/323）
4. 结构化编辑安全（53/323）

低支持度的观察则被自动路由到13个references/文件中（详见Appendix A）。这一层级结构完全由频率分布驱动，无需人工策划。

8. 与Meta-Harness的对比

这两条路线的互补性非常明显。Trace2Skill生成的技能可以作为Meta-Harness的初始种群，而Meta-Harness优化后的Harness又能产生更高质量的轨迹来反哺Trace2Skill。

9. 局限与改进方向

论文在Section 6列出了两项主要限制：

1. 补丁的因果效应不可分离：分层合并无法量化单个补丁的边际贡献或检测补丁间的交互效应。改进方向是引入Shapley值或消融测试。
2. 技能章节的效用不可追踪：缺乏归因追踪机制，技能可能随着演化变得臃肿。改进方向是引入细粒度归因追踪以支持自动修剪。

此外，演化集与测试集之间的分布偏移对技能质量的影响尚未被系统评估；技能创作与技能使用的模型分离也值得进一步探索。

10. 总结

Trace2Skill的算法贡献可以提炼为三个可复用的设计模式：

1. 并行分析器 + 分层归约：将全局归纳问题分解为局部模式提取 + 统计聚合，在保持质量的同时获得对数级的加速。
2. 智能体验证循环：通过最小修复与再评估，将因果推断操作化为可执行的诊断协议，显著降低了错误归因率（Table 6）。
3. 频率驱动的层级生成：利用补丁的跨轨迹流行度自动构建“通用原则-边缘案例”的文档层级，实现无监督的知识结构化（Section 4.4）。

这些设计模式为智能体技能的自动化提供了一份可参照的算法蓝图。与Meta-Harness的对比进一步揭示：自动化智能体工程正在分化为探索驱动与归纳驱动两条技术路线，而两者的交汇，很可能孕育出更强大的元学习系统。

注：本文中所有表格编号（Table 1-6）、附录编号（Appendix A、B.1-B.3）及图示编号（Figure 1-2）均对应原论文中的位置。