结构化决策实战：把 Agent 的「判断」变成程序能处理的「数据」

先说背景：一个「只做选择题」的模型品类出现了

9 月 29 日的 OpenAI DevDay 上，Decisions API 是个不太起眼但值得琢磨的发布：它跑在一个特化版的 GPT-6 Luna 上，不生成自由文本。你传一段上下文（文本或图像），再加一份自己定义的、数量有限的答案清单，它只返回一件事——选了哪个选项，以及每个选项的概率。官方口径是单次约 150ms，而同样的问题走常规 Luna 调用要 1.6 秒左右。计费也变了：只收输入 token，$0.10 / 百万，输出 token 根本不存在。

有意思的是，这个品类不是 OpenAI 定义的。两周前 TypeSafe AI 发布了 Jev：纯文本输入，70-500ms 返回，每个选项都给概率，$0.042 / 百万输入、输出免费。OpenAI 的版本在概念上几乎是对着 Jev 做的——yes/no、choices、scores 三种问题类型，连 API 的形状都很像，只是多了图像输入，价格贵了一倍多。

10 月 6 日，Simon Willison 让 GPT-6 Astra 读完 OpenAI 的文档，当晚就写出了 llm-openai-decisions 插件。这个圈子的人向来是用行动投票的：一个晚上就能撸出可用插件，说明这东西确实挠到了痒处。

丑话说在前面：截至 10 月 7 日，Decisions API 仍然是 limited preview。OpenAI 承诺「未来几天」扩大范围，但 10 月 5 日的 changelog 里还没有动静。价格、配额、可用性都可能变。下面讲的是思路和方法，不是 API 手册；preview 阶段的东西，落到生产一定要自己留一手。

真正的痛点：agent 循环里最贵的是「做决定」，不是「干活」

如果你写过 agent，大概率见过这个模式：主循环里每个分支都要先问一次模型。「这条用户消息是技术问题还是退款？」「这段 diff 能直接合并吗？」「下一步该调搜索还是读文件？」每次判断都是一次完整的 LLM 调用：写 prompt、等生成、解析返回的文本、处理格式漂移、失败了重试。

这笔账有两层。第一层是 token：判断用的 prompt 往往不短，上下文还得塞进去；返回的文本里一半是推理过程，只有最后一句是你要的答案——而你为整段输出都付了钱。第二层更隐蔽，是格式漂移：模型今天返回 technical，明天返回 Technical Issue，后天给你一整段解释，外加一句「希望这对你有帮助」。你的解析代码写得越健壮，维护成本越高；写得简单，线上就三天两头崩。

结果就是：判断逻辑的成本经常超过真正干活的成本。主任务一次调用搞定，前面为了决定「要不要干、怎么干、干完给谁」烧了三四次。决策模型的思路，就是把「判断」从文本生成里剥离出来：输出空间是封闭的，模型只能在你给的选项里打分，返回的是程序能直接用的数据——选项名加概率，没有解释，没有废话，没有格式漂移。

四个立刻能抄的实战模式

(a) 路由：工单和消息分流。这是 OpenAI 官方自己举的例子，也是最成熟的用法。独立开发者的 SaaS 每天收到用户消息：技术问题进技术队列，账单问题进账单流程，退款请求走退款 SOP，广告和垃圾信息直接丢弃。以前的做法是调一次通用模型「分类一下」，再解析它的回答；现在变成一次决策调用：上下文是用户消息原文，选项是 [technical, billing, refund, spam, other]，返回直接就是队列名，if 都不用写解析。

概率在这里第一次有了用武之地：0.9 以上自动分流；0.6 到 0.9 之间打上「待复核」标签进队列，人工扫一眼；0.6 以下说明这条消息连决策模型都拿不准，降级丢给通用模型细看，或者直接转人工。注意 other 这个选项必须有——没有兜底的分类器，第一个奇葩输入就会把你的 pipeline 带崩。

