用例
Decisions API 用于请求路由
路由本质上是一个有限决策：哪个队列、什么优先级、交给人还是自动化。决策调用会返回选中项以及每个选项的概率，高置信的自动分派，其余交给人工分流。
更新于
为什么路由天然契合
路由问的是一个有限问题——我的哪个队列该接这个——这正是决策端点原生回答的。不用从生成文本里解析队列名，也不用费尽心思阻止模型发明第五个队列。
同一次调用可以对同一工单提多个问题，队列、紧急度、是否需要人工复核，一轮全部解决，只消耗 1 积分。
- 队列分派：账单、平台、账号、其他
- 优先级：从低到阻塞的有序评分
- 升级判断：一个 noul 问题判断是否需要人先过目
把 criteria 写成队列说明
choice 问题里每个选项都配一段「什么归这里」的简短说明。按给新分流同事写须知的方式写——这些说明就是你的路由策略。
始终保留一个「其他 / 不清楚」选项。给模型一个诚实的出口，避免模糊工单被强行塞进错误的队列。
一次调用：队列加紧急度
把工单文本作为 state，同时问两个问题：choice 选归属团队，score 评紧急度。响应里能拿到 answers.team.choice、answers.urgency.score，以及两个问题下每个选项的概率。
一次请求中的 choice + score
// Route a ticket: ask for team + urgency in one call,
// then gate the automation on confidence.
const res = await fetch("https://decisions-api.net/api/v1/decisions", {
method: "POST",
headers: {
Authorization: "Bearer YOUR_KEY",
"Content-Type": "application/json",
},
body: JSON.stringify({
model: "decisions-1",
state: "Payments fail with a 500 since your last deploy. Enterprise plan customer.",
questions: {
team: {
type: "choice",
instructions: "Which queue should handle this request?",
criteria: {
payments: "Billing, charges, or payment failures.",
platform: "Deploys, infrastructure, or API errors.",
account: "Login, SSO, or permissions.",
other: "Unclear or out of scope.",
},
},
urgency: {
type: "score",
instructions: "How urgent is this for the customer?",
criteria: ["can wait", "normal queue", "needs attention today", "blocking revenue"],
},
},
}),
});
const { answers } = await res.json();
// Illustrative response: answers.team -> { choice: "payments", confidence: 0.84 }
// answers.urgency -> { score: 3, confidence: 0.79 } (0 = lowest level)
if (answers.team.confidence >= 0.8 && answers.team.choice !== "other") {
assignToQueue(answers.team.choice, { priority: answers.urgency.score });
} else {
assignToQueue("human_triage", { note: "low confidence" });
}按置信度决定是否自动分派
概率分布才是让路由可以放心自动化的关键。一个可用的默认值：置信度 ≥ 0.8 时自动执行分派，低于此的全部进人工分流队列。
阈值要在你自己的工单历史上调——正确取值取决于错派工单的代价与延迟工单的代价之比。
在模型之间路由请求
同样的模式可以决定由哪个模型来回答。用一个 choice 问题，选项比如 fast_model（简短的事实性或格式化请求）、strong_model（多步推理、代码、长上下文）和 human（法律、退款，或任何不该由模型单独回答的事）。每个选项都带回概率，你能看出这次分配有多纠结。
用同样的方式做门控：置信度低时，把请求路由到人工或更稳妥的路径，而不是盲信最高分选项——第二名的概率会告诉你这次选择有多接近。
成本与量级
一次成功调用消耗 1 积分，无论问 1 个还是 6 个问题。历史工单 backlog 可以用控制台的批量工具跑同一请求形状处理 CSV 或 JSONL 文件。
常见问题
最多能路由到几个队列？
一个 choice 问题支持 2 到 8 个选项。队列更多就分层决策：第一次调用选部门，第二次在部门内选团队。
能在同一次调用里评估紧急度吗？
可以——加一个 score 问题，写有序的分级说明。一次调用最多 6 个问题，队列、紧急度、升级标志可以一起解决。
边界模糊的工单怎么办？
答案里带每个选项的概率。前两名接近时——比如 0.45 对 0.42——就当作模糊工单转人工分流，而不是盲信胜出项。
非英文工单能用吗？
state 和选项说明用你工单的实际语言写，选项 key 保持 ASCII，路由代码更易读。
它能决定由哪个 LLM 回答请求吗？
可以——把各个模型设为 choice 问题的选项，并描述各自擅长什么。低置信度的情况路由到更强的模型。
现在就路由一张工单
新访客一次免费试用决策——把一张真实工单粘进试用台，读出概率分布。