决策模型让分类任务告别文本解析

应用里有不少 AI 调用，只需要判断工单类别、是否紧急、该选哪个模型，却要先让聊天模型生成文字，再把文字解析成代码能用的值。作者关注的决策模型（decision model），就是专门处理这些固定选项判断的工具：输入状态和问题结构，直接返回各选项的概率。

它的吸引力不在于更聪明，而在于输出天然适合程序消费。不过，格式不会错，不代表判断不会错；概率能参与业务分流，也不代表它已经可靠到可以直接触发自动操作。

为什么一个分类判断还要先生成 JSON

作者反复写过这样的代码：先要求模型输出 JSON，再提取、解析和校验。

const raw = await llm(`Classify this ticket. Reply with JSON:
{"category": "billing" | "bug" | "other", "urgent": true | false}`);

const parsed = ticketSchema.safeParse(JSON.parse(extractJson(raw)));
if (!parsed.success) {
  // 重试？使用默认值？记录日志然后祈祷？
}

要看的是 ticketSchema.safeParse 这一行：业务只想拿到分类结果，却需要额外处理模型输出的格式问题。

作者列出三个麻烦：JSON 前后可能夹着解释，字段值可能超出枚举，以及模型明明只略微倾向「紧急」，最后却输出一个看起来毫不犹豫的 true。前两个是格式和类型问题，第三个是决策信息丢失。

决策模型接收当前状态，以及一组限定回答类型的问题，例如是否、枚举选项或量表分值。它在一次前向计算中返回各选项的概率，不生成文本。

输出符合类型约束，只解决了结果能不能被程序接住，没有保证结果判断正确。

按照原文的描述，Cloudflare 的 Clef 和 Amazon 的 Strands Decider 2B 都于 2026 年 10 月 1 日发布，提供开放权重。TypeSafe 的 Jev 此前已经采用类似方式。

概率的用处，是让程序保留犹豫的空间

一个 urgent: true 无法告诉程序，模型到底有多确定。作者最看重的是，决策模型把这种不确定性暴露成数值，于是代码可以为不同区间安排不同处理路径：

if (p.urgent > 0.9) page(oncall);
else if (p.urgent > 0.6) queueForHuman(ticket);
else autoReply(ticket);

这里的关键是两个阈值：超过 0.9 才呼叫值班人员，超过 0.6 则进入人工队列，其余自动回复。中间区间给人工介入留出了位置。

但这是一段说明用法的示例。原文没有给出阈值的验证过程，也没有说明模型输出的概率是否经过校准。比如，一批标为 0.9 的结果，实际是否有约九成判断正确，文中没有证据。

作者确实做过的应用，是把 Jev 放在编程 Agent 前面，充当模型路由器。每条消息只回答一个分类问题：任务属于 tiny、everyday、large 还是 hardest，然后由分类结果选择后续模型。

Clef 和 Decider 带来的变化，是这类模式有了开放权重选项。作者指出，它们可以在自己的硬件上运行，让这一步判断不必经过外部 API；原文没有交代所需硬件和具体部署成本。

哪些调用适合换，哪些还得留给聊天模型

适合决策模型的任务，通常有一个共同点：答案范围事先就能列清楚。

原文举出的场景包括路由、工单分诊、判断工具调用是否可以免确认执行，以及判断房源照片里是否有停车位。它们需要的是有限选项里的判断，而不是一段解释。

代价也很直接：没有文本输出，就不能承担代码生成、聊天或摘要。作者还指出，一次并行前向计算在困难问题上弱于能够逐步推理的模型，不过文中没有展开具体测试和差距。

因此，判断入口可以很窄，后面的执行模型仍然可以很强。作者的编程 Agent 路由就是这种分工，而不是用小模型接管整个编程过程。

我的判断

我认同作者对输出接口的判断。固定分类任务如果长期依赖提示词、正则和重试循环，确实值得重新检查模型选型。让输出结构贴近调用代码，能减少一部分胶水逻辑。

但原文把聊天模型概括为「只能拿到答案」，范围有些宽。它没有与结构化输出、受约束解码等常见替代方案做对照，也没有提供准确率、延迟和成本数据。「更容易测试、更便宜」目前应当视为作者的经验判断，不能直接当成一般团队的选型结论。

另一个边界是工具安全。模型可以判断一次调用看起来是否安全，但原文没有证明这种判断足以代替权限规则。概率适合参与分流，能否执行仍需要业务约束。

能拿来做什么

• 检查现有 AI 调用中所有「只能回答以下选项」的提示词，把工单分类、任务路由这类有限答案任务列为候选。
• 在 Node 服务里把判断结果与处理策略分开，明确哪些结果自动处理、哪些进入人工队列，再用实际样本确定阈值。
• 给编程 Agent 尝试增加任务难度路由，参考作者的四档分类，同时记录错分后是否出现回答质量下降或重复调用。
• 评估本地部署时，同时比较现有结构化输出方案，记录准确率、延迟、资源占用和维护成本，再决定是否迁移。