Google DeepMind推出Gemini Decision 1及专用Decisions API，试图把Agent系统中大量“该调用哪个工具”“是否符合政策”“应分给哪类模型”“风险有多高”等封闭式判断，从通用生成模型中拆出来。开发者可以一次提交最多25.6万Token的文本、图片、音频、视频或PDF，并围绕同一份材料提出最多1000个相互独立的问题；模型不逐字生成解释，而是在一次前向计算中直接为候选项给出概率和置信度。Google公布的典型端到端延迟为150至250毫秒，价格为每百万输入Token 0.10美元、输出免费。不过，这些延迟数据主要来自不超过1.6万Token、最多100个问题的测试，并不证明满上下文、1000问时仍能保持相同速度；独立评测也把它排在18款决策模型中的第9位，说明它的校准和多模态能力突出，但并非所有决策任务的综合冠军。
文章作者、来源：Google DeepMind
Agent不必用“写作文”的方式作每一次判断
目前许多Agent即使只需要回答“是或否”，也会调用完整的生成模型。模型需要读取上下文、推理并逐Token输出文字，应用随后再从答案中解析一个布尔值或类别。
这种方式灵活，但在高频工作流中很浪费。一个客服Agent可能需要依次判断用户意图、账户风险、适用政策、工具权限、升级队列和回复模型；每一步都调用生成模型，会累积延迟、费用及格式解析错误。
Gemini Decision 1采用不同思路：开发者先定义有限的候选答案，模型只负责给这些选项评分。它不是聊天模型，也不会起草解释，更接近一个能够理解长上下文和多模态信息的通用分类、排序与策略判断层。
Google提供三种问题形式：
- “是／否”判断，返回条件成立的概率；
- 从2至255个选项中选择，并返回每个选项的归一化概率；
- 按预先定义的有序量表评分，同时返回各等级概率和加权分数。
每个结果还带有0至1之间的置信度。应用可以设定阈值：置信度高时自动执行，置信度不足时转给更强模型或人工审核。blog.google
一份材料可以同时接受1000项检查
一次请求最多可以包含25.6万Token，并针对同一份输入提出1000个独立问题。
例如，保险公司可以同时提交一份扫描索赔表、现场损坏照片、客户通话录音和账户资料，然后要求模型判断材料是否齐全、属于哪类事故、是否存在欺诈信号、应该分配给哪个队列，以及需要多紧急地处理。
共享材料只计费一次，各问题只额外增加自身的指令和候选项Token。因此，当几十项检查都要读取同一份长文件时，它会比把文件重复发送几十次更经济。官方定价为每百万输入Token 0.10美元，不收取输出Token费用，也没有单独的OCR或音频转写费。
但这1000个问题必须彼此独立。模型不会让第二个判断读取第一个判断的结果。如果工作流是“先判断文档类型，再根据类型采用不同审核规则”，开发者仍需在代码中连接两步，或再次调用API。需要生成说明文字、提取任意字段或撰写回复时，也仍然需要生成或信息抽取模型。
150至250毫秒有明确的适用边界
Gemini Decision 1跳过逐Token解码，直接在一次前向计算中为全部候选项评分。Google称，模型计算的中位耗时为50至100毫秒，包含服务和网络环节后的端到端延迟约为150至250毫秒。
官方测试显示，在不超过1.6万Token的多模态输入上，把单次请求从1个问题增加到100个，延迟基本保持平坦。相同基准中，其成本据称比通过Interactions API调用Gemini 3.5 Flash-Lite低近五倍。
这些数字不能直接外推到所有情况。模型虽然允许25.6万Token和1000个问题，但Google没有证明同时用满两项上限仍能在250毫秒内完成；大型视频、音频和PDF的上传时间也不包含在模型计算时间里。实际部署必须使用自己的文件长度、问题数量和网络位置重新测量。
多模态是它相对于传统分类器的主要差异
传统分类器通常面向一种预先固定的数据格式，而Gemini Decision 1能够在同一请求中共同读取文字、图片、音频、视频和PDF。
官方示例向模型提交了一张茶水间台面的照片和一句文字说明，同时询问三件事：是否存在未清理的液体、应当擦拭还是叫保洁、现场严重程度如何。模型判断存在少量泼洒，建议用布擦拭，并给出各选项概率。
开发者还可以降低图片或视频分辨率，以牺牲部分细节来减少Token和费用。对于理赔、内容审核、商品检查或视频事件识别，这比先分别运行OCR、语音识别、视觉模型和规则引擎更容易搭建；但统一模型也意味着，一旦其对视觉或语音内容理解错误，多个后续判断可能同时受到影响。
官方基准领先，不代表综合评测第一
Google称Gemini Decision 1在路由、推理、排序和多模态理解基准中表现领先，并取得最低的校准误差。其官方比较中，模型在JevBench达到92.2%，高于GPT‑6 Luna的90.9%和Jev 1.14的90.0%；校准误差为0.0250，约为Jev的0.0494的一半。
但它没有包揽所有任务。Jev在浏览器任务决策Mind2Web Multimodal中以86.8%略高于Gemini的86.2%，在判断何时调用工具的When2Call上也以82.0%领先Gemini的79.9%。
独立的Artificial Analysis Decision Index v2.1给Gemini Decision 1约66分，在18款决策模型中排第9。它在知识与推理类项目中排名第一，却在需要同时正确理解整份简历、发票、收据或论文的AA‑Paperclip测试中，只有33%的文档能够做到全部问题均答对；Drex Max v1.1为63%。在独立When2Call测试中，它也落后于Drex Max和Jev。
这说明“置信度校准好”和“每项判断都最准确”不是同一件事。校准良好的模型更清楚自己何时可能出错，有利于设置人工复核阈值；但如果应用错误地把高置信度当成事实保证，仍然可能自动执行错误决定。
Google先把它部署成内部产品的控制层
Google已经在多个产品中使用这套API。Gemini Notebook用它判断查询应当交给哪个模型及何种思考强度，官方称普通查询延迟最多降低40%；Stitch用它快速响应语音或点击产生的设计修改；Google Labs的CC从200多个表情中选择反应；Google Search则将它放在MCP工具调用之前，检测对抗行为和危险内容。
这些案例揭示了其真正定位：它不是用户最终看到的智能，而是位于Agent背后的控制平面。生成模型负责写代码、组织语言和解决开放问题；决策模型负责决定下一步调用什么、是否允许调用、需要多强的模型，以及何时应当停止自动化并交给人。
这种分工可能比单纯扩大通用模型更适合大规模Agent系统，因为大量日常步骤并不需要“更会写”，只需要足够快、便宜并且概率可信地选对分支。
Gemini Decision 1目前通过Gemini Developer API的`v1beta`端点提供，Google Cloud支持仍标为“即将推出”。Google尚未公开参数量、训练数据、训练算力、具体架构或完整系统卡，因此无法判断它是否由现有Gemini模型蒸馏而来，也无法独立验证训练层面的安全与数据声明。