智能体的贵不在模型，在每一步重新想一遍

开头：一个每天都在跑的流程

一个工单进来，智能体读一遍，判断它属于哪一类，查一下客户历史，决定要不要升级，写一条回复。这个流程一天跑几千次，每次输入不同，做法一样。写这段流程的 SOP 早就存在，问题在于它每次执行都要重新问一遍模型：下一步该干什么。

这就是 2026 年企业自动化平台上最普遍的用法。ReTrace 团队拿到了一个生产平台的真实数据：2026 年 4 月到 6 月，客户在这个平台上建了 5,115 个自动化，其中 91.8% 是运行时规划的智能体。而这 5,115 个自动化里，被执行次数最多的前十名，有七个是固定工作流。

这两个数字放在一起，说明一件被忽略的事：客户并不傻，他们知道高频流程该用确定性的做法。真正的信息在比例的另一半——九成以上的新建自动化走了智能体这条路，因为它省事，写一段自然语言 SOP 就能上线，不用画流程图、不用接分支。代价是每一次运行都要付一遍「重新想」的钱。这篇论文要解决的，就是把这笔重复的钱省下来，而不是等模型变便宜。

钱和时间花在哪一层

先看时间。在用了三到五个工具的智能体里，选择下一步这件事占用了执行时间的 37% 到 43%。这不包括 token 成本，是纯时间。也就是说，一个跑一百七十秒的任务，有五六十秒花在「接下来该调哪个工具、参数从哪来」上面，而不是花在工具本身。

这里要分清两笔账。模型单价在往下走，Anthropic 每百万 token 的均价五个月掉了七成多；可是每一轮决策都要重新发一次上下文，单价下降被调用次数吃掉了。所以账单的分子是「每轮决策 × 轮数 × 上下文长度」，波动来自后两项，而这两项由架构决定，不由采购决定。

采购拿到的表格通常只有第一项。那张表里的单价确实重要，但它描述的是一个单位，而真正决定成本的，是这个单位要被用多少次。在一百七十秒的任务上，用掉五六十秒来选下一步，就是「单位用得太多次」的具体形态。

编译成工作流是件什么事

ReTrace 的做法值得讲清楚，因为它决定了适用边界。智能体运行时会把每一步的理由写进日志，比如「客户要求退款，订单已发货，因此升级给人工」。工具调用本身不写理由，只有调用记录，所以只看调用序列无法判断「为什么在这里升级」。这一步的理由，就是决策条件。

方法分三步：从带推理的轨迹里抽出每一步的条件、工具和输入来源；把多次运行的抽取结果合并成一份紧凑的规则文档，每条规则挂着它来自哪几次运行；再从规则文档生成可执行的工作流，到这一步才和平台相关。模型只用在前两步，一次性的构建过程；运行的时候由代码选下一步，虽然某个工具自己可以调模型，比如分类一份文档。

这个结构解释了为什么它可以编译到不同平台：规则文档是中间产物，跟编排平台解耦。对企业的实际含义是，编译一次的成本可以摊到多个平台上，也可以在下一次换平台时复用，而不是每换一次重做一遍。

生产环境的实测：什么降了，什么升了

79 个生产流程上的结果：编译出来的工作流完成率 93.8%，智能体是 96.8%，差三个点；单任务成本从 0.127 美元降到 0.096 美元，降 24%，这个成本包含工具内部调用的模型；中位耗时从 68 秒降到 37 秒，降 46%。

但平均耗时反而从 153 秒升到 163 秒。这个反常值的成因值得每个 CTO 读一遍。79 个流程里有 20 个用到网页自动化，把这 20 个去掉之后，编译版本平均 58 秒，智能体平均 92 秒，成本只有它的 19%。也就是说，整体平均值被网页那一组拉上去了。

网页那一组为什么会拉上去？因为一次成功的网页工具调用中位耗时 270 秒，失败只要几秒钟。智能体那些跑得「快」的运行，有相当一部分是因为它的调用根本失败了。论文给了一个更刺的数字：网页工具调用成功率，编译版本 86.6%，智能体 27.3%。平台还会把没有任何成功工具调用的智能体运行标记为完成，于是完成率这个指标自己也在帮忙掩盖问题。

