新的决策模型实际上做什么
决策模型是一个小型、快速的分类器，用于在分支之间进行选择。在 agentic 系统中，它回答诸如以下问题：哪个工具应该处理这个请求，规划器应该继续还是升级，哪个子代理应该接收任务。该模型不持有凭证、预算或持久状态。它输出一个标签或一个结构化选择。然后，持有这些东西的调用方会对该选择采取行动。
延迟预算迫使模型只能看到运行过程的压缩视图。为了在亚秒级时间内返回决策，路由器接收一份摘要：最近的轮次、任务描述，或许还有可用工具列表。它看不到完整的执行轨迹、累积成本、用户的权限，或之前分支的下游副作用。它的决策在构造上就是有损的。这不是缺陷；正是这种设计权衡让路由器足够廉价，可以被频繁调用。但这也意味着路由器不能成为保证约束的组件。
这些模型已发布的基准测试衡量的是在留出任务集上的路由准确率。它们并不衡量遏制能力：错误分支是否会导致未授权操作、超出预算或泄露数据。准确率和遏制能力是不同的属性。如果调用方把路由器的输出当作权威，那么路由器即使高度准确，仍然可能是不安全的执行点。
类别错误：路由与强制执行
强制执行需要一个能够拒绝的组件。路由器提出建议；执行器拒绝。如果路由器只是建议性的，调用方决定是否遵循建议。如果路由器是权威性的，它就需要审计轨迹、一种验证其输入的方式，以及一种在模型出错时仍然安全的故障模式。大多数决策模型不提供这些。它们不是 XACML 意义上的策略决策点，后者会根据策略评估请求，并返回带有义务的允许或拒绝决策。决策模型返回的是分支标签。区别不是语义上的；而是架构上的。
考虑一个具体机制。假设一个路由器在 read_file 工具和 write_file 工具之间进行选择。路由器看到的是压缩视图：用户要求“更新配置”。它选择了 write_file。如果调用方把这当作许可，写入就会继续。路由器从未检查用户是否具有写入权限、文件是否受保护，或更改是否超出预算。这些检查属于下游的执行器。如果执行器缺失，故障模式并没有被消除；它只是从路由器的准确率转移到了调用方的信任上。
诚实的权衡是，强制执行会增加延迟和复杂性。下游执行器必须评估策略，这可能需要状态查询、加密检查或外部调用。正是这种成本让团队倾向于把强制执行折叠进路由器。但一个快速分类器无法在不变成策略引擎的情况下承担策略引擎的重量，而到了那一步，它就不再是一个 2B 路由器了。
放置规则：放在规划器循环内，绝不放在出口路径上
把决策模型放在规划器循环内，在那里它们可以在任何副作用发生之前塑造计划。绝不要把它们放在出口路径上，在那里它们的输出会直接触发外部操作。规划器循环可以容忍错误分支，因为计划仍然要接受审查、模拟或下游执行器的检查。出口路径不能。
为每个路由器配一个失败时关闭的下游执行器。执行器应该是一个独立组件，拥有自己的策略、自己的凭证和自己的审计日志。即使路由器建议了某个操作，它也应该能够拒绝。执行器应该失败时关闭：如果它无法评估策略，就拒绝。这与路由器的故障模式相反，后者是猜测。
记录路由器的输入快照，而不只是它的输出标签。输入快照
路由器评估需要对抗性输入，而不是留出任务集。留出集衡量的是路由器与标签一致的概率。对抗集衡量的是当路由器出错时会发生什么：错误分支会造成伤害，还是执行器会抓住它？第二个问题才是对安全真正重要的问题。
衡量错误分支的成本，而不是分支的准确率。对于每一种可能的错误路由，估计最坏结果：未授权写入、预算超支、数据泄露、卡住的循环。如果成本被下游执行器限制住，那么路由器的准确率就是一个性能指标。如果成本不受限制，那么路由器就是伪装的执行点，而这是设计缺陷。
这重新定义了评估目标。不要问“路由器选对工具的频率有多高？”，而要问“当它选错时，爆炸半径有多大？”答案决定了路由器是否可以廉价且有损，还是需要被策略决策点取代。
这对代理架构意味着什么
像 Amazon 的 Strands Decider 和 Cloudflare 的 Clef 这样的决策模型是有用的路由原语。它们降低了分支成本，并让代理循环更具响应性。但它们不是控制面。把它们当作控制面，只会转移故障模式，而不是消除它。正确的模式是分层的：规划器循环内有一个快速、有损的路由器，下游有一个失败时关闭的执行器，以及一条记录路由器输入快照的审计轨迹。这种模式接受路由器的局限性，并把强制执行负担放在它该在的地方。
权衡是明确的：你为强制执行付出延迟和复杂性成本，并获得遏制能力。你无法从一个永远看不到完整状态且无法拒绝的分类器那里获得遏制能力。工程工作就是把路由器放在其有损决策安全的位置，并构建执行器来兜住其余部分。
封面照片：Jakub Pabis / Pexels。