Google DeepMind 发了个新端点，叫 Gemini Decisions API。底层模型是 gemini-decision-1。它做的事很专一：一次请求塞进一堆问题，模型在单次前向里直接把每个问题的分打出来，返回 0 到 1 的置信度。这件事值得写，是因为它把 agent 里最常见的一类动作，判断和打分，单独抽成了一个原语。这篇里的数字，我从 blog.google 的发布文章里一个个核过，出处标在正文里。

三种题型

先拆它的核心能力。它支持三种题型，官方分别叫 noul、choice、score。

noul 是 yes/no 判断估算条件成立概率，choice 是从 2 到 255 个候选项里挑一个返回归一化概率，score 是按有序量表打分返回连续加权分数，三种题型能在一次请求里混着用共享同一份输入，每个答案都带一个 0 到 1 的置信度。它跟生成模型最本质的区别就在这里，生成模型要逐 token 解码出一段文字再解析答案，它不做解码，直接在一次前向里对所有候选项打分。

我核对数字的过程是这样。先抓了 blog.google 那篇发布文章全文，把 256K、1000、2 到 255 这几个数一个个抄下来，回官方文档对。对到 50 到 100 毫秒这一条，我又确认了一遍它是模型计算延迟，不是端到端。端到端是 150 到 250 毫秒，官方文档写的。这两个数容易混，我分开记了。

from google import genai

client = genai.Client(http_options={"api_version": "v1beta"})

result = client.decisions.create(
    model="gemini-decision-1",
    input=[
        {"type": "image", "uri": "https://storage.googleapis.com/generativeai-downloads/images/spill.jpg",
         "mime_type": "image/jpeg"},
        {"type": "text", "text": "Breakroom counter check before the 9 AM client meeting."},
    ],
    questions={
        "has_spill": {"type": "noul",
                      "instructions": "Is there an uncleaned liquid spill on the counter?"},
        "next_action": {"type": "choice",
                        "instructions": "Which cleanup action fits the scene?",
                        "criteria": {"wipe_with_cloth": "Small counter spill with a cloth nearby."}},
        "severity": {"type": "score",
                     "instructions": "Rate the severity of the counter mess.",
                     "criteria": ["Clean and ready.", "Minor localized spill.", "Major spill."]},
    },
)

这段代码的结构我照原文，变量名和 criteria 内容自己缩了。它演示的是一次请求同时问三种题型，输入是一张图加一句话。

为什么快又便宜

它跟普通生成模型的差别，在机制上。普通模型是逐 token 解码，生成一段文字再解析。gemini-decision-1 不做逐 token 解码，它在单次前向里直接对候选项打分。所以从 1 个问题到 100 个问题，延迟几乎不变。原文原话是 nearly flat。

延迟数字是这样的。模型计算中位 50 到 100 毫秒，端到端 150 到 250 毫秒。这俩是原文白纸黑字写的，不是我测的。输入上限 256K tokens，多模态，文本图像音频视频 PDF 都能进。计费更干脆，输入 token 是 0.10 美元每 1M，输出 token 计费为 0，因为没有输出 token。官方还给了个对比，比 Gemini 3.5 Flash-Lite 加 Interactions API 的组合便宜近 5 倍。这个 5 倍也是官方口径，不是我算的。

我的判断是，这套机制决定了它的适用面。它适合有界决策：工具选择、策略检查、模型路由、上下文打分、把模糊 case 导给人工兜底。不适合自由生成的场景，因为它根本不生成内容。

对 agent 路由意味着什么

这篇文章最有信息量的部分，是 Google 自己怎么用它。我把它当一手证据读。

我把这四个用例从官方文章一段段抄下来，一个字没改。Gemini Notebook 用它做动态模型路由，把查询实时导到最优的模型层级和思考档，日常查询延迟最高降了 40%。Stitch 这个画布实验用它在几秒内生成可播放的线框图。CC 从 200 多个表情符号里选合适的 emoji 反应。Google Search 拿它做 MCP 工具的安全层，在延迟范围内检测对抗行为和内容。这四个用例，都是官方写的。

这四个用例指向同一个方向。决策这件事，正在从让大模型生成一段话再解析，变成让一个专门的小模型直接打分。前者贵、慢、还得处理解析失败。后者便宜、快、天然输出结构化结果。

这个转向有个前提值得说破。打分模型能替代生成模型，前提是你的决策空间是有界的，候选就那几项，判定的标准也能写成描述。一旦决策空间开放、标准说不清，还是得回到生成模型去。所以它抢的是路由、分类、合规检查这类窄决策的活，不是所有 agent 动作的活。这个分界很硬。别越界。

它已经在 OpenRouter、LangChain、Vercel、LiteLLM、Pydantic AI、Pipecat、LiveKit、OpenCode 这些地方上线。这意味着你未必直接调 Google 的端点，你常用的框架里可能已经能勾到它。这几个名字我照原文抄的。

给个判断

给结论。你的 agent 里有大量判断和打分，比如路由到哪个模型、这条请求该不该放行、结果要不要导人工，那这个端点值得看，它把这类动作的成本压到了生成模型的一个零头。你的 agent 就是一路生成到底，不做什么路由和分类，那它对你是过度设计，别硬上。

一句话。Gemini Decisions API 的意义不在于又多了个模型，在于它承认了一件事：不是所有决策都值得花一次完整生成。把判断抽出来单独定价，本身就是个信号。