跳转到主要内容
你写好了一条防火墙规则——一个针对 shell.exec 的 deny、一个 egress 白名单、一个只在 rm -rf 上触发的参数子句——而现在你想在它改变任何一次 生产工具调用之前知道它确切做你认为的事。防火墙给你三种非破坏性的方式来 测试防火墙规则，每一种回答一个不同的问题：

Dry-run 一次调用

Test 沙箱把一次合成工具调用喂过真实引擎并返回判定——不派发任何东西， 不记录任何东西。Developer+。

重放一个姿态

Simulate 对照你最近的流量重放一个自治级别，并统计它本来会拦截 多少次调用。Member 可读。

对照实时流量运行

影子模式在真实调用上评估一整条策略，但把每个执行性判定降级为 audit。杀伤半径为零。
三者都通过控制台配置（或 /api/workspace/firewall/* 管理路由，它们用 你的会话 / 访问令牌认证——而非一个中继 sk-orca-… 密钥）。在你测试时， 你智能体的 /v1/* 中继调用绝不改变。

​
1. 用 dry-run Test 沙箱测试防火墙规则

Test 沙箱是最紧的循环：交给它一次单一的合成工具调用，它运行真实的 评估引擎——完整的策略解析、按优先级顺序遍历规则、首个匹配生效——然后返回 判定、产生它的规则，以及人类可读的原因。该调用是一次 dry run：不向任何 工具派发任何东西，也不向事件信息流或 Discovered-tools 清单写入任何东西。 它精确地回答一个问题：给定这个确切的工具名和这些参数，我的策略决定什么 ——以及哪条规则决定它？
Test 沙箱是 Developer+。它能按 id 对照一条未保存的草稿策略预览，且响应 浮现匹配到的策略名和规则标签，所以它比一次纯读取更接近一次写入面预览—— 不像 Simulate 和其他读取视图，它们对每个成员开放。

​
一次具体的 dry run

假设你添加了一条应该只在命令包含 rm -rf 时拒绝 shell.exec 的规则。 你想在一次操作中确认两件事：危险命令被拒绝，而一个无辜的仍然通过。
1

测试危险调用

在 Security → Firewall 中，打开 Test 标签，挑选 response 执行面，输入工具名 shell.exec 和参数 {"command": "rm -rf /data"}， 然后运行。响应点名判定和匹配到的规则：
{
  "verdict": "deny",
  "policy_name": "prod-agents",
  "rule_label": "block destructive shell",
  "reason": "destructive shell command",
  "gap": false,
  "shadow_mode": false
}
2

测试无辜调用

用 {"command": "ls -la"} 再次运行。该参数子句不再匹配，所以该规则 落到策略默认——你应该看到 allow 或 audit 以及一个空的 rule_label。 如果 rm -rf 拒绝而 ls -la 不拒绝，你的 参数子句 限定正确。
3

在绑定之前预览一条草稿

传入一个 policy_id 以对照一条特定草稿策略评估，而非你的流量当前解析到 的那条——这样你能在你给它绑定一个密钥或把它晋级为工作区默认之前证明 一条新策略是对的。
读取响应中的 gap。gap: true 意味着一条策略解析出来但其中没有规则 匹配该调用（且工作区处于观察模式）——该工具溜过了每一条规则并落到默认。 那是一个要在你上线之前关闭的覆盖漏洞，而非一个可信任的判定。
Test 沙箱使用与实时评估相同的执行面——inbound、response、mcp、 egress（默认 inbound）——所以在每条规则被钉到的执行面上测试它。在 inbound 上没有调用时参数，所以一条 sanitize 规则在那里升级为一次拦截， 与它在生产中会做的完全一样；关于为什么执行面重要，参见 执行面。

​
2. 在应用一个自治级别之前模拟它

Test 沙箱检查一次调用。Simulate 回答姿态级别的问题：如果我把整个 工作区切换到一个更严格的 自治级别， 它会拦截我最近流量的多少？ Simulate 对照你的尾随防火墙事件重放一个候选级别的 deny 规则，并返回本来会 发生的影响——只有工具名和计数，绝无参数。它是只读且 Member 可读的，所以 团队里任何人都能在一个 Developer 承诺之前预览 tight 的杀伤半径。
  • tight——默认拒绝、拒绝破坏性 shell、拒绝 fetch 形态的工具 （SSRF 向量）、执行 PII Shield + Secrets Blocker。Simulate 显示这个 底线会捕获你真实流量的多少。
  • balanced——默认 audit、拒绝破坏性 shell、PII Shield 仅审计 （flag PII）。推荐的起始姿态。
  • permissive——仅观察；不执行任何东西。
Simulate 不改变任何东西——它是一个对过去事件的假设。应用一个自治 级别（一个 Developer+ 写入）物化出真实、可编辑的 autonomy_* 策略和 防护栏行，并支持从审计快照一键撤销。用 Simulate 预览，然后在计数看起来 合适时应用。

​
3. 影子模式：对照实时流量测试，杀伤半径为零

Test 沙箱和 Simulate 是离线预览。影子模式是实时的那个：一个逐策略的 标志，在真实智能体流量上评估该策略、遍历每一条规则、挑选一个判定——然后 把每个执行性判定（deny、sanitize、pending_approval）降级为 audit， 并给原因加上前缀 [shadow] would …。该调用总是会通过；没有任何东西被拦截、 脱敏或挂起。 那让 事件信息流 读起来就像一次关闭了 执行的生产运行。按 [shadow] 过滤，你就有了该策略即将开始拦截的每一次调用 的完整列表——而它一次都还没拦。
测试方法对照运行它回答的问题
Test 沙箱一次合成调用”这个确切调用得到什么判定，哪条规则决定？“
Simulate最近的事件”一个更严格的自治级别会拦截多少次调用？“
影子模式实时流量”这条策略会在真实生产流量上拦截什么？”
影子模式是三者中更深入的那个——完整的实时覆盖，杀伤半径为零。它有它自己的 页面：用影子模式上线一条防火墙策略 讲解切换开关、[shadow] would … 原因，以及切换到执行。

​
4. 一个实用的测试顺序

三个工具组合成一条安全上线路径——最便宜的检查在先，最宽的覆盖在后：
1

Dry-run 你刚写好的规则

用 Test 确认每条新规则在它应该触发的调用上触发、在它不应该的上通过 ——包括反面情况。快速、Developer+、不持久化任何东西。
2

衡量姿态（可选）

如果你倾向于一个自治级别而非手写规则，先 Simulate 该级别并对照真实 流量读取本来会被拦截的计数，再应用它。
3

对照实时流量做影子

打开影子模式，让一个有代表性窗口的真实调用流动。读取 [shadow] would … 事件；收紧任何暴露了一个误报的规则——仍在影子中， 杀伤半径为零。
4

执行

当信息流在你预期的内容上触发、在你不预期的内容上不触发时，关闭影子。 下一次调用就真正执行。
测试预览的是策略，而非受治理的技能。一个处于 block 或 quarantine 模式的 技能 即便在一条影子策略下仍然执行 ——技能的审查处置胜出。把一条策略置于影子从来就不是请求解除一个技能的 隔离。

​
5. API 参考

这些管理路由使用你的会话 / 访问令牌并是工作区限定的：
方法与路径角色用途
POST /api/workspace/firewall/testDeveloper+对照解析出的（或一条草稿 policy_id）策略 dry-run 一次合成工具调用。返回 verdict、policy_name、rule_label、reason、gap、shadow_mode。不派发或记录任何内容。
GET /api/workspace/firewall/simulate?level=Member对照最近事件重放一个自治级别；返回本来会被拦截的计数。
GET /api/workspace/firewall/policies/:idMember读取一条策略当前的 shadow_mode 标志。
PUT /api/workspace/firewall/policiesDeveloper+切换该策略上的 shadow_mode。
Test 请求体接受 surface（默认 inbound）、一个必需的 tool_name、一个 可选的 args_json，以及一个可选的 policy_id 以覆盖解析。

​
接下来去哪里

影子模式

实时流量上线：[shadow] would …、事件过滤器，以及切换到执行。

验证参数

把一条规则限定到哪些参数——Test 沙箱让你对照 rm -rf vs ls -la 验证的那些子句。

判定

当一次测试不再是测试时，allow / audit / deny / sanitize / pending_approval / cap_cost 各自做什么。

事件日志

影子判定落入的地方——过滤、钻取到运行和匹配到的规则。
关于这些测试检验的规则匹配语法，参见完整的 防火墙规则 参考；关于测试在更广模型中的位置， 参见 执行模式。