这就引出一条可以直接用的采购判据：不要用平台自报的完成率和平均耗时比较供应商，先要工具层的调用结果日志。 完成率是平台自己的判定口径，工具结果才是外部可核对的账。两家供应商报出同样的 96%，一家是每单都真的调通了，另一家是三成单子在外围工具上失败但流程被标记完成，这两个数在报表上长得一模一样。

延迟：一百七十秒变成一点三秒

τ²-Bench 上的对照更能说明机制。编译版本的任务成功率 75.8%，智能体 80.6%，差 4.8 个点；单任务耗时从 170 秒降到 1.3 秒。SOP-Bench 上，一次任务 0.40 秒，智能体要 46.6 秒。

这个量级的差距不是在同一个架构里优化出来的，它是「要不要每一步都问模型」的差别。智能体每一步都是一次完整的模型调用，等待时间来自推理本身；工作流里代码选分支，只有工具内部需要模型时才等。对客户体验的含义很直接：需要人在旁边等的场景，比如客服坐席的实时辅助，1.3 秒和 170 秒是两个产品。

SOP-Bench 上还有个细节不能漏。不做修复的编译版本是 80.6%，比少样本直接生成工作流的 83.6% 低；用带标签的训练失败做三轮修复之后升到 87.8%，超过智能体的 85.5%。修复的输入是「哪条输入失败了、正确答案是什么」，这个信息只有在有标注的情况下才存在。没有标注的团队拿不到这个提升，所以不要把一个带标注实验的结果当成通用结论。

推理值多少钱：一个分场景的答案

这是全篇最值得记住的实验。把智能体的推理去掉，企业流程的完成率掉 8.8 个点，τ²-Bench 掉 6.2 个点；但在 SOP-Bench 上反而涨 1.7 个点。

同一个动作，在长流程上是必要的，在短流程上是负担。原因是 SOP-Bench 的流程短、分支少，条件基本写在 SOP 文本里，推理没有提供额外信息，只是重复了一遍已知条件；而企业流程里有大量隐含条件——订单状态和物流状态哪个优先、退款金额和客户等级怎么组合判断——这些不写在 SOP 里，只在人做的时候体现，推理正是在这一步补上了它。

所以「要不要编译」这个问题问错了。正确的问题是分段的：同一份 SOP 里，哪些判断的条件是可枚举的，哪些判断的条件依赖经验。前者编译掉，后者留给模型。ReTrace 的做法也是分段的——它只把能从推理里读出来的条件写成规则，读不出来的部分不会被凭空发明出来。

回本期：大约七十五次运行

构建不是免费的。论文的估算里，构建一次至少要做 11 次模型调用；智能体每跑一次，平均有 12.1 次规划调用。也就是说，构建成本大约等于十一次运行的成本，而省下的部分来自每一次运行。用测得的节省和 τ²-Bench 的构建成本算，构建成本在约 75 次运行之后被收回。

75 次听起来门槛不高，真正有价值的是后面那个数：那七个最常跑的工作流，在三个月里各跑了 29.7 万到 52.8 万次。以 75 次为回本线，这些流程的回本期在第几个小时就过了。这条对比说明一个决策顺序：先按执行次数排序流程，再考虑编译，不要按「哪个流程最复杂」排序。复杂的流程往往跑得少，跑得少的流程编译回不了本。

顺带一个采购能用的问题：供应商给你的编译报价，对应多少次运行能回本？答不出这个数的报价，本质上是把一个一次性的工程投入卖成了长期服务费。

四个判据：把问题变成可决定的

第一，运行量。 同一份 SOP 年化运行次数低于两百次，编译不划算，因为构建成本相当于十一次运行，修复与维护还要再加。判断线可以粗一点：年化运行次数 × 单任务节省 > 构建成本的五倍，才值得动手。

第二，条件能不能被写出来。 判据是有没有带推理的轨迹。如果日志里只有工具调用，看不出为什么走这一步，编译出来的规则就是猜的，出错的方式还很隐蔽——它不会报错，只会在某类输入上默默走错分支。这一类流程应该先补日志，不要先编译。

第三，SOP 与工具是否稳定。 论文自己写明了：SOP 或工具一变，工作流可能要重建。季度内会改的流程不适合编译，因为重建成本会把节省吃掉。这一条排除了大量「正在优化中」的流程——它们恰恰是最想省钱的。

