你可以将代币支出削减超过90%，而无需依赖开源模型。

一年前，代币支出还不是讨论的话题。我记得有人告诉我，这项技术将“彻底改变他们的业务”，所以他们并不太在意在代币上的花费。如今，嘲笑“代币最大化”很容易，但当时这种做法非常普遍。

快进到今天，情况已经发生了很大变化。大型公司内部的人工智能使用量急剧上升，代币支出也随之增加。生产力仅略有提升，而且肯定没有转化为大多数高管所期望的财务回报。现在，他们想知道为什么账单不断增长，应该衡量什么指标，以及如何在保持效率提升的同时降低代理的成本。

作为背景，我是@varickagents的首席执行官。我们为全球最大的公司构建代理。我们的核心重点是证明以最便宜的代币支出实现最大的效率提升，因此，我们注意到相同的模式反复出现。

Daniel，负责我们的FDE团队，最近写了一篇文章，讨论公司很快将如何像交易公司管理资本一样管理代币支出：将资金从低回报的用例中转移，重新分配到高投资回报率的用例上。这更多是财务方面的问题。但工程方面呢？

如果智能是昂贵的，你如何尽可能少地使用智能，同时确保你使用的智能以尽可能低的成本做有用的工作？通过这种框架，衡量标准变得清晰：你应该追踪智能的投资回报率，而不是原始支出，甚至不是每位员工的支出。

简单来说：如果花10美元在Fable 5上能解决1个难题，而花10美元在Gemini 3.6 Flash上能解决100个简单问题，那么问题就变成了你的“难题”中有多少其实只是“简单问题”的集合。剧透警告：大多数都是如此。

一旦你将复杂的工作流程分解为各个步骤，你就会意识到，在调用模型时，大多数步骤根本不需要顶尖智能。有些步骤可以是确定性的，有些可以使用较小的模型，还有些输出可以被缓存，而不必每次都重新生成。

贵公司90%的token开销本就不该发生。少花点token。

大多数企业工作流程是确定性的

当我们深入探究token开销时，很快注意到一件事：许多被称为“智能体”的工作流程，其实只在少数几个地方需要LLM的判断，但团队却对所有环节都使用了AI。

从外部看，这些工作流程显得非常复杂（涉及多个系统的写入、流程可能走的不同路径、审批/异常处理）。我们会审视这些复杂流程，并断定需要一个配备前沿AI的复杂智能体来运行它。

但当我们一步步梳理这些流程时，我们发现“智能体”所做的很多工作其实简单且确定：检查字段是否匹配、将数据从一个地方移到另一个地方，或者只是应用一条规则。我们意识到这些琐碎任务可以用代码完成，成本低得多，而我们却用昂贵的智能来运行它们，浪费了token。

我们逐渐认识到，工作流程中的步骤数量与该流程所需的智能程度，是两件截然不同的事情。

一旦你将它们分离出来，许多企业工作流程大多是确定性的，只有极少数地方真正需要模型思考。任何确定性的部分都可以且应该用代码实现，这意味着在大多数此类工作流程中，AI 的使用其实是过度设计。

工作流程是错误自动化单元

一旦我们以这种方式审视工作流程，就意识到我们一直思考的自动化单元是错误的。

模型现在已足够强大，你可以给它们大量上下文和几个工具，让它们自行处理相当复杂的过程。但这同时也意味着模型在许多并非必需的地方被使用，毫无理由地消耗你的 token 预算。

这是我们看到的最大设计错误：在工作流程层面进行自动化。相反，应将工作流程分解为其中的单个任务，因为每个任务对智能的需求完全不同。

一旦你确切知道哪些工作流程组件需要 AI，哪些不需要，就能更精细地决定 AI 的使用位置，最终只在需要判断力的地方花费 token。

这些主要是工作流程中无法提前知道正确答案的部分，因为答案取决于具体情况。例如，设想一个代理收到一封电子邮件。根据客户询问的内容，这封邮件可能有不同含义。每当答案依赖于背景上下文且存在多种合理处理方式时，模型就变得有用，因为这里确实需要做出判断。

