💻 computer science

TraceCompiler: Skill-Guided Mining and Compilation of LLM Agent Traces into Mostly Deterministic Workflows

本文介绍了 TraceCompiler，这是一个技能引导型系统，它通过利用可审计证据严谨地推断工具间的依赖关系，将噪声较大的 LLM 智能体轨迹（traces）编译为具有高度确定性的可执行工作流，从而在保持高精度依赖恢复的同时，显著减少运行时 API 调用。

原作者： Salma El Yadouni (EPFL), Guanyi Li (Binome Technologies)

发布于 2026-08-05

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Salma El Yadouni (EPFL), Guanyi Li (Binome Technologies)

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正在教一个非常聪明但有点丢三落四的机器人管家如何制作你最喜欢的三明治。你演示了一遍制作过程：它拿了面包，然后拿了奶酪，接着拿了刀，然后又拿了一次刀，因为它忘了，接着又去拿了一次奶酪以检查标签，最后才拿了面包。它做出了三明治，但它走过的路径是一段混乱的、由重试、反复检查和在厨房里徘徊组成的“之”字形轨迹。现在，想象你要求机器人做一百次同样的三明治。如果你只是让它通过每次尝试来“学习”，它每次都会为那段混乱的“之”字形路径付出代价，白白浪费能量和时间去重新发现已经知道的步骤。这正是现代使用工具（如检查日历或发送消息）的 AI 智能体（AI agents）所面临的情况。它们在即时解决问题方面非常出色，但它们经常在每一次新的请求中都重复造轮子、重读指令或重试失败的尝试。现在的重大问题是：我们能否将那些混乱、重复的“日记”进行清理，并将它们转化为一套严格、高效的食谱，让 AI 无需每次都费力思考就能遵循？这就是一个机器人每天早上必须重新摸索如何走路，与一个拥有预设“肌肉记忆”来走路之间的区别。

由此，诞生了 TraceCompiler，这是一个旨在成为“厨师”的新系统，负责将那些混乱的机器人日记转化为清晰、可执行的食谱。这项工作的研究人员意识到，虽然 AI 智能体擅长探索，但它们并不擅长记住自己高效的路径。TraceCompiler 扮演着侦探和编辑的双重角色。它观察数百次执行同一任务（例如在 Venmo 上要钱或向播放列表添加歌曲）的嘈杂尝试，并试图弄清楚哪些步骤实际上是必要的，而哪些仅仅是 AI 在原地打转。

TraceCompiler 的核心魔力在于一条关于“因果关系”的严格规则。在一个混乱的日志中，两个动作可能会紧接着发生，但这可能只是巧合，比如机器人先拿面包，然后拿奶酪。TraceCompiler 拒绝假设拿面包这个动作“导致”了拿奶酪。相反，它要求证据：“奶酪是否确实需要一个只有‘拿面包’这一步才能产生的特定信息？”如果答案是否定的，这个连接就会被切断；如果答案是肯定的，且没有其他步骤能提供该信息，则保留这个连接。这使得系统能够剔除掉“噪声”——即重试、偶然的查询和冗余的检查——并留下一个精简的工作流。

结果令人印象深刻，但也伴随着重要的注意事项。在针对旅游相关任务的数据集进行测试时，系统的自动化规则正确识别了步骤之间的必要连接，准确率（precision）约为 93%，召回率（recall）约为 94%。这比那些仅仅观察下一步动作的简单方法（准确率仅为 71% 左右）或仅仅统计步骤共同出现频率的方法有了巨大的飞跃。在一次涉及 Venmo 资金请求的具体测试中，系统成功将一个需要 34 次 API 调用、过程混乱的过程缩减到了仅需 11 次核心调用。这是工作量的大幅减少！

然而，论文非常谨慎地没有声称这是一个完美的、神奇的解决方案。该系统不仅仅是一个随处适用的“黑盒”；它是一个谨慎的编辑。例如，在尝试编译一个“向播放列表添加歌曲”的工作流时，系统碰壁了。它意识到 AI 的日志并没有清晰显示歌曲是在被“添加”还是“删除”，由于这两者是相反且不可逆的操作，系统拒绝了编译。它选择停下来并表示：“我不确定，所以我不会盲目猜测，”而不是冒险删除用户的音乐。这种“拒绝编译”的行为实际上是一个特性而非缺陷，证明了系统优先考虑安全性而非速度。

