成功的路径即昂贵的路径：任务成功率越高，成本就越高的智能体

失败的智能体（Agent）运行成本很低。它可能会误导查询、陷入死胡同、返回“我无法提供帮助”，而执行这些操作可能只消耗几百个 Token。但成功的运行却是一场“灾难”。它检索上下文、进行反思、调用三个工具、再次反思，最后缝合出一个自信的、长达数段的答案——其 Token 消耗是那些几乎不花钱的失败运行的五十倍。

这就是智能体经济学中令人不安的现状：你的理想路径（Happy Path）就是你的高昂路径。你所销售的结果，也就是你在营销页面上承诺的、用户为此向你致谢的结果，正是你的系统所能执行的最昂贵的操作。如果你按照过去十五年 SaaS 的定价方式——按每个席位收取固定月费——那么智能体每出色地完成一次工作，都在悄悄侵蚀你的利润。

大多数团队是后知后觉才发现这一点的。他们观察成本仪表板，看到失败的成本很低，便得出结论：提高可靠性将节省资金。事实并非如此。提高成功率只会增加你的账单。

为什么成功的运行成本要高出五十倍

让我们从机制谈起，因为这里的直觉确实是反直觉的，值得具体剖析。

单次对话补全（Single-shot Chat Completion）是“一进一出”的模式。而智能体运行则是一个循环。每一次迭代都会将不断累积的上下文——系统提示词、对话历史、工具定义、之前所有的工具执行结果——重新发送回模型。上下文并不是保持不变的。它随着每一步的进行而增长，而你必须为每一步的完整内容付费。

数字差异非常显著。行业测量数据显示，智能体的工作负载消耗的 Token 数量约为 50 倍于同类对话交互的消耗。在一次简单的五步循环中，一项分析发现，为了获得相同的结果，智能体路径的成本比直接调用的成本高出约 3.2 倍。如果增加到五十步，倍数将超过 30 倍。在两百步时——这在自主调试或研究场景中并不罕见——倍数会突破 100 倍。越往后的迭代越昂贵，因为到那时，上下文窗口已经充满了历史信息。

现在再来看看成功与失败的成本划分。失败往往是一个短循环：智能体找不到工具，无法验证答案，于是早早放弃。步数少、上下文薄、账单小。而成功之所以是一个长循环，恰恰是因为它完成了工作——它收集证据、进行工具调用、自检。让答案变好的因素，正是让它变昂贵的因素。

这就是为什么“智能的单位价格正在下降”是一个具有误导性的安慰。虽然每 Token 的价格每季度都在下降，但每个结果所消耗的单位数量增长得更快，因为我们不断要求智能体完成更难、更长、更彻底的任务。更便宜的 Token，更多的 Token，更昂贵的账单。

为什么成功率的提升反而会压缩你的毛利

这是一个让财务团队措手不及的陷阱。

假设你的智能体今天能解决 60% 的任务，接着你发布了一系列改进——更好的检索、在推理步骤使用更强大的模型、增加一次反思环节——将解决率提升到了 85%。毫无疑问，这是一款更好的产品。用户更满意了，流失率降低了。

但你单个任务的成本也随之上升了。

两件事同时发生了。首先，那些以前“快速失败”的任务现在变成了“缓慢成功”：它们从低成本的短循环池进入了高成本的长循环池。其次，改进本身——额外的反思、更大的模型——增加了每一次运行的 Token 成本，包括那些原本就能成功的运行。你并没有让成功变得更便宜。你制造了更多最昂贵的事件，并让每个实例都变得更贵。

如果你的单个任务收入是固定的——在按席位定价模式下实际上就是固定的——那么利润等于收入减去成本，而你刚才在收入持平的情况下提高了成本。一次真正的产品胜利，在损益表（P&L）上表现为毛利压缩。工程部门发布了改进，庆祝解决率图表的上升，而首席财务官（CFO）却看到毛利率下滑了一个百分点。没人撒谎；他们只是在看不同的指标。

预见这一点的唯一方法是停止衡量单次调用成本（Cost per Call），转而衡量单次结果成本（Cost per Outcome）——具体来说，就是衡量每个已解决任务的成本。单次调用成本告诉你 Token 很便宜；而单次结果成本告诉你，交付一个更好的智能体是否让你变得更穷。

没人预料到的定价错配

更深层的问题是结构性的，且在智能体出现之前就已存在。SaaS 定价是建立在“席位”基础上的。一个席位代表一个人，人的产出是有限的，按人收取固定费用之所以可行，是因为服务一个用户的成本与服务下一个用户的成本大致相当。

智能体打破了这种界限。智能体不占用席位。它执行工作——有时是数千项任务——其成本随工作的难度而变化，而不是随着登录人数而变化。在按席位定价的模式下，两个支付相同费用的客户可能会给你带来截然不同的成本。数据非常残酷：在固定定价模式下，重度用户消耗的资源通常比轻度用户多出 100 到 1,000 倍。这并非尚未挖掘的增长空间。对于你最重度的客户，每一张发票其实都在产生真实的、经常性的亏损。

而且这种反转是极其讽刺的。按席位定价在客户雇佣最多员工时收费最高——而员工正是你的智能体理应取代的对象。你的产品越好，客户需要的席位就越少，你赚的钱就越少，而且你运行的智能体任务还越多。客户层面的成功和成本层面的成功都在推低你的利润。你为你所销售的成果被惩罚了两次。