(b) 门禁：「这条 shell 命令可逆吗？」coding agent 要执行命令之前，先问一个 yes/no 问题：「执行这条命令是否可逆（数据可恢复、无外部副作用）？」rm -rf node_modules 可逆，重装就行；rm -rf ~ 不可逆，直接拦截，要求人工确认或改写成安全版本。

门禁场景对延迟极其敏感：它卡在「执行」之前，慢一秒，整个 agent 循环就卡一秒。通用模型 1.6 秒的往返放在这里是不可接受的，150ms 级别的决策调用才有意义。这也是「快」比「聪明」重要的典型场景——门禁不需要模型写小作文，只需要一个可靠的是/否。

(c) 评分：按 rubric 给代码 diff 打分。自动合并 PR 是每个独立开发者的梦想，也是事故高发区。用 score 类型的问题，把 rubric 写进问题描述里：「只改了依赖版本号、无逻辑变更 = 高分；改了核心业务逻辑 = 低分；删了测试 = 直接最低分。」决策模型返回一个分数，超过阈值自动合并，低于阈值转人工 review。

但我要提醒一句：评分是四个模式里最容易「看起来很准、实际很水」的一个。rubric 写得越具体越好，「代码质量高」这种词等于没写。而且一定要定期抽查——让人工或主模型复核一批已打分的 diff，对不上号的地方，就是你的 rubric 有漏洞。

(d) 下一步选择：agent 循环里的「调度器」。假设你的 agent 有 6 个工具：搜索、读文件、写文件、跑测试、发 HTTP 请求、问用户。每一步都问决策模型：「基于当前状态，下一步最应该调用哪个工具？」选项就是工具名列表，返回的 top1 直接就是函数名，不用解析，不会拼错。

这比让主模型在几千 token 的 prompt 里「顺便决定」下一步便宜一个数量级。而且调度逻辑从主 prompt 里抽出来之后，主模型的 prompt 可以瘦身，整个系统的可调试性会好很多——「为什么这一步调了搜索？」查决策日志就行，不用去翻几万 token 的对话历史。

设计规则：选项是约束，不是建议

这是全文最值钱的部分。决策模型用得好不好，几乎全看问题和选项设计，模型本身反而是次要的。

1. 选项保持 3 到 7 个。20 个选项的「选择题」和自由文本没有本质区别，约束就失效了；2 个选项又容易把复杂情况硬塞进二元对立。7 是个经验上限，超过 7 先想想能不能分组、分层。
2. 问题要写得像单元测试的断言。反面例子：「这条消息是什么意思？」正面例子：「这条用户消息是否在字面上请求退款？只看字面请求，不考虑情绪和语气。」决策模型没有「解释」的机会，每个词都要经得起推敲。写完问题自己读三遍，有歧义的词，换掉。
3. 用概率做阈值，别只看 top1。高置信自动走，低置信转人工或降级到通用模型。阈值不能拍脑袋：拿 200 条你自己的真实数据跑一遍，看概率分布落在什么区间，再定线。不同场景的线不一样，路由和门禁的阈值就不该相同。
4. 永远给默认分支。other、unknown、escalate 必须出现在选项里。决策模型也会选错，没有 fallback 的决策链，第一个异常输入就全崩。这是铁律。
5. 把决策日志记下来。每条记录：输入摘要、问题版本、返回的选项和概率、最终走了哪个分支。每周抽 50 条，对比「决策模型的判断 vs 人工/主模型的复核」，不一致的 case 就是你的选项设计或问题描述有漏洞的地方。决策系统是越用越准的，但前提是你得看日志。
6. 对概率多一分警惕。有第三方拿 3600 道逻辑题实测过：Luna 在需要多步推理的题目上，标称 99% 以上置信度的选项，实际准确率只有 68% 左右；而且选项的排列顺序会影响概率分布。所以厂商给的置信度别直接当真理——一定要在自己的数据上校准，阈值是跑出来的，不是读出来的。

成本账：只收输入 token 意味着什么

核心变化一句话：决策调用没有输出 token，高频判断场景的成本直接掉了一个数量级。下面给你公式，不给你编好的结论——数字请填自己的实测。

