当系统进入多 Agent、Auto-Run、HITL 2.0 阶段后，治理复杂度会快速上升。
如果策略仍停留在文档、会议纪要或“大家都知道”的口头共识，最终一定出现三类问题：
- 执行不一致：同一规则在不同团队、不同 Agent 上行为不同。
- 变更不可控：改了规则却不知道影响了哪些流程。
- 审计不可证：出了问题无法证明“当时为什么这么执行”。
这章要做的就是把治理规则变成工程资产：像代码一样被开发、测试、发布、回滚和审计。
学习目标
完成本章后，你将能够：
- 设计 Policy as Code 的规则模型与仓库结构。
- 为策略建立测试体系（单测、场景测、回归测、对抗测）。
- 将策略变更纳入 CI/CD 门禁，做到“未通过不生效”。
- 建立策略决策日志与审计回放，支撑合规和事故复盘。
一、策略即代码：先明确“策略对象”
策略不是一条 if-else，而是四类对象：
AccessPolicy：谁能在什么上下文调用什么能力。RiskPolicy：风险评分如何影响执行模式与审批链。DataPolicy：哪些数据可见、可写、可出境。ReleasePolicy：哪些指标达标才允许发布与放量。
把对象分清后，规则才能稳定演进，而不是互相覆盖。
二、规则仓库结构建议
建议为策略建立独立仓库或独立目录，最小结构如下：
policy/
access/
risk/
data/
release/
schemas/
tests/
fixtures/每条规则应包含：
- 规则 ID（全局唯一）
- 版本号
- 生效范围（环境、团队、工作流）
- 生效时间
- 责任人
2.1 示例规则
id: POL-AI-AUTO-RUN-L3-001
version: 1.2.0
type: access
description: L3动作必须双签审批
scope:
env: ["prod"]
workflow: ["auto_run"]
rule:
if: "action.level == 'L3'"
then:
approval: "dual_sign"
auto_execute: false
owner: platform-governance三、策略测试金字塔：别只做“语法通过”
很多团队只验证规则文件能解析，这是远远不够的。
3.1 单元测试（Rule Unit Test）
验证单条规则在输入样本上的判定结果。
3.2 场景测试（Scenario Test）
验证多条规则组合后是否得到预期决策。
3.3 回归测试（Regression Test）
用历史事故样本确保“修过的问题不再回来”。
3.4 对抗测试（Adversarial Test）
构造越权、冲突、模糊输入，验证规则不会被绕过。
四、策略变更门禁：规则改动必须“先验证再生效”
策略变更应进入与代码同等的交付门禁：
- Schema 校验：字段完整性、类型正确性。
- 兼容性校验：是否影响现有工作流。
- 规则冲突检测：是否出现互斥判定。
- 测试通过率门槛：关键测试必须 100% 通过。
- 审批流程：高风险策略需双审。
policy_ci_gate:
must_pass:
- schema_validation
- conflict_detection
- regression_suite
quality_bar:
critical_tests: "100%"五、策略发布：灰度、生效窗口、可回滚
策略更新不应直接全量生效。
5.1 发布步骤
shadow：只评估不执行，观察判定差异。canary：在小流量/低风险流程生效。progressive：逐步扩大范围。stable：全量生效并冻结版本。
5.2 回滚要求
每次策略发布必须绑定上一个稳定版本，支持一键回滚。
六、策略冲突管理：治理规则也会“打架”
常见冲突：
- A 规则要求自动执行，B 规则要求人工双签。
- 数据规则允许读取，访问规则禁止调用。
6.1 冲突解法
- 规则优先级（例如：安全 > 合规 > 效率）
- 显式冲突策略（deny-overrides / allow-overrides）
- 冲突日志必须可查询
conflict_resolution:
strategy: deny_overrides
precedence:
- data_policy
- access_policy
- risk_policy
- release_policy七、审计链路：每次判定都要有证据
策略系统的审计最小事件应包含：
- 输入上下文摘要（脱敏）
- 匹配到的规则列表与版本
- 决策结果
- 决策理由
- 规则仓库 commit SHA
{
"traceId": "trace_20251217_01",
"policyDecision": "deny",
"matchedRules": ["POL-AI-AUTO-RUN-L3-001@1.2.0"],
"reasonCodes": ["requires_dual_sign"],
"policyCommit": "8f4c2d1"
}这让你在事故复盘时能回答“当时系统按哪条规则做了什么决策”。
八、Foundation 接口建议
public sealed class PolicyInput
{
public string PolicyType { get; init; } = string.Empty;
public string ContextJson { get; init; } = string.Empty;
}
public sealed class PolicyDecision
{
public string Effect { get; init; } = "deny"; // allow/deny/review
public IReadOnlyList<string> MatchedRuleIds { get; init; } = Array.Empty<string>();
public IReadOnlyList<string> ReasonCodes { get; init; } = Array.Empty<string>();
}
public interface IPolicyEngine
{
PolicyDecision Evaluate(PolicyInput input);
}
public interface IPolicyReleaseService
{
void Deploy(string policyVersion, string stage); // shadow/canary/progressive/stable
void Rollback(string policyVersion);
}这组接口将策略执行与策略发布解耦，便于独立治理。
九、落地顺序（建议 3 周）
第 1 周：建模与仓库
- 完成策略对象分类与规则格式统一。
- 建立策略仓库与版本规范。
第 2 周：测试与门禁
- 落地单测/场景测/回归测。
- 接入 CI 门禁与冲突检测。
第 3 周：发布与审计
- 上线 shadow -> canary 发布流程。
- 打通判定审计事件与回放查询。
常见坑
1) 策略写进应用代码
会导致规则变更必须发版，治理效率极低。
2) 规则无版本号
无法复盘与回滚，审计链断裂。
3) 只测“允许路径”
拒绝路径和冲突路径同样关键。
4) 策略仓库无人负责
没有 owner 的规则会快速腐化，最终形同虚设。
下一章我们进入《跨租户与多环境治理：统一规则、分域执行》，解决大规模组织下“同一平台不同业务域”的策略一致性与差异化配置问题。