Strands Decider 2B：2B 参数的开源决策模型，本地几十毫秒出结果

决策模型（decision model）正在成为 Agent 架构里的新一层：它不生成文本，只在一组选项里做选择、给分数，但更快、更省、还自带可靠度评分。

原文：Introducing Strands Decider 2B: a small, open source, decision model，Strands Agents 官方博客，2026 年 10 月 1 日，作者 Marc Brooker、Mike Chambers、Fabio Nonato de Paula。本文为中文翻译整理，代码与数据均取自原文。

今年早些时候 Strands 团队公布了 strands-labs，一个用来动手试最新 agentic AI 方法的地方。这次他们往里加了一个新东西：Strands Decider 2B，一个为快速实验、本地开发和创新优化的小型决策模型。

Strands Decider 属于"决策模型"（也叫 system one model）这一新类别。自 TypeSafe AI 本月发布 Jev 之后，这类模型开始受到大量关注。和可以生成任意输出的 LLM 不同，决策模型被设计用来在一组选项之间做选择（例如"'turn on the lights' 这句话和咖啡机有关吗？是或否。""'sihamba ngokushesha' 这句是什么语言？英语、祖鲁语还是荷兰语。"），以及给出简单的数值评分（例如"'这是我读过最好的文档' 情感是正向的吗？0 到 1 之间。"）。

用灵活性换来的，是决策模型的几个硬优势：同等规模下更快、更强；永远从给定选项里给出答案；并且可以以极低延迟运行。

代价也很明确：这种"一次并行前向算出所有输出"的方式，让它在解决复杂问题上明显弱于 reasoning 模型；而无法生成文本，也使它不适合编码、聊天机器人、文档摘要这些 LLM 的常见任务。

此外，决策模型会为每个决策给出高质量的可靠性分数（也就是"这个 yes/no 我有多确定"），这是前沿 LLM 推理 API 不提供的。它还能极其高效地对同一个 prompt 提多个问题。这些特性组合起来，正好适合驱动许多开发者正在用 Strands Harness SDK 和最近发布的 Strands harness 构建的那类 agentic 工作流。Strands 团队预计，这一类模型会在未来几周、几个月乃至几年里，给 agentic AI 带来大量有意思的创新。

Strands Decider 2B 是他们在这条路上的第一个贡献：一个 20 亿参数的模型，可以跑在本地 CPU 或 GPU 上，能在几十毫秒内对有意义的问题给出回答，准确率和校准度与目前已知的同类别模型具备竞争力。代码以开源形式发布在 GitHub，权重放在 Hugging Face，连构建模型用的全部训练数据和脚本一并开源。

本文提纲

1. 决策模型是什么：它和 LLM 的分工
2. 模型架构：砍掉 LM head，换上 pointer head
3. 三项指标：准确率、校准度与延迟
4. 为什么偏偏是 2B
5. 能拿来做什么
6. 上手：CLI 与 Strands Agent 里的干预示例

决策模型是什么：它和 LLM 的分工

先把这类模型的定位说清楚。LLM 的能力边界是"生成任意文本"；决策模型的边界是"从给定选项里选一个，或者打一个 0 到 1 的分"。

这个约束换来了三件事：

• 同尺寸下更快、更强：不生成文本，就不需要在词表上做完整解码。
• 答案永远合法：输出必然落在给定选项集合内，不存在"编了一个不存在的选项"。
• 延迟极低：原文给出的量级是几十毫秒。

它还附带一个 LLM 推理 API 通常拿不到的东西：每个决策的可靠度分数。这一点对生产环境的 Agent 很关键——当决策本身带置信度时，上层就能据此决定是放行、追问用户，还是升级给更强的模型。

反过来，局限同样明显：单次并行前向让它在复杂问题上远不如 reasoning 模型；不能生成文本，所以编码、对话、摘要这些活它干不了。它不是一个更小的 LLM，而是另一种东西。

模型架构：砍掉 LM head，换上 pointer head

Strands Decider 2B 的核心思路很直接：

1. 取一个预训练好的 LLM 躯干（Qwen3.5-2B），去掉 LM head，也就是拿掉它生成文本的能力；
2. 用一个 pointer head 替换 LM head。这个头会把每个选项位置的 hidden state 与 <answer> 位置的 hidden state 做打分对比，从而为每个选项给出分数；
3. 这个 head 非常小，总参数只有一百万多一点；
4. 躯干用 rank-16 的 LoRA 适配器做微调。

翻仓库时你会发现，这已经是该架构的第二个大版本。第一版思路类似，但用的是 slot head，实测效果明显更差。事实上这次发布的模型是 v19，背后经历了大量迭代，每个版本改了什么仓库里都有记录，可以跟着一路看过来。

三项指标：准确率、校准度与延迟

对这类模型，团队关心三个性能目标：准确率（答得对不对）、校准度（置信度分数可不可信）、延迟（决策有多快）。

前两项是一起测的：准确率用 JevBench 公开集，校准度用同一数据集上的 Brier score。结果是 strands-decider-2b 在两项上表现都不错——2B 级别的 33 个模型中排第 3；如果剔除那些刚超过 2B 的模型，30 个里排第 1。随着架构迭代，分数还在变好，团队手里也有不少后续改进的想法（原文鼓励社区一起贡献）。

