共同的问题：路由决策的延迟与成本复利
先看问题的形状。一个生产级智能体管线里，真正的「重活」——写代码、生成报告、长文推理——通常只占调用次数的少数；占大多数的是那些毫秒级的判断：这条输入该分给哪个工具、要不要升级到人工、这个请求属于哪一类。这类判断如果每一次都动用完整的生成式模型，代价是双重的：每次调用数百毫秒起步的延迟，以及按生成 token 计费的成本。单看一次无所谓，但一个任务里如果有几十个决策点，延迟会复利式累加成秒级，成本则随任务量线性放大。
这正是 2026 年 10 月初那一周发生的事情的背景。据 Cloudflare 官方博客、Strands Agents 官方博客与 Claude Code 文档分别记录：10 月 1 日，Cloudflare 宣布开源决策模型 Clef 与 Clef-flash；同一天，Anthropic 随 Claude Code v2.1.287 发布了 Mods 特性（据 10 月 4 日 dev.to 的分析与官方文档）；同日，Amazon 的 Strands Agents 团队发布了开源决策模型 Strands Decider 2B。三天、三家、三种完全不同的架构答案——值得注意的是，这三家团队互相之间并无协调，他们的共同前提只有一个：足够多的企业团队在路由层撞上了用生成式 LLM 做小决策的延迟与成本天花板，市场已经到了可以为这一件事单独立项的时点。
三份答卷的分歧不在「要不要优化路由层」——这一点已经没有争议——而在决策逻辑应该住在哪：Cloudflare 和 Strands 都认为应该住在一个可独立版本化、微调、评测的专用模型里，分歧只在托管还是本地；Anthropic 则认为决策智能本来就在智能体内部，缺的只是在恰当的时机注入逻辑的接口。这个「住址问题」一旦选定，迁移是有真实成本的，值得在早期想清楚。
Cloudflare Clef：专用决策模型与结构化概率输出
Cloudflare 的方案是两个开源决策模型：Clef（更高精度）与 Clef-flash（延迟优化）。据官方博客与 Hugging Face 模型卡，两者的核心设计是「不做开放式文本生成，而是按预定义的 schema 字段返回带概率的类型化答案」——你可以把它理解成一个把分类任务固化下来的极小模型：输出不是一段话，而是「字段 A：选项 X（置信度 0.93）」这样的结构化结果。
几个关键工程细节：其一，Clef-flash 的架构是「仅预填充、单次前向传播」（prefill-only, single forward pass），从 Qwen3.5-9B 后训练而来——砍掉了解码循环，这是它能压低延迟的结构性原因；其二，Cloudflare 自报 Clef-flash 的决策延迟中位数为 38.8 毫秒，该数字镜像收录在 BenchLM 上，但 BenchLM 明确注明未独立复跑；其三，与竞品 Jev 模型相比，Clef 额外带了视觉编码器（可对图像分类），支持 64k 上下文窗口；其四，两个模型均以 Apache 2.0 许可在 Hugging Face 开源，部署形态以 Cloudflare 边缘托管为主，同时保留本地自托管选项。
读这份方案要抓住的一点是「部署目标」：Clef-flash 是为托管部署调优的——如果你已经在 Cloudflare 边缘网络上跑智能体服务，把高频路由决策下沉到同栈的决策模型里，网络往返几乎可以忽略。对不在该生态内的团队，Apache 2.0 与本地自托管选项保留了退路，但 9B 级别的底座意味着本地推理的资源门槛不低。
Strands Decider 2B：砍掉语言模型头的「指针」架构
Amazon Strands Agents 团队同日发布的 Decider 2B 走了一条更激进的瘦身路线。据 Strands Agents 官方博客：这是一个 20 亿参数的开源模型，权重托管在 Hugging Face、代码开源在 GitHub，其架构做法是拿一个预训练底座，把语言模型头（LM head）整个换掉，代之以一个「指针头」（pointer head）——对每个候选决策选项，将对应位置的隐藏状态与答案位置的隐藏状态做比对打分，输出每个选项的概率分值，外加一个经过校准的可靠性分数。它不生成自由文本，因为生成文本所需要的整组解码参数在这里已经不存在了。
这个架构选择带来三个直接后果。其一，体量：2B 参数对 Clef-flash 的 9B 底座，明确瞄准的是本地推理——官方描述其面向快速实验、本地开发与本地 CPU 或 GPU 推理，答案返回在数十毫秒量级（同样是厂商自报口径）。其二，训练透明度：训练数据与训练脚本随权重一并发布，团队可以自行微调或复现，这在决策模型里是不多见的开放程度——决策模型的价值高度依赖「在你自己的决策分布上的表现」，而训练脚本开放意味着你可以把它重新校准到自己的分布上。其三，与 Strands Harness 的协同：Decider 2B 可以直接嵌入 Strands 生态的工作流中，在本站此前解构过的 Strands Harness 架构里承担路由角色，本地推理的成本优势在管线级会复利。
需要标注的口径：官方博客对精度与校准的声明截至发稿缺乏独立复现，与 Clef-flash 的情况相同。
Claude Code Mods：把决策逻辑注入执行循环
Anthropic 的答案与另外两家不在同一个维度上竞争。随 Claude Code v2.1.287 发布的 Mods（据 Claude Code 官方文档），是一套用 JavaScript 或 TypeScript 编写的事件处理器，运行在 Claude Code 执行管道内部而非旁边。据 10 月 4 日 dev.to 的分析，Claude Code 负责人 Boris Cherny 于 10 月 1 日宣布该特性，社区反响显著，GitHub Trending 上可见快速生态采用。
Mods 的机制是事件驱动的：当工具调用、提示提交等事件发生时，处理器被触发，可以在事件传递给下一个处理器之前检查甚至修改它。官方文档列出的能力包括：在执行前拦截并修改工具调用、包装或替换界面组件、渲染自定义面板与状态条、跨多个钩子共享状态。换句话说，Mods 回应的不是「用什么模型做路由」，而是「在智能体自己的循环里，给出注入自定义逻辑的标准位置」——路由智能本就存在于智能体中，缺的是一个注入点。
这个设计的代价在安全剖面一节展开。这里先记下一个工程上的差异：专用决策模型与智能体运行时之间隔着一层网络边界（哪怕本地部署也有进程边界），而 Mods 直接活在执行循环里，对执行状态有最完整的视野、零额外跳数。集成深度与风险敞口，在这里是同一枚硬币的两面。
三种赌注的对照：决策逻辑放在模型里还是运行时里
把三个方案放进一张表，分歧会看得更清楚：
| 维度 | Cloudflare Clef / Clef-flash | Strands Decider 2B | Claude Code Mods |
|---|---|---|---|
| 发布时间 | 2026-10-01 | 2026-10-01 | 2026-10-01（v2.1.287） |
| 架构路线 | 专用决策模型（Qwen3.5-9B 后训练，仅预填充单次前向） | 开源指针模型（2B，LM 头换指针头） | 运行时钩子（JS/TS 事件处理器） |
| 输出形态 | 按 schema 字段返回带概率的类型化答案 | 选项概率分 + 校准可靠性分 | 对事件流的中途拦截与改写 |
| 部署形态 | Cloudflare 边缘托管为主 + 本地自托管可选 | 本地 CPU/GPU 推理为主 | 平台原生，随 Claude Code 运行 |
| 许可 | Apache 2.0 | 开源（权重 + 训练数据 + 脚本） | 平台特性，非独立开源件 |
| 延迟口径 | 38.8ms 中位数（自报，BenchLM 镜像未复跑） | 数十毫秒量级（自报） | 运行时内联，无独立网络跳数 |
| 额外能力 | 视觉编码器（图像分类）、64k 上下文 | 训练全开放，可重校准 | UI 定制、状态共享、工具调用改写 |
两个补充读法。其一，这三者并非严格互斥：一个企业管线完全可以在外部高频路由上用 Clef-flash，在基于 Claude Code 的编码智能体内部用 Mods 做指令化，同时把 Decider 2B 嵌进本地部署的 Strands 工作流——三个方案各自覆盖决策点的不同位置。其二，真正值得对赌的是「标准」：一旦团队围绕某种决策基础设施形态建立了版本管理、评测集与回滚流程，迁移成本就是真实的。这也是为什么三家选择在同一时间窗口密集发声——对开发者的心智占位，在品类形成期比功能清单更重要。
安全剖面：一条已经 documented 的供应链风险
三个方案的安全属性差异悬殊，而且差异是文档化的、不是推测的。
Clef 与 Decider 2B 作为独立模型，安全边界清晰：它们做分类，不碰文件系统，不持有用户凭据；两者均开源，可以自托管与审计。真正的风险敞口集中在 Mods。据 Claude Code 官方文档：Mods 以安装者完整用户权限运行，可读写文件、观察每一次提示与工具调用、消耗账号上的 API 用量；没有沙箱，没有代码审查流程，没有签名要求。官方提供的是 claude plugin validate 检查命令与 --safe-mode 禁用开关——是自查工具，不是审查门禁。
这个敞口并非理论风险。dev.to 的分析引用了一项已发表的研究：在被分析的智能体技能（skills）样本中，26.1% 至少包含一处安全漏洞，其中数据外泄占 13.3%、权限提升占 11.8%。而 Mods 的系统访问深度高于 skills——权限更大、注入点更靠近执行循环。在自己编写 Mods 的场景下，这是可接受的工程取舍；但在规模化安装第三方 Mods 的场景下，供应链审查责任完全落在使用者一侧。这也是三种路线里「生态开放度」与「安全成本」权衡最极端的一个：发布门槛越低，生态起量越快，审查缺位的代价也越晚但越重地显现。目前官方未披露是否会跟进审查流程或沙箱层，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
选型三问与未决事项
把这一周的发布翻译成选型清单，三个问题值得先问自己：
- 路由层延迟在你的管线里是否复利？如果一个任务只有三五个决策点，专用决策模型的收益有限；如果有几十个，即便每次只省几百毫秒，累计也是秒级。Clef-flash 与 Decider 2B 的自报延迟数字（38.8ms 与数十毫秒）都未独立复现，务必用自己的决策分布压测。
- 决策逻辑要放在模型里还是运行时里？独立模型可版本化、可微调、可独立评测，审计上更干净；运行时钩子与执行状态零距离，集成更深但边界更糊。两者没有普适答案，取决于你的审计要求与迭代频率。
- 你能承受多大的供应链敞口？自己写的 Mods 与第三方 Mods 是两种完全不同的风险等级；在审查与沙箱机制出现之前，生产环境规模化安装第三方 Mods 需要把第三方代码当作拥有本机完整权限的程序对待。
未决事项同样清晰：三种方案的性能声明全部是厂商自报，截至发稿不存在任何独立基准；Clef-flash 的精度/延迟曲线、Decider 2B 的校准质量、Mods 的生态规模与安全事件率，都是接下来一个季度值得回访的观察点。此外，Jev 等竞品模型在视觉能力与上下文长度上的差异说明决策模型内部也在快速分化，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。