Microsoft-Decision-1 上线：首个 systemone 调用与免费输出

Microsoft-Decision-1 发布

微软把 Microsoft-Decision-1 推上了 Foundry 和 OpenRouter，时间点紧随 Liquid 开源 d1 权重发布之后。这款模型瞄准的赛道很明确：不要再让聊天模型吐 JSON 了，把决策交给专门的决策模型，让它返回类型化的概率值。

接入方式上的差异值得留意。Liquid 给的是权重文件，微软给的是托管的 systemone 端点，定价为每百万输入 token $0.042，输出免费，底座模型是 Qwen3.5-9B，并明确表示后续会 rebase 到 MAI 和 OpenAI 模型上。API 形态两边一致，但那句 rebase 的备注才是真正的坑。

它到底返回什么

按 Microsoft Learn 和 OpenRouter 页面的说明，一次请求不是 chat completion。你需要传入一个 state（字符串或 JSON）加上带名字的 questions。每个 question 有三种类型：

type	你提供	你得到
`noul`	一个是/否条件	`[0, 1]` 区间内的 `P(yes)`
`choice`	带描述的命名选项	选中项 + 每个选项的概率
`score`	有序评分标准（2 级以上）	概率加权的等级索引

没有自由文本，也没有书面理由。这正是设计意图所在。你的代码拿到概率后自行做阈值判断，决定路由、分流工单或拦截工具调用。Foundry 上的端点路径为：

<your-foundry-resource-endpoint>/providers/microsoft/v1/systemone

请求里的 model 字段填的是你的部署名称，而不是 Microsoft-Decision-1 这个字符串。OpenRouter 上的模型 ID 是 microsoft/microsoft-decision-1，并且官方文档明确指出 chat-completions SDK 用不了，必须走 Decisions / System One 接口。

什么是"决策模型"（Decision Model）

决策模型是一类专门为"在有限选项中做出选择"而设计的模型，与生成模型的根本区别在于输出空间。生成模型的自回归解码过程允许在任意 token 序列上分配概率，因此输出是自由文本；决策模型则把输出约束在预定义的结构上——一个是/否判断、一组命名选项、或一个有序等级。这种约束带来三个工程上的好处：一是无需解析，返回值天然就是程序可用的类型；二是校准度可以在训练时直接针对任务目标优化，而不是靠 prompt 碰运气；三是推理成本极低，因为不需要生成完整句子，只需前向计算若干 logits。这类模型通常也被称为分类器或判别模型，但当它作为 API 端点托管、接受自然语言 instructions 和 criteria 时，形态上更接近"可编程的判断函数"。微软把 Decision-1 定位为生成模型的补充而非替代，正是基于这一定位差异。

noul、choice、score 三种类型的设计含义

三种类型对应三类常见的业务判断。noul 返回一个标量 P(yes)，适合二值门控，比如"这个请求是否涉及生产数据"——阈值由调用方设定，模型不替你做决定。choice 返回命名选项上的分布，适合多路路由；关键设计点是它总会选中一个，因此必须显式提供弃权选项，否则模型被迫在证据不足时仍给出答案。score 返回概率加权的等级索引，输出是一个带权平均的连续值而非单个整数，这让"偏中间"的判断能被阈值区分出来，适合严重程度分级或步骤质量打分。三者的共同点是都不返回自由文本和书面理由，这是刻意的：理由会引入不可解析的噪声，也让评估变得困难。调用方拿到概率后自行做阈值判断，把决策逻辑留在自己的代码里，模型只负责提供校准过的证据。

微软官方给出了哪些数据

根据 Achint Srivastava 的博客，以下均标注为厂商数据：

在微软的 36 项基准测试对比中准确率最高，约 15 万个问题在训练时保持盲态。
延迟测试中（P50）比 GPT-6 Sol 快约 35 倍，比 H2O-Lightning-4B v1.1 快 2.5 倍。
在八种输入扰动下，决策平均翻盘率仅 1.3%；当选项描述被改写或选项顺序颠倒/打乱时，零翻盘。
Xbox Research 场景：对 1 万多条反馈标注与 GPT-6 Sol 持平，速度快 14 倍以上，成本低约 200 倍（微软的表述）。
Copilot 质量评分：与 GPT-5.6 Luna 持平，速度快约 100 倍（微软的表述）。

这些数字我没有复现过。建议把它当作发布声明，然后在自己的标注工单集上实测。

第一次调用的请求形态

一次调用可以在同一个 state 上问三个问题。以下模式来自 Learn 和 OpenRouter 文档：

import json, os, urllib.request

body = {
    "model": os.environ["DEPLOYMENT_NAME"],  # 你的 Foundry 部署名称
    "state": "Help! My payouts have been failing for 3 days.",
    "questions": {
        "is_urgent": {
            "type": "noul",
            "instructions": "Does this message convey urgency?",
            "criteria": {
                "true": "Explicitly time-sensitive",
                "false": "No urgency expressed",
            },
        },
        "team": {
            "type": "choice",
            "instructions": "Which team should handle this?",
            "criteria": {
                "billing": "Payments, invoicing, refunds",
                "technical": "Bugs, outages, integrations",
                "sales": "Pricing, upgrades, new accounts",
                "cannot_tell": "Not enough information, or not a support request",
            },
        },
        "frustration": {
            "type": "score",
            "instructions": "How frustrated is the customer?",
            "criteria": ["Calm", "Frustrated", "Very angry"],
        },
    },
}

