一个Agent在回答用户之前，常常已经做了几次选择：这句话要不要检索？交给哪个模型？能不能调用某个工具？是否需要转给人？这些判断通常只有几个候选答案，却可能每次都让通用大模型跑一遍。Strands Agents开源的Strands Decider 2B，正是冲着这类重复判断来的。它给候选项打分，而不是写一段漂亮的解释。对做企业Agent的人来说，值得细看的并非“2B也能做AI”，而是一个更琐碎的问题：决策应当放在系统的哪一层。
先把“决策”与“回答”分开
Strands Agents于10月2日介绍并开源Strands Decider 2B。按照当日AI日报的介绍，它约有20亿参数，以Qwen3.5-2B为主体，去掉传统语言模型的输出头，换成比较候选答案的pointer head，并用LoRA微调。模型、训练数据和训练脚本已公开。它面向分类、模型路由、工具选择、策略判断等任务，而非开放式聊天或自由文本生成。
这意味着系统要先把问题整理成可以比较的选项。比如工单到来，候选项是“查内部知识库”“交给代码助手”“转人工”；Decider做的是比较这些候选项与当前上下文的匹配程度。如果问题本身还需要调查、计算或者撰写一段合规解释，那个工作并没有因为引入Decider而消失。它仍然需要后续模型、工具或人来完成。
这种划分听起来像传统分类器，但Agent场景比固定标签分类稍难。同一句“帮我处理发票”，在报销对话和供应商付款对话中，可能需要走不同流程；同一个工具，上午能用，下午因为权限撤销就不能用。把上下文、候选动作和实时约束一起送进决策环节，才是它在系统里有用的方式。小模型做选择，前提是应用已经把“可选什么”想清楚。
115毫秒，说明了什么，又没说明什么
项目方给出的测试数据是：本地RTX 3090上，小任务中位决策延迟约115毫秒；M3 MacBook上约153毫秒。这是项目方公布的测量，不是所有企业环境下的端到端响应时间。网络转发、提示构造、候选集合长度、并发争抢、权限查询以及后续大模型调用，都不包含在一个孤立的模型推理数字里。日报也提醒实际部署需要另行复核。
但这组数字仍提示了一个值得试验的方向。一个用户请求若经历多次模型路由和工具选择，每次额外等待都会叠在一起。尤其在需要边查边做的流程里，决策发生得比最后的文字生成更频繁。换用专门的决策模型，未必能让单次完整任务突然快好几倍，却可能降低那些反复出现、答案格式很窄的步骤所占的时间。
账不能只算Token。自部署需要显存、服务维护、监控与故障切换；候选项整理、日志回放、标注误路由案例也有成本。若某项业务每天只有少量请求，增加一套模型服务反而不划算。要算的是每千个任务的总成本、排队时延和错误补救开销，而不是把115毫秒直接换算成节省比例。
Pointer head改变的是输出契约
通用语言模型做工具选择时，常见写法是让它输出一个工具名称或一段JSON。应用再解析文本，检查名称是否有效、参数是否齐全，遇到不合法输出还得重试。Strands Decider 2B把输出端改成比较候选答案的pointer head，至少在设计上更贴近“从给定选项中选一个”的任务。候选项在前，模型负责比较，调用方拿到分数和可靠度，再按自己的规则决定下一步。
这里容易误解的词是“可靠度”。它有助于做阈值判断，却不能直接当作现实世界里“有九成把握不会出错”的承诺。若业务真的依赖某个分数阈值，就要拿本企业数据校准：高分错选有多少、低分却选对的有多少，换了产品线或换了提示之后曲线有没有变。不能只看平均准确率。一次把敏感客户资料路由到错误工具的代价，和一次把普通咨询交给人工的代价，不在同一个量级。
还要允许模型说“不确定”。如果分数接近，系统可以请求更强的模型复判，或者转人工。若每次都被迫在两个坏选项里选一个，输出再规整，也只会把错误包装得更干净。候选集合里何时加入“拒绝”“补问用户”“无权执行”，应当由业务和安全规则决定。
模型路由不是一张静态价目表
很多团队谈路由，第一反应是按请求难度把简单问题送去便宜模型，复杂问题送去昂贵模型。实际难度不是一眼可见的属性。用户说“把上周的合同改一下”，看上去很短，系统可能要识别合同版本、改动权限与影响范围；用户贴来一页冗长的会议记录，任务或许只是抽取日期。输入长度并不能替代风险判断。
比较可行的做法是将路由结果拆开看：任务是否需要外部工具、哪个工具有访问权、需要何种能力的生成模型、什么情况必须停下来。Decider可以参与其中的高频选择，但不应成为唯一的权限裁判。权限是否存在，最好由身份系统或工具网关以确定性规则查询；涉及付款、删除、向外发送数据的动作，也不能靠一个分类分数直接放行。
把“工具选择”和“工具授权”写成同一个决策，会埋下麻烦。前者回答哪把扳手适合拧这颗螺丝，后者回答眼前这个人能不能碰机器。模型可能擅长推荐扳手，却不应自行签发门禁卡。企业设计Agent时，常常需要在这两个环节之间加一道明确的校验：先推荐，再由执行层核验身份、范围和审批状态。校验失败，系统就返回一个真实的失败原因，而不是让模型换个说法继续试。
用自己的错误样本做评估
开源意味着企业可以审视模型、数据和训练脚本，也能在本地试验。这不等于模型天然适合自家工单、研发流程或合规分类。第一轮试验应收集已有Agent日志中真实发生过的决策点，删去个人与敏感内容后，给每个样本保留当时的候选项、可用权限、最终动作和复盘结论。否则用一批精心写好的标准题测出高分，到了生产环境仍会碰到混乱输入。
评测集最好故意纳入棘手例子：用户把两个意图混在一句话里；候选工具名称相似；知识库看似相关但已过期；权限刚被收回；原本可自动完成的任务现在需要人工批准。观察的不只是选对率，还包括拒绝率、转人工率和低置信决策的分布。一次路由错误之后能否停在工具执行之前，比表格上多几个百分点更实际。
对照组也要留着。沿用现有规则或通用模型路由，同时在影子模式下记录Decider会怎么选，不让它真正执行。若差异集中在低风险请求，再挑一小类业务试运行；若差异集中在权限和敏感数据流转，先查原因。测试时把提示模板、候选顺序和模型版本固定下来，不然前后两周数据变了，很难判断是模型更好还是题目变了。
候选项是产品设计的一部分
工程团队容易把选择题的选项当作随手拼接的字符串。可模型只会在给定选项里打分。假如系统仅提供“搜索互联网”和“直接回答”，它无法选择“只查授权的内部文档”；假如没有“询问用户具体是哪份合同”，含糊请求就可能被硬塞进某个执行动作。
因此候选项需要版本管理，也要有业务负责人。一个工具下线了，候选集合应同步更新；工具改了数据访问范围，相关描述与授权检查要一并调整。尤其是策略类判断，分类标签的文字描述如果模糊，模型分数再稳定也没意义。与其频繁调提示词，不如先让团队对每个选项代表的真实行为达成一致。
还要警惕“上游一句话，下游一长串动作”。模型选了“处理退款”，后面可能接查询订单、核实资格、生成建议、实际打款。这个标签太宽，无法承担整条链路的风险控制。把它拆成可审计的小步骤，在执行前保留独立授权点，系统遇到异常才有地方刹车。
企业先从窄场景试，而不是重写整套Agent
适合先试的，是候选动作有限、判断重复、错了能及时发现的场景。例如对客服咨询选择知识库类别，或为开发助手在几个已授权的查询工具间路由。这类场景可以用历史样本回放，记录模型选择与人工标注的分歧，也能计算接入之后是否真的少调用了通用模型。
不适合第一天就交出去的，是高度依赖新事实、责任边界模糊、出错难撤销的决策。生产环境可以设置两层保险：模型只给建议，运行时规则决定能否执行；对于分数不稳或代价高的请求，回退到原有流程。回退让系统在尚不擅长的任务上保持边界。
上线后，关注分布漂移。促销季的客户咨询与平时不同，新工具的加入会改变候选集合；模型即使一行代码都没动，误选率也可能上升。定期抽样人工复核，并把差错原因分成“输入不足”“选项设计有问题”“模型判断错误”“权限系统拒绝”几类。分类做得越诚实，改进时越不容易把所有锅甩给模型。
还要量一量“省钱”是不是把工作转嫁给了人。若低置信请求大量转人工，模型调用费确实下来了，客服或运维队列却可能变长。试点报告应该同时列出自动完成率、人工接手后的处理时长，以及用户为了补充信息多等了多久。若一条路由让用户反复解释同一件事，即使模型每次只花百余毫秒，也谈不上效率提升。把人的等待时间算进去，这套架构才有机会被公平评价。
一次错误路由该如何复盘
假设Agent答应用户查一份合同，最后却调用了公共搜索工具。系统日志若只有“模型选择：搜索”，复盘几乎无从下手。至少需要留下当时用户意图的脱敏摘要、候选项版本、模型输出分数、实际授权结果，以及最终有没有执行。日志里不该复制合同全文；保留能解释决定的必要信息就够了。
复盘时先分清错误发生在哪一层。如果候选项里根本没有“查询内部合同库”，是产品流程漏了出口；如果选项有，但模型总把“合同编号查询”误判为网页搜索，才是模型或输入描述的问题；如果模型建议正确、网关仍让无权工具运行，则应查授权执行链。把三种故障都写成“AI偶尔会幻觉”，下次还是会犯。
还可以给路由加一条“反事实”记录：如果选择第二高分选项，是否会触碰更多敏感数据？团队可以据此判断阈值设计是否过于激进，无需让生产系统实际执行第二条路线。风险高的选项应有更高的进入门槛。小模型低延迟的好处，要在系统能识别错误并及时止损时才有实际价值。
组织分工比模型分工更容易被漏掉
一套多模型Agent上线，模型团队也许负责推理效果，平台团队维护工具网关，业务团队定义什么叫任务完成。若没有人对候选项和误选成本负责，小模型很快变成新的“黑盒”。不妨为每类路由指定负责人：谁能新增工具，谁批准改变拒绝阈值，谁定期阅读误选案例。责任划清，才能知道模型表现下降时该找谁。
采购或自建时也别只问模型能否部署在现有机器上。还要问能否导出决策日志、能否冻结模型和候选版本、灰度期间能否一键回退。一个性能略逊但证据链完整的路由器，常常比漂亮的单次基准成绩更适合接入真实业务。尤其当工具能写入、删除或发送资料时，排障能力不是锦上添花。
留给大模型的工作，反而更明确
Decider并不是宣告通用大模型不再重要。它把小而频繁的选择前置，让生成模型负责分析资料、写回复、处理含糊的用户意图。把路由视为专门任务，团队也更容易问清楚：哪些判断能以候选项表示？哪些判断涉及新事实、必须查工具？哪些判断需要人承担责任？
我更在意最后一个问题。能给选项打分的模型，在系统里会显得很能干；但一个分数并不替企业定义政策，也不能证明动作获得授权。真正可用的分工，是让决策模型做它擅长的比较，让规则守住边界，让复杂任务有去处。先拿一条低风险流程跑通，再谈替换多少次大模型调用，可能比画一张“多模型协同架构图”更快看出值不值得。
来源与口径
本文依据《AI技术每日分析》2026年10月3日第（二）节扩写；其中架构、开源范围与延迟数字沿用日报口径，未另作外部核验。项目方原文：Strands Agents｜Introducing Strands Decider 2B: a small, open source, decision model。文中工单、合同、客服等是解释架构的假设性场景，并非项目方已公布的落地案例。
选题来源：AI技术每日分析·二