AI agent Policy Engine 规则分层：权限、合规、风险和豁免如何在系统里表达

很多 AI agent 项目的规则都先写在 prompt 里：不要越权，不要泄露，不要做高风险动作。问题是，prompt 里的规则只对“新生成的意图”有影响，对系统执行、历史恢复、工具调用、人工审批和日志审计几乎没有约束力。

一旦进入真实业务，规则必须从“语言提醒”升级为“系统可执行的 policy”。

建议先配合 AI Agent 安全与权限控制、AI agent 数据脱敏实践、AI agent 人工审批控制台设计和 AI Agent 事故响应手册一起看。

先给结论：Policy 至少分 4 层

层级	解决什么
Permission	当前用户或系统是否有资格做这件事
Compliance	是否触发合规和数据限制
Risk	这一步风险是否高到必须人工确认
Exception	是否存在有记录的豁免或特例

把这些规则混成一句“谨慎处理”，最后只会让模型背锅。

再进一步，真正可落地的 policy engine 不只是“把规则拆成四层”，还要解决三件事：规则从哪里来、谁能改、线上如何解释和回滚。没有治理面，规则层次再清楚，也会在几次迭代后变得不可控。

一、Permission 规则先判断“能不能做”

Permission 层主要回答：

当前用户是否能读这份资料
当前 agent 是否能调用这个工具
当前环境是否允许写入这个系统

这是最适合做成硬阻断的一层。如果 permission 不通过，后面的 risk 和 compliance 根本没必要继续算。

Permission 层最怕的是来源分散。用户权限、agent 工具权限、环境权限如果来自三套不同配置，最终很难解释“为什么这次被拒”。所以 permission 规则最好明确区分来源：

身份权限：当前用户或服务账号能做什么
工具权限：当前 agent/toolset 是否允许这个动作
环境权限：当前环境是否允许写外部系统

这样 policy 输出时，才能准确告诉系统是哪一层没过。

二、Compliance 规则判断“即使有权限，是否也不该这样做”

很多团队把 permission 和 compliance 混在一起。区别在于：

permission 是“有没有资格”
compliance 是“是否满足额外限制”

例如：

用户有权限看某条客户记录，但这条记录的某些字段不能进入模型上下文
agent 有权限生成外发文案，但某些内容必须先通过合规检查

compliance 不一定直接拒绝，也可能要求改走脱敏、摘要或人工复核路径。

如果 compliance 规则会随地区、客户类型或数据等级变化，建议把规则上下文也做成显式输入，而不是散在业务代码里。例如：region=cn、data_class=restricted、customer_tier=enterprise。否则同一条 policy 很容易在不同入口表现不一致。

三、Risk 规则判断“需不需要升级处理”

不是所有风险都该直接阻断。很多时候更合适的是升级到人工或特殊流程。

风险级别	常见动作
low	自动继续
medium	记录并继续，必要时提示
high	进入人工确认
critical	直接阻断

Risk 层的重点不是“尽量不让 agent 做事”，而是给不同风险配置不同门槛。

为了让 risk 真正可操作，建议把风险输出拆成两个部分：

riskScore 或 riskLevel：给决策引擎和报表使用
riskReasons[]：给审批台和审计使用

没有原因的风险等级，很难让人接受，也很难在误报时修正。

四、Exception 规则必须显式记录，而不是靠人临时放行

真实业务里总会出现特例：

某个项目临时允许某工具越过默认限制
某类客户在特定时间段内允许加急流程
某条规则在测试环境里临时放宽

这些豁免如果只靠口头约定或本地配置，后面一定难以审计。Exception 至少要记录：

{
  "exceptionId": "ex_123",
  "scope": "project_456",
  "ruleId": "risk.external_send.requires_review",
  "approvedBy": "ops_lead",
  "expiresAt": "2026-05-10T00:00:00Z",
  "reason": "活动期间临时放宽"
}

豁免规则最好永远是“加在显式规则之后的受控覆盖”，而不是直接把原规则删掉。否则系统最后只会留下一个结果，看不出到底是规则本身允许，还是有人临时放宽过。

