先看证据
从生成一段话，转向给选项打分
微软发布了 Microsoft-Decision-1，一种面向路由、分类、验证和智能体控制的决策评分模型。它基于阿里巴巴的 Qwen3.5-9B 后训练，接收情境、问题和一组固定选项，再在一次调用中为每个选项返回概率，而不是生成一段解释或结论文本。模型目前通过 Microsoft Foundry 和 OpenRouter 提供托管 API，确切参数规模未披露。
这项变化看起来像是输出格式的调整，实际改变的是模型在软件系统里的位置。通用生成模型往往先产出文字，再由应用解析或判断；Decision-1 则试图直接给出程序可以消费的 JSON 分数。对于原本就要从有限答案中选一个的工作，这可能减少“模型说了什么”和“系统该执行什么”之间的一层转换。
固定选项让判断更容易接入，也更受题目约束
模型卡列出的任务包括是非题、多选题、评分、分类、按评分标准评判 AI 回复，以及依据给定证据检查内容是否有根据。它也支持设置“无法判断”一类的弃答选项。共同点是：应用先定义可能的答案，模型再对这些答案评分，结果以 JSON 返回，不附带解释。
这种设计适合把判断嵌进已有流程，例如在执行前给智能体提出的工具调用打分，或根据请求类型选择不同模型。但选项由应用提供，也就意味着应用承担了定义问题边界的责任。若候选项漏掉重要情况，概率再精细也无法补出未提供的答案；弃答选项能表达不确定，却不能替代对选项是否完备的设计与审查。
成绩领先，但领先范围并不等于普遍胜出
微软称，模型在 9 个系统、36 项基准和 147,137 个问题的比较中取得最高平均准确率 83.5%，高于 Quyet-1.0-Large 的 81.9%。基准被描述为未用于训练；不过，Decision-1 只回答了其中 23 项，因此 83.5% 是它能够作答的 23 项基准平均值，而不是覆盖全部 36 项的平均表现。微软还报告其校准分为 92.2，略低于 Quyet-1.0-Large 的 93.1。
这些数字支持一个有限判断：在微软所测、且模型能够处理的任务集合里，Decision-1 的平均准确率靠前，校准表现也较强。它们并不能说明模型在任意分类或控制任务上都优于其他方案。比较本身由微软进行，且材料没有给出各项基准的完整结果和具体任务构成；“基准未见”也只说明其与训练数据的关系，不能代替对生产数据分布的检验。
低延迟和低单价，仍须放回完整链路核算
微软报告的延迟是 p50 85 毫秒、p95 125 毫秒，输入价格为每百万 token 0.042 美元，输出免费。这让它看起来适合高频、短决策的环节，例如请求路由或执行前检查；与大型生成模型相比，固定选项、只回结构化结果，也有机会降低单次调用的开销。但现有材料没有披露硬件配置，也没有提供可自行部署的权重或量化版本，因此不能据此推算本地运行成本。
延迟比较尤其需要谨慎。微软的数字来自 Foundry 测量，而竞争模型使用 JevBench 的调整后中位数；材料同时引述 H2O.ai 的说法，称该调整会把测得时间翻倍并额外增加 0.15 秒，且其自测中位数为 29 毫秒。不同测量路径并未形成统一的对照条件，因而“快多少”不宜直接当作架构选型结论。团队应核算实际请求长度、调用次数、重试和网络开销，并在自己的服务环境里测端到端延迟。
把它放在判断节点，而不是当作安全策略
对于工程团队，合适的试用入口不是把 Decision-1 接管整个智能体，而是挑出已有明确选项、又能用历史数据复核的窄任务。例如，可以先比较它对工具调用的评分与人工审核结果，再观察错误是否集中在某类选项或输入。模型报告称，在扰动测试中决策翻转率为 1.3%，但材料没有说明扰动设计细节，因此这个数字不能直接代表真实环境中的稳定性。
还要把模型评分与执行权限分开。Decision-1 不提供解释，闭源 API 的权重也不可自行检查，且 OpenRouter 提到权重持续更新、API 形状保持固定。对于高风险操作，概率分数应当作为规则、阈值、人工复核或其他验证机制的输入，而不应单独成为放行依据。更稳妥的判断是：把它视为一个可能更快、更便宜的结构化判断组件，用自有数据评估收益和失误代价，再决定哪些低风险环节可以自动化。