Microsoft Decision-1 模型发布，但 Nadella 的背书并非主线

Microsoft 于 2026 年 10 月 9 日推出 Microsoft Decision-1 模型，并直接强调其在速度、一致性以及 36 项基准测试中的表现。Satya Nadella 放大了此次发布的影响力，但该产品实际出自 Microsoft 的工程团队。这一区别很重要，因为 Decision-1 并不是又一个围绕 CEO 叙事打造的通用助手。

该模型瞄准的是更狭窄的问题。许多 AI 应用会反复对输入进行分类、为输出评分、路由请求，并决定智能体是否应继续执行。即使并不需要开放式写作或长篇推理，开发者也常将这些步骤交给大型语言模型。

Microsoft 希望用更快、边界更明确的预测来取代这种模式。该公司通过对 Qwen3.5-9B 进行后训练来构建模型，而不是从 Microsoft 的基础模型起步。这一选择也构成了此次发布的核心张力：Microsoft 正在推广专业化 AI，但其初始版本依赖的是 Alibaba Qwen 系列模型。

这并非只是一个小模型与大模型之间的竞争。Microsoft 的观点是，许多智能体工作流不应再把通用 LLM 当作解决一切问题的答案。如果这一判断成立，市场可能会从单模型应用转向由专业模型组成的流水线。

Microsoft Decision-1 模型究竟改变了什么

Microsoft Decision-1 将结构化选择与开放式生成分离，为开发者提供专门处理软件需要立即消费的决策的模型。

传统 LLM 通常会返回文本，即使应用实际只需要一个类别、分数或是非答案。软件随后还必须解析响应，并判断其中措辞是否对应允许执行的操作。这种额外解释既增加延迟，也引入了新的故障点。

Decision-1 接受固定选项，并返回这些选项的概率。它支持是非决策、多项选择题，以及基于开发者定义量表的评分。Microsoft 将其称为单次决策评分，即模型根据提供的证据进行评估，而无需先生成冗长的推理回复。

例如，一个客服应用可以提供客户消息，并要求 Decision-1 选择紧急程度。相同请求还可以询问案件应转交给哪个团队，以及是否需要人工审核。应用代码可直接读取这些边界明确的答案，无需从一段文字中提取标签。

这一差异很容易被忽略，因为 Decision-1 本身仍源自语言模型。Microsoft 表示，其针对这一更狭窄的行为对 Qwen3.5-9B 进行了后训练。因此，该模型保留了语言理解能力，同时以适合程序化操作的形式呈现输出。

Microsoft 将路由、分类、优先级排序、验证、数据标注和工作流控制列为目标任务。其他示例包括评估 AI 回复、检查智能体拟议操作、对搜索结果排序，以及分流事件报告。

这些任务广泛存在于智能体系统中。一个智能体可能在选择模型前先对请求分类，在生成后为草稿评分，再决定是否调用另一项工具。在每个阶段都使用大型推理模型，可能会不断累积延迟与不必要的计算量。

Microsoft 用一个简单的时间示例说明这种累积效应：在 20 个连续决策的每一步增加 100 毫秒，就会为工作流增加两秒。随着开发者加入更多检查点和分支，快速分类器的价值也会随之提高。

该公司的发布分析称，Decision-1 在 Microsoft 对 36 项基准的比较中获得了最高准确率。这些基准包含近 15 万道题目，涵盖路由、排序、多语言输入、长上下文、安全性和推理等领域。

Microsoft 还称，Decision-1 的速度是其比较中第二快模型 H2O-Lightning-4B 的 2.5 倍。该公司报告称，其中位延迟约比 GPT-6 Sol 低 35 倍。这些数据来自 Microsoft 自身评估，而非独立基准实验室。

该模型可通过 Microsoft Foundry 获取，后者是 Microsoft 用于发现、评估和部署 AI 模型的平台。Vercel 也通过其 AI Gateway 提供了该模型，模型标识符为 microsoft/microsoft-decision-1。

此次发布改变的更多是可选架构，而非 AI 能够理解的内容。开发者早已使用传统分类器、规则、嵌入模型和更小的 LLM 来完成路由。Decision-1 则通过统一的模型接口，封装了多种边界明确的决策格式。