公式：月成本 = 每天调用次数 × 30 × 单次输入 token 数 × 单价 / 100 万。单次输入 token 数 = 问题描述 + 选项清单 + 上下文，这三块你自己数一遍就知道，含糊不得。

• 场景：每天 1 万次路由判断，每次输入 800 token（数字是假设的，请替换）。
• Decisions API：30 万次 × 800 = 2.4 亿 token × $0.10/百万 ≈ $24/月。
• 通用模型（以 Luna 常规调用 $0.10 输入 / $0.50 输出为例）：输入成本同样是 $24，但每次还要输出约 300 token 的推理和答案：30 万 × 300 = 9000 万 × $0.50/百万 = $45；合计约 $69。决策模型省掉了输出部分，大约是三分之一。
• 如果用 Jev（$0.042/百万输入）：同样算法约 $10/月。

两个提醒。第一，通用模型那 300 token 输出是我拍的示意数：你的 prompt 越长、模型输出越啰嗦，差距就越大；反过来，如果你的判断 prompt 本身很短，差距会缩小。公式给你了，代入自己的数字算一遍，别直接抄结论。第二，延迟账也一样：官方口径 150ms 对 1.6 秒，10 倍，但这是厂商口径，有第三方明确指出目前还没有独立复现。门禁、实时路由这种对延迟敏感的场景，上线前自己压测 p50/p95/p99，别拿 keynote 上的数字做架构决策。

什么时候别用它

• 需要细腻判断的时候。比如「这条用户反馈背后真正的诉求是什么」——选项列不出来，就别硬套选择题。决策模型擅长的是「分类」，不是「理解」。
• 需要创意或开放式推理的时候。它不生成文本，brainstorming、写文案、想名字，这些找它就是找错人。
• 需要多步逻辑链的时候。上面提到的实测已经说明了问题：推理深度一上去，准确率掉得很快。复杂的判断要么拆成多步简单判断串起来，要么直接上通用模型，别指望一个 150ms 的调用替你做五步推理。
• 选项本身频繁变化的时候。如果你的分类体系每周都变，维护选项列表、重新校准阈值的成本，会吃掉省下来的 token 钱。决策模型适合「问题稳定、量大、延迟敏感」的场景；分类体系还在天天改的早期产品，先用通用模型顶着，等模式稳定了再收敛成决策调用。

工程建议：包一层薄薄的 adapter，别把逻辑焊死在某一家

Jev 和 OpenAI Decisions 在概念上几乎一样（三种问题类型，连返回的形状都像），但细节一定会分化——preview 阶段尤其如此。今天只有 OpenAI 一家支持图像输入，明天可能 Jev 也加上了；今天 $0.10，明天可能降价也可能涨价。把业务逻辑直接写成「调 OpenAI Decisions API」的形状，等于把未来半年的议价权交了出去。

做法不复杂：自己定义一个 decide(question, options, context) -> (choice, probabilities) 的接口，后面挂三个实现：Jev、OpenAI Decisions、本地规则引擎（关键词加正则打底）。业务代码只认这个接口，不知道后面是谁在干活。

三个好处。第一，preview 挂了、涨价了、没拿到资格，改一行配置就能切，业务代码不用动。第二，本地开发和测试用规则引擎，零成本跑通全链路，CI 里也不用烧真钱。第三，规则引擎给你一套免费的对照基线——「决策模型 vs 规则」不一致的 case，拿去做前面说的日志抽查，校准阈值特别好用。

最后一条，是 preview 阶段的纪律：别把核心链路押上去。路由可以先上，失败了顶多分错类，人工能兜回来；门禁这种安全相关的，先用决策模型做「建议」，执行前还是走你原来的确认流程。等 GA、等自己压测完 p95、等阈值在真实数据上跑稳了，再收紧。快的东西，更要慢用。

当「判断」变成结构化数据，agent 才算长出了反射弧。主模型负责想，决策模型负责在几百毫秒里拍板，规则引擎在底下兜底——三层各干各的，互不堵路。这可能是未来一年 agent 架构里最值得下的注：不是更大的模型，而是更便宜的判断。