评估一个 AI 智能体时，最麻烦的不是打分，而是分数本身不可信。同一个回答，让大模型当裁判，这次说 4 分、下次说 3 分，理由还写得头头是道。2026 年 11 月 4 日，AWS 在官方博客给出另一种解法：把 Amazon Bedrock AgentCore Evaluations 的评分环节交给“决策模型”（decision model），也就是一类只从固定选项里做选择、返回校准概率、不生成自由文本的小型专用模型。配合这篇博客一起露面的，还有 AWS 开源的 Strands Decider 2B，一个 20 亿参数、能在本地跑、中位延迟约 115 毫秒的决策模型。
这件事的意味不止于多了一个评估器。它意味着 agent 评估正在从“让大模型写评语”转向“用专用小模型做可阈值化的结构化裁决”。
现象层：评估的痛点
AgentCore Evaluations 是 Amazon Bedrock AgentCore 的一项能力，负责在 agent 的整个生命周期里打分：开发阶段按需评、对存储会话跑批量任务、对生产流量做在线评分。它自带 15 个内置评估器，也支持两类自定义评估器，一种是用 Bedrock 模型按你的指令和评分标准打分的 LLM-as-a-judge，另一种是在 AWS Lambda 里跑你自己逻辑的 code-based 评估器。
AWS 这篇博客点出的问题很具体：有些评估问题又窄又可重复。“这个回答是否遵守了政策？”“这次工具调用批准起来安全吗？”“这个答案和检索到的上下文一致吗？”这类问题不需要一篇小作文，只需要一个标签和一个可以设阈值、可以信任的数字。
内置的 LLM-as-a-judge 评估器会给出分数加理由。这在需要连接证据、识别缺失信息、把回答层层拆解的任务里很有价值，因为解释本身和分数一样有用。但它的代价是置信度会漂移：同一份输入，不同轮次可能给出不同分数，而且每次都要调用一次通用大模型，成本和时间都不低。
决策模型正好补在这个缝隙里。它吃进去的是结构化状态和一组固定允许答案，吐出来的是这些答案上的校准概率分布。你拿到的不是一个会漂移的自由文本，而是一个可以直接阈值化、聚合、编程执行的可信数字。
决策模型到底是什么
决策模型是一类小型专用模型，训练目标就是从固定选项中选择，并返回校准后的置信度分数，而不是生成自由文本。TypeSafe 把它称作“System One Models”，灵感来自丹尼尔·卡尼曼《思考，快与慢》里快而直觉的系统 1 与慢而审慎的系统 2 之分。TypeSafe 给它的托管决策模型取名 Jev，致敬经济学家威廉姆·斯坦利·杰文斯，蒸汽机效率提升反而推高了煤炭需求，智能成本每下降一个数量级，同样会解锁数量级更多的使用场景。
Jev 和 Strands Decider 2B 都支持三种问题类型：
- “noul”：是非题，返回 0（否）到 1（是）之间的概率
- “choice”：最多 255 个选项，返回概率最高的选项、完整分布和置信度
- “score”：2 到 10 个有序等级，返回概率加权分数、等级分布和置信度
“这个回答里的每个事实都有工具结果支撑吗？”是是非题；“这个回答在四级评分标准下有多有帮助？”是 score 题。很多评估量表天然就落在这三种类型里。
Strands Decider 2B 的硬指标
Strands Decider 2B 是 AWS Strands Labs 开源的决策模型，Apache 2.0 许可，权重挂在 Hugging Face 的 StrandsAgents 组织下，训练数据和构建脚本也一并开源在 GitHub（strands-labs/strands-decider）。Strands Agents 团队的 Marc Brooker、Mike Chambers、Fabio Nonato de Paula 在官方博客里披露了更多细节。
架构上，它拿预训练的 Qwen3.5-2B 做躯干（torso），拆掉 LM head，换上一个 pointer head 来给每个选项打分。这个 head 很小，总共一百多万参数；躯干用 rank-16 的 LoRA 适配器微调。当前发布的是 v19 版本，背后经历了大量迭代，第一代用的是 slot head，表现明显更差。
性能数据很能说明这类模型的定位：
- 在 JevBench 公开集上，2B 级别 33 个模型里排第 3；排除那些略超 2B 的模型后，30 个模型里排第 1
- v19 checkpoint 在 231 个公开任务上准确率 72.3%（167/231），Brier 分数 0.342，期望校准误差 0.052
- JevBench 上的简单任务 100% 做对，标准难度任务 87.5%，困难任务 50.5%
- 延迟：RTX 3090 上中位数约 115 毫秒；M3 MacBook 上小任务中位数约 153 毫秒，且随任务 token 数近似线性增长
115 毫秒意味着什么？意味着你可以在 agent 每次调用工具前都拦一下做安全裁决，而不会让用户体验出现可感知的卡顿。这也是决策模型和推理模型的分野：它用单次并行前向生成所有输出，换来的是速度，牺牲的是复杂问题解决能力。AWS 写得很直白，它不适合编码、聊天机器人、文档摘要这些通用 LLM 任务。
不是替代，是筛选层
AWS 在博客里反复强调一件事：决策模型不是 LLM 评估器的替代品，而是补充。
做法是把决策模型当成筛选层。因为它一次请求能对同一状态回答多个问题，你可以先让它跑一轮 pass/fail 信号扫过所有指标，只把那些需要深入评估的轮次挑出来，交给内置评估器，后者的解释能帮你调查到底哪里出了问题。
博客给出的示例是一个 HR Assistant agent，用 Strands Agents 构建，部署到 AgentCore runtime，靠五个返回固定 mock 数据的工具回答员工关于 PTO 余额、PTO 申请、HR 政策、福利和工资单的问题。评估由三部分组成：确定性代码检查、内置 LLM-as-a-judge 评估器，以及由 Jev 或 Strands Decider 2B 驱动的决策模型评估器。用固定数据是为了方便验证评估器行为；当你还有 ground truth 时，可以确认每个评估器是否抓住了该抓住的错误。
实践路径也很务实：先在你自己的流量上验证决策模型对某个问题的判断，确认它对你的参考标签有多高的吻合度，再逐步扩大覆盖。信任建立起来之后，它既可以单独胜任某个评分，也可以扩展到政策里的具体有害性或刻板印象类别。
谁会赢，谁危险
决策模型真正威胁的，是那些把“评估”简单等同于“调个大模型写评语”的方案。当评估问题可以被表述为固定选项上的选择，且你需要可阈值化、可聚合、可追溯的置信度时，决策模型在速度、成本和一致性上都有压倒性优势。
对开发者来说，最现实的路径不是二选一，而是分层：决策模型做窄而可重复的检查，LLM-as-a-judge 做需要连接证据和深度解释的评估，确定性代码做兜底。AWS 已经把这条路铺到了 AgentCore Evaluations 里，通过 code-based 评估器，你可以把 Jev 这样的托管 API 或 Strands Decider 2B 这样的本地模型接进去，把 AgentCore 的评估器输入转成决策模型请求，再把模型的概率转回评估结果。
这里还有一层竞争格局值得注意。TypeSafe 的 Jev 走的是托管 API 路线，Strands Decider 2B 走的是开源本地路线，两者在 JevBench 上正面比拼。一个 2B 参数的小模型能在 231 个公开任务上拿到 72.3% 的准确率，说明这类“系统 1”模型已经跨过了可用的门槛。接下来拼的不是谁更大，而是谁更稳、更便宜、更容易嵌进已有的 agent 流水线。
Agent 评估的下半场，裁判不再需要会写小作文。当 115 毫秒就能给出一次可校准的裁决，那些靠自由文本漂移出分的“大模型法官”，正在被一群又快又稳的“小模型仲裁员”取代。
快报