但我们看到的另一个错误是，把最强大的前沿模型用在每一个需要一点判断力的任务上。我们的方法是把工作流拆分成一个个独立任务，然后针对每个任务对模型进行基准测试，并使用能可靠处理该任务的最小模型，而不是一次性把整个事情交给前沿模型。最终，我们构建了一个系统，在可能的情况下运行 Gemini 3.6 Flash，只在绝对必要时才动用 Opus。大致分布是 90% 非前沿模型、9% 接近前沿模型、1% 前沿模型。我们称之为 90/9/1 分配。与全部使用前沿模型相比，这种分配正是本文开头提到的 90% 成本节省的来源。

模型应成为系统中更小的部分

一旦你评估了某个步骤真正需要多少智能，你就会意识到工作流中的大多数步骤并不需要强大的模型。事实上，有些步骤根本不需要模型。

确定性步骤应该用普通代码实现（例如，如果我们收到一封邮件，就应该下载其附件，如果有的话）。简单明了：如果 X，则 Y。

而更简单的推理应该交给更小、更便宜的模型，比如 Gemini 3.6 Flash（例如，读取发票上的行项目，如果是订书机，就调用 LLM 将其 GL 编码到正确的类别——在这种情况下是“办公用品”）。

已知的输出可以从缓存中重复使用，而不是每次都重新生成全新的结果（例如，每次读取行项目时，都应将其 GL 编码映射到缓存中，这样每当看到“订书机”时，就知道它是“办公用品”，甚至无需调用 LLM）。

让每一次模型调用都物有所值

从当前实际运行的流程开始。你通常会发现在很多地方，结果无需模型即可确定。这些部分就应该直接写成代码。如果这样，那就那样。你知道的，就是那种经典的老派方式。

剩下的部分则是需要判断力的小范围领域。那里模型是必需的，但各个步骤所需的智能程度并不相同。一个较小的模型可能完全适用于某个步骤，而另一个步骤则需要更强大的模型。对于这些步骤，当涉及大量判断或领域知识，或者答案出错代价过高时，应保持人在回路中。

上下文是另一个令牌被低效消耗的大领域。过去两年在应用AI领域的经验告诉我们，模型周围的“护栏”对令牌消耗量有着非常大的影响。Eyad 几个月前写了一篇文章，讲述如何正确构建这样的护栏。我强烈建议把那篇文章发给为你构建代理的人。

一个好的护栏能防止模型被不需要的信息淹没。如果决策只取决于几个字段或可能一份文档，就没有理由在每次LLM调用时发送整个工作流的历史记录。窄上下文也更准确，因为无关信息正是模型容易混淆的地方。

TL;DR

许多从外部看起来像代理式的工作流，一旦分解开来，大部分都是确定性的。

你很少（如果有的话）应该让一个模型推理整个工作流，而是应该将工作流分解为单独的任务，然后逐个任务决定哪些真正需要模型。

对每项任务，深入审视实际所需的判断程度。如果答案可以预先知晓，就用代码解决。若需一定判断，则选用能可靠处理的最小模型。若出错后果严重，则升级至更强模型或人工介入。

尽可能缩小上下文范围，并在相同输入反复出现时，通过缓存复用输出结果。

简而言之：目标是精打细算地使用智能，不仅为了节省令牌开销，更为了提升准确性。

AI 未如你所愿地工作？

这正是我们在 Varick 为客户所做的事情。大部分工作已不再是证明智能体能够自动化某个流程，而是设计该流程，使其在运行数百万次时仍具经济合理性。更重要的是，确保工作真正从你的团队手中卸下：可靠且全天候运行。

如果你是一家试图掌控 AI 的大型企业，这正是我们解决的问题。欢迎访问我们的网站 varickagents.com，预约时间与我们的 AI 专家团队交流。