这种封装可能会让专业化决策层更容易被采用。它也让 Microsoft 进入了一个正在形成的软件类别：模型返回的是类型化预测，而不是对话式散文。

这则消息为应用团队带来了一个具体问题：现有 LLM 调用中，究竟有多少是真正的生成式任务？如果其中相当一部分只是从预定义选项中做选择，Decision-1 就提供了 Microsoft 对这种日益昂贵设计习惯的答案。

为什么 Microsoft 要将决策与生成分离

Decision-1 反映了更广泛的转变：从单体式 AI 助手转向模块化系统，让每项任务交由形态适配的模型处理。

早期生成式 AI 应用通常将几乎所有请求发送给同一个前沿模型。这种方法简化了原型开发，因为同一个端点既能总结文本、分类工单、提取字段，也能撰写回复。但随着应用流量和智能体步骤增多，它的吸引力逐渐下降。

生产系统面临三种演示中容易被掩盖的压力。每次模型调用都会增加延迟。每个 token 都会消耗计算能力。每次自由形式的响应都会给格式和下游行为带来不确定性。

决策模型通过缩小输出空间来应对这些压力。被要求在四个已定义操作中选择的模型，不需要再写出第五种操作。它可以返回所选操作及可由代码评估的置信度数值。

置信度信号很重要，但需要谨慎解读。Microsoft 希望 Decision-1 的概率得到校准。经过校准的 90% 预测，在可比案例中应当大约十次有九次正确。

这并不意味着 90 分验证了底层事实。它意味着模型会在提供的证据和标准下，对自己的答案表达置信度。开发者仍需借助标注示例，了解这些分数在其自身数据上是否可靠。

Vercel 的 Decision-1 指南具体说明了这一边界。该指南指出，模型可以对用户报告进行分类，但无法证实所报告的产品问题确实存在。负责该产品的系统仍是权威来源。

这种分工意味着一种更模块化的智能体架构。生成式模型可以理解模糊目标或起草回复；Decision-1 随后可以为草稿评分、选择路由，或判断是否应由人工审核。

当决策完全确定时，规则仍然适用。当组织拥有大量已标注且稳定的数据时，传统机器学习分类器仍具吸引力。Decision-1 所处的空间是：输入以自然语言表达，但输出必须保持在声明的边界内。

这一定位让它比固定规则引擎更灵活。开发者可以用语言描述标准，而不必手动编码每一种表述。但它又比通用 LLM 更受约束，而这正是重点所在。

Microsoft 表示，相同输入应导向相同决策。在其稳健性测试中，公司以八种方式修改请求，包括重新排序选项和引入无害的格式变化。该公司报告称，Decision-1 在这些扰动下平均有 1.3% 的情况改变了答案。

在 Microsoft 的测试中，当选项描述被改写，或选项被反转或打乱时，该模型没有出现答案翻转。一致性在决策控制应用分支时尤为重要。用户不应仅因两个等价选项以不同顺序出现，就被引导至不同工作流。

再次强调，这些都是厂商自行报告的结果。Microsoft 设计了模型、选择了评估框架，并发布了比较结果。开发者应将这些数字视为进行测试的理由，而不是测试的替代品。

该模型通过多个平台发布，可能会加快这种评估。Microsoft Foundry 为面向 Azure 的团队提供了直接部署路径。Vercel 的网关则通过决策接口提供该模型，支持类型化的选择、评分和布尔问题。

OpenRouter 的可用性也扩大了潜在受众。这些分发渠道降低了将 Decision-1 与现有分类器或 LLM 提示进行比较所需的部署门槛。

因此，此次发布是在工作负载层面对通用模型提供商施压。Decision-1 无需在写作、编程或研究方面胜过前沿模型。它只需要以可接受的准确率和更低延迟，处理足够多的重复性决策调用。

这是一个更狭窄、但可能规模很大的竞争。智能体应用可能会为每一次用户可见的回复生成许多内部决策。随着这些应用扩大规模，无形的路由和评估调用可能成为其基础设施的重要组成部分。