延迟方面，在市面上常见的硬件上，本地决策的中位延迟约 115 毫秒。决策耗时与任务规模相关，大致随任务规模近似线性增长。原文给出的数据是在本地 NVIDIA RTX 3090 上测的，但在 M3 MacBook 上表现也没差太多——小型任务的中位延迟约 153 毫秒。团队表示在降低延迟下限上还有很多想法。

为什么偏偏是 2B

把 Strands Decider 做成小模型有两个原因。

一是鼓励实验。你可以直接在自己已有的硬件上使用它，甚至训练它，试错成本低、速度快、风险小。

二是 20 亿总参数像是一个甜点位置：小到方便做实验，又大到能真正干活。例如 strands-decider-2b 在 JevBench 上的简单任务做到了 100% 正确，而这类问题恰好对应人们在 Agent 里经常遇到的那批较简单的判断。

能拿来做什么

原文的回答是"想做什么都行"，然后给了更严肃的清单。目前看到早期落地效果的场景包括：模型路由、工具选择、评测、护栏（guardrails）、记忆、上下文管理、策略分类。

另一个方向是混合 Agent：用 LLM 做最难的决策，用决策模型做那些简单、重复、程式化的判断，从而同时降低成本和延迟。还有人把决策模型和固定工作流语言结合起来，做出另一种混合工作流。除此之外，也有人在用这类模型玩游戏、做任务自动化、走迷宫——这个领域的创新速度相当惊人。

上手：CLI 与 Strands Agent 里的干预示例

最简单的入口是 strands-decider CLI：

pip install strands-decider

选择题

你可以让模型基于一段状态和一个问题来选：

strands-decider ask StrandsAgents/strands-decider-2B-hobson-v19 \
  --state "Help! My payouts have been failing for 3 days! " \
  --choice "Which team should handle this?=billing,sales,retail"

输出示例：

choice_0 -> billing (confidence 0.768)
  billing                  0.845
  retail                   0.091
  sales                    0.064

可以看到，模型把 billing 作为概率最高的答案，并给出了 0.768 的置信度。

放进 Strands Agent：拦截一次"凭感觉"的工具调用

仓库的 examples/strands/ 下还有把 strands-decider-2b 用进 Strands agent 的示例：agent 本身跑在本地，连接同样跑在本地的 Strands decider，再使用 Amazon Bedrock 上的默认 LLM。

场景是刻意设计得比较小的。agent 有一个（必不可少的）演示工具 get_weather，以及一个让它"过度积极"的 system prompt：用户只问"What's the weather?"、没说城市时，agent 会自己猜一个城市然后直接调工具。但在这次调用真正执行之前，strands-decider-2b 会读取对话和这个待执行的工具调用，回答两个 yes/no 问题：

• 这些参数值有没有用户真实说过的依据？（剧透：没有）
• 现在还没跟用户确认，就调用这个工具是不是太早了？

几行 Python 就能把预测结果变成决策，于是 agent 转而回头去问用户指的是哪个城市，而不是自信满满地汇报一个没人提过的地方的天气。

QUESTIONS = {
    "args_grounded": Decider.noul(
        "Are the tool's argument values grounded in facts the user actually provided?",
        {
            "true": "every argument value traces back to something the user said",
            "false": "an argument value was guessed or invented, not stated by the user",
        },
    ),
    "premature": Decider.noul(
        "Is it premature to call this tool now, before clarifying with the user?",
        {
            "true": "the assistant should ask a clarifying question before calling the tool",
            "false": "there is nothing left to clarify; calling now is appropriate",
        },
    ),
}

这里用的模式就是 Strands 的干预系统（intervention system）：实现带 before_tool_call 方法的 InterventionHandler，传给 Agent(interventions=[...])，它会在任何工具执行前运行。它返回的是一个有类型的动作：Proceed、Deny、Confirm（停下来问人）、或者 Guide——把这一轮交还给模型并附上反馈，而不是直接阻断调用。这个 handler 本身就是一个 Python 类，Strands 不关心里面装的是什么，所以无论你调用的是他们的决策模型、一条 Cedar 策略，还是另一个 agent，形状都是一样的（模型调用前后、以及整个 invocation 前后也有等价的 hook）。原文强调：这个例子是示意，不是推荐用法，其中的问题、阈值和策略都是手工挑的。真正想说明的是：便宜到这种程度的决策，可以放在 LLM 调用永远放不起的路径上。

Strands 团队正在做决策模型集成的库，可以关注仓库的后续更新。

参考链接

• 原文：Introducing Strands Decider 2B - Strands Agents 官方博客，2026-10-01
• GitHub: strands-labs/strands-decider - 开源代码、训练数据与脚本
• Hugging Face: StrandsAgents - 模型权重
• Strands Agents 官网 - Harness、Harness SDK、Shell、Evals 等文档

你会把决策模型放在 Agent 的哪一层？是模型路由、工具选择，还是 before_tool_call 的护栏？评论区聊聊你的想法。

---

作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。