Amazon 推出 AWS Strands Decider 2B，Jev 类模型持续涌现

Amazon Web Services 发布了 AWS Strands Decider 2B，这是一款面向有限选择而非开放式文本生成的开放模型。就在 TypeSafe AI 推出 Jev 数周后，此次发布让 AWS 直接加入了快速升温的决策模型竞争。

这些模型有望为 AI 智能体提供不同的基础。软件不再要求大语言模型描述下一步行动，而是给出固定选项，并获得带有置信度评分的选择结果。

这种更收窄的约定带来了速度和可控性，但也形成了一项严苛考验。AWS 必须证明，其模型在精心设计的基准测试之外依然准确、校准良好且实用。与此同时，随着更大的平台采纳同一基本理念，TypeSafe 也必须守住先发位置。

这一时机进一步提高了赌注。OpenAI 也在同一周宣布了限量预览版 Decisions API，表明专用决策层正成为智能体基础设施的重要组成部分。

AWS Strands Decider 2B 将实验转化为开放模型

AWS 已将一位工程师受 Jev 启发的实验，转化为面向智能体工作流的完整开放式决策模型。

Strands Labs 于 2026 年 10 月 1 日发布了该模型。该组织围绕 Strands Agents 生态系统开发实验性工具和协议。

官方发布详情将 Strands Decider 2B 描述为一款针对本地开发、实验和智能体自动化优化的小型模型。其权重、训练脚本和训练数据均已公开提供。

尽管产品名称如此，初始模型实际包含 19 亿个参数。AWS 表示，它可在本地 CPU、Apple silicon Mac 或兼容 GPU 上运行。

该模型不会撰写段落、编写代码或总结文档。它接收一个状态、获得一个或多个结构化问题，并对开发者定义的选项进行评估。

客户支持系统提供了一个直观示例。状态中可能包含一条关于付款失败的投诉。模型随后可以选择将该案例交给账单、销售或其他团队。

它也可以评估一个是非陈述，或在有序量表上指定一个位置。每个回答均包含评分，软件可据此决定是采取行动、升级处理，还是请求人工审核。

这种输出约定将决策模型与普通聊天机器人区分开来。生成式模型可能返回解释、限定条件或格式错误的结构。Strands Decider 必须从呈现给它的选项中作出选择。

AWS 通过公开模型仓库发布了实现。开发者可通过命令行界面运行该模型，或将其部署在 HTTP 端点之后提供服务。

该仓库描述了在 Nvidia RTX 3090 上 115 毫秒的中位响应时间。这一结果仅适用于已公布的测试环境，并非通用的延迟保证。

该系统能够针对同一段文本评估多个问题，而无需反复处理完整状态。当智能体在采取行动前需要进行多项检查时，这一设计尤为重要。

例如，智能体可以对传入请求分类、估算紧急程度并选择处理人员。它无需让更大的模型分别生成三份解释，即可完成这些判断。

AWS 表示，置信度是该设计的核心。在简短、此前未见过的分类任务中，该项目报告称，高于特定置信度阈值的回答约有 95% 是正确的。

这仍是项目自身的评估，而非覆盖生产工作负载的独立证明。但它展示了预期的运行模式：自动处理高置信度案例，并将不确定案例转交处理。

此次发布形成了本文的核心张力。构建一个开放、快速的决策模型如今已相对容易。要让置信度评分在陌生环境中持续可信，则困难得多。

为什么智能体工作流需要更小的决策模型

大多数智能体步骤不需要一款能够写论文的模型，但它们仍然需要比固定规则更强的判断力。

现代智能体通常结合多种工作。它们解释请求、检索信息、选择工具、检查政策，并决定是否应调用另一款模型。

大语言模型可以处理所有这些步骤。但当工作流只需要一个有界答案时，它们的灵活性也会带来额外开销。

例如，工具路由器可能需要在搜索、电子邮件、日历或文档检索之间作出选择。由于软件已经知道可用操作，生成式回答就变得没有必要。

