大多数 agent 里那些看起来不起眼的小判断，其实是整条链路里最贵的一段。要不要调用这个工具、这句话该走哪个模型、这段上下文够不够格进 prompt、这条工单算不算紧急，每一个都要单独问一次大模型，一次几百毫秒，一次几十万 token 记在账上。2026 年 11 月 11 日 Google 放出的 Gemini Decisions API 就是冲着这段开销来的：它不做生成，只对候选选项打一次分，输出 token 永远记 0，端到端 150 到 250 毫秒。
真正扎眼的不是延迟，是那张表里的一个数：Top-1 校准误差 0.0250。同一个表里，TypeSafe Jev 1.14 是 0.0494，GPT-6 Luna 是 0.0721，Gemini 3.5 Flash-Lite 是 0.2104。校准误差决定了你设的置信度阈值能不能用，它错得少一半，意味着自动化那条线可以往下挪一截。下面把这次发布拆成机制、延迟、校准、价格四块看，最后说清什么场景不该用它。
一次前向打分取代逐字解码
传统做法是把判断变成一个生成任务：写一段 prompt 问模型「这属于哪一类」，模型逐 token 解码出一个词，你的代码再把它解析回结构。这条链路里有两层浪费。第一层是解码本身，输出几个字也要算几十个 token 的生成成本。第二层是解析，模型可能多写一句解释，可能把类别名换个说法，于是你得写正则兜底，兜不住的进人工。
Gemini Decision 1 换掉了整个输出路径。它不生成答案文本，而是在一次前向传播里给候选选项打分，直接返回概率和置信度。请求体只有三段：模型 ID、一份共享输入、一张问题表。这个形状意味着返回的东西本身就是结构化的，代码拿到就能分支，不存在解析这一步。
这个变化看着只是工程细节，实际改了错误的性质。生成式方案错了，你看到的是「模型答了个别的」，需要事后判断它为什么跑偏；打分式方案错了，你拿到的是一个偏低的概率，阈值当场就能拦下来。前者靠日志追溯，后者靠代码短路，后者能写进单元测试。
代价是自由度。它只处理封闭集合的问题：候选清单是你给的，它负责排序和给分。你想让它生成一句解释、写一段总结、拼一个新答案，这套接口做不到。它被定位成 agent 内部分支调用的专用件，不是通用对话模型。
三类问题：是/否、选择、评分
官方文档把问题分成三种类型，覆盖了绝大多数分支判断。第一种是 noul，问一个是非题，返回 yes 的概率，取值被限定在 0.01 到 0.99 之间，可以附上真和假各自的描述条件。第二种是 choice，从 2 到 255 个选项里选一个，返回赢家以及每个候选的归一化概率。第三种是 score，按 2 到 255 个有序评分档打分，返回一个概率加权的连续分数，以及每一档的概率分布。
三种类型正好对应 agent 里最常见的三件事。工具选择是 choice，策略检查是 noul，上下文质量评级和结果好坏打分是 score。一次请求里可以把三种混着问，最多 1,000 个独立问题对着同一份输入。这一点比单次调用便宜更要紧：同一段对话、同一张票据、同一段录音，不用为了三个判断各传一次。
每个答案都带一个 0 到 1 的置信度，Google 在文档里给的用法很直白：置信度低的走兜底路径或者转人工。这句话背后的假设是概率可信，而概率可不可信要靠校准误差来验证，这一点后面单独说。
有一个限制必须提前知道：问题之间是并行打分的，互相看不到对方。你没法问「如果第一个条件成立，第二个条件怎么判」这种带依赖的问题。需要级联的判断只能拆成多次请求，或者在前端用代码串起来。
三类问题背后的假设也不一样，这决定了你怎么读返回的数字。noul 的回答是一个概率，适合做守门，比如这条内容要不要拦、这次调用要不要缓存。choice 的回答是一组归一化概率，适合看分布，两个选项分数接近时说明边界模糊，这时候硬选不如转人工。score 的回答是加权连续值，适合做排序和分层，把一批样本按分数排队往往比切一个硬阈值更稳。
类型选错会让整套东西白做。比如把「工单紧急程度」写成 noul，你只能得到「紧急或不紧急」的概率，丢掉了中间的梯度；写成 score 就能拿到连续分数，再按自己业务的分布切段。反过来，把一个二元开关写成 score 也没有收益，反而多解释了三个等级的含义。
150 到 250 毫秒是怎么守住的
延迟数字是两个口径：模型计算中位数 50 到 100 毫秒，端到端 150 到 250 毫秒。中间那一百多毫秒花在网络、排队和请求处理上，不是模型本身。官方说这个区间在输入不超过 16K token 时成立，并且从 1 个问题加到 100 个问题几乎不涨。
不涨的原因在线程里：问题并行打分，共享输入只做一次前填。你问 1 个还是问 100 个，输入部分的计算量是同一份。这就是为什么它适合放在 agent 的循环里，而不适合做成一次性的批处理任务。循环里每多一次判断就多一次调用，单次成本必须压到几十毫秒级，否则用户体验直接塌。
计费方式跟这个结构是对齐的。共享输入每个请求只计一次费，不管上面挂了多少个问题；每个问题只增加它自己的指令和判定条件的 token。没有思考 token 费用，没有转写费用，没有 OCR 费用。图片和视频可以调分辨率来控制视觉细节和 token 花费，这一条对多模态输入的账单影响很大。
一个容易出现误判的地方：端到端 150 到 250 毫秒是在 Google 托管的环境里测的。你自己的服务在国内、中间隔着代理、还串了一个网关做鉴权，真实延迟可能是这个数字的两三倍。评估时要按自己的链路量，不要拿官方数字当 SLA。
延迟压到这个量级之后，架构上的选择会变。原来因为怕慢，大家把多个判断合并进一次大 prompt，让模型一口气输出一大段结构化结果，再靠解析拆开。现在单次调用便宜到几十毫秒，拆成三个独立请求反而更稳：每个请求只承担一个判断，错了能单独重试，也不用担心一个大输出里某个字段坏掉整段作废。
这个拆分的收益在失败处理上最明显。合并请求失败一次，整段判断全废，必须重跑全部；拆开的请求失败一个，只需要重跑那一个，外侧的熔断和降级也好写。用几十毫秒换一份可恢复的执行图，这笔账在多数中台服务里是划算的。
校准误差 0.0250 才是真卖点
Google 自己发的对比表里放了四家：自家的 Gemini Decision 1、TypeSafe Jev 1.14、GPT-6 Luna 走 OpenAI Decisions、以及自家的 Gemini 3.5 Flash-Lite。九个基准里它拿下七个第一，JevBench 公开集 92.2% 是最高分，Amazon ESCI 的 58.7% Macro-F1 是它最低的一项。
输的两项值得单独看。Mind2Web Multimodal 上它 86.2%，输给 Jev 的 86.8%；When2Call 上它 79.9%，输给 Jev 的 82.0%，差两个百分点。When2Call 量的是「什么时候该调用工具」，这恰好是 agent 里最容易出问题的一环，在这个指标上落后，说明它在边界判断上还不是最强。
真正的差距在最后一行：Top-1 校准误差 0.0250，Jev 是 0.0494，Luna 是 0.0721，Flash-Lite 是 0.2104。校准误差衡量的是「模型说七成把握时，实际是不是七成对」。这个指标直接决定阈值能不能用：误差大的模型说 0.8，你可能得按 0.5 来理解，阈值就成了玄学；误差小的模型说 0.8，你可以相信它。
Flash-Lite 那个 0.2104 特别说明问题。它是个通用小模型，准确率不算差，但校准误差是 Gemini Decision 1 的八倍多。用通用模型做分类，你得到的是「大概对」的标签；用专用决策模型，你得到的是一个可以写进 if 语句的数值。这两种东西在工程上不是一回事。
| 基准 | Gemini Decision 1 | TypeSafe Jev 1.14 | GPT-6 Luna | Gemini 3.5 Flash-Lite |
|---|---|---|---|---|
| JevBench 公开集 | 92.2% | 90.0% | 90.9% | 86.6% |
| Amazon ESCI Macro-F1 | 58.7% | 56.7% | 54.7% | 47.2% |
| New Yorker Caption | 79.7% | 72.0% | 68.4% | 73.7% |
| Mind2Web Multimodal | 86.2% | 86.8% | 81.8% | 78.0% |
| PubMedQA | 79.8% | 78.2% | 74.4% | 77.6% |
| Global-MMLU-Lite 非英语 | 86.0% | 85.0% | 79.6% | 78.8% |
| When2Call | 79.9% | 82.0% | 70.4% | 60.9% |
| Top-1 校准误差，越低越好 | 0.0250 | 0.0494 | 0.0721 | 0.2104 |
这张表全部是 Google 自报数据，拒绝回答和安全拦截都算错。看这种表的第一条纪律是记住出处：自报意味着自家模型在自家选的基准上表现最好，属于正常现象，不能当成独立第三方结论。真要决策，得在自己的数据上跑一遍。
还有一个隐藏信息在表格的空白处。MMAU 音频和 Video-MME 这两项，TypeSafe Jev 和 GPT-6 Luna 都是未报告。这不是谁藏着掖着，是两家没有对应的多模态能力覆盖，或者没测。一张对比表里出现大面积空白，说明这轮竞争的维度已经分叉：一边是纯文本判断的精度，一边是多模态的覆盖面，选型时得先确认自己到底需要哪一种。
价格表要按七个评测一起算
单价是每百万输入 token 0.10 美元，输出 token 计费为零。这个数字很便宜，但便宜不是它的强项。同一个表里，七个共有评测的总花费是 Gemini Decision 1 花 0.88 美元，TypeSafe Jev 1.14 花 0.68 美元，GPT-6 Luna 花 0.93 美元，Flash-Lite 花 4.14 美元。它比 Jev 贵三成，只是比通用小模型便宜四倍多。
所以正确的比较不是「谁最便宜」，而是「在什么结构下谁更省」。它的计费把共享输入和问题分开：一次请求传一段两万 token 的对话，上面挂二十个判断，输入只算一次钱。如果你的场景是「同一份大材料上问很多小问题」，这个结构非常划算；如果你的场景是「每个小问题配一份小材料」，省下来的部分有限。
反过来，Jev 在七个评测上总价更低，说明它的计费结构在另一类负载上更优。这两家的差别不在绝对价格，在计费模型和你能接受的部署形态。Jev 对外提供的是独立决策模型服务，Gemini Decision 1 只能跑在 Google 托管上，没有开源权重，不能自托管。
自托管这条限制在合规场景里是硬门槛。数据不能出境的业务，托管 API 直接出局，再便宜也用不了。这一点必须在选型表里单独列一行，不能混在性能和价格里比。
算账时还要把「省下的通用模型调用」算进去。原来一个判断走一次通用模型，输入输出两头都计费，还得算上解析失败重试的那部分。换成决策接口之后，输入按一份共享计费、输出永远为零，重试的代价也跟着降。真实节省往往不在单价对比上，在于链路里那些原本被默默计费的失败重试。
但别把这张账算成必然盈利。如果你的判断量本来就小，一天几万次调用，单价的差别摊到月账单上是几十美元，为它改架构的人力成本远超省下的钱。这类接口的价值在调用量大的中台服务里才显出来，量小时它只是一个更优雅的写法。
把置信度接进分支要写的代码
请求体的三段结构在文档里写得很清楚，字段名和三种问题类型都是公开的。下面这段是请求的形状，模型 ID、共享输入、问题表三样东西，问题表里三种类型各放一个。
request = {
"model": "gemini-decision-1",
"input": {"text": "用户反馈：退款申请提交三天了，订单状态还停在处理中。"},
"questions": {
"need_human": {"type": "noul", "question": "这件事是否需要人工客服接手"},
"intent": {"type": "choice", "options": ["咨询", "投诉", "退款", "其他"]},
"urgency": {"type": "score", "levels": 4, "question": "用户情绪的激烈程度"}
}
}
拿到答案之后，真正需要写的是分档逻辑。三种类型回来都是概率，代码要做的是把概率变成动作，这里的关键是阈值必须显式写出来，不要藏在默认值里。
def route(answers, low=0.35, high=0.75):
plan = {}
for name, ans in answers.items():
p = ans["confidence"]
if p >= high:
plan[name] = "accept"
elif p <= low:
plan[name] = "reject"
else:
plan[name] = "escalate"
return plan
这两个阈值不是拍脑袋定的，要靠自己的历史数据回放来定。拿一批已经有人工结论的样本跑一遍，画出置信度分布，看接受区间的准确率和拒绝区间的准确率分别落在哪，再决定线画在哪。校准误差小的模型，这一步会好做很多，因为分布的形状跟真实正确率是对得上的。
落地上还有一个细节容易被忽略：转人工这条路径要预留容量。置信度低的样本比例不取决于模型，取决于你的业务有多少真正的灰色地带。先量清楚这部分占比，再决定是否上线，别等灰度之后才发现三成请求都进了人工队列。
分档逻辑还应该带埋点。接受、拒绝、升级三条路径各自的比例，加上每一档的实际正确率，是后面调阈值的唯一依据。没有这组数据，阈值就永远是凭感觉设的，模型升级之后也没法判断是不是真的变好了。埋点这件事必须在第一版就做进去，后补的代价是历史数据缺一段。
什么时候不该用它
第一种不该用的情况是任务本身要生成内容。它不输出文本，只会打分。需要模型写答复、写摘要、写解释的场景，它帮不上忙，硬套只会让你多写一层拼接逻辑。
第二种是边界特别模糊的判断。它自己在 When2Call 上就输给 Jev 两个百分点，说明「该不该调用工具」这类判断还没到碾压级。如果你的业务全压在这一类判断上，先做 A/B，别直接换。
第三种是数据不能出托管云的场景。它只能跑在 Google 的 API 上，没有权重，没有私有部署，这一条写死在产品形态里，不是配置能解决的。
第四种是需要问题之间互相依赖的判断。同一请求里的问题并行打分，彼此看不见。链式推理、多步条件、需要中间结果支撑下一步的场景，只能拆成多次请求，或者交给通用模型做。
把这四条和自己的能力盘点对一遍，结论通常很清楚：如果你的 agent 里有大量「给几个选项选一个」「是或否」「打个等级」的小调用，而且这些调用现在都在用通用模型硬扛，那这次发布正好对症。如果你的调用大多是开放生成，那就继续用通用模型，别为了省几百毫秒把架构改复杂。
落地路径上建议先做一件很小的事：把现有链路里所有「判断类」调用列出来，按三类打标。标完之后你会发现，真正需要生成的调用可能只占少数，剩下的都是选择题。这份清单本身就是收益评估的起点，也是后续接任何一个决策模型的对照物。
最后提醒一句关于数字的纪律。这篇文章里的准确率、延迟、价格全部来自 Google 官方博客和它公开的基准表，这些数字在别人的业务上不一定成立。选型时唯一可信的验证是在自己的数据上跑回放，看校准误差和业务准确率，而不是拿榜单名次当结论。榜单说明它是个正经产品，回放说明它适不适合你。