Microsoft 的 Qwen 基础令其策略更复杂

最值得关注的细节是，Microsoft 的专业模型以 Qwen3.5-9B 为起点，而 Microsoft 计划在后续版本中改用 MAI 和 OpenAI 模型作为基础。

多年来，Microsoft 一直在推广广泛的模型目录，而非强迫客户使用单一提供商。Decision-1 将这一理念植入模型本身：其首个基础来自 Qwen，而其公布的未来计划则包括 Microsoft 和 OpenAI 的基础模型。

这是一种务实的工程选择。对现有模型进行后训练，让 Microsoft 能够专注于决策行为、评估集、结构化接口和部署体验。从零开始构建基础模型会增加时间和成本，却未必能提升这类边界明确任务的表现。

但这在战略上也有些尴尬。Microsoft 对 OpenAI 进行了大量投资，并正在构建自己的 MAI 系列。以 Qwen 为基础推出冠有 Microsoft 名称的模型，表明当另一种基础模型更符合眼前工程目标时，模型血统可能变得次要。

Microsoft 并未隐藏这一来源。其技术文章称，Decision-1 是通过针对快速、单次评分对 Qwen3.5-9B 进行后训练而创建的。文章还称，未来迭代版本将重新基于 OpenAI 和 MAI 模型构建。

这一路线图使 Decision-1 成为比一组模型权重更大的事物。持久的产品可能是 Microsoft 的训练方法、决策 API、基准测试套件和 Foundry 分发层。其底层基础模型可以变化。

这类似于应用开发者如今对待数据库或云基础设施的方式。他们关心稳定的接口、可预测的行为和运营控制。如果这些契约保持不变，底层实现可以持续演进。

微软的做法也挑战了这样一种假设：模型品牌必须对应单一的基础架构。Decision-1 所指的其实是一种角色。无论由哪种基础模型提供语言表征，它的目的都是快速评估有限范围内的选项。

因此，主要竞争分野并不是微软对阵 Qwen，而是专用决策系统与通用 LLM 调用之间的较量。Qwen 提供了背景信息，因为它揭示了微软如何将产品推向市场，但它并未界定该产品的核心竞争。

OpenAI 和其他模型提供商同样面临这一架构问题。它们的前沿系统能够进行分类和评估，且往往具备很高的准确性。不过，这些能力并不自动意味着它们就是每一种内部决策场景下的最佳运营选择。

较小的专用模型无需变得更通用，也能胜出。它可以凭借可预测的输出、更快的响应、更简化的解析流程以及更低的基础设施需求取得成功。这与以广泛智能为重点的基准测试竞赛，追求的是不同的优化目标。

微软的内部案例进一步强化了这一定位。Xbox Research 使用 Decision-1 对来自问卷、Steam 和 X 的 10,000 多条开放式反馈进行分类。研究人员先定义主题，再由模型将反馈归入相应类别。

微软表示，该模型在这项任务中的质量可与 GPT-6 Sol 相媲美，同时运行速度超过其 14 倍。该公司还称其具有显著的成本优势，不过各组织仍应在自身的部署条件下复现这一比较。

Copilot 团队则使用该模型评估聊天和智能体回复。微软称，Decision-1 的质量可与 GPT-5.6 Luna 相当，但运行速度快 100 倍。

微软还测试了该模型在事件响应中的表现。在这一场景中，工程师需要从日志、工单、消息、通话记录及其他来源中检索相关知识。该公司称，对于这类与检索相关的决策任务，Decision-1 的表现优于 LLM，速度也更快。

这些案例仍属于内部案例研究。它们比抽象承诺更有价值，因为描述了可识别的工作负载；但微软同时掌控着实现过程和结果报告。

Xbox 案例尤其适合处理客户访谈、产品评价或支持消息的团队。有限范围的分类器可以整理海量反馈，而知识系统则保留原始材料以供审查。团队仍需能够访问每个主题归类背后的证据。

这种分离方式同样适用于个人工作流。模型可以提出标签或优先级建议，而个人知识库则保留底层笔记和来源，供随时查阅。分类应当改善检索，而不应取代记录本身。