结构化输出功能可以约束大模型的回答。但底层系统仍会执行自回归生成，按顺序生成 token，直至回答完成。

决策模型消除了这一生成循环。它并行评估提供的选项，并返回它们的相对评分。

这一设计对重复性的工作流关卡尤其有吸引力。企业智能体可能需要在执行前检查每一项拟议操作，而不仅仅是展示给用户的最终回答。

设想一个正在准备账户报告的智能体。它可能需要决定哪些文档相关、信息是否存在冲突，以及敏感内容能否离开内部系统。

这些判断可在一项任务中发生多次。将每一道关卡都发送给前沿模型，可能增加延迟和运营复杂性。

AWS 杰出工程师 Marc Brooker 正是从这一工作流问题出发产生兴趣。他公开的工程笔记将决策模型描述为具备明确步骤的智能体的实用构建模块。

在 TypeSafe 于 9 月 15 日发布 Jev 后，Brooker 启动了名为 Hobson 的个人项目。他将实验规模限制在约 20 亿参数，并测试了多种架构。

该工作经历多个版本后，AWS 才将其作为 Strands Decider 2B 准备发布。公开模型为第 19 版，反映出简洁接口之下经历了大量迭代。

Brooker 报告称，该模型一度与其他同等规模的参赛条目并列公共 JevBench 排行榜首位。他也承认，从该基准测试得出结论存在局限。

这种坦率很重要，因为智能体路由并非普通文本分类。错误标签可能选择不合适的工具、暴露数据，或发起不受欢迎的外部操作。

置信度评分为此类风险提供了一种应对方式。工作流可以接受高置信度选择，同时将不确定案例交由更强的模型或人工处理。

这种方式形成了分层智能体架构。小型决策模型负责处理常规关卡，而生成式或推理模型则应对模糊任务。

这一模式更接近普通软件工程，而非一个无所不知的单一助手。不同组件承担不同职责、接口和失败处理策略。

开发者早已使用规则、分类器和嵌入模型构建此类系统。决策模型有望提供更广泛的语言理解能力，同时不放弃结构化输出。

这一前景解释了 AWS、OpenAI、研究人员和独立开发者的突然关注。它也给当前将每一步都路由给单一大模型的团队带来压力。

异构工作流需要更多设计工作。开发者必须定义合法选项、设定置信度阈值、记录结果并建立升级路径。

但它仍可能比单一、不受约束的智能体提供更好的控制。构建可搜索技术知识的团队，在搭建工程知识库时也可以采用类似的分离方式。

关键问题并非更小的模型能否作出决策，而是它们能否在真实软件中常见的混乱条件下作出正确决策。

AWS Strands Decider 2B 以开放性挑战 Jev

核心竞争是 AWS Strands Decider 2B 对阵 Jev：开放性与可复现性，正面临专有数据与专业化开发的较量。

TypeSafe 将 Jev 描述为 System One 模型，借用这一标签来指代快速而直觉性的判断。它返回类型化决策，而非自由形式文本。

Jev 帮助确立了当前的决策模型类别。开发者提供一个状态和问题，随后获得选择、量表位置或概率，而不是散文式回答。

AWS 明确表示，Jev 为其项目提供了灵感。这使得 Strands Decider 不只是围绕类似市场需求构建的偶然竞争者。

这两项工作目前提出了不同主张。AWS 提供权重、脚本、数据、代码，以及开发者可在自有硬件上运行的模型。

TypeSafe 提供商业模型，并主张有用的智能不仅取决于复制一种架构。其高管强调数据质量、训练纪律和持续的模型改进。

TypeSafe CEO Diogo Almeida 告诉 TechCrunch，大量实现方案可能低估模型智能本身仍有多么困难。他将许多新入局者描述为架构实验，而非持续发展的智能项目。

这项批评指出了关键竞争问题。开放实现可以被检查、修改和本地部署，但开放性并不保证更好的判断。