此外，研究人员也承认，虽然“编译后”的工作流非常高效，但他们并未衡量创建这些工作流本身所花费的时间或成本。这就像是在说“这辆新车油耗很低”，却没告诉你制造这个引擎花了多少钱。他们还发现，虽然该系统在合成数据（计算机生成的示例）上表现良好，但它高度依赖于 AI 识别模式的能力，并且目前还无法完美处理每一种可能的混乱日志。

最终，TraceCompiler 展示了我们可以将 AI 智能体混乱、重复的行为转化为清晰、确定性的程序，但前提是我们必须对什么才算作“证据”保持严苛。这是朝着 AI 不再仅仅是每次都去“摸索”，而是学会遵循一条可靠、高效路径迈出的一步——只要我们能证明这条路径既安全又必要。

技术摘要：TraceCompiler

问题定义

工具使用型语言模型（LLM）智能体频繁重新发现已经执行过的流程，从而导致显著的 Token 使用成本和延迟。一个单一的循环意图（例如，请求付款或列出票据）通常会触发一个包含可重用结构（必要的工具、真实的依赖关系、稳定的配置）与偶然执行历史（重试、模式发现查询、风格化排序以及重复的事实解析）混合的追踪（trace）。

目前的方案（如将追踪总结为文本指导）仍要求 LLM 在运行时重新解释该流程。传统的流程发现方法并不充分，因为观察到的事件顺序并不意味着依赖关系；连续的调用可能源于独立的业务、失败的尝试或数据流。此外，部署后的日志往往存在部分可观测性问题，仅记录参数而不记录工具输出，使得通过匹配生产者输出到消费者输入来验证依赖关系变得不可能。

核心挑战在于如何将嘈杂、部分可观测的智能体追踪编译为可执行且基本确定性的工作流，其中由证据支持的决策被移出模型的运行时责任，仅留下真正开放的选择留给 LLM。

方法论

TraceCompiler 是一个技能引导的系统，它挖掘噪声追踪簇并将其编译为类型化工作流。该流水线包含以下阶段：

1. 意图发现与聚类

对话被嵌入为结合了初始请求与交织的推理/工具调用的文档。阈值聚合（余弦距离、平均联动）将追踪分组为意图簇。系统优先考虑保守的欠合并（under-merging），以避免污染不同的意图。幂等预处理步骤用于检测并拆分混合了无关意图的对话。

2. 归一化与行为去噪

原始追踪被归一化为规范的 app.action 词汇表。动作被标记为：

必需（Essential）： 任务所必需。
恢复/探索/冗余（Recovery/Exploratory/Redundant）： 保留用于分析，但可能被移除。
死输出（Dead Output）： 下游从未消费其输出的动作（例如，模式查找）。
重试 vs. 变体（Retry vs. Variation）： 系统区分噪声（趋向成功的参数抖动）与真正的扇出（系统性不同的参数，例如，针对每首歌的搜索）。通过字面计数器检测分页循环。

3. 参数级依赖验证

这是核心创新。只有当满足以下条件时，边 $a \to b$ 才会被视为硬依赖：

$b$ 的参数中的一个值可以追溯到 $a$ 的输出。
排除法： 该值的每一个替代来源（用户话语、静态上下文、工具默认值以及所有其他前序调用的输出）均已被排除。

如果存在合理的替代来源（例如，两个类型兼容的生产者），则该边被降级为疑似（suspected），且不施加排序约束。这防止了编译器仅基于邻接关系推断出虚假的依赖。

4. 出处分类与静态上下文

绑定被分类为：

常量（Constant）： 在追踪中保持稳定（在构建时解析）。
用户输入（User Input）： 在运行时解析。
复制边（Copy Edge）： 被证明起源于特定生产者的值。
转换（Transform）： 确定性的转换。
LLM/动态（LLM/Dynamic）： 需要运行时模型解析的真实语义绑定。

编译器被指定执行基于作用域的静态上下文注入，在构建时解析稳定值，并禁止在运行时进行这些值的发现工具。然而，此功能在报告的结果中并未被实际执行；两项案例研究均未报告注入的值，该设计元素仍处于等待证据阶段。如果一个不可逆的副作用是不确定的（例如，变动方向是模糊的），编译器将**放弃（abst abstains）**并不对其生成可执行图，而是将请求升级（escalate）。

5. 编译与运行时

