一次判断不到一分钱：OpenAI 把「决策」拆成独立接口，智能体的成本账要重算

一个智能体审一张报销单，要做的事其实很碎：判断发票是不是增值税专用发票、金额有没有超过部门标准、供应商在不在白名单、附件清不清楚、要不要转人工。单拎出来每一件都简单，但一次任务里可能连着做几十次。

过去的做法是每个判断都调一次通用对话模型，让它「说说看」，再从一段话里把结论抠出来。模型要生成完整句子，应用还要解析，延迟和费用都堆在这一步。任务越长，堆得越高。

OpenAI 在 10 月 22 日把这一步单独拆了出来。Decisions API 只要一个结论，不要一段解释：开发者定义问题与允许的答案，接口返回概率、选项或评分。官方把它叫「有界答案」——问题有明确范围，模型的活儿是选，不是写。

这个变化听起来像产品细化，实际是成本结构的变化。当判断从「生成」变成「选择」，token 花在哪里、延迟卡在哪里、钱算在谁头上，全都不一样了。

把镜头拉远一点看：一个客服智能体处理一通电话，真正需要「说人话」的只有开头和结尾两句，中间是十几轮「要不要转人工、要不要查订单、要不要升级投诉」的判断。过去的架构里，这些判断和回答共用一个接口、一套计价，谁也说不清钱花在哪。拆开之后，账才算得清。

predicate 回答「是不是」。给一个条件，比如「这张照片里商品有没有明显破损」，返回 0 到 1 的概率。它适合一切是非题：这张单据是不是重复提交、这段评论是不是在投诉、这个客户是不是高风险。

choice 回答「是哪一类」。开发者把选项列好——售前、售后、投诉、财务——模型返回其中一个，并附上各选项的概率与整体置信度。工单路由、下一步动作、转不转人工，都属于这一类。

score 回答「有多严重」。给一组有序等级，2 到 10 级，返回按概率加权的平均分。结果是连续值，可能落在两级之间，正好对应「介于轻微与中度之间」这种真实判断。

三种类型的共同点，是把解释从返回值里拿掉了。代价是模型不再告诉你为什么这么判，收益是应用不用再解析自然语言。对工程来说，这是一个很实在的交换：少一层解析，就少一类线上事故。

这三类也基本覆盖了企业里 90% 的「看一眼就该有结论」的动作。真正需要长篇推理的，是少数；绝大多数流程卡住的地方，是没人愿意一遍遍做那些一眼就能判断的小事。

标准价是每百万输入 token 0.10 美元，缓存读取 0.01 美元，输出不计费。对比走 Responses API 调同一颗 GPT-6 Luna，省掉的主要是生成那段解释的 token。

算一笔小账。一次工单分类大约 800 个输入 token，按标准价约 0.00008 美元，折人民币不到一厘；一天 5000 张工单，一个月大约十几块钱。缓存命中时还能再低一个数量级。

但别把这笔账算成「免费」。输入仍然计费，长上下文、图片、一次 400 个问题都会把输入放大；判断完如果要生成回复，那次生成照旧按生成模型计价。省钱的边界很清楚：只省「不需要说人话」的那部分。

真正值得注意的是计费方式带来的设计变化。当输出不收费，开发者就不会再为了省 token 去压缩提示、砍上下文；相反，为了让判断更准，会愿意多给材料。这种激励方向，和过去「能少说就少说」的优化习惯正好相反。

公测时单次请求上限 200 个问题，正式版提到 400。这个数字对批量场景很关键：一次门店质检要核 400 条规则，过去要发 400 次请求，现在一次就能拿回 400 个结论。

配合提示缓存，规则说明只写一次、后续复用，新增的只有当次内容。对「同一套标准、每天评几千条」的业务，这几乎是量身定做的结构——检查表越长，均摊到每条的成本越低。

原生 JSON 输入也很实用。订单、表单、检测记录本来就是结构化的，不必先拼成一段中文再喂进去；少一次转换，就少一处口径偏差，也少一类「模型把字段读串了」的故障。

还有一个容易被低估的能力：图片可以直接写进问题里。门店巡检拍的照片、仓库的堆头、施工的隐蔽工程，都能作为判断依据，而不是先由人描述一遍再交给模型——描述这一步，往往才是误差的来源。

批量判断也有代价。400 个问题共用一份上下文，意味着它们会互相「看见」；如果问题之间存在逻辑依赖，比如后一问要基于前一问的结论，就不适合塞进同一次请求。把它当成并行的、彼此独立的检查项，而不是一条推理链，是用对它的前提。

