用低成本分类器优化编码代理模型开销

Agent 的单 token 价格降了，账单却未必跟着降。Google Developers Blog 这篇实验文章把问题落到了「每个成功任务花多少钱」：模型选错、推理过度、输出截断和重试，都可能吃掉价格下降带来的收益。

作者用 50 道编程任务测试了一条路线：让轻量分类器 Jev 判断任务是否需要多步推理，再选择 Gemini 模型和 thinking level。结论有先后顺序：先试 Flash 的低思考配置，再判断路由是否值得加。

路由要判断具体能力，别笼统地问难不难

作者最初让 Jev 在 simple 和 complex 之间二选一，结果几乎全被分到 simple，连 LRU 缓存状态追踪和模幂运算也没分出去。

问题出在分类标准。「复杂吗」混合了知识量、计算步骤、代码长度等因素，分类器很难稳定执行。作者随后改成一个原子判断：回答是否需要连续进行超过一次计算、模拟或逻辑推导。

Jev 是结构化输出分类器，一次前向计算可以完成 Choice 选项判断、Score 数值评分，或用 Noul 返回二元命题成立的 0 到 1 概率。它适合回答一个边界清楚的问题，而不是代替工程师定义「复杂」。

下面这段请求把分类标准收敛为「是否需要多步推理」：

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.

要看的是 instructions 中的判断边界，以及注释里的概率读取位置。代码没有给出实际请求、升级阈值和完整路由实现，不能直接作为可运行方案。

在最初 16 道题上，Jev 两次分别与人工难度标签一致 13 道、14 道。作者又拿关键词加长度规则作比较：命中 sequence、modulo、race condition，或超过 35 个词，就升级模型。规则在开发集上达到 15/16，即 93.8%。

冻结规则后，作者加入 34 道未见任务，覆盖信息提取、schema 校验、短分类、单步代码检查、状态模拟、数学或逻辑链、语言语义陷阱七类。规则准确率跌到 70.6%，下降 23.2 个百分点；Jev 在这部分达到 34/34，整套达到 48/50，即 96.0%。

原因很直观：长 Kubernetes YAML 里提取一个端口，可能只需查找；很短的 Python 可变默认参数代码，却可能需要追踪多次调用。输入长度和推理步骤不是一回事。

省钱应该调思考级别，不能只卡输出长度

作者对 gemini-3.8-flash 比较了 maxOutputTokens=300 和 maxOutputTokens=4096，两组都保留默认 thinkingConfig。

简单任务上的 thinking tokens 几乎一样。答案本来就很短，降低上限没有减少推理消耗，300 上限版本的费用反而略高。难题却受到了影响：25 道难题中失败 7 道，其中 6 道在推理期间耗尽额度，没有输出答案；另 1 道完成了输出，但答错了。

输出上限是容量限制，思考级别才是这里真正需要调整的配置。

把简单题送到受限版本、难题送到普通 Flash，虽然答对了全部 50 道，仍比全部使用普通 Flash 略贵，而且更慢。便宜分支没有真正便宜，分类再准也救不了成本。

第二轮实验换了两个候选：默认不进行思考的 gemini-3.5-flash-lite，以及设置低思考级别的 Gemini 3.8 Flash。后者独立答对全部 50 道，成为路由必须超过的基线。原文建议直接设置 thinkingLevel: "LOW"，不要用输出限额代替。

这一步很容易被忽略：团队忙着设计分类器时，可能还没试过降低现有模型的思考级别。

短任务适合分流，长上下文可能越切越贵

在作者的任务集里，Flash-Lite 对简单题都答对了，单题耗时约半秒，但在 25 道难题里错了 6 道。Jev 把这 6 道全部识别为复杂任务，再升级到 Flash LOW，最终整条路线答对 50/50。

相较于全部使用 Flash LOW，这个组合降低了成本和响应时间。不过，输入短，每题费用差距很小；对交互式 Agent，少等一会儿可能更有价值。关键词路由虽然更便宜，却把 5 道难题送到了 Flash-Lite，其中 2 道失败，最终只有 48/50。

难题升级到默认思考级别的 Flash，也没有胜过全量 Flash LOW 的成本表现。只有 LOW 开始解决不了任务，升级更重配置才有依据。

长上下文则要另算。真实编程 Agent 经常重复携带仓库地图和工具定义。原文称 Agent Platform Context Caching 能让重复发送部分节省 75% 到 90%，但缓存归属于具体模型。在 Flash-Lite 和 Flash 间切换，需要维护两份缓存，或者失去已有折扣。因此，独立日志解析、schema 检查适合路由；依赖大量仓库上下文的连续回合，更适合先固定模型。

模型选择还要看任务类型。作者认为 Gemini 3.1 Pro 更适合深度推理；实验中的 Pro 配置拒绝了两条简短代码安全审查请求，Flash 则作出了回答。这不能推导出谁更安全，只能说明实际配置的拒答行为也必须测。

我的判断

我认同这篇最有价值的顺序：先找出能稳定完成任务的轻配置，再考虑分类路由。对多数团队，调低 thinking level 的实施成本，通常比维护分类服务、升级策略和监控链路更容易控制。

但这是一组经验性实验，还不足以证明 Jev 在真实编码流量中普遍领先。每种配置只运行一次，样本只有 50 道，难度人工标注，验收采用简单自动评分。分类标签一致率也不等于最终任务成功率，Jev 全套分类为 96.0%，路由仍可能达到 100%，因为分错类别未必导致答错。

原文还存在口径疑点：一处写 Jev 标为 SIMPLE 的任务有 27 道，另一处写难题有 25 道；如果前者是预测标签、后者是人工标签，可以并存，但原文没有清楚对齐。速度比较也分两轮，涉及默认 Flash 或 Pro 的结果只能近似看待。

此外，提供的正文没有具体费用、延迟表，也没有完整路由代码。我们无法据此计算业务节省比例，更不能把「接近理想路由」直接当成生产承诺。

Jev 也不是唯一选项。Google 明确说明与 TypeSafe 没有合作，这篇不构成产品背书。原文提到，可在 Compute Engine GPU VM 或 Cloud Run 上部署 DiffusionGemma，通过开源服务提供相同的 Choice、Score、Noul API。只是自托管按 GPU 小时计费，需要重新计算利用率和维护成本，不能沿用 API 调用的账本。

能拿来做什么

• 先为现有 AI 编程任务建立 Flash LOW 基线，直接设置 thinkingLevel: "LOW"，记录验收通过率、费用和耗时，再决定是否增加路由。
• 从独立日志解析、配置字段提取、schema 校验开始试分流，用「是否需要连续多步推导」这样的单一判断建立分类器，并用未参与规则设计的新任务验证。
• 对携带仓库地图和工具定义的连续编码回合，先核算单模型缓存收益，再评估跨模型切换；安全审查任务还要单独检查目标配置的拒答表现。
• 把调用轨迹和 thinking-token 数量送到 Cloud Logging、BigQuery，按「总支出 ÷ 验收成功任务数」统计成本，同时检查截断和重试。失败任务产生的费用也必须进入分子。