2026 年 10 月 6 日，Vercel 的 AI Gateway 上线了一项新能力：当主模型的回答触发你设定的置信度条件时，网关可以把这次决策交给另一个模型重新做一遍。该功能目前处于 beta。
要理解这一步为什么重要，先要理解“决策请求”和普通生成请求的区别。决策请求不问模型“写一段话”，而是让它在一组选项里选、给一个分数、或者回答是或否，并且要求它返回答案的同时给出置信度。置信度一旦是结构化字段，它就从一句自我评价变成了可以被程序判断的信号——这也是这次回退功能能成立的前提。
发生了什么：把“不自信”变成一条可编程的路由规则
官方给出的配置方式是：在 providerOptions.gateway.models 下增加一个条件对象。没有写这个字段的请求，行为完全不变——这一点对已有集成很关键，意味着这是一次纯增量的能力，不需要迁移。
支持置信度回退的问题类型，以及与原有硬失败回退的关系（编辑绘制）。
条件本身支持组合，也就是说回退可以由多个信号共同决定，而不是只看一个阈值。组合的价值在于区分“哪种不确定”：一次决策请求里往往同时包含多个问题——既要选出分类，也可能要给一个评分。只看其中一个问题，可能恰好漏掉真正含糊的那一个；把条件写到多个问题上，回退才会对着真正薄弱的地方触发，而不是对整条请求无差别地加一次调用。
更值得注意的是一条容易被忽略的默认行为：如果条件里省略了 question，这条规则会对该类型的所有问题生效。官方举的例子是，{ confidenceBelow: 0.6 } 会在任何一个 Choice 或 Score 类问题的答案低于 0.6 时触发。写错这一处的代价是：你可能只想保底某一个关键判断，结果所有问题都开始触发二次决策。
官方示例里完整的一次调用是这样的：从 @ai-sdk/gateway 引入 gateway，从 ai 引入 experimental_decide as decide；调用 decide 时传入 gateway.decisionModel('typesafe-ai/jev')、一个描述账单争议的 state，以及一个名为 intent 的 Choice 问题（选项是 billing 与 technical）。回退写成 { model: 'openai/gpt-6-astra', when: { question: 'intent', confidenceBelow: 0.6 } }，最终结果通过 result.answers.intent.choice 读取。
完整工作场景：工单分流为什么要这一层
设想一个把客服工单路由到不同团队的流程：进入的工单要被判断该归“账单”还是“技术”处理。
老的做法是给决策模型写一个固定的问题，拿到答案就用。问题在于，遇到描述含糊的工单——比如用户抱怨“扣了钱但功能没生效”——模型的答案可能介于两者之间，而它一旦给出一个确定的选项，下游就当作确定的事实去执行了：路由到账单组，然后被账单组退回，再转给技术支持。这类错误不会报警，它只是让工单多绕一圈。
加了置信度回退之后，这一层判断被显式写成了规则：如果 intent 这个问题的置信度低于 0.6，这次决策交给 openai/gpt-6-astra 重做一遍，最终采用回退模型的答案。你不需要在业务代码里写 if-else，也不需要自己解析模型的自我评价，规则和阈值都在网关这一层表达。
对已经在用 decide 的团队，这意味着“路由质量”第一次变成了一个可以调参的对象：阈值定高一点，触发回退的次数变多、成本上升、准确率上升；定低一点反过来。它是一个旋钮，而不是一个只能接受的既定行为。
为什么这会改变工作流
这件事真正的位移在于：模型的不确定性从“运行时才知道的事”变成了“可声明的策略”。过去处理模型答不可靠的办法，大多是在应用层重试、加校验、或者干脆换一个更大的模型全程兜底；这些做法要么写死在代码里，要么对所有请求一视同仁地增加成本。
置信度回退把成本按需分配：大多数请求交给便宜的主模型跑一次就结束，只有触发条件的那部分才多花一次调用。对于决策类任务——分流、分类、审核、路由——这比“全量上大模型”更接近实际需要的性价比曲线。
它也和 AI Gateway 已有的能力接得上：既然模型调用已经统一走网关，把“什么时候该换模型”这条规则放在同一层，是自然的收口位置。
限制与需要人接管的环节
第一，也是最需要写进预算的一条：触发的回退会真的跑第二次决策，官方明确说两次都会计费。阈值不是免费的旋钮，定得太敏感会直接反映在账单上。
第二，回退改变的是“用哪个模型的答案”，不改变“答案是否正确”。如果两个模型对同一份含糊输入给出同样自信的错误判断，这层机制不会发现任何异常——它处理的是置信度低的情况，而不是置信度虚高的情况。
第三，条件类型是分档的：Choice 与 Score 走 confidenceBelow 阈值，Boolean 类问题用的是概率区间。把两类问题的配置方式混用会得到意料之外的行为，需要按类型分别写。
第四，它和原有回退不冲突，但也不是替代关系。写在 models 里的裸模型名继续负责兜住硬失败（比如模型报错或不可用），置信度条件是叠在上面的一层判断。
第五，功能处于 beta，接口以 experimental_ 前缀暴露。对生产链路来说，这意味着要接受它随时可能调整，谨慎的做法是先在非关键路径上跑一段时间。
第六，人应当在阈值上做最终判断。0.6 只是一个例子，不是一个推荐值；合适的阈值取决于业务能容忍多少误判，以及每次多跑一次决策愿意付多少钱。
如何试用
在 providerOptions.gateway.models 下加一个条件对象即可，不写这个字段的现有请求不受影响。官方 changelog 给出了基于 @ai-sdk/gateway 与 ai 的完整示例代码，并指向了 decision fallbacks 的文档页。
信息来源
- Vercel Changelog：AI Gateway adds confidence-based decision fallbacks（2026-10-06，作者 Rohan Taneja）— https://vercel.com/changelog/confidence-based-decision-fallbacks
- Vercel Docs：AI Gateway decision fallbacks 文档
HiFox：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 HiFox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，
欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
