一句话定义：Decisions API（决策 API）是把模型“做一个明确判断或选择”的能力，封装成低延迟、结构化输入输出的接口，供业务系统在毫秒到百毫秒级内同步调用。
打个比方。Chat Completions API（聊天补全接口）像请一位顾问坐下来聊：你把背景讲清楚，他斟酌着写一段回答，慢一点没关系。Decisions API 更像地铁闸机：刷卡、比对、放行或拦下，几毫秒出结果，而且结果必须是“能放行或不能放行”这种离散答案，不是一段议论文。
展开讲原理。这类接口的输入通常是结构化字段：场景标识、用户或对象 ID、一组候选选项、若干特征值。输出也被收窄：选哪个候选、是否放行、打哪个标签、给哪一档权益，往往还附带置信度和原因码，方便审计与回放。正因为输出空间有限，模型可以做小、做蒸馏、做缓存、做批量预计算，延迟和成本才压得住。
它和聊天补全 API 的分工大致是这样：
| 维度 | 聊天补全类接口 | 决策 API |
|---|---|---|
| 输入 | 自然语言、多轮上下文 | 结构化字段 + 候选集 |
| 输出 | 自由文本、工具调用 | 有限动作 + 置信度 + 原因码 |
| 延迟预期 | 秒级可接受，可流式返回 | 稳定低延迟，常被调用方超时约束 |
| 失败方式 | 答得不好可以重问 | 必须给出兜底决策 |
| 典型场景 | 客服、写作、问答 | 风控、流量路由、推荐、工单分派 |
实际系统里两者常常同时存在，中间由“请求分诊”（triage）衔接：网关先用规则或小模型预判，简单的走缓存和固定策略，复杂的才落到决策模型，仍拿不准的再升级给聊天补全模型或人工。分诊的价值在于把昂贵、慢的路径留给真正需要的少数请求。
降级策略是这类接口的核心设计。模型超时、限流、版本异常时，接口不能报错卡住业务，而要返回预设的兜底动作：默认放行、默认拒绝、推荐热门项、回退到上一版规则，同时打上标记供事后复核。换句话说，决策 API 的契约是“永远能给出一个结果”，哪怕不是最优的那个。
对从业者的实际意义：先把决策空间和兜底策略定清楚，再谈模型选型；输出结构化、可解释、可回放，比单纯追求模型规模更重要。对普通职场人来说，你在 App 里感受到的“秒批额度”“秒出推荐”“工单自动派对人”，背后往往就是这类接口在工作。具体接口形态与字段定义各家不同，以官方页面为准。