分析结果被编译为一个具有类型化节点（TOOL, TRANSFORM, DECISION, LLM, HUMAN）的可执行定义（DAG）。运行时路由程序如果匹配到保守的相似性阈值，则将请求分发至编译后的工作流；不匹配的请求则回退到通用智能体。

编译器的引擎（v1）被实现为一个版本化的 LLM 技能——即一个作为智能体加载的指令包——而非训练好的模型。这允许进行对抗性审计和快速修订，而无需重新训练。

核心贡献

形式化： 将循环出现的智能体追踪复用建模为针对工作流结构、参数出处及部分可观测性下残余 LLM 决策的编译问题。
流水线： 一个完整的无监督流水线，涵盖意图发现、行为去噪、依赖验证、出处分类及可执行工作流生成。
依赖规则： 一种正式的、保守的参数级依赖规则，仅通过排除替代来源来准入边。它引入了显式的证据元组和针对模糊情况的“疑似”关系。
评估： 对两个共享不同机制的基准真相（T1 和 AppWorld）进行评估，并与基于顺序和基于重复次数的基准进行对比。
案例研究： 展示了成功的编译（Venmo 付款请求）以及在不可逆副作用不确定时拒绝编译的情况（Spotify/Todoist）。

结果

依赖准确性

T1 语料库（训练集）： 该机制化规则在 15,775 个 def–use 边上实现了 0.928 的精确度和 0.943 的召回率。这显著优于基于邻接的基准（0.711 F1）和基于频率阈值的直接跟随度量（0.712 F1）。
- 注意事项： 消融研究显示，在该特定语料库上，排除测试几乎是空洞的，因为每个关系至少有一个候选生产者。因此，报告的准确性主要依赖于在存活候选者中选择最近的幸存者，而非完整的排除测试。由于语料库限制，排除纪律是由 LLM 技能而非机制化规则执行的。
盲测技能运行（Blind Skill Run）： 在 T1 的 250 条边子集上，LLM 技能在单次运行中达到了 0.992 的精确度和召回率。
AppWorld： 相对于基于重放的参考（该参考恢复了掩码值），该规则在 563 个 token 边上实现了 0.993 的精确度。这作为一种自一致性检查而非独立验证，因为参考构造与被测试规则共享相同的假设（偏好相同的应用程序 token）。此外，此项仅界定了 session-token 归属，并未验证非 token 标识符流的恢复。

工作流编译与执行

Venmo 意图： 将 34 个观察到的 API 调用（包括重试和模式查找）编译为 11 个运行时调用。该工作流在保留实例的 21 个状态测试中通过了 15 个。6 个失败的原因是，保留实例所需的特定分支在训练集中从未被观察到，导致系统选择升级而非执行。
Spotify/Todoist 意图： 编译器正确地拒绝了编译此意图，因为变动方向（添加 vs. 删除）在追踪中是不确定的，代表了一种不可逆的副作用。
调用缩减： 在 56 个 AppWorld 场景中，可移除部分的调用中位数（模式发现和字节恒等的重复）为 51.4%。

意图发现

在 T1 上，聚类在覆盖的对话中实现了 0.930 的纯度，但相对于参考标签的调整兰德指数（ARI）较低（0.235）。这表明系统发现的划分比参考标签更细（将领域细分为模板级的任务），而非误分类。

意义与主张

论文声称观察到的邻接并不意味着依赖。通过强制执行要求排除替代来源的证据纪律，TraceCompiler 可以将嘈杂的追踪编译为确定性的工作流，从而减少运行时工具调用和 LLM 调用。

安全性： 系统优先考虑安全性而非完整性。它会对不可逆动作不确定的工作流进行放弃，从而防止执行不安全、投机性的程序。
效率： 虽然论文测量了调用缩减（例如，34 $\to$ 11 次调用），但它明确并未声称净效率提升，因为未测量离线编译成本。其经济学前提是，一个能力强大的模型可以将分析成本分摊到重复执行中。
局限性： 作者承认当前的评估依赖于合成或模拟器生成的数据。“排除”纪律由 LLM 技能执行，而非完全由机制化规则执行，这是由于语料库限制（缺乏诱饵 token）。系统目前缺乏针对 API 漂移的工作流版本控制和失效机制。

这项工作确立了：观察到的追踪对“必要性”的界定与其对“依赖关系”的界定一样紧密，并且用于测试编译工作流的工具（执行引擎）本身也是需要经过验证的推理程序。