跳转到主要内容
你写好了一条防火墙策略——一种默认拒绝姿态、一条针对 shell.exec 的 deny、一个 egress 白名单——而且你相信它是对的。但把它对照生产智能体 流量切换上线是一次信仰之跃：一条过宽的规则，你就会拦下你的智能体正当 发出的调用。 防火墙影子模式就是那个安全上线开关。它是一个逐策略的标志，告诉网关 完全像在生产中那样评估该策略、记录一切，但不拦截任何东西。每个执行性 判定都被降级为 audit，事件原因前缀为 [shadow] would …，这样你就能 精确读出该策略本来会做什么——而它还什么都没做。
影子模式是一个策略上的标志，在控制台中设置（或通过 /api/workspace/firewall/policies 管理路由，它们使用你的会话 / 访问 令牌——而非一个中继 sk-orca-… 密钥）。切换它是一个 Developer+ 操作。你智能体的 /v1/* 中继调用不改变。

​
1. 防火墙影子模式做什么

当一条策略的 shadow_mode 标志开启时，网关运行完整的评估——解析策略、 按优先级顺序遍历规则、挑选一个判定——然后，就在判定生效之前，降级任何 本来会改变该调用的东西：
解析出的判定在影子模式下
deny→ audit，原因 [shadow] would deny — …
sanitize→ audit，原因 [shadow] would sanitize — …
pending_approval→ audit，原因 [shadow] would pending_approval — …
allow / audit不变（已是非拦截性的）
该调用总是会通过。没有任何东西被拦截，没有任何参数被脱敏，没有任何人工 挂起被开启——但事件以该策略本来会产生的判定被记录，所以 事件信息流 读起来就像一次关闭了执行的 生产运行。
[shadow] would … 前缀是你的头条过滤器。在事件信息流中按它排序，你就有 了这条策略即将开始拦截的每一次调用的完整列表，而它一次都还没拦。

​
2. 一次具体的上线

假设你有一条策略 prod-agents，带有一条针对破坏性 shell 命令的 deny 规则，而你想确认它不会在任何正当的东西上触发。
1

打开影子模式

在 Security → Firewall → Policies 中，打开 prod-agents，把 Shadow mode 切换为开启并保存。该策略保留它的绑定和它的规则——它 只是停止执行。
2

让真实流量流动

你的智能体像以前一样继续调用网关。每一次工具调用都被评估；没有任何 东西被拦截。给它一个有代表性的窗口——足够长以覆盖你真实的工具组合。
3

读取本来会发生的拒绝

打开 Events 并按 [shadow] 原因 过滤。每一行显示工具、执行面、运行以及匹配到的规则——所以一次 shell.exec 调用上的 [shadow] would deny — destructive shell command 正是你在生产中会看到的，只是少了 HTTP 400。
4

关闭影子模式

一旦信息流显示该策略在你预期的内容上触发、在你不预期的内容上不 触发，就把 Shadow mode 切换为关闭。从下一次调用起，那些 [shadow] would deny 事件就变成真实的 firewall_blocked 拒绝。
如果影子模式确实暴露了一个误报——一次正当的调用匹配了一条 deny 规则——那就在仍处于影子模式时修复该规则（收紧 glob 或添加一个 参数子句），再次观察信息流。 你对照真实流量迭代，杀伤半径为零。

​
3. 影子模式不软化什么

影子模式是对该策略的预览，而非一个主关闭开关。
受治理的技能在一条影子策略下仍然执行。 一个 block 模式的 技能 仍然拒绝，一个 quarantine 模式的技能 仍然挂起等待审批，即便匹配到的策略处于影子状态。技能执行模式是技能的 审查状态的一个属性，而非你正在预览的策略的属性——把一条策略置于影子从来 就不是请求解除一个技能的隔离。该策略在事件中仍标记为处于影子，但技能的 处置胜出。
还有几个值得了解的边界：
只有执行性判定（deny、sanitize、pending_approval）被降级。一个 allow 或 audit 已经放行该调用，所以没有东西可软化——那些事件仍 携带影子徽标，这样你就能分辨它们被记录时该策略处于影子。
一条 cap_cost 规则会基于该运行累积 的花费解析为一个具体的 allow 或 deny，而影子模式随后降级的就是 那个解析出的判定——一次本来会触发上限的拒绝会像其他任何一样显示为 [shadow] would deny。
影子模式独立地存在于每条策略上。你可以让一条全新的策略处于影子，同时 一条久经考验的策略继续执行——没有一个工作区范围的影子开关让你忘了 关掉。

​
4. 影子模式 vs. 其他上线旋钮

防火墙给你三个不同的”先别破坏任何东西”的控制项。它们解决不同的问题：
控制项范围它回答的问题
影子模式单条策略”如果我执行这条策略，它会拦截什么？“
audit 默认判定单条策略”记录任何规则都没点名的一切，不拦截任何东西。“
观察模式工作区”哪些工具在运行时没有任何策略覆盖它们？”
影子模式是当你有一条真实的、执行性的策略并想在它改变流量之前衡量其确切 影响时该使用的那个。一个 audit 的 默认判定 针对的是一条策略中未匹配的尾部；观察模式则是关于工作区范围内的覆盖 缺口，而非某条特定策略的执行。
你可以把它们叠加。一条处于影子模式的新默认拒绝策略是可能最温和的上线： 即便是默认拒绝底线也只记录 [shadow] would deny 而非拦截，所以你在拒绝 上线之前就能看到你的 allow 规则尚未覆盖的全部调用集合。

​
5. 合规包先落入影子

当你以观察（非执行）模式 安装一个合规包 时，它物化出的防火墙 策略会以影子模式开启创建——它们对照你的流量评估和记录而不拦截任何 东西。把该包晋级为执行会把那些策略切出影子。同样的机制，为你应用： dry-run 这些控制，读取本来会发生的判定，然后执行。

​
6. 切换它

在控制台中，影子模式是策略编辑器上的一个切换开关。同一个标志在管理 API 上作为策略对象上的 shadow_mode 暴露——这些路由使用你的会话 / 访问 令牌并需要 Developer+：
方法与路径角色说明
PUT /api/workspace/firewall/policiesDeveloper+在请求体中对该策略设置 shadow_mode: true / false。
GET /api/workspace/firewall/policies/:idMember读取一条策略当前的 shadow_mode 状态。
每一次变更都写入一条 审计行 并 递增该策略的 version 整数，所以打开和关闭影子本身也被追踪。

​
接下来去哪里

创建并绑定一条策略

影子模式上线的两步设置——创建策略，绑定一个密钥。

事件日志

[shadow] would … 出现的地方——过滤、钻取到运行和规则。

判定

影子模式降级的执行性判定，以及每一个在实时下做什么。

执行模式

影子、审计和观察如何契合更广的执行模型。
关于一旦你关闭影子后一条策略能阻止的威胁，参见 危险工具调用 与 过度代理。