微软点名 Qwen 的决定也创造了未来的比较基准。如果该公司推出基于 MAI 的 Decision-1 后继版本，开发者便可测试微软在更换基础模型后，是否仍保持了延迟、校准和一致性。

基准测试无法解答自动化问题

快速、准确的基准测试结果，并不能证明 Decision-1 可以在无人监督的情况下安全地控制高影响力工作流。

微软在涵盖近 150,000 个问题的 36 项基准测试中评估了该模型。它还使用来自 11 项基准测试的 5,250 条请求进行安全测试，覆盖有害内容、提示词注入和越狱尝试。

这些评估工作具有意义，但基准测试的广度并不能消除特定部署场景中的错误。一个支持路由模型可能整体表现优异，却反复错误处理罕见的医疗、法律或安全相关请求。

同样的问题也适用于经过校准的概率值。校准取决于示例的分布。在一种请求组合上测试的模型，可能会在用户语言、政策或产品变化时变得过度自信。

因此，开发者必须依据目标工作负载中的已标注样本评估 Decision-1。测试集应包括常规案例、模糊案例、证据不完整的案例、对抗性输入，以及两个类别都看似合理适用的案例。

团队应审查高置信度错误，而不仅仅是平均准确率。低置信度错误可以转交人工审核。携带高置信度的错误答案则更可能触发自动化操作。

微软将置信度描述为决定执行、延后还是请求审核的机制。只有团队在计划采用的阈值下衡量错误率，这一设计才有价值。通用的置信度阈值不可能适用于所有类别。

后果应决定所需证据的标准。自动标记客户反馈的风险低于封禁账户。对搜索结果进行排序，与授权付款或更改生产基础设施并不相同。

Decision-1 也依赖开发者编写的判断标准。即使模型按设计运行，含糊或重叠的类别描述也可能导致行为不稳定。结构化输出无法修复结构不良的决策。

应用必须将行动策略与预测分离。模型可以估计某起事件属于安全队列，但应用代码仍应强制执行允许采取哪些行动、保留审计轨迹，并升级处理不确定案例。

当智能体可以调用工具时，这一点更为重要。微软将智能体控制列为使用场景之一，包括决定智能体应继续、停止、重试，还是将工作交给另一模型或人员。在这个节点上的错误选择可能影响后续步骤。

智能体控制模型还会面对由其他模型生成的输入。这些输入可能包含幻觉、格式错误的计划，或从外部来源复制的提示词注入内容。Decision-1 自身的安全测试并不能保证其在所有周边架构中都受到保护。

微软称，它在保留有用行为的同时测试了有害请求、越狱和提示词注入。独立评估仍需复现这些发现，还应测试间接提示词注入，即恶意指令出现在被分类的文档或网页中。

该公司的科学发现案例同样值得谨慎看待。Microsoft Discovery 使用自适应重新规划循环，对实验进行评分并修订计划。微软报告称，Decision-1 产生了显著更一致的评分，并加快了重新规划流程。

一致性有助于长期实验，但并不能证明科学正确性。一个始终错误的评分标准，可能会将重复工作引向无效路径。

这正是 Decision-1 最初应作为经过衡量的组件，而非不容置疑的权威来运行的原因。开发者可以将预测结果展示给审核人员、收集修正意见，并在观察到真实错误后自动化处理范围有限的类别。

组织还需要在部署后持续监控。新产品、政策变化、季节性语言和用户行为都可能改变输入分布。一个通过上线评估的模型，即使其权重没有任何变化，也可能发生性能退化。

决策日志应保留输入、判断标准、可选项、所选答案、概率值、模型版本以及下游操作。这些记录使团队能够调查错误，并比较未来的模型版本。

这些控制措施并非微软独有。它们适用于任何决策模型、分类器或基于 LLM 的评估器。Decision-1 让软件更容易消费其输出，但运营上的简洁不应被误认为是认知上的确定性。

