跳转到主要内容
你已经有一条在 staging 中信任的 防火墙策略，而你想 要第二条用于生产、改了两条规则——或者你想收紧实时策略而不丢失对改了什么的 追踪。两者都是策略生命周期动作：把第二条策略立起来作为一个起点，并依靠 每次更新都递增的 version 来知道你的变更已传播。 本页是生命周期参考——分支、版本、默认值，以及启用/禁用/删除。关于首次设置 参见 创建与绑定；关于规则语法参见 防火墙规则。
所有策略管理都发生在控制台中（或 /api/workspace/firewall/* 管理路由， 它们用你的会话 / 访问令牌认证——而非一个中继 sk-orca-… 密钥）。只有你 智能体的 /v1/* 调用才使用中继密钥。创建、编辑和默认一条策略是 Developer+ 操作；读取策略列表及其版本对每个 Member 开放。

​
1. 把你的姿态分支成第二条策略

没有”fork”判定或复制按钮——一个策略名在每个工作区内唯一，所以模式是立起 一条第二条、独立版本化的策略，并在不触碰原始策略的情况下自由地让它发散。 有两种方式播种它：
1

创建新策略，然后编写它的规则

打开 Security → Firewall → Policies → New policy。一条新策略以无 规则和你选择的 default_verdict 创建——在编辑器中编写它的规则（或手动 从源策略复制几条过来）。给它一个工作区内唯一的名称（例如 prod-firewall 与 staging-firewall 并列）。
2

或应用一个用例模板

Templates 库（POST /api/workspace/firewall/templates/apply）在 单个事务中创建一条新策略外加它的所有规则——Coding、Support、RAG、 Data、DevOps、Browser 或 Baseline。当一个模板匹配时，比手工编写更快。
3

发散并绑定

编辑新策略的规则——收紧破坏性 shell 的 deny、换一个 egress 白名单主机 ——然后通过 firewall_policy_id 把它绑定到生产密钥，或将它标记为工作区 默认。源策略不受触动。
第二条策略是测试一个更冒险姿态的安全方式。立起一条、在它上面打开 影子模式、把它绑定到一个金丝雀密钥， 并观察事件信息流——其他每个密钥上的生产策略继续不变地执行。
每条策略携带它自己的来源、它自己的绑定密钥数和它自己的版本线。

​
2. 每次更新都递增的版本

每条防火墙策略都有一个 version 整数。它在策略创建时从 1 开始，并在 每次更新时递增一——一次规则编辑、一次默认判定变更、一次启用/禁用切换、 一次影子模式翻转。它是单调的，绝不重置。 
// GET /api/workspace/firewall/policies/:id  → (abridged)
{
  "id": 42,
  "name": "prod-firewall",
  "enabled": true,
  "is_default": true,
  "default_verdict": "audit",
  "shadow_mode": false,
  "version": 7,          // bumped from 6 → 7 by your last save
  "rule_count": 11,
  "attached_key_count": 3
}
该版本是你的传播信号：网关短暂地缓存解析出的策略，而每次保存都让那个 缓存失效，这样你的编辑在数秒内对绑定的密钥生效——无需重新部署，无需修改 智能体代码。version 不驱动缓存；它是一个你回读的单调变更计数器。当你 保存一条策略并想确认变更已上线时，重新读取该策略并检查 version 是否 前进。
策略 version 是一个变更计数器，而非一个还原点。 它告诉你策略发生了 变更并让网关传播该编辑——它不是一个逐版本 diff 或回滚。关于完整的带 diff 和一键还原的版本化历史，那项能力位于 防护栏： GET /api/guardrail/:id/history、…/history/diff 和 POST /api/guardrail/:id/revert（还原是 Developer+）。对于防火墙策略，你的 审计追踪和在列表中保留一条降级的已知良好策略，就是你保留一个还原点的方式 ——参见 §5。

​
3. 设置并移动工作区默认值

一个工作区可以把一条策略标记为默认。每个没有自己 firewall_policy_id 的密钥都解析到它 （解析顺序）。
  • 编辑一条策略并把它设为工作区默认。晋级一个新默认值会在同一事务中降级 旧的那个——绝不会有两个默认值的窗口，也绝不会有交换中途没有默认值的 窗口。
  • 立起第二条策略是把默认值向前滚的一种干净方式：构建新策略、调整、在影子 模式下验证，然后晋级它。旧默认值留在列表中、被降级，作为你的回退。
移动默认值会一次性改变每个未绑定密钥的执行。如果新默认值把 default_verdict 收紧为 deny，你的规则没有明确允许的调用会立即开始被 拦截。在 影子模式 背后上线一个新默认值 并观察 Events，再晋级它。

​
4. 启用、禁用和删除

把 Enabled 切换为关闭会阻止一条策略解析出来。但记住防火墙的回退： 一个其绑定策略被禁用的密钥回退到工作区默认值——禁用不会把该密钥 移出防火墙范围。要把一个密钥从执行中移除，请解绑它（把 firewall_policy_id 设为 0），而不要仅仅禁用它的策略。（这与防护栏 不同，在防护栏中一个被禁用的绑定会解析为无。）
DELETE /api/workspace/firewall/policies/:id（Developer+）移除一条策略 ——但如果任何密钥仍引用它则返回 409。先解绑或重新指向那些密钥， 然后删除。这个守卫正是为什么立起第二条策略、而非就地重写，是演进一条 实时密钥依赖的策略的更安全方式。
一个策略名在一个工作区内唯一，所以第二条策略需要一个新名称。使用一个 能在生命周期中存活的约定——staging-firewall / prod-firewall，或一个 日期后缀——而非 policy-copy-2。

​
5. 审计追踪

每一次策略创建、更新（包括一次默认晋级或一次影子模式翻转）和删除都写入一个 审计行——既有一个工作区行又有一个中央 admin 行——在变更提交之后。 一次失败的保存（重复名称、无效判定）什么都不写。规则 blob 和密钥绝不被 写入审计日志。 所以即便防火墙策略本身不携带一个 diff-and-revert 历史，审计追踪告诉你 谁在何时改了哪条策略，而单调的 version 告诉你它已经改了多少次。 把那个与在列表中保留一条降级的已知良好策略搭配，你就有了一条实用的还原 路径。

​
6. 生命周期一览

操作路由角色
列出策略（+ 版本、计数）GET /api/workspace/firewall/policiesMember
读取一条策略GET /api/workspace/firewall/policies/:idMember
创建策略（无规则）POST /api/workspace/firewall/policiesDeveloper+
应用一个模板（策略 + 规则）POST /api/workspace/firewall/templates/applyDeveloper+
更新（递增 version）PUT /api/workspace/firewall/policiesDeveloper+
删除（若有密钥绑定则 409）DELETE /api/workspace/firewall/policies/:idDeveloper+
在依赖一条新的或刚晋级的策略之前，在沙箱 Test 标签中 dry-run 它——它 返回判定、匹配到的规则和原因，而不派发任何东西。参见 测试规则。

​
接下来去哪里

创建与绑定

首次设置路径——创建一条策略并把一个密钥指向它。

影子模式

在不改变实时流量的情况下上线一条新的或重新默认的策略。

防火墙 + 防护栏

动作策略如何与文本防护栏组合——以及版本化还原位于哪里。

范围：密钥、策略、工作区

绑定和工作区默认值如何解析。