在 Agent 系统里，高频的往往不是长文生成，而是细碎判断：是否调用工具、选择哪条模型链路、上下文是否符合要求、工单是否紧急。Google 推出的 Gemini Decisions API 将这类任务从生成式调用中拆出：它不生成答案文本，只对给定候选项进行一次前向打分，返回概率和置信度。官方数据显示，其输出 token 计费为 0，端到端延迟为 150 到 250 毫秒，Top-1 校准误差为 0.0250。
小判断不再逐字生成
过去，开发者通常把判断写成提示词，让模型输出类别，再由代码解析。这会产生输出 token，也可能因模型补充说明或改写导致解析失败。Gemini Decisions API 的请求包含模型 ID、共享输入和问题表，返回结构化概率，代码可直接用于分支。
- noul：是非题，返回 yes 概率，取值限定在 0.01 到 0.99，可为真、假分别描述条件。
- choice：从 2 到 255 个选项中选择，返回胜出项及每个候选的归一化概率。
- score：按 2 到 255 个有序评分档打分，返回概率加权连续分数和各档概率分布。
一次请求可针对同一份输入混合提出最多 1,000 个问题，适合同一段对话、票据或录音上的多个判断。限制是问题并行打分、彼此不可见，不能表达依赖关系；该接口也只处理封闭候选，不生成解释或总结。
延迟与计费围绕共享输入重构
官方给出的延迟分为两层：模型计算中位数为 50 到 100 毫秒，端到端为 150 到 250 毫秒；该区间适用于输入不超过 16K token 的情况，从 1 个问题增加到 100 个问题几乎不增加延迟。原因在于多个问题共享同一份输入，只做一次前向处理。
计费也遵循这一结构。输入价格为每百万输入 token 0.10 美元，输出 token 计费为 0。共享输入每个请求只计一次费用，后续问题只增加其指令和判定条件对应的 token。官方还提到没有思考 token 费用、转写费用和 OCR 费用；图片和视频可通过调整分辨率控制视觉细节和 token 花费。
这类数字对架构的影响不止是账单。此前为了避免多次调用过慢，开发者可能把多个判断合并进一个大提示词，再解析长输出。若单次判断延迟和成本被压低，拆分请求反而更利于失败重试、熔断和降级。不过，官方端到端数字来自 Google 托管环境，若企业链路包含代理、网关和鉴权，实际延迟可能更高，选型时需按自身链路测量。
校准误差决定阈值可信度
相比延迟，更关键的是校准误差。它衡量模型给出的置信度是否与真实正确率一致。若模型称有 0.8 把握，实际也应接近八成正确，阈值才有工程意义；反之，阈值只能靠经验猜测。
Google 公布的对比表中，Gemini Decision 1 的 Top-1 校准误差为 0.0250；同一表格里，TypeSafe Jev 1.14 为 0.0494，GPT-6 Luna 为 0.0721，Gemini 3.5 Flash-Lite 为 0.2104。校准误差越小，置信度越适合直接驱动自动化规则。
在九个基准测试中，Gemini Decision 1 获得七个第一。JevBench 公开集得分为 92.2%，为最高；Amazon ESCI 得分为 58.7% Macro-F1，为最低。未拿第一的项目包括 Mind2Web Multimodal：86.2%，低于 TypeSafe Jev 1.14 的 86.8%；When2Call 得分为 79.9%，低于 TypeSafe Jev 1.14 的 82.0%。When2Call 衡量“什么时候该调用工具”，正是 Agent 分支判断中的难点。
这些数字来自 Google 自报，且拒绝回答和安全拦截都算错，不能作为独立第三方结论。表格中 MMAU 音频和 Video-MME 两项，TypeSafe Jev 和 GPT-6 Luna 未报告，也说明不同模型的能力覆盖并不一致。实际落地前，仍需在自有数据上复测。
适用边界与落地检查
从价格和形态看，Gemini Decisions API 并非单纯追求最低单价。其输入价格为每百万输入 token 0.10 美元，输出 token 计费为 0；在七个共有评测的总花费为 0.88 美元，TypeSafe Jev 1.14 为 0.68 美元，GPT-6 Luna 为 0.93 美元，Gemini 3.5 Flash-Lite 为 4.14 美元。若同一份大输入需要挂多个小判断，共享输入只计一次费的结构更友好；若每个问题都对应一份小材料，优势有限。
该产品只提供托管 API，没有开源权重，不能自托管；数据不能出境或对私有部署有硬性要求的业务需要提前排除。它适合“是或否”“多选一”“分级打分”等封闭问题，不适合需要生成答复、摘要、解释的任务，也不适合问题之间存在依赖、需要链式推理的场景。
对开发者而言，更实际的做法是先盘点现有 Agent 链路：把判断类调用按 noul、choice、score 分类，统计调用量、失败重试和人工兜底比例，再决定是否迁移。若迁移上线，阈值应显式写入代码，用历史样本回放确定接受、拒绝和转人工的边界，并埋点记录各路径比例和实际正确率。
这次发布显示，Agent 基础设施正在从通用模型包办输出，转向生成与决策分工。对高频中台服务，这可能改变成本和运维结构；对调用量小或开放生成为主的团队，它更接近可选工程工具，而非必须更换的底座。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/dang-agent-zhi-xu-zuo-xuan-ze-ti-gemini-decisions-api-ba