这在宏观数据中已有体现。分析师目前估计，软件公司每录得 100 万美元的 AI 产品收入，就有大约 23 万美元作为推理成本流出，这还没算销售、研发或营销人员的支出。定义了云时代的 80% 以上的毛利率已不再是默认配置；AI 密集型产品的毛利率正滑向 60% 到 70% 左右。对变动成本产品采取固定费率定价，不仅是把钱留在桌上——它还会把你最好的客户变成你最大的负担。

对真正产生变量的指标进行监控

你无法管理你无法衡量的东西，而且大多数团队衡量的粒度都是错误的。月度 Token 总账单对此毫无用处。你需要将成本归因于那些会发生变化的单位。

两个维度的切分最为关键。

每个已解决任务的成本。 为每一次 Agent 运行打上标签，标注其结果——已解决、升级（escalated）、已放弃——以及完整的 Token 消耗，包括工具调用（tool-call）的开销。然后用总支出除以“已解决”的结果数量，而不是总运行次数。当你发布可靠性改进时，这个数字才会发生变化，并且在每次评审中，它都应该出现在解决率图表的旁边。如果解决率上升了，而“每个已解决任务的成本”上升得更快，那么你发布的其实是一个披着功能外衣的毛利倒退。

每个用户群组的成本。 按 Agent 支出对客户进行分桶，观察分布情况，而不是平均值。平均值会掩盖一切。你需要寻找长尾——那些运行量是中位数 100 倍的账户——因为在固定定价体系下，这些账户会让你亏钱，而且如果你看不到问题，就无法通过定价或限制额度来解决它。群组视图能将“我们的成本上升了”转化为“这 11 个账户占据了超额支出的 70%”。

一个由他人花大价钱换来的教训：预算报警（alert）不等于预算控制（control）。很多团队设置了在支出达到 X 美元时触发的报警，然后由人工在一小时后看到——到那时，失控的循环（runaway loop）早已烧光了钱。有记录显示，单个 Agent 循环曾跑掉数万美元。报警是可观测性。执行（Enforcement）则是一个独立的系统，它必须能够“停止”运行，而不仅仅是“注意到”运行。

防止良好结果吞噬毛利的产品杠杆

监控告诉你问题的轮廓。解决问题是一个产品决策，而不仅仅是基础设施决策。这里有四个杠杆，大致按其帮助程度排序：

投入上限。 在编排循环（orchestration loop）内部强制设置 Token、轮次或工具调用的硬上限——不是作为报警，而是作为运行撞上即停的“墙”。每个严肃的 Agent 框架都支持最大迭代次数（max-iterations）限制；请务必使用它。上限能保护你免受病态长尾的伤害：即那种可能螺旋上升到 47,000 美元的运行。大多数合法任务在达到上限前很久就能完成，因此设置合理的上限几乎不会让你损失什么，却能完全消除最坏情况。

简单路径的模型路由。 大多数传入的任务都很简单。不要在这些任务上使用最昂贵的价格。将任务划分为三到五个复杂度层级，并为每个层级分配能达到质量标准的最低成本模型，仅针对真正困难的情况才升级到强力模型。采用这种做法的团队报告称成本降低了近 87%，因为昂贵模型最终只处理了约 10% 真正需要它的工作。这里的纪律是按“层级”监控质量，以便你在某个层级的默认模型表现下滑时能及时察觉。

升级阶梯。 并非每个任务都应该自动运行到结束。有些任务应该在早期就被检测为低置信度或低价值，并进行移交——移交给更便宜的确定性路径、移交给人工，或者直接告知“我们无法处理”，用户通常更喜欢这样，而不是缓慢、昂贵且错误的答案。早期升级是“廉价失败”的合法版本：你在漫长且昂贵的循环开始前就停止了支出。

挂钩成本的定价。 上述杠杆缩小了差距，但无法完全消除，因为这种差距是结构性的。最终，定价必须承认成本随工作量扩展。市场已经在发生变化——混合定价（即平台费加随 Agent 活动扩展的消耗组件）预计到 2026 年底将成为软件公司的主流模式。基于结果的定价则走得更远：按合格线索、按解决案例、按追回销售额收费。这种模式具备其他模式不具备的属性——当 Agent 漫无目的地游走并烧掉 Token 却未交付成果时，成本由你承担，这正是迫使你修复问题的动力。

心态转变

你能做的最有用的事情就是停止将 Token 视为基础设施的账单项目，而是开始将“每个结果的成本”视为一个产品指标——它应该与解决率、延迟和留存率放在同一个评审环节中。

当这些数字分处不同阵营时，工程团队发布的“胜利”会悄悄地烧钱，而且直到季度毛利评审时才会有人把这两者联系起来。当它们在同一个阵营时，增加一个反射（reflection）环节的提议将根据其对“每个已解决任务成本”的影响来评估，而不仅仅是准确率。这就是博弈的关键。

当你的 Agent 获得成功时，它的成本会更高。这并不是一个需要被优化掉的 Bug——这是你构建的产品的物理特性。你的工作不是让成功变得廉价，而是确保每次 Agent 获胜时，你也同样获胜。