TraceCompiler：技能引导的Agent轨迹挖掘与确定性工作流编译
TraceCompiler: Skill-Guided Mining and Compilation of LLM Agent Traces into Mostly Deterministic Workflows

当LLM Agent反复处理同一类任务（如"帮我订一次旅行""给某人转账"）时，每次执行都会产生一条工具调用轨迹，其中混杂着重试、探索性调用、参数趋同的冗余调用，以及真正必要的因果链条。一个自然的想法是把这些反复出现的调用序列"编译"成确定性工作流，以后遇到同类任务直接按脚本执行，省去反复推理的开销。但陷阱在于：调用A观察到总是发生在调用B之前，并不代表A产生的数据被B消费——它可能只是Agent的决策习惯、API文档顺序，或纯属偶然。如果把这种"偶然相邻"错误地固化为"执行顺序约束"，编译出的工作流会在训练分布之外的场景里出现隐蔽的错误执行。论文要解决的正是如何在充满噪声的真实轨迹中，严格区分"真实数据依赖"与"表面顺序相关"。

意图发现：把每段对话（初始请求+逐轮执行记录）嵌入为文档，用余弦距离+平均连接的凝聚聚类识别"同一类任务"的轨迹簇（相似度阈值0.45，簇最小规模5）。作者刻意选择偏保守的合并策略——"欠合并比过合并伤害更小"，避免把本质不同的任务错误地归为一类而共享错误的工作流。

行为去噪：把每个动作标记为essential（必要）、retry（重试）、exploratory（探索性）、redundant（冗余）、dead_output（无用输出）等类别。关键判据不是"调用了几次"而是"参数是否趋同"——参数相同的重复调用是重试噪声，参数系统性不同的重复调用是真正的并行扇出（fan-out），二者处理方式完全不同。

证据元组（核心创新）：论文明确表态——"观察到的相邻关系从不构成依赖证据，只有被证明的数据流才能约束编译出的DAG"。具体做法是：对于观察到调用a先于调用b，只有当b的某个参数值能唯一追溯至a的输出时，才承认边a→b成立；每条保留下来的"硬边"都携带一个可审计的证据元组⟨消费者、参数路径、具体值、推定生产者、被排除的其他候选来源⟩。如果存在其他合理来源能解释该参数值（比如它也可能来自常量或用户输入），这条边就被降级为"suspected"（疑似），不再对执行顺序构成约束。变量绑定被系统性地划分为常量、用户输入、直接复制的输出、经过转换的输出，以及无法归因、只能算作LLM残留决策五类。

另一个案例很能说明系统的"保守性"设计：面对Spotify/Todoist场景中涉及不可逆副作用（到底是"添加"还是"删除"某首歌/某任务）但方向无法从观测数据中充分确定的情况，编译器选择主动拒绝编译，而不是赌一个大概率正确的方向。留一法测试中失败的那一折，也是因为某个分支从未在训练轨迹中被观测到，系统选择"上报无法处理"而非盲目按已知分支执行。

作者也明确划定了结论边界："我们衡量的是调用次数的减少，而非离线编译成本"——因此论文不主张任何"净效率提升"的结论；在Hermes-Function-Calling-v1这类单轮函数调用语料上的迁移实验则是负面结果，说明该方法依赖多轮、可重复的任务结构，并非普适工具。

这篇论文和最近看到的"轨迹失败预测"类工作共享同一个大趋势——Agent执行痕迹本身正在变成一种可复用、可挖掘的资产，而不只是一次性的执行日志。区别在于处理方向：失败预测是从轨迹中学习"什么会出错"用于提前拦截，TraceCompiler则是反过来，把"探索性的、试错式的执行"蒸馏成"确定性的、可直接复用的程序"。这本质上是把LLM Agent在重复任务上花费的大量推理算力，转化为一次性的编译成本+多次的低成本执行，思路上和传统编译器优化（把解释执行编译为AOT代码）高度类似，只是这里"源代码"是Agent留下的行为痕迹而非人写的程序。

对我关注的Agent架构和可靠性问题最有启发的其实是方法论层面的克制：论文没有去追求"尽可能多地把轨迹编译成工作流"，而是把"证据不足就拒绝编译"作为一等公民设计——这和duplex agent里"交互层要能识别自己不确定、该移交给推理层"的思路是同构的：一个可靠的系统首先要能诚实地知道自己什么时候不知道。0.928/0.943这种精确率召回率放在生产环境里，意味着仍有约7%的假阳性依赖边风险，如果不配合"疑似边不约束执行"和"不确定即拒绝编译"这两条安全阀，这套方法在真实部署中是危险的。另外，"调用可移除中位数51.4%"这个数字本身也提示了一个现实：相当比例的Agent推理步骤是在做已经被证明冗余或探索性的工作，这对于设计更高效的Agent执行/规划分层（尤其是需要控制延迟和token消耗的实时交互场景）是一个值得参考的量化基线。