ClawTrace — 把 agent 每步操作的"成本账"先算清再蒸馏

是什么

ClawTrace 是一种给 agent 做 skill 蒸馏前先把每一步成本算清的方法。日常类比：你想把外卖小哥的”高效路线”教给新人——但你不能只看他总共送了多少单，得拆开看”哪一步真省时""哪一步是浪费”，再把浪费的删掉、把高价值的保留。

蒸馏（distillation）在 agent 圈通常指：让一个跑过的大 agent 留下记录，把其中”有用的动作链”压成轻量 skill 给后续 agent 用。问题是绝大多数 trace 里不是所有步都有价值——有的纯绕弯、有的反复重试、有的只是模型在自言自语。

ClawTrace 给每一步一个成本归因分数（cost attribution），然后用三类补丁动手术：

preserve：保留高价值步，原样进 skill 库
prune：剪掉低价值步（重试 / 自言自语 / 误判）
repair：修补错误步（把”点错按钮再退回”换成正确的目标动作）

这个流程像剪辑师做粗剪：先把废镜头删掉（prune），再补几个连贯镜头（repair），最后保留的画面（preserve）才是上线版。

为什么重要

不理解 ClawTrace 这套思路，下面这些事都没法解释：

为什么很多”agent → 学徒”蒸馏方法测着不错、上线后 skill 越积越垃圾——因为没区分高低价值步
为什么 reflect / self-critique 类方法看似聪明、实际拉慢了 agent——它们在保留”思考过程”，而 ClawTrace 发现那些步通常该被剪
为什么 voyager 这类 skill library 里很多 skill 第二次根本不被复用——蒸馏时没修复错误步
为什么 prune 在论文里被反复证明比 preserve / repair 都更影响最终质量——多数 trace 里”应该删的”远多于”应该保留的”

核心要点

ClawTrace 的核心可以拆成 三件事：

逐步打成本分：每一步动作都有一个分值——动作消耗 token / API 钱 / 时间，再除以”它对最终目标推进了多少距离”。类比：买东西要看单位价格，不看总价。
三类补丁动手术：preserve / prune / repair 各管一类问题。重点是 prune——发现”小哥送外卖中间路过自家楼下吃了顿饭”这种步要砍掉。
prune 才是质量护栏：实验证明，在所有有效手段里，减法比加法贡献大。skill 库的瓶颈不是”没收集够”，而是”垃圾步没清干净”。

这与传统直觉相反——多数蒸馏论文聚焦”加更好的步”，ClawTrace 用数据指出砍掉垃圾步贡献更大。

实践案例

案例 1：一条 trace 里 prune 能删掉多少

原始 trace：23 步 → 完成"订机票"任务
ClawTrace 分析：
  preserve: 8 步（搜索 / 选航班 / 填乘客 / 支付）
  prune:    13 步（自言自语 / 重试 / 浏览无关页）
  repair:   2 步（点错地区改回中文）
最终 skill：10 步可复用版本

下次遇到”订机票”相似任务，新 agent 拿 10 步版本起步，比从 23 步原始 trace 起步省 60% token。

案例 2：prune 比 repair 更关键的实证

实验组	复用准确率	skill 平均长度
全保留 trace	41%	22 步
仅 repair	47%	22 步
仅 prune	68%	9 步
prune + repair	71%	9 步

仅 prune 一个手段就拉了 27 个百分点的复用准确率。repair 只是锦上添花。

案例 3：成本归因的最小公式

step_cost(s)        = tokens(s) + α * latency(s)
step_value(s)       = goal_progress(s) - goal_progress(s-1)
attribution(s)      = step_value(s) / step_cost(s)
prune if attribution(s) < threshold

goal_progress 怎么算？让一个 LLM 评判员看”在这一步前后，距离任务目标的语义距离”。这条思路把”agent 的步骤价值”硬量化了，让蒸馏从手感变成可调参数。

踩过的坑