第四，失败代价能不能承受。 生产数据里完成率掉了三个点。这三个点值多少钱，取决于掉的是哪三个点：如果掉的是低价值咨询类工单，可以接受；如果掉的是合规审批，不能。判断方法不是看总体完成率，是把失败样本抽样分类，看里面有没有不可接受的类型。

反过来，有四类流程不该编译：外部交互不确定的（网页自动化那一组，整体平均耗时反而上升）、异常分支多且没有历史轨迹的、SOP 文本还在频繁修改的、失败代价不可承受的。这四类不是「暂时别做」，是「做之前先解决前置条件」。

论文自己承认的局限

任何转述都要带上这一段，否则读者会把它当成产品说明书。

作者自己列的局限有五个：推理可能是错的，也可能并不反映真实原因，构造阶段的检查只验证生成的代码能被加载、不含规划调用，以及在可重跑的情况下能复现多少已记录步骤，并不验证恢复出来的条件是正确的；评测只覆盖同一流程的新输入，不覆盖跨流程迁移；SOP 或其工具变化可能导致工作流需要重建；质量差的轨迹会限制能恢复出来的东西；企业侧完成率由平台上报，平台可以把失败的运行标成完成。

第五条的份量最大。它意味着本文引用的 93.8% 和 96.8% 都是平台口径，不是外部审计过的口径。我们在前面用它推出「要看工具结果日志」这个判据，同一个理由也适用于本文自己的数字：把这三个点差距当成精确结论是错的，把它当成方向是合理的。

我们的判断

第一，未来两年企业自动化会分成两层：一层是编译过的确定性工作流，承接高频、条件可枚举的流程；一层是运行时规划的智能体，承接低频、判断依赖经验、SOP 还在演化的流程。今天的问题不是选哪一层，是九成以上的新建自动化都落在了第二层，而执行次数最多的前十名里七个在第一层——这个错配就是可省的成本本身。

第二，模型变便宜不会让这个错配消失。单价下行抵掉的是 token 成本，抵不掉每一步重新决策的时间成本和调用次数。企业真正该盯的指标不是每百万 token 多少钱，是每完成一次任务要多少次决策、每次决策等多久。

第三，采购上有一个立刻能改的地方：把「完成率」和「平均耗时」从供应商对比表里拿掉，换成工具调用成功率、单任务决策次数、每个被接受结果的全成本。前两个指标供应商可以自己定义，第三个不行。

三个可以这个季度做的动作

一，把自动化清单按最近三个月的执行次数排序，取前二十名，标出各自是智能体还是固定工作流。凡是被执行次数最多的那一批里还是智能体的，先算一个数：单任务里有多少时间花在「决定下一步」。用 37% 到 43% 这个区间做上界估算，够用来排序。

二，挑三个流程做编译试点，验收标准写成工具调用结果，不写完成率。试点周期六周，产出一个数：单任务成本、单任务决策次数、工具成功率各是多少。这三个数是后面所有谈判的基础。

三，把 SOP 的判断条件过一遍，标出哪些条件是「写不出来的」。写不出来的那些，不要硬编译，先补日志，让下一次运行留下理由。这一步不花钱，但它决定了下一轮编译能不能做对。

来源

ReTrace: Distilling Tool-Using Agents into Planner-Free Workflows，arXiv:2611.14492v1，2026-11-10 提交：arxiv.org/abs/2611.14492v1

文中引用的 91.8%、5,115 个自动化、前十名七个固定工作流、37–43%、93.8% 对 96.8%、单任务 0.127 美元降到 0.096 美元（-24%）、中位 68 秒到 37 秒、平均 153 秒到 163 秒、20 个网页自动化流程的 58 秒对 92 秒与 19% 成本、工具成功率 86.6% 对 27.3%、中位 270 秒、τ²-Bench 的 75.8% 对 80.6% 与 170 秒到 1.3 秒、SOP-Bench 的 80.6%/83.6%/87.8%/85.5%、0.40 秒对 46.6 秒、去掉推理的 -8.8/-6.2/+1.7、构建至少 11 次调用与每跑 12.1 次规划调用、约 75 次回本、七个工作流三个月 29.7 万至 52.8 万次，均出自该论文正文与附录。

局限一节逐条对应论文第 7 节 Limitations 的表述。