OpenAI Codex 源码研究(四):可测试规则和模型评审如何协作

沙箱回答“命令最多能触达什么”，审批链则回答另外两个问题：这条命令是否需要询问，以及某些审批请求能否自动处理。

Codex 在这条链上提供了两种互补机制：确定性的 execpolicy 规则，以及面向特定审批路径的 Guardian 模型评审。

execpolicy：可测试的命令规则

codex-execpolicy 使用 Starlark 语法描述前缀规则：

prefix_rule(     pattern = ["cmd", ["alt1", "alt2"]],     decision = "prompt",  # allow | prompt | forbidden     justification = "解释规则存在的原因",     match = [["cmd", "alt1"], "cmd alt2"],     not_match = [["cmd", "oops"]], ) 

其中有四个重要设计：

1. decision
    支持放行、询问和禁止，多个规则命中时取最严格结果；
2. match
    与 not_match 会在加载策略时校验，相当于策略文件自带回归样例；
3. justification
    为规则提供可读理由；对于 forbidden，文档建议在合适时给出替代方案，但并非语法强制；
4. 匹配先检查首 token 的精确规则。只有启用 host executable 解析时，绝对路径才可能回退到 basename 规则；host_executable 可进一步限制允许解析的绝对路径。

这比“字符串白名单”多出两个关键能力：规则可解释，变更可验证。

Guardian：对审批请求做独立评审

core/src/guardian/mod.rs 描述了四步流程：

1. 重建紧凑转录，保留用户意图及近期相关上下文；
2. 使用独立 Guardian 会话评估计划动作，并返回结构化 JSON；
3. 超时、执行失败或输出格式错误时按拒绝处理；
4. 应用评审给出的明确结果。

Guardian 会继承父配置中的受管网络代理和允许列表。配套政策覆盖数据外泄、凭据探测、持续削弱安全和破坏性操作等风险类别。

需要强调的是，Guardian 不是对所有命令都运行的通用安全证明。它服务于特定审批路由；实际是否启用、处理哪些请求，取决于配置和调用路径。

两种机制为什么要分层

execpolicy 适合可枚举、可复现的组织规则，例如禁止某类命令或限制可执行文件路径。Guardian 适合需要结合用户意图和近期上下文判断的审批请求。

前者稳定、可测试；后者灵活，但会带来延迟、误判和模型依赖。因此更合理的组合是：能用确定性规则解决的先用规则，只有上下文判断确有价值时再进入模型评审，并让失败方向保持保守。

本文基于 OpenAI Codex commit 343074d 的静态源码分析。文中的架构判断不等同于对安全性、性能或生产成熟度的背书。