因此，“公开预览”标签意义重大。微软向开发者提供的是一款可供评估的产品，而不是宣称它已经成为所有分类系统的既定替代方案。最有价值的早期部署将是边界明确、可逆且可衡量的。

Microsoft Decision-1 发布后值得关注的事项

三个信号将决定 Decision-1 会成为标准智能体组件，还是仅停留为一个有趣的 Foundry 选项。

第一个信号是独立复现基准测试结果。微软公布的速度、准确性、校准度和稳健性数据，为发布提供了有力依据。外部研究人员和生产团队现在需要在透明的硬件和工作负载条件下验证相同的主张。

一项有价值的独立评估应包括传统分类器、紧凑型 LLM、前沿模型和竞争性决策系统。它不应只衡量整体准确率，延迟分布、校准误差、故障稳定性以及输入发生变化后的表现同样重要。

若独立结果接近微软的数据，将强化专用模型的论点。若差距很大，则表明发布时的基准测试可能捕捉的是有利条件或工作负载。

第二个信号是向 MAI 和 OpenAI 基础模型迁移的计划。微软表示后续迭代将使用这些模型系列，但尚未说明重新构建基础模型会如何影响行为。

后继版本应在保留结构化 API 的同时提升可衡量的性能。开发者会希望了解概率值是否仍可比较、提示词能否顺利迁移，以及旧阈值是否依然适用。

如果基础模型变更迫使用户进行大量重新测试，就会削弱 Decision-1 作为稳定产品层的理念。如果过渡平稳，则会支持微软将基础模型视为可互换实现细节的策略。

第三个信号是微软团队之外的生产采用情况。Xbox、Copilot、事件响应和 Microsoft Discovery 提供了有价值的演示，但都处于供应商自身的组织内部。

外部案例研究应披露工作负载、基线、审核流程和量化的错误成本。一个节省时间却增加升级处理量的路由系统，可能无法带来净改善。如果反馈分类器能够在不隐藏重要少数主题的前提下减少人工整理，它便可能取得成功。

采用情况还将显示，开发者究竟更偏好专用决策 API，还是熟悉的聊天补全接口。结构化决策格式提供了更清晰的契约，但团队已经围绕提示词和 JSON 输出建立了广泛的工具体系。

如果开发者开始围绕不同的模型角色设计智能体管道，Decision-1 将变得具有战略重要性。一个模型负责生成，另一个负责检索，而 Decision-1 则负责分类或控制。承载智能的将是应用，而非任何单一模型。

这种架构带来了新的工程工作。团队必须跨组件追踪决策、管理版本，并确定每一步由哪个模型负责。他们还需要代表完整系统的共享评估数据。

回报是更强的控制力。模块化管道可以将昂贵的推理留给真正困难的案例，把重复性分类交给更快的模型，并将不确定输出路由给人工。

对于知识工作者而言，实际影响往往仍然不可见。更快的分类可以整理进入的材料、确定通知优先级或分发请求，而不会生成一段可见文字。这些隐藏决策的质量仍会塑造用户所看到的内容。

评估这类工作流的人应提出一个直接问题：系统能否说明某个项目为何获得该标签，并保留原始证据？用于知识融合的工具可以帮助用户跨来源材料开展工作，但它们本身无法纠正不可靠的决策策略。

Microsoft Decision-1 值得关注，是因为它挑战了通用 LLM 的默认使用方式，而不是因为某位 CEO 分享了它的发布消息。Microsoft 将 Qwen3.5-9B 打造成一个边界明确的决策引擎，并将其纳入 Foundry 日益扩展的模型目录。

该公司的基准测试结果让这款模型值得一试。但这些结果并不能让其预测自动得到验证，也不能免除高影响工作流中人工审核的必要性。

开发者应从一个范围狭窄的决策场景开始：该场景应已有带标签的示例，并具备明确的回退方案。将 Decision-1 与现有方法进行比较，检查那些高置信度的错误，并衡量整个工作流，而非只关注单一基准分数。

专用决策模型会成为 AI agents 的控制层，还是性能更强的通用模型会吸收同样的工作？答案将来自独立测试、Microsoft 承诺的重新基准测试，以及真实部署所提供的证据。