goal_progress 评判不稳：同一条 trace 用不同 prompt 评，prune 决策能完全不同——必须固定评判模型 + 多次平均
过度 prune 杀死多样性：只留”最高效路径”会让 skill 库面对新任务时变脆，需保留若干次优变体
repair 容易过拟合到本次任务：把”误点中文 → 改回英文”补成”必须英文”，下次中文用户被坑
threshold 没法跨任务通用：订机票和订酒店的 step_cost 量纲不同，必须任务级标定阈值
prune 后 trace 变碎：相邻步逻辑被砍断，后续模型读不懂动作链——必须配合”上下文桥接”修补

适用 vs 不适用场景

适用：

agent skill library 蒸馏（voyager / skill-as-pseudocode 这类思路）
大 agent 录制的长 trace 要分发给小 agent 复用
token / latency 成本敏感的生产环境
需要 audit “为什么这步保留 / 那步删了”的合规场景

不适用：

一次性任务（prune 收益不够覆盖标定成本）
任务路径只有一种（没什么可 prune）
agent trace 极短（<5 步，三类补丁全没空间）
没有可靠 LLM 评判员可用——goal_progress 估不准时整个 pipeline 退化为随机剪

历史小故事（可跳过）

2022：知识蒸馏 KD 思路在 LLM 训练里成熟，但只压模型权重，不压 trace
2023：voyager 把”动作 trace → skill”做成 explicit pipeline，但全保留模式
2024：开始有工作给 trace 加 critique 步，本质是 repair 思路的雏形
2025：cost-aware 概念在 RAG 里先火（按 token 价值剪检索结果），后被搬到 agent
2026：ClawTrace 把”每步 cost + 三类补丁”做成统一框架，明确 prune > repair > preserve 的优先级
未来 2-3 年：可能进一步把”哪一步该剪”训成在线决策模型，而不是离线打分

学到什么

蒸馏 = 减法 + 修补，preserve 不是核心动作
逐步成本归因让 skill 质量从手感变成可监控的指标
prune 才是质量护栏——这个洞察反直觉但被实验数据反复验证
agent 学习里，“删干净”经常比”加更多”重要
可量化的 cost 归因 让”做得好不好”从主观评价变成可被监控的工程指标
三类补丁的优先级（prune ≫ repair > preserve） 给后续工作一个明确的设计 prior

关联

voyager —— 蒸馏的对象：原始 trace
skill-as-pseudocode —— 蒸馏后的高效表示形式
skill-sd-self-distillation —— 自蒸馏路径，不需要外部教师
reflexion —— 反思链路常被 ClawTrace 当低价值步剪掉
react —— ReAct 风格的推理动作链，是典型蒸馏来源
mmskills-multimodal —— 视觉 skill 蒸馏也需要 cost-aware 化
toolformer —— 工具调用蒸馏的近邻方向
orca-continuous-batching —— 把”成本归因”思路用到模型推理调度
reflexion —— ReAct + 反思链路常被 prune 的对象
mind-skill —— skill 类工作的另一条”心智动作”路线
agent-r1-2511 —— RL 训练 agent 的对照路径，与蒸馏互补

反向链接

agent-r1-2511 —— Agent-R1 — 把 LLM agent 当 RL 环境训练的模块化框架
mind-skill —— MIND-Skill — 用归纳和演绎双 agent 抽 skill 并保证质量
mmskills-multimodal —— MMSkills — 把视觉 agent 的”操作经验”做成多模态卡片
react —— React UI 组件库
reflexion —— Reflexion — 让 LLM 自我反思
skcc-skill-compiler —— SkCC — 给 LLM agent 写一个真正的 skill 编译器
skill-as-pseudocode —— Skill-as-Pseudocode — 把 agent 笔记本写成可校验的伪代码
skill-sd-self-distillation —— Skill-SD — 用 agent 自己抽出的 skill 当 dynamic teacher 自蒸馏
voyager —— Voyager — LLM 终身学习智能体
zombie-agents-2602 —— Zombie Agents — 自进化 agent 的长期记忆能被持久化”借尸还魂”