上生产之前有三件事要注意。cannot_tell 是故意设计的——choice 类型总会选一个选项，没有弃权标签的话，乱码也会被分配到一个团队。Learn 文档明确建议在不应强制选择时加入弃权选项。选项描述就是策略本身："Payments, invoicing, refunds" 并不覆盖 "这封钓鱼邮件是你们发的吗？"，如果钓鱼属于欺诈/安全类别，就得写进 criteria 里。认证方式支持 Entra ID 或 api-key，Learn 推荐用 DefaultAzureCredential。

成本算术

微软和 OpenRouter 都标注 $0.042 / 1M 输入和 $0 / 1M 输出。输出免费是因为这类调用没有传统意义上的 completion token——你拿到的是结构化答案。

举个例子：10 万次请求 × 2,000 个计费输入 token ≈ $8.40 的模型输入费用（不含重试、检索、审核和平台费用）。这就是决策模型在路由这类无聊但占比 80% 的场景里显得划算的原因。OpenRouter 标注的上下文窗口是 32,768 token，纯文本输入，结构化决策输出，不支持图像或音频。

为什么输出 token 可以免费

传统定价按输入和输出 token 双向计费，因为生成模型需要逐 token 自回归解码，输出长度不确定且直接消耗算力。决策模型的输出是固定结构的：noul 只需一个标量，choice 只需在有限选项上做一次 softmax，score 只需对有序等级算一个加权索引。这些计算在模型最后一层前向之后即可完成，不需要生成任何自然语言 token，因此输出侧几乎没有边际推理成本。微软和 OpenRouter 把输出定价为 0，反映的正是这一结构性差异，而不是营销补贴。理解这一点对成本估算很实用：决策调用的费用完全由输入侧决定，也就是 state 加 questions 加 criteria 的总长度，重试和输入膨胀才是成本的主要变量，输出无需担心。

Qwen 到 MAI 的 rebase 才是关键

微软说 Decision-1 是从 Qwen3.5-9B 后训练而来，并且很快会 rebase 到包括 MAI 和 OpenAI 在内的其他底座上。API 形态承诺保持不变，但底下的权重会换。

实际后果有三点。第一，不要把"这是 Qwen 模型"写死到监控、评估框架或合规文档里当作永久事实，要固定你评估过的部署/模型版本。第二，任何静默底座切换之后都要重新跑标注集——校准度和翻盘率是产品声明，不是合同，rebase 之后不重新测量就不成立。第三，如果你需要开放权重或气隙推理，这款产品不对路，Liquid d1 才是本地路径，Decision-1 是 Foundry/OpenRouter 内的托管路径。

什么是"rebase"以及为什么它比版本升级更麻烦

在后训练语境里，rebase 指的是保留原有的接口、任务定义和输出契约，但把底层的基座模型整体替换掉，然后在新基座上重新做对齐训练。这不同于普通的小版本迭代——权重、知识分布、分词器行为都可能改变，甚至训练数据之外的泛化特性也会漂移。对使用者而言，API 形态不变意味着代码不用改，但模型的校准曲线、对 criteria 措辞的敏感度、以及在不同输入扰动下的稳定性都可能重新洗牌。微软把 Decision-1 的底座从 Qwen3.5-9B 换到 MAI 和 OpenAI 模型，正是典型的 rebase 场景：服务名和端点保持不变，但每次切换后你之前测得的所有概率阈值和翻盘率数据都可能失效。这也是为什么文章强调要固定"部署/模型版本"而非模型名称，并在切换后重跑标注集。

在 agent 中怎么接

用 noul 把守工具调用。 "这个工具参数是否触及生产数据？"——只有高于高阈值才自动放行，否则交给人工或更强的模型。

用 choice + 弃权做路由。 当 cannot_tell 胜出或最高概率低于阈值时升级处理，阈值从 0.7 左右开始调。

用 score 给 agent 步骤打分。 在执行前对提议的下一步动作按评分标准打分。

不要让 Decision-1 参与重大人事决策。 微软自己的模型卡和 Learn 页面都写明，不得将其作为就业、信贷、医疗等决策的唯一依据。

记录 state、criteria、answers 和你采取的动作。 路由出错时，你需要判断是证据缺失、选项描述不当，还是阈值设错了。

为什么这件事值得关注

Agent 技术栈里充斥着"调用 LLM、求它输出 JSON、解析"的套路。一个托管式的决策端点，返回校准过的概率、输出不收费、还直接放在 Foundry 部署旁边，对路由、门控和评分来说是一个具体的替代方案。它不替代生成模型做写作，但能让你不再用生成模型去回答一道选择题。

边缘和离线场景继续用 Liquid 的开源 d1，已经在 Azure 或 OpenRouter 生态里的选 Microsoft-Decision-1。在信任任何一个之前，先用同一套标注集把两个都测一遍。