跳转到主要内容
当两条规则都可能匹配同一次工具调用时，防火墙规则优先级决定哪一条胜出。 一条 防火墙策略 是一个有序的规则列表——引擎按 优先级顺序遍历它们、在第一条匹配的规则处停止，并应用它的判定。把顺序弄对， 一个宽泛的守卫加一个窄的例外就干净地共存；弄错了，宽泛的规则就吞掉你本想 划出的那个例外。 本页是关于排序的聚焦参考。关于完整的规则语法参见 防火墙规则；关于一条规则能产生的判定参见 判定。

​
1. 顺序：优先级升序，首个匹配生效

在一条策略内，规则以 priority ASC, id ASC 顺序评估：
  1. 更低的 priority 先运行。 一条 priority: 0 的规则在一条 priority: 10 的之前被检查。把它想成一个队列位置，而非一个强度分数 ——更小的数字先发言。
  2. 平局由规则 id 打破。 同一 priority 上的两条规则以创建顺序（升序 规则 id）运行，所以更旧的规则赢得平局。当顺序确实重要时使用不同的优先级， 而非依赖 id 平局打破。
  3. 首个匹配生效。 引擎在第一条其条件全部成立的规则处停止并应用它的 判定。列表中更靠下的规则对那次调用从不被查询。
  4. 无匹配 → 默认判定。 如果没有任何匹配，则应用策略的 default_verdict ——除非你改过它，否则为 audit。
一条规则只在每一个声明的条件同时成立时才匹配： 执行面、 工具名 glob、可选的技能 glob、可选的 参数子句，以及 egress 范围 （仅 egress 规则）。一个部分匹配就是不匹配，而评估移到下一条规则。

​
2. 一个具体示例：特定先于宽泛

标准的排序工作是让一个窄的 allow 在一个宽的 deny 中存活。把特定的 规则放在一个更低的优先级上，这样它先被触及： 
// Rule A — priority 10: trust this one exact tool.
{ "label": "allow safe shell", "priority": 10,
  "tool_name_glob": "shell.echo", "verdict": "allow" }

// Rule B — priority 20: block the rest of the shell family.
{ "label": "block shell family", "priority": 20,
  "tool_name_glob": "shell.*", "verdict": "deny" }
一次对 shell.echo 的调用先撞上 Rule A（优先级 10）、匹配，并被允许 ——引擎从不触及 Rule B。一次对 shell.exec 的调用落空 A（glob 不匹配）、 撞上 Rule B，并被拒绝。 翻转优先级，那么优先级 10 的宽泛 shell.* 拒绝会先捕获 shell.echo，而你 优先级 20 的 allow 就成了死代码。经验法则：最特定的在先，最宽泛的在后。
不要为此依赖 id 平局打破。如果 allow 和 deny 共享同一 priority，胜者是 你先创建的那条规则——一个脆弱的排序，会在你删除并重新创建一条规则时静默 翻转。给特定的规则一个更低的 priority，意图就明确了。

​
3. 在依赖顺序之前验证它

一旦一条策略有不止一小撮规则，在纸上推理优先级就容易出错。Test 沙箱对 一个样本工具调用运行真实引擎，并告诉你不只是判定，还有哪条规则胜出 ——这样你能确认你预期的规则实际触发了：
1

打开该策略的 Test 标签

在控制台中，打开该策略并切换到 Test（Developer+）。
2

提交一个样本调用

输入一个工具名（以及参数，如果你的规则检查它们）并运行它。不派发任何 东西，不持久化任何东西——它是一次 dry run。
3

读取匹配到的规则

结果点名判定、匹配到的规则（按标签/id），以及原因。如果一条 宽泛规则在你预期一条窄规则的地方胜出，降低该窄规则的 priority 并重新 测试。
关于完整的沙箱参见 测试规则，关于就地 编辑规则顺序参见 管理策略。

​
4. 技能执行叠加于其上

规则优先级决定胜出规则的判定——但那并不总是最终答案。如果该工具调用归属于 一个受治理的 技能，则该技能的执行模式在 首个匹配解析之后叠加在胜出判定之上应用：
技能模式对胜出判定的影响
allow无变化——规则判定成立。
quarantine把任何未到 deny 程度的判定升级为 pending_approval；一个现有的 deny 保持原样。
block无论规则判定如何都强制一个 deny。
所以一个 quarantine 技能能把一条规则的 allow 变成一个被挂起的调用，而 一个 block 技能即便没有规则点名它的工具也拒绝一个调用。Quarantine 只 升级——它绝不把一个 deny 降级为更柔和的东西。这就是为什么一个被自动检测为 有风险的技能会保持被隔离直到你审查它，无论你的规则有多宽松。
技能模式不是一条规则，所以它没有一个 priority，你也无法相对于你的规则 重新排序它。它总是在胜出判定被选中之后评估。如果一个受治理技能的模式 正在拦截你预期允许的调用，在 技能 上修复它， 而非通过添加一条更高优先级的 allow 规则——规则无法覆盖该模式。

​
5. 不走首个匹配的东西

有几个机制位于逐规则优先级遍历之外——知道它们落在哪里，这样你就不会试图 排序它们：
一条在其上限之下的 cap_cost 规则被 当作非匹配，所以评估继续到下一条规则，而非让它以首个匹配作为一个许可 胜出。在上限之上它解析为一个 deny。它绝不仅仅因为被触及就短路一条更低 优先级的规则。
一条 序列规则 跨一个时间窗口匹配 一链调用，所以它由一个异步匹配器被动地执行，而非在完成该链的单次调用 上。它点亮事件信息流，但不为一次单独调用赢得首个匹配遍历。
影子模式 不改变哪条规则胜出——它在 首个匹配解析之后把胜出的执行性判定降级为 audit（原因前缀为 [shadow] would …），这样你能在一条策略改变流量之前衡量它的影响。

​
6. 把它拼起来

对于任何一次工具调用，完整的解析是：
  1. 解析策略——绑定到发起调用密钥的那条，或工作区默认值。参见 范围。
  2. 以 priority ASC, id ASC 遍历规则——首个匹配生效；无匹配 → default_verdict。
  3. 应用技能执行——一个受治理技能的模式叠加在胜出判定之上（block 强制 deny，quarantine 升级）。
  4. 应用影子模式——如果开启，把执行性判定降级为 audit。
  5. 记录事件——判定、执行面、工具和匹配到的规则落入 事件信息流。
编辑一条规则的优先级会在下一次调用时对绑定到该策略的每个密钥生效——无需 重新部署，无需修改智能体代码。在重新排序之后重新运行 Test 沙箱以在实时流量依赖它之前确认新的 胜者。

​
接下来去哪里

判定

每个胜出判定实际做什么。

Glob 语法

工具名匹配如何决定一条规则是否甚至是一个候选。

测试规则

Dry-run 一条策略并看到哪条规则胜出。

工具白名单

最依赖排序的默认拒绝模式。
关于一条规则背后的匹配语言，参见完整的 防火墙规则参考；关于技能如何叠加于其上，参见 防火墙技能 与 执行模式。