Trace2Skill 的技术深读：并行归纳、分层合并与技能演化的可计算框架

给 Agent 写 Skill 文档是当下研究的重点。但手工写 Skill 太慢，让模型自己凭参数知识生成又几乎没用。更麻烦的是，同一份人类专家写的 Skill，在 122B 模型上效果拔群，换到 35B 上反而拖后腿。Skill 的“规模敏感性”成了一个被忽视的暗坑。 阿里 Qwen 团队联合 ETH、北大等机构提出的 Trace2Skill，换了一条完全不同的路：不让模型凭空编，而是让它分析自己跑任务留下的成功和失败轨迹，从轨迹里归纳出可迁移的操作规范。整个过程并行处理、分层合并，最后自动生成一份结构清晰的 Skill 文档——主文档放通用原则，边缘案例归档到附录。 今天重点分析 Trace2Skill 的三阶段算法细节，以及它与 Meta-Harness 的路线对比。

论文：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 的性能不仅取决于模型权重，还取决于其加载的技能文档（Skills）——编码了领域知识、操作流程和失败模式的结构化文本。Anthropic 的开创性工作确立了技能的工程价值，但 SkillsBench [Li et al., 2026b] 的系统评估暴露了两个深层矛盾：

1. 1. 参数化知识无法生成有效技能：让模型仅凭自身知识草拟技能，性能与无技能基线无统计差异（见 Table 1 Parametric 行）。

1. 2. 人类技能是模型规模敏感的：同一份专家编写的 xlsx 技能，在 Qwen3.5-122B 上带来 +20pp 增益，在 35B 上反而比无技能低 9.3pp（Table 1 Human-Written 行，35B Vrf 9.67% vs No Skill 19.00%）。

第二条尤为关键。人类专家在编写技能时，不可避免地嵌入了对模型能力的隐性假设——例如“模型能理解复杂的多步指令”、“模型会严格遵循工具使用规范”。当技能被迁移到能力剖面不同的模型上时，这些假设失效，技能反而成为噪声。技能文档由此成为一种非移植性知识载体，这与“一次编写，处处运行”的工程理想背道而驰。

现有自动化技能演化方法（EvoSkill, AutoSkill, XSkill, Memento-Skills）普遍采用在线顺序更新：每来一条新轨迹，对技能做一次增量编辑。这种范式从控制论角度看存在两个结构缺陷：

• • 上下文漂移：第 次更新后的技能 成为第 条轨迹被分析时的上下文。后续 Analyst 看到的是一个已经被之前轨迹“污染”过的技能版本，其提出的补丁与早期补丁之间存在不可控的交互。
• • 局部过拟合：单条轨迹提取的“教训”可能高度特化于该实例的偶然特征（如特定文件名、特定行列号）。直接写入主文档会稀释技能的泛化纯度。

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

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

2.1 技能的数据结构

技能 在 Trace2Skill 中被建模为一个文件系统子树：

其中 是 Markdown 格式的根文档 SKILL.md，编码程序性知识； 包含三类辅助资源：scripts/（可执行脚本）、references/（领域参考文档）、assets/（静态资产）。这一结构在 Equation (1) 中形式化。

2.2 轨迹的数据结构

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

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

2.3 演化目标

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

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

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

对于 中的每个任务 ：

1. 1. 将 的 SKILL.md 内容注入系统提示。模板：

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

生成后，轨迹被划分为：

• • ：success == False 的轨迹集合
• • ：success == True 的轨迹集合

论文在电子表格实验中将 SpreadsheetBench-Verified 的 400 个样本对半分为演化集和测试集各 200。从 Section 4.3 的表述推断，约 70 条失败轨迹被送入 Error Analyst。

** 阶段一总结

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

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

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

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

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

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

4.1 Error Analyst () 的强制验证循环

Error Analyst 的设计目标是从单条失败轨迹中提取可验证的根因。其 Prompt 模板：

关键流程为：

Algorithm: Error Analyst A^-
Input: failure trajectory τ, ground truth y*, skill S0
Output: patch p (diff format)

1.  surface_error ← Compare(τ.final_output, y*)
2.  hypothesis ← None
3.  while hypothesis is None or not validated:
4.      if hypothesis is None:
5.          hypothesis ← TraceFailure(τ.react_log, surface_error)
6.      else:
7.          hypothesis ← ReviseHypothesis(τ.react_log, validation_result)
8.      
9.      # 实施最小修复验证
10.     fixed_output ← ApplyMinimalFix(τ, hypothesis, y*)
11.     validation_result ← Evaluate(fixed_output, y*)
12.     
13.     if validation_result.is_correct:
14.         validated ← True
15.     else:
16.         validated ← False
17. 
18. memory_items ← ExtractMemoryItems(hypothesis, τ)  # ≤3 items
19. patch ← GeneratePatch(S0, memory_items)
20. return patch

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

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

4.2 Success Analyst () 的频率意识设计

