ReTrace：将工具调用Agent蒸馏为无规划器工作流

业务过程自动化需要在新输入上反复执行同一套标准作业程序（SOP）。LLM Agent 能按照自然语言写成的 SOP 行事，但每次运行、每一步都要调用 LLM 做决策，规模化后延迟与成本都会显著增加。ReTrace 的思路是：把 SOP 和少量已记录的 Agent 运行轨迹，转化为可复用的工作流——由代码而不是 LLM 来选择下一步。

核心问题：每次运行都要“想一遍”

用 LLM Agent 执行 SOP 的代价在于“每一步都重新推理”。对高频、重复的业务流程来说，这种模式并不经济：每次运行都要为相同的决策支付推理成本，而且延迟随步骤数累积。

ReTrace 关注的是一个被忽视的信号——Agent 的推理过程。Agent 在每次工具调用时写下的解释，往往说明了它为什么采取这个动作；单看工具调用序列则看不出条件。ReTrace 正是从这些推理文本中提取每一步背后的条件。

LLM Agent 的推理成本结构：在 ReAct 等主流 Agent 范式中，每一步决策都包含一次完整的 LLM 前向推理，输入上下文随步骤数线性增长（历史工具调用与观察结果不断追加），因此单步成本并非恒定，而是逐步上升。对于步骤数为 N 的 SOP，总推理成本大致呈超线性增长，延迟也随之累积。这使得 Agent 在高频业务流程中的单位任务成本远高于传统脚本化自动化，也是 ReTrace 主张将规划阶段与执行阶段分离的经济动因。

方法：从推理文本中提取条件，编译成代码工作流

ReTrace 的流程可以概括为三步：

1. 提取条件：从 Agent 的推理与工具调用记录中，抽取出每个步骤背后的判断条件。
2. 合并为规则文档：把多次运行中提取的条件合并成一份紧凑的规则文档。
3. 生成可执行工作流：从规则文档生成工作流，由代码决定下一步。只有这最后一步依赖具体平台，因此规则文档可以针对不同的编排平台分别编译。

这种分层设计让“蒸馏”出来的流程具备一定的平台可移植性，而不是绑定在某一个 Agent 框架上。

τ²-Bench 与 SOP-Bench：τ²-Bench 是面向工具调用型 Agent 的评测基准，通常模拟客服等双人（用户与 Agent）对话场景，要求 Agent 在遵守业务规则的前提下调用数据库与 API 完成任务，并以最终状态是否满足目标来判定成功率。SOP-Bench 则聚焦于以标准作业程序为约束的业务流程，程序数量多、规则明确，适合衡量工作流方法相对 few-shot 生成与原始 Agent 的表现差异。两者共同的特点是任务有确定性判定标准，因而适合比较完成率、每任务成本与延迟这三类指标。

效果：接近 Agent 的完成率，更低的成本与延迟

据论文报告，在生产平台的 SOP 上，ReTrace 工作流的完成率略低于原始 Agent，但每个任务的成本明显更低。在 τ²-Bench 上，任务成功率同样略低于 Agent，但运行时间从秒级的大幅等待缩短到秒级以内；对训练失败样本进行三轮修复后，k=2 工作流的表现有明显提升。

在 SOP-Bench 的若干程序上，未经修复的 ReTrace 略逊于 few-shot 生成，但利用带标签的训练失败进行修复后，成功率反超，且每任务耗时远低于 Agent。这些结果指向同一个结论：把规划交给代码，可以在保留大部分成功率的同时，显著降低推理开销。

few-shot 生成基线：few-shot 生成指的是直接把少量示例（SOP 片段或历史轨迹）放进提示词，让 LLM 一次性产出工作流或代码的做法。它不需要额外的条件抽取与规则合并，实现简单，但缺乏对多次运行中隐含条件的系统归纳，容易在边界条件上遗漏或产生不一致。ReTrace 在未经修复时略逊于这一基线，说明条件抽取与规则合并本身会引入信息损失；而利用带标签的训练失败样本进行修复后反超，则表明该损失可以通过有监督的迭代修正来弥补。

启示：Agent 蒸馏的一条务实路径

ReTrace 的价值不在于让 Agent 完全消失，而在于重新划分职责——LLM 负责“教会”流程，代码负责“执行”流程。对于 SOP 稳定、运行频繁的业务场景，这种 planner-free 的工作流形态比每次调用 LLM 更贴近生产要求。

它同时提示了一个更一般的观察：Agent 的推理文本不只是给人看的解释，也是可以被提取、压缩并固化为规则的结构化知识。如何稳定地抽取条件、如何处理多次运行之间的条件冲突，仍是这类方法落地时需要面对的工程问题。