AWS 开源 20 亿参数「决策器」与执行沙箱：智能体栈的中间层成形

做 AI Agent 的人大多踩过同一个坑：让一个通用大模型在几个工具之间选一个，它要么绕一大圈解释，要么干脆选错，而这两种错误都要付出 token 与延迟的代价。亚马逊云科技给出的解法是把「决策」这件事单独拆出来，用一个只有 20 亿参数的小模型专门做选择题，再配一个策略沙箱约束执行动作。两个项目都以开源形式发布。

一分钟速览

• 亚马逊云科技开源 Strands Decider 2B，一个 20 亿参数、专门做多选项评分与路由的决策模型。
• 模型以小型基座为基础，把语言模型头换成用于给候选答案打分的指针头，并用 LoRA 适配器微调。
• 在 NVIDIA RTX 3090 上决策延迟中位数约 115 毫秒，在 Apple M3 MacBook 上处理小任务约 153 毫秒。
• 在 JevBench 的 231 项公开任务上，v19 检查点准确率为 72.3%。
• 权重、训练数据和训练脚本均已公开，可本地运行与修改，支持 CLI 与 Strands 智能体集成。
• 同时开源的 Strands Box 提供智能体执行沙箱，把操作系统级隔离与 Dogwood 策略语言结合。
• 沙箱支持 Shell 命令、Python 执行、MCP 工具、文件系统操作与网络访问，策略可在模型之外强制执行。

为什么「选择」值得一个专用模型

智能体工作流里最频繁的动作不是生成文本，而是做判断：这一步该调用搜索还是查数据库？这个请求该路由到大模型还是小模型？这条回复是否越过护栏？这些问题的共同点是选项有限、需要给出置信度、而且调用频次极高。用通用大模型做这类事，等于用卡车送快递——能送到，但成本与延迟都不合理。

Strands Decider 2B 的思路是把任务形式化成「给候选答案打分」。输出层不是逐 token 生成自然语言，而是指针头对预先给出的选项逐一评分，返回选择结果与置信度分数。这种结构带来两个直接好处：一是延迟稳定，不受输出长度影响；二是结果可判定，便于下游系统做阈值判断，而不是去解析一段自然语言。

它覆盖的场景包括模型路由、工具选择、分类、护栏判断和上下文管理。对工程团队而言，这意味着可以把原本写在提示词里的「请你判断……」改造成一次轻量推理调用，既省 token，也省掉了解析输出的胶水代码。

115 毫秒与 72.3%：小模型的现实边界

性能数据需要放在具体语境里读。RTX 3090 上 115 毫秒、M3 MacBook 上 153 毫秒，说明这个模型可以在消费级硬件上跑到接近实时的水平。对于一次用户请求要经过五六个决策节点的智能体来说，这个延迟是可以接受的；如果每个节点都调用云端大模型，光网络往返就足以让体验崩掉。

准确率 72.3% 则是一个需要诚实看待的数字。在 231 项公开任务的 JevBench 上，这个成绩不算惊艳，官方也承认已公布的结果并不能证明它在性能上直接优于同类产品 Jev。这意味着 Decider 2B 的定位不是「更聪明」，而是「足够准、足够快、可以自己部署」。对于需要数据不出内网的场景，这个取舍往往比多几个点的准确率更重要。

竞品的差异也主要在部署形态：Jev 通过托管 API 提供，Strands Decider 2B 开源可本地跑。选择哪一个，本质上是选择「省事」还是选择「可控」。

Strands Box：把约束从提示词里挪出来

如果说 Decider 解决的是「想清楚」，Strands Box 解决的就是「别乱来」。它是一个为智能体提供隔离执行环境的沙箱，把操作系统级隔离与一门叫 Dogwood 的开源策略语言结合起来。Dogwood 用来定义智能体可以执行哪些操作，支持 Shell 命令、Python 执行、MCP 工具调用、文件系统操作和网络访问。

这套设计最关键的一点是：控制逻辑运行在语言模型之外。传统做法是把「不要删除文件」「不要访问外部网络」写进系统提示词，然后祈祷模型听话；而 Strands Box 用内核强制的隔离机制，把智能体的交互路由到策略层，由策略根据操作内容和执行历史决定允许还是拒绝。例如，策略可以要求智能体必须先通过测试才能把代码推送到仓库，也可以限制外部 API 的调用频率。

这个差别在工程上意义重大。提示词是软的，模型可能被注入、被诱导、被更长的上下文带偏；而策略是硬的，不依赖模型的配合。沙箱还可以配合不同的模型与智能体框架使用，无论运行在本地还是云上，这降低了引入执行策略的改造成本。

和现有方案比，它补的是哪块空白

市面上已有的方案大致三类：基于容器的沙箱、Firecracker 这类 microVM、以及各家云厂商的托管式智能体执行环境。它们的共同点是限制文件系统、进程与网络访问，也就是管「能碰什么」。Strands Box 多出来的一层是「按操作语义与历史判断」——管「在什么条件下才能碰」。这个区别在真实业务里很实用：读一个配置文件与读一份客户名单，在文件系统层面没有区别，在业务语义上天差地别。

当然，这也带来新的复杂度。策略需要人来写，写得太松等于没写，写得太紧智能体寸步难行。Dogwood 作为一门新语言，生态与工具链都还在早期，团队要评估学习成本。

趋势洞察：智能体的竞争，正在从模型转向「决策层 + 执行层」

这两个项目放在一起看，指向一个正在成型的架构分层：上层是通用大模型，负责理解与生成；中间是专用小模型，负责高频、结构化的决策；下层是策略沙箱，负责执行边界。过去一年行业把注意力集中在最上层，比拼参数与榜单；但真正决定智能体能不能进入生产环境的，恰恰是中间和下面这两层。

开源是这套打法的关键一环。权重、数据、训练脚本全部公开，意味着企业可以在自己的机房微调出贴合业务的决策器，也可以审计沙箱的每一条策略。对希望在内部部署智能体、又不愿把数据交给第三方的组织来说，这种「可拥有」的能力比多几个百分点的准确率更有吸引力。接下来值得观察的是，会不会有更多厂商跟进这一分层，把「决策器」做成智能体栈里的标准组件。