每 token 的 API 价格持续下降，但自主编码智能体的工程账单却不断攀升。每百万 token 的价格已不再是真正决定生产经济性的指标。如今占主导地位的指标是单次成功任务成本：即所有循环迭代、工具调用、重试和内部思考过程的总支出，除以通过验证的任务数量。
当智能体在其执行框架中为每一个微小决策都调用高思考推理配置时，你就是在为那些轻量级配置早已能准确回答的问题支付深度推理的价格。为避免这种不必要的开销，可以考虑添加一个轻量级路由层，在常规决策到达昂贵的推理模型之前将其拦截。
这正是将 TypeSafe 的 Jev 分类器接入 Google Antigravity 模型调用之前这一做法的前提。Jev 是一种专为高吞吐决策流水线设计的结构化输出分类器，它不逐 token 生成文本，而是在单次前向传播中评估结构化分类原语：从列表中选择一个 Choice、一个数值 Score，或一个 Noul——后者针对二元陈述返回 0 到 1 的概率。
为完整披露：Google 与 TypeSafe 并无合作关系，本文也不构成对 TypeSafe 或其产品的背书。此处使用 Jev 仅作为轻量级分类器的一个示例，同样的路由模式也可以用其他分类器构建，包括 Google 原生的分类器。例如， 判别式模型入门 codelab 就在你自己的 Google Cloud 项目中，对 Google DeepMind 的开源权重模型 DiffusionGemma 运行同类分类器。
我们针对实时 Gemini 和 Jev API 运行了一个 50 题、自动评分的编码智能体基准测试，以检验一个近乎免费的分类器能否将每个任务路由到仍能正确完成它的最便宜模型。以下是我们得到的发现：
1. 正则表达式和 token 长度框架路由器在未见过的智能体任务上会失效
让 Jev 路由编码任务的最朴素方式，是提出一个宽泛的单一 Choice 问题： simple 或 complex。当我们最初在 16 个编码智能体任务上测试时，Jev 几乎把所有任务都路由到了 simple，甚至包括需要 LRU 缓存追踪或模幂运算的任务。TypeSafe 的文档明确警告不要采用这种反模式。如果一个问题权衡多个因素或需要元判断，就应将其分解为原子检查。
当我们把宽泛的 Choice 问题替换为一个原子 Noul 问题后，分离效果立刻得到修正。问题是：回答这个问题是否需要执行多于一次的连续计算、模拟步骤或逻辑推演，而不是单次直接查找、格式检查或一步分类？
def call_jev(question_text):
body = {
"state": question_text,
"model": "jev-latest",
"questions": {
"multi_step": {
"type": "noul",
"instructions": (
"Answering this requires performing more than one "
"sequential calculation, simulation step, or logical "
"deduction, rather than a single direct lookup, format "
"check, or one-step classification."
),
}
},
}
# Send the request above to the classifier's API.
# response.answers["multi_step"].noul is the probability used to route.
在这最初的 16 个任务上，Jev 首轮路由的 16 个中有 13 个与我们手工标注的难度一致，第二轮为 16 个中有 14 个。许多工程团队会问，既然可以用 Python 编写零成本的正则表达式和提示词长度启发式规则，匹配诸如 sequence, modulo 和 race condition 之类的词，或对任何超过 35 个词的提示词进行升级，那他们是否还需要分类器 API。
在用于编写这些确切规则的 16 道开发题上，本地启发式规则得分为 16 题中的 15 题，即 93.8%。为检验该启发式规则在接触真实编码智能体流量后是否依然有效，我们冻结了其代码，一字未改，并新增了 34 道未见过的留出任务，涵盖七个编码智能体类别：事实提取、模式验证、短分类、单跳代码检查、状态模拟追踪、数学或逻辑链，以及微妙的语言语义缺陷。
在这 34 道留出题上，冻结的启发式规则下降了 23.2 个百分点，降至 70.6%。诸如从 Kubernetes YAML 清单中提取端口、从统一 git diff 头部提取文件路径，或从 Python 回溯中提取行号这类现实中的简单任务，都超过了 35 个词并触发了误升级。相反，诸如跨调用的可变默认参数、 {1: "a", True: "b", 1.0: "c"} 上的 Python 字典键哈希，以及 C 语言短路求值这类简洁的多步代码追踪，由于缺少启发式规则中硬编码的谜题词，被错误地路由到了简单路径。Jev 对全部 34 道未见任务分类的一致率为 100.0%，即 34 题全对，在整个测试套件上达到 50 题中的 48 题，即 96.0%。
2. MaxOutputTokens 是上限，而非思考预算调节旋钮
构建快速路径路由器时的一个常见错误，是假设在推理模型上设置较低的 maxOutputTokens 上限就能让它在简单任务上花费更少。我们的 50 题数据说明了这一假设为何不成立。
当我们比较 gemini-3.8-flash 与 maxOutputTokens=300 对 gemini-3.8-flash 与 maxOutputTokens=4096 ，同时将 thinkingConfig 保持为 API 默认值时，两种配置在 Jev 标记为 SIMPLE:
注意： 数据反映的是在样本测试套件上的单次实验测量结果；实际延迟、token 数量和计费成本将因提示词长度、上下文缓存和生产负载而异。
将模型输出上限设为 300 个 token 并没有在简单任务上省下任何钱。该上限只是一个天花板，而简单答案从未接近过它。在简单任务上，设上限的版本实际上比不设上限的版本成本略高。该上限唯一的作用是让 25 道难题中的 7 道出错。其中六道题上，模型在仍在推理时就用尽了空间，从未给出答案。第七道题上，它压缩推理以适配限制，按时完成，但答案错误。
因此，一个将简单任务发送给设上限模型、将难题发送给普通 Flash 的 Jev 路由器，把 50 题全部答对。它的成本仍略高于跳过路由器、对所有任务都使用普通 Flash，而且速度更慢。如果你那个廉价选项实际上并不能让模型在简单任务上思考更少，那么任何路由器都无法为你省钱。即便是一个零成本的完美路由器也不行。
3. 在没有路由器的情况下，将 Jev 与最强配置进行基准对比
减少思考开销最直接的办法，就是让模型少思考。因此我们进行了第二轮测试，采用两个更轻量的选项：Flash-Lite（默认完全不思考）和思考等级设为低的 Gemini 3.8 Flash。我们将这些结果加入同一结果文件，并逐题匹配。
关于计时的说明。路由器每项任务的大部分时间花在 Flash-Lite 和 Flash 调用上，我们在与纯 Flash 基线相同的运行和时间窗口内测量了这些调用，因此它们之间的速度对比是公平的。Jev 自身的决策只占总时间的一小部分，且来自第一轮。与默认 Flash 或 Pro 的速度对比混合了两轮数据，因此请将其视为近似值。
注意: 数据反映的是在样本测试套件上的单次实验测量结果；实际延迟、token 数量和计费成本将因提示词长度、上下文缓存和生产负载而异。
7 桶细分展示了 gemini-3.5-flash-lite 和启发式路由器在哪些任务上出错，以及 Router Jev: Flash-Lite to 3.8 LOW 如何恢复 100% 准确率：
在没有路由器的情况下，最强配置是低思考等级的 Gemini 3.8 Flash。它解决了全部 50 道任务。这是路由器必须超越的数字。
Jev 路由器超越了它。 它先将每项任务发送给 Flash-Lite，仅将 Jev 标记为复杂的任务升级。它也解决了全部 50 道任务，并且与对所有任务都使用低思考等级相比，有助于降低成本和响应时间。在如此短的提示词上，每项任务的成本差异很小，因此对于交互式智能体而言，更短的等待时间是更大的收益。
为什么有效。 单独运行时，Flash-Lite 在半秒内回答了所有简单任务，但错过了 25 道难题中的 6 道。Jev 以高置信度将这 6 道全部标记为复杂并进行了升级。这使其成本接近完美路由器所能达到的水平。
关键词启发式更便宜, 但这只是因为它出错了。它将 5 道难题发送给 Flash-Lite，其中 2 道失败，50 道中仅答对 48 道。
升级到更重的设置在这里并不划算. 将难题路由到默认思考等级的 Flash 比在所有任务上运行默认思考更便宜。但它仍然比在所有任务上运行低思考等级更贵，而后者已经解决了全部 50 道任务。只有当低设置开始失败时，升级到更重的目标才有意义。
局限：每种配置仅运行一次，50 条提示词，难度手工分配，评分采用简单自动评分。
4. 每 token 价格并不能说明全部问题
我们的结果中有两点只有在你超越它之后才会显现。
路由和缓存的作用方向相反。 我们的测试提示词是简短的独立任务，在这些任务上 Jev 路由器有助于降低成本和响应时间。真实的编码智能体往往不同。它们每一轮都发送相同的大块上下文，例如仓库地图和工具定义。Agent Platform Context Caching 会存储该块，因此重新发送时你只需支付 75% 到 90% 更少的费用。问题在于缓存属于单个模型。如果你的智能体在 Flash-Lite 和 Flash 之间逐轮切换，它要么保留两个缓存，要么失去折扣。实际的分工是：路由简短的、自包含的任务，如日志解析或模式检查，并将长的、上下文密集的轮次保留在单一模型上。
让模型匹配工作负载。 Gemini 3.1 Pro 专为深度、多步推理而构建，并将同样的深度带入每个请求，包括不需要它的简短查询。对于主要由快速检查和提取组成的工作负载，Flash 配置更合适，而 Pro 最好留给需要其推理深度的任务。模型配置还可以对安全相关提示词应用不同的安全设置。在我们的运行中，Pro 配置拒绝了两条简短的代码安全审查提示词，而 Flash 回答了它们。如果你的智能体执行安全审查，请在你计划使用的配置上测试这些提示词。
每成功任务成本需要正确的分母
构建路由器的其他方式。 Jev 是获得快速分类器的一种方式，但不是唯一方式。 开始使用判别模型 代码实验室在 DiffusionGemma 上运行相同的 Choice、Score 和 Noul 问题，DiffusionGemma 是 Google DeepMind 的开放权重模型，托管在 Compute Engine GPU VM 上，或托管在你自己的 Google Cloud 项目中的 Cloud Run 上。一个开源服务器在其前面暴露相同的 API，因此本文中的路由代码只需要不同的端点。我们的结果来自 Jev，因此在切换之前请在你自己的任务上测量准确率和延迟，并记住自托管模型按 GPU 小时计费，而不是按 token 计费。
综合来看，这些结果给出了三条实用规则。
在构建路由器之前，先从低思考等级的 Flash 开始。 它解决了全部 50 道任务，且成本远低于默认设置。降低输出 token 上限并不能替代这一点，因为它不会减少模型在简单任务上的思考量。直接设置思考等级，使用 thinkingLevel: "LOW"。
使用 Jev 路由简短的独立任务。 将简单任务发送给 Flash-Lite，将难题发送给低思考等级的 Flash。就每个因素向 Jev 提出一个简单的 yes-or-no 问题。在我们的测试中，与对所有任务运行低思考等级的 Flash 相比，这有助于降低成本和响应时间，并接近完美路由器所能达到的水平。将长的、上下文密集的轮次保留在单一模型上，以便缓存继续有效。对于高吞吐量的仓库工作负载， Jeff Nelson 的 BigQuery 和 Cloud Run 级联模式 应用了相同的思路。
测量你的智能体实际花费。 将智能体的追踪和思考 token 计数发送到 Cloud Logging 和 BigQuery，以便你可以看到哪些任务驱动了你的支出，并捕捉导致支出膨胀的截断或重试。基准代码将在开源审查后发布。
总之，运行智能体最具成本效益的方式是将每项任务匹配到适合它的模型。 先从轻量设置下的快速模型开始。你往往会发现它已经能完成任务。然后加入一个像 Jev 这样几乎零成本的小型分类器，只把困难任务发送给更强的模型，并且提出简单的“是/否”问题，而不是一个宽泛的问题。评判每个选项时，要看它每正确完成一项任务的成本，而不是每个 token 的成本。
发布于： 上一篇 下一篇 相关文章
移动端
Web
教程
操作指南
使用 A2UI 与 CopilotKit 智能体构建生成式 UI 应用
2026 年 10 月 29 日
AI
云
教程
影响力
通过 Agents CLI 评估提升智能体质量的爬山法
2026 年 10 月 28 日
移动端
AI
操作指南
公告
借助 Google Play 服务中的 LiteRT 实现更小的应用和更快的 GPU 推理
2026 年 10 月 28 日