Box 用它在 30 个保险凭证案例上做路由，官方口径是约快 5 倍、准确率与 Responses API 持平，低置信度的仍然转人工。这个组合最有参考价值：快，但不牺牲准确率，靠的是把不确定的挑出来给人。

Datadog 用它给智能体生成的 shell 命令打风险分，p95 延迟快 40 倍。注意是 p95 而不是均值——长尾也被压下来，才敢把它放进「执行前必须过一遍」的热路径。

Sierra 在客服编排里选下一步动作，p95 低于 280 毫秒，单次成本降约九成；Speak 在实时语音里把「下一动作」的时间从 1.4 秒压到 0.13 秒。到了这个量级，产品形态会变：边说话边判断、边输入边校验、边扫描边分拣，才真正成立。

需要提醒的是，这些都是厂商自述、场景各异，不能直接套到自己业务上。但方向是一致的：判断被拆成独立接口后，延迟的单位从「秒」变成「百毫秒」，很多过去只能人等机器的环节，可以反过来。

这也解释了为什么案例集中在客服、安全与开发工具三个领域：它们的共同点是「每一步都要判断，但不需要每次都解释」。凡是符合这个特征的业务，都值得重新算一遍延迟与成本。

只支持 GPT-6 Luna 一颗模型，意味着没有多模型比价的空间；答案类型只有三种，开放式分析、长文写作、多步推理都不在范围内。它是一个窄接口，不是一个更快的万能接口。

更关键的是前提：有界答案要求「你先把选项定义好」。工单该分几类、风险分几档、什么算需要复核，这些必须由人来定。模型只在既定框架里选，不负责发明框架。

所以它替代的不是分析师，而是那句「帮我看看这属于哪一类」的重复劳动。反过来，如果一家企业连分类标准都还在打架，接了这个接口只会把混乱放大——它会非常稳定地把单子分到你临时写的那几类里。

还有一层现实约束：数据出境与合规。接口提供零数据保留与 HIPAA 适用场景，推理可落在美国与欧盟；但对数据必须留在境内的业务，这套能力更适合作为方法论参考，落地要么走私有化，要么用同类小模型自己训一个判断器。

另外要留意的是一致性。同一张单子今天判成「售后」、明天判成「投诉」，在人工审核里还能靠沟通弥补，在自动化流程里就是两条完全不同的路径。所以真正上生产之前，得拿一批历史数据跑一遍，看同一输入在多次调用下的稳定程度，而不是只看单次准确率。

第一类是工单与咨询路由。把「售前、售后、投诉、财务」做成 choice，按置信度决定直派还是转人工。这类场景量大、判断标准相对稳定，最容易算出投入产出。

第二类是单据与附件分流。发票、合同、回单、体检报告先分类再进流程，低置信度的进人工复核队列。它的价值不在快，而在把「人工先看一遍再决定交给谁」这一步省掉。

第三类是风险与合规打分。给供应商资质、报销异常、合同条款风险打有序等级，超过阈值自动升级。score 的连续值在这里比分类更好用，因为业务本来就需要一片「灰区」。

第四类是质检与巡店评分。把检查项拆成 predicate 与 score，现场照片直接判定，督导只处理异常项。这类场景过去最大的痛点是回填：人回到办公室再凭记忆填表，数据早就失真了。

四类落点有个共同前提：判断之后要能接到动作上。分类完了不派单、打分完了不升级、分流完了不通知，那这套接口就只是个更快的报表工具。判断层的价值，最终由它触发的那一步决定。

第一是标签体系。分类必须互斥且穷尽，否则模型只能在错的选项里挑一个「最不错」的。这一条听着像老生常谈，但大多数企业的工单分类至今仍是「其他」占三成。

第二是置信度阈值与兜底。Box 与 Sierra 都把低置信度转人工，这不是能力不足，是设计。阈值定在哪里，取决于错一次的代价——财务单据可以严，营销素材可以松。

第三是可追溯的记录。判断接口不返回理由，业务系统就得自己记：输入是什么、选项有哪几个、结果与置信度是多少、下一步谁处理的。没有这层记录，出了错连复盘都做不了。

说到底，判断层不是买一个接口就完事。它要求企业先把「什么算对」写下来。这件事和上一套管理系统的顺序是一样的：流程先结构化，数据先在线，判断才可能被自动化。

如果只能带走一句话，那就是：先把「哪几类、什么算异常、谁来复核」这三件事写成文档，再去看接口报价。顺序反过来，最容易出现的局面是买了一堆调用量，最后只用来给工单打标签。