专有服务可以在不公开每个组件的情况下改进数据和模型。客户随后必须信任供应商的测量结果，并通过 API 观察性能。

AWS 的发布使架构更容易研究。Strands Decider 以 Qwen3.5-2B-Base 的模型主干为起点，即预训练 Transformer 的内部网络，不含其文本生成头。

开发者移除原始语言建模头，并将其替换为包含约 100 万参数的指针头。该组件将每个提议选项与模型对答案的表征进行比较。

团队使用 rank-16 LoRA 适配器调整模型主干。LoRA 是一种微调方法，通过更新一组较小的新增参数，而非重新训练每个权重来完成调整。

该架构执行一次前向传播，无需解码循环。模型失去了生成解释的能力，但获得了对预定义选项进行直接评分的机制。

AWS 使用 11.5 万行数据训练该项目。Brooker 表示，其中约 11.3 万行来自公开数据集，约 2,000 行包含合成的高难度问题。

训练过程还采用了自蒸馏，即模型从冻结版本或早期版本中学习。AWS 使用这一技术来减少模型已能处理任务上的性能退化。

这些细节为开发者提供了一个可复现的起点。它们也暴露出 TypeSafe 可以据此主张：仅靠架构无法提供持久优势的领域。

训练数据决定模型学会辨别哪些差异。校准程序则决定在相关案例中，0.9 的评分是否表现得像 90% 的可靠性。

置信度数值只有在与观察到的结果相符时才有用。一款在陌生语言、对抗性输入或细微政策问题上自信地失败的模型，可能比一款公开表达不确定性的模型更危险。

一项独立的 Jev 评估对 1.13 版本进行了测试，涵盖 37 个数据集和 346,009 次请求。任务包括分类、路由、推理、审核、法律分析和量规评分。

研究人员报告称，该模型在若干常规数据集上表现强劲。但他们也发现，它在低资源语言、细粒度标签、噪声类别以及基于量规的质量判断方面表现较弱。

这些局限适用于这一类别，并不意味着每个具体实现都会如此。它们说明，单一的综合排行榜无法裁定 AWS 与 TypeSafe 之间的竞争。

AWS 通过公开完整开发路径获得了可信度。TypeSafe 仍有机会凭借更优质的数据、泛化能力和托管式改进实现差异化。

OpenAI 又增加了一层竞争因素。据报道，其处于有限预览阶段的 Decisions API让开发者可以向模型提供预定义选项，包括图像类别和潜在的智能体行为。

OpenAI 尚未提供足够的公开证据来进行详细比较。不过，它的加入仍印证了自动化系统中对受限决策的潜在需求。

因此，AWS、TypeSafe 和 OpenAI 面临着同样的实际考验。客户将依据决策质量、升级处理行为、延迟和运营适配性来评判它们，而不是类别标签。

这种机制以灵活性换取控制力

Strands Decider 的价值在于放弃开放式生成，而不是取代前沿模型的广泛能力。

指针头设计是这一权衡的核心。它对应用提供的选项进行评分，而不是从不受限制的词汇表中搜索下一个 token。

这种差异减少了答案违反接口规范的可能性。如果工作流提供的是计费、销售和零售三个选项，模型就必须对这些选项评分。

它无法凭空创造第四个部门，也不能把选择隐藏在解释性文字中。调用应用会直接获得可处理的值。

封闭领域也支持明确的阈值设定。团队或许会执行置信度高于经测试边界的选择，并将其余情况全部升级处理。

这一策略应根据实际工作负载中的标注样本进行调优。直接照搬公开基准的阈值，可能无法反映另一家公司的文档或客户用语。

决策模型还可以针对多个问题复用已编码状态。这一特性使其适合对同一封邮件、文档或拟议智能体操作执行复合检查。

审批工作流可能会询问某项操作是否符合用户请求、是否涉及敏感数据，或是否需要对外沟通。每个回答都可以接入独立的策略。

模型仍依赖开发者提供的选项和上下文。如果遗漏了有效选项，即使校准再完善的模型也无法选中它。