五、规则版本和发布来源要可追踪

当 policy 越来越多时，另一个关键问题会出现：线上这次决策，到底用了哪版规则集？如果查不出来，任何审计和回滚都会很痛苦。

建议每次 policy 执行都至少带上：

{
  "policyBundleId": "bundle_2026_05_07_01",
  "policyBundleVersion": "2026-05-07.1",
  "ruleSource": "central_registry",
  "environment": "prod"
}

这样当规则误拦截或漏拦截时，团队能快速定位是某次 bundle 发布的问题，而不是笼统地说“policy 最近变了”。

六、Policy Engine 输出要能被系统消费，不只是显示给人看

一个可执行的 policy 结果至少要包含：

{
  "allowed": false,
  "decision": "human_review",
  "matchedRules": [
    "permission.tool.send_email.denied",
    "risk.external_send.high"
  ],
  "userMessage": "当前动作需要更高权限或人工确认。",
  "auditCode": "POLICY_REVIEW_REQUIRED"
}

其中：

decision 给工作流引擎用
userMessage 给前端或运营用
matchedRules 和 auditCode 给审计和排查用

如果 policy 结果只是一段人类可读文本，系统仍然无法稳定执行。

如果这套结果还要进入人工审批台，建议再补一个 explanation packet：

{
  "decision": "human_review",
  "matchedRules": ["risk.external_send.high"],
  "primaryReason": "external send with high impact",
  "recommendedActions": ["approve", "reject", "edit_and_resume"]
}

这会比单纯展示规则 id 更适合给人快速理解。

七、规则执行顺序很重要

一个常见顺序是：

permission -> compliance -> risk -> exception merge -> final decision

不要一开始就先跑 risk 分析，再发现其实这个动作根本没权限。顺序错了，不仅浪费成本，还会让决策解释变得混乱。

同时要先定义“谁有最终优先级”。一个可执行的优先级原则通常类似这样：

条件	结果
permission deny	直接 deny
compliance require_redaction	改写输入后重新评估
risk high	human_review
exception approved	在规定范围内覆盖前面结果

重点不是规则写成哪种 DSL，而是同一动作在多条规则命中时，系统必须给出唯一且可解释的结论。

八、规则变更必须进回归，不要只测一两个 happy path

Policy engine 很容易在一次看似无害的规则调整后，把别的场景一起带坏。建议至少保留这几类回归样本：

permission deny 的硬阻断样本
compliance 改写后允许继续的样本
risk high 进入人工审批的样本
exception 覆盖后允许放行的样本

规则系统最怕“每条规则自己都对，组合起来却错了”。

九、上线后要看 policy 指标，而不只是拦截数

建议持续观察：

指标	用途
policy deny 比例	判断是否过严或异常放大
human_review 触发率	判断风险门槛是否合理
exception 覆盖占比	判断系统是否过度依赖豁免
explain packet 缺失率	判断解释链路是否完整
规则版本回滚次数	判断 policy 发布是否稳定

如果 exception 覆盖占比持续升高，通常意味着基础规则已经脱离业务现实，需要重构而不是继续打补丁。

十、失败案例：prompt 说要谨慎，系统却没有真正阻断

一个外发 Agent 的 prompt 明确写了“发送前请谨慎确认”。但因为系统没有 policy engine，模型某次误判“这次可以自动发送”，工具层又没有二次校验，结果通知真的发出去了。

修复后，他们把发送动作改成：

permission 先验证用户和 agent 的外发资格
compliance 检查是否包含敏感字段
risk 判断是否属于高风险外发
结果统一输出 human_review

从那以后，“请谨慎”才真正变成系统行为，而不是一句愿望。

十一、Policy Engine Checklist

结语

AI agent 的 policy 设计，本质上是在把“组织规则”翻译成“系统规则”。只有 permission、compliance、risk 和 exception 分层明确，agent 才能既有边界、又不至于处处卡死。