Success Analyst 的 Prompt包含一条关键约束：频率意识——覆盖更多实例的行为模式应优先列出。输出为 1-3 条 Success Memory Item，随后被转换为对 SKILL.md 的补丁。

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

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

时间复杂度： 轮 LLM 调用（不计 Analyst 内部的迭代轮次）。对比顺序方法需要 轮，加速 1-2 个数量级。

** 阶段二总结

<labs-tailwind-structural-element-view-v2 style="display: block;color: rgb(48, 48, 48);font-family: "Noto Sans SC";font-size: medium;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 400;letter-spacing: normal;orphans: 2;text-align: start;text-indent: 0px;text-transform: none;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;white-space: normal;background-color: rgb(255, 255, 255);text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;" data-pm-slice="0 0 []">

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

- 成功分析师 (A+ )： 采用单次（Single-pass）工作流，快速提取促成正确的通用模式。

- 错误分析师 (A− )： 这是整个诊断的核心。它不再进行简单的单次思考，而是启动代理化循环（Agentic Loop）。

相比于传统的单次调用（往往会将 57% 的错误肤浅地归咎于“解析错误”），代理化循环通过读取文件、对比 Ground Truth（地面真值）和验证修复方案，将误判率降至 14%。它能区分出“偶然的怪癖”与“系统的漏洞”。

错误分析师的“内心独白”： “初步观察显示智能体在第 12 步计算失败。我需要读取 recalc.py 的执行日志……果然，LibreOffice 无法处理 Excel 的数组公式。我必须对比一下 Ground Truth 的计算逻辑。原因定位：公式回写在物理层面是失效的。补丁建议：‘禁止直接使用复杂公式，必须在 Python 中预计算结果，并以字面值（Literal Value）回写。’”

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

</labs-tailwind-structural-element-view-v2>

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

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

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

5.1 Merge Operator 的六个显式约束

的完整 Prompt 包含六条指令：

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

流行模式偏置（Prevalent pattern bias）是第七条隐式指令：

“当多个补丁独立地提出针对同一类失败或成功模式的相似编辑时，将此重复出现视为任务系统性属性的证据。优先保留此类流行编辑，并将其表达为一般原则而非实例特定修复。”

这一指令将归纳推理操作化为可执行的频率加权策略。

5.2 分层归约算法

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

Algorithm: Hierarchical Merge
Input: patch set P, merge batch size B, skill S0
Output: merged patch p*

1.  current_level ← P
2.  while len(current_level) > 1:
3.      next_level ← []
4.      for i = 0 to len(current_level) step B:
5.          batch ← current_level[i : min(i+B, len(current_level))]
6.          p_merged ← M(S0, batch)
7.          next_level.append(p_merged)
8.      current_level ← next_level
9.  p* ← current_level[0]
10. return p*

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

5.3 程序化护栏

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

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

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

** 阶段三总结

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

描述。

树状筛选机制： 将补丁池 ∣P∣ 按步长 Bmerge =32（工程推荐值）进行分组。这就像是一场多轮淘汰赛，每 32 个补丁合并为一组，递归上升直到层数 L 达到顶端，生成一份唯一的全局更新。

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

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

- 文件检查： 物理存在性验证，拒绝任何引用不存在资源的“死链接”。

- 物理冲突检测： 确保两个补丁不会修改同一文件中的重叠行，避免内容紊乱。

- 格式验证： 强制 Markdown 语法校验，确保手册可被任何智能体解析。

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

6. 实验结果的深层解读

6.1 人类技能的非移植性

Table 1 中 Human-Written 基线的跨模型表现：

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 显示 +Combined 显著优于 ReasoningBank（+13.8pp Vrf @122B，+9.2pp @35B）。原因包括：检索的嵌入空间失配、注意力竞争，以及分层合并的主动去重与抽象。

6.5 Agentic 错误分析 vs. 单次 LLM 调用

Table 6 显示 Agentic +Error 在所有四个 Author-Mode 组合的 Avg 上均胜出（差距 +0.8pp 到 +13.3pp）。定性分析确认 Agentic 循环通过制品访问和修复验证拒绝了伪阳性归因。

6.6 数学推理与 VQA 跨域验证

Table 2 显示数学推理技能在跨模型迁移上保持正向增益（122B 技能迁移到 35B 时 DAPO-Math +5.0pp，AIME +5.0pp）。Table 3 已在前述分析。

7. 生成的 SOP 层级结构

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

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

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

8. 与 Meta-Harness 的对比

两条路线的互补性明显：Trace2Skill 生成的技能可作为 Meta-Harness 的初始种群；Meta-Harness 优化后的 Harness 可产生更高质量的轨迹反哺 Trace2Skill。

9. 局限与改进方向

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

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

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

10. 总结

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

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

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

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

Ref:

Meta-Harness 的技术深读：为什么 Harness 搜索需要完整的执行轨迹

大模型落地一年，我悟了：Harness才是护城河——从O(n²)复杂度看Harness的必然