Policy as Code
类型：策略治理规范
复用规则：稳定复用的规范说明页
当前口径：截至 2026-03-17，
Policy as Code仍然更适合被定义为一类治理与工程实践，而不是单一正式标准；当前公开权威口径可参考 CNCF 对Policy as Code的定义，以及 Open Policy Agent 官方文档对策略语言、Bundle 分发和 Decision Logs 的工程实践权威来源：CNCF Glossary、OPA 官方文档；当前方案不引入新策略组件，规范主要约束既有
Casbin策略、网关规则、模型与工具治理配置的受控管理方式当前方案执行点：
Casbin策略资产、门户 / BFF 规则配置、网关与运行时受控策略、发布流程与审计链路
当前定位
Policy as Code 是当前方案的策略资产化治理基线。
它要求把权限、审查、风险控制、工具可用范围、模型路由规则和关键阈值等“会改变系统行为的策略项”，从零散代码和人工口头配置中抽出来，变成可版本化、可评审、可测试、可发布、可回滚的受控资产。
规范约束什么
- 哪些规则必须视为“策略资产”，不能只藏在业务代码或环境变量里。
- 策略如何被编写、评审、测试、发布、审计和回滚。
- 策略如何分发到各执行点，并在运行时产生可追踪的裁决记录。
- 当策略执行失败、依赖不可用或上下文缺失时，系统如何兜底。
核心原则
- 策略与业务代码分离，避免逻辑和规则耦合成不可审查黑盒。
- 策略变更进入版本管理、评审和发布流程，而不是直接在线热改。
- 关键策略在发布前要可测试、可校验、可做兼容性检查。
- 运行时决策要可追踪，能看到命中规则、输入上下文和裁决结果。
- 策略执行失败时要有清晰的失败模式和默认行为，不能默默放行。
在当前方案中的落点
- Casbin 的模型与策略规则应作为正式策略资产纳入版本管理和发布流程。
- 门户 /
BFF/ 工具层中的高风险动作限制、工具白名单、环境开关和租户规则，不应散落在临时代码分支中。 - 模型路由、知识可见范围、Prompt 安全阈值和外部动作限制，都应按“策略资产”而不是“实现细节”管理。
- 发布流程要支持策略测试、灰度、回滚和审计，避免“改了一条规则导致全平台行为漂移”。
与组件 / 协议关系
- 与 Casbin 的关系是“策略治理规范”与“策略裁决实现”的关系。
- 与 OpenAPI 的关系是：接口契约描述接口形态，策略资产定义接口在什么条件下可被调用。
- 与 OpenTelemetry 和审计链路配合时，应记录策略命中与决策结果，形成可复盘证据。
- 与 Maker-Checker 配合时，高风险策略变更本身也应纳入审批和双人复核。
适用场景
- 授权与访问控制策略
- 工具白名单、黑名单和动作分级
- 数据访问、知识检索和租户隔离规则
- 模型路由、成本阈值、风险阈值与发布门槛
- 网关与平台运行时的统一策略收敛
边界
- 不等于引入某一个特定开源项目；它首先是一种治理方法。
- 不替代业务规则设计和责任归属，写成代码不代表策略本身正确。
- 不替代审批流；高风险策略上线仍应走人工评审与受控发布。
- 不意味着所有配置都要做成复杂 DSL，关键在于是否进入受控生命周期。
落地规则
- 明确“哪些属于策略资产”，至少包括授权规则、工具限制、风险阈值、模型路由和关键安全开关。
- 所有正式策略资产都应进入版本库，具备责任人、评审人、变更说明和回滚路径。
- 策略发布前至少经过静态校验、示例测试和关键场景回归验证。
- 运行时应记录策略版本、输入上下文摘要、命中规则与决策结果。
- 策略执行失败时，涉及高风险动作应默认收敛到保守路径，而不是无声放通。
治理注意点
- 要防止把环境差异、租户例外和历史兼容逻辑不断堆到同一套策略里，导致规则失控。
- 要区分“平台级通用策略”和“业务场景特定策略”，避免职责边界模糊。
- 要对策略变更建立分级门槛，尤其是权限、数据、外发动作和模型切换相关规则。
- 要确保策略日志和审计日志能关联到请求、用户、应用和发布批次，形成闭环。