选项措辞不佳会带来另一种失败模式。两个相互重叠的标签可能分散概率，使置信度难以解读。

上下文质量同样重要。模型无法推断出藏在它从未收到的文档中的策略例外。

这也是为什么决策模型不会消除工作流工程。它们只是将工作重心从解析生成文本，转向定义状态、选项、阈值和升级规则。

AWS 承认，Strands Decider 在复杂问题上的表现不如推理模型。它并非面向编程、文档摘要、长时间对话，或需要生成解释的任务。

当工作负载与其边界相符时，这种限制是优势。当团队把廉价决策当作推理的替代品时，它就会成为负担。

模型可以对支持工单分类，而无需解释推理过程。但受监管的决策或影响重大的安全操作，可能需要由另一流程提供可审计的依据。

即使看似简单的操作，也可能隐藏多步骤逻辑。判断证据是否支持某项主张，可能需要计算、外部验证或化解矛盾。

关于纯决策评估的研究展示了这一限制。一项研究发现，在常规偏好判断和基于事实的真实性任务上，Jev 与更强的评判模型表现接近。

但在需要推导的数学、代码、逻辑和专家问题上，差距明显扩大。措辞精巧但错误的答案也可能误导这个较小的决策模型。

更有效的模式是级联。高置信度的常规判断交给决策模型，而不确定案例则转交更强的系统。

这些证据支持 AWS 正在瞄准的架构，但并不支持用 Strands Decider 替换所有智能体模型。

这种区别对安全监控至关重要。快速模型可以检查每项拟议操作，并在执行前标记明显不匹配的情况。

更模糊的操作仍应触发更深入的评估或人工审批。置信度是路由信号，而非安全保证。

一项被广泛报道的 Jev 游戏测试展示了这两面。Jev 通过从预设操作中选择完成了 Pokémon Red，但当系统陷入困境时，Claude Opus 5 协助调整了选项。

这一演示表明，受限选项可以支持长序列操作。它也显示出，系统周边框架可能承载了大量能力。

这一教训直接适用于 Strands Decider。模型准确率固然重要，但选项设计、监控和恢复逻辑将决定已部署的智能体是否真正有效。

早期数据尚未证明什么

AWS 已发布的证据足以支持开展实验，但尚不足以证明该模型在不同组织中的生产可靠性。

报告中的延迟数据来自特定硬件和测试输入。更长的状态、不同的处理器、并发流量和部署开销都会改变响应时间。

置信度结果同样需要在具体工作负载中复现。针对短分类任务校准的分数，在内部策略或专业术语场景下可能呈现不同表现。

Brooker 曾指出，在开发过程中，领域内准确率比泛化能力更容易提升。这对评估该模型的团队而言是一个重要警告。

模型可能在与训练语料相似的任务上表现良好，却在新的问题结构上举步维艰。公开基准的成功并不能消除这种分布差距。

多语言表现是另一个悬而未决的问题。底层 Qwen 主干模型拥有广泛的语言知识，但微调既可能保留这些能力，也可能使其退化。

AWS 表示，其训练过程部分采用蒸馏以限制遗忘。独立测试必须确定这一努力在不同语言和领域中的实际效果。

基准污染也是该类别中所有模型面临的另一个问题。开发者在改进架构和数据时，可能会查看公开测试样例，即便并未直接用这些样例训练模型。

Brooker 承认自己看过 JevBench 样例，并设计了合成流程。这一披露并不会使结果失效，但它限制了强有力的比较性结论。

因此，生产评估应包含在模型选型前创建的私有样例，还应涵盖罕见故障、模糊标签和对抗性措辞。

校准在部署后需要持续监控。用户行为和文档格式会发生变化，昨天的阈值可能因此不再可靠。

团队应记录状态、提供的选项、模型版本、分数、所选操作及最终结果。没有这一追踪记录，他们就无法衡量置信度是否依然具有实际意义。

开发者还必须决定当所有选项都很差时该如何处理。即使正确回应缺失，强制选择也可能显得果断。

明确的弃权或升级路径有助于解决这一问题。工作流应将不确定性视为可执行的信息，而不是一种麻烦。

开放权重使得私下开展这些测试更加容易。组织可以评估敏感数据，而无需将其发送给外部模型提供商。

本地部署也带来了责任。每个组织都必须管理服务、更新、安全、性能和模型治理。

托管服务会将一部分运营工作转移给提供商，但也可能使模型训练过程和更新计划变得不那么透明。

没有任何一种模式会自动赢得这一权衡。买方必须决定，对自己的工作负载而言，控制力、可复现性、托管式改进还是可测量的准确率最重要。

这一术语同样值得保持怀疑。“System One”与审慎推理模型形成了易于记忆的区分，但这一标签并不会带来新的科学保证。

在品牌包装之下，它是一个由预训练 Transformer 构建的专用神经分类器。它的实际价值取决于可衡量的结果，而不是心理学类比。

因此，最大的未知因素并不是 AWS 是否构建了一个能运行的决策模型。开放代码和已发布的测试清楚地支持这一结论。

不确定性在于持久优势。如果许多团队都能构建类似模型，差异化将转向数据、校准、集成和可信评估。

这种变化有利于 AWS 的分发能力和开发者触达，也有利于 TypeSafe——前提是其专用训练能持续产生更优的决策。

OpenAI 可通过现有模型平台和多模态能力参与竞争。但其有限预览仍使关键性能和部署细节悬而未决。

市场不会通过发布周的排行榜解决这个问题，而会通过生产错误率、升级量和开发者留存率作出判断。

三项信号将揭示决策模型能否长期存在

下一阶段将检验决策模型会成为持久的智能体基础设施，还是仅停留于一阵密集的实验热潮。

第一个信号是对 AWS Strands Decider 2B 的独立评估。研究人员应测试未见过的工作负载、多语言输入、对抗性措辞和不断变化的选项集。

如果该模型展现出强泛化能力和稳定置信度，将支持 AWS 的开放路线。如果它在熟悉数据集之外迅速退化，则会强化 TypeSafe 的观点：架构才是容易的部分。

第二个信号是其在真实 Strands 工作流中的采用情况。有价值的证据将包括用于路由、审核、策略检查或模型选择的可复现部署。

仓库活跃度和实验性演示可以反映开发者兴趣。生产案例研究必须说明，该模型是否能在不造成不可接受错误或升级量的情况下减少延迟。

第三个信号是 TypeSafe 和 OpenAI 的回应。TypeSafe 需要证明除了率先推出之外的可量化优势，而 OpenAI 必须澄清其 Decisions API。

直接比较应使用相同的状态、选项、阈值和结果标签。基于无关基准的营销主张无法回答核心问题。

开发者无需等待胜者出现才开始实验。他们可以从低风险工作流起步，确保错误选择仍可逆转。

一个有价值的试点项目应包括具有代表性的私有测试集、明确的弃权路径和更强的备用模型。每项决策都应与其后续结果一同记录。

团队应避免从资金转账、访问控制变更或不可逆的外部通信开始。这些操作需要更深入的保障措施和明确的人类授权。

最佳的早期应用场景，是在已知选项中进行重复分类。工单路由、文档分流、相关性过滤和安全模型选择都符合这一特征。

AWS Strands Decider 2B 让这类实验更容易开展，因为其实现可供审查，也可本地部署。它同样消除了跳过严谨评估的借口。

真正的机会并不在于用它全面取代大语言模型，而是将大语言模型保留给那些受益于生成、延展推理或解释的工作。

可靠的决策层可以处理这些工作外围更狭窄的关口。不可靠的决策层则可能比任何较慢的模型更快地放大错误。

在你当前的 AI 工作流中，哪一项重复性选择值得采用经过审慎评估的决策模型？在信任其置信度之前，你又需要哪些证据？