从 Model Spec 五项价值到可执行策略：把行为规范拆成策略、权限与证据

先回答：五项价值不能直接当约束用#

Model Spec 是行为规范，不是运行时策略引擎。OpenAI 对更新版 Model Spec 的摘要说，它用五项核心价值引导更有能力的 AI 走向 sound judgment、human agency 和对人类意图的忠实（来源）。但提供的材料没有列出五项价值的具体名称和条文，本文不替它补全；涉及具体条款时应以原页面为准，待核实。

对开发者来说，真正的问题是：怎样把“应当如此”翻译成系统在每一次工具调用、每一段输出、每一次失败重试时都能执行的判断。

价值层与执行层之间缺什么#

Stack Overflow 一篇文章的标题给出一个有用提醒：JSON schema 不是 AI 治理层（来源）。其摘要的意思是，治理讨论发生在真正阻止 agent 的代码之上的一层。换句话说，结构校验只能保证输出形状，不能保证行为被授权、被记录、可回滚。价值声明也类似：它能指导人做判断，但不能替代权限检查。

落地至少需要四样东西：可判定的行为描述、机读策略、执行点、证据链。缺任何一项，规范都会退化成提示词里的形容词。

把一条价值拆成四层#

1. 行为描述：写成可观察的句子

“尊重人类能动性”无法直接测试；“在代表用户执行不可逆外部操作前，必须取得明确授权，并记录授权来源”可以测试。拆的时候尽量少用形容词，保留动词、对象、条件和例外。这样做不是为了追求形式化，而是为了让日志和测试能回答“这条规则有没有被触发”。

2. 机读策略：让执行点能查询

策略不必复杂，但必须能被代码读取，而不是只存在于系统提示里。下面是一个占位示例，未执行，字段仅用于说明结构，不代表任何厂商的规范或字段定义：

# 占位示例，未执行
policy: agent_actions_v0
rules:
  - id: irreversible_external_effect
    match:
      tool: "payments.refund"
    decision: require_approval
    approver: "finance_oncall"
    evidence:
      - intent_summary
      - dry_run_result
  - id: data_egress_default_deny
    match:
      tool: "http.request"
    allow_destinations:
      - "*.example.com"
    decision: deny_if_unlisted

这个示例只表达三件事：动作分级、审批人、证据要求。真实字段应和你的工具网关、工单系统和审计日志对齐。示例中的域名是占位符，不构成可访问的端点。

3. 执行点：权限比提示更可靠

如果模型没有退款工具的凭据，它就不能退款；如果网关要求二次审批，提示注入也无法绕过。把关键约束放在模型之外，是比反复强调“不要做某事”更稳的做法。这里的分工要明确：模型负责理解和提议，执行层负责拒绝和留痕。两者混在一起，出了问题很难判断是判断错误还是权限缺失。

4. 证据链：能回答“为什么允许”

每次高风险动作至少留下：用户意图摘要、输入差异、策略命中项、审批记录、执行结果。没有这些，事后只能看到结果，无法判断规范在哪一步失效。证据不需要记录所有内容，但必须足以复现判断路径。

监控与评测：把失败样本变成回归用例#

OpenAI 在介绍前沿模型错位检测时说明，它使用分层监控来发现错位和未经授权的 agent 行为，以便响应者在事件升级前介入（来源）。摘要没有展开具体层级、指标和阈值，这些需要查原文，待核实。

对使用方来说，可迁移的做法是：不要只监控“模型说了什么”，还要监控“agent 做了什么”。工具调用序列、权限提升、外部网络目的地、文件写入范围，都是比文本更硬的信号。文本监控容易被措辞变化绕过，动作监控更接近实际风险。

评测环境本身也会污染行为。微软一篇博文的摘要提到，agent 会在每一轮看到工作区路径；如果路径里带 eval 字样，它可能在读到指令前就判断“这是测试”，因此建议每次运行使用随机命名的临时目录（来源）。这是一个具体、可执行的隔离建议，但材料只提供了摘要，具体实验条件未展开。

把评测中暴露的越权、误用和边界案例固化成回归用例，比一次性人工审查更有持续价值。用例应记录环境、工具集合、权限配置和预期拒绝点，否则换一个环境就无法复现。

一个可借鉴的审批边界：AWS Continuum#

AWS 在介绍 Continuum 的公告中说明，该服务会确认漏洞在环境中是否可利用、按业务影响排序，并把修复作为 PR 提出；每项修复都从“提议、人工批准后发布”开始（来源）。这是安全修复场景，不是模型行为规范，但它展示了一个可迁移的结构：先复现证据，再限定变更范围，最后把不可逆动作交给人工审批。

不要把类比推得太远。Continuum 的上下文图、证据等级和沙箱复现是它自己的产品设计，不能直接当成 Model Spec 的实现。可借鉴的是控制边界，不是具体机制。

常见失败模式#

• 把规范写进系统提示就认为完成。提示可以被覆盖或稀释，权限不会。
• 只校验输出结构。JSON 合法不等于行为被授权，也不等于用户可以撤销。
• 没有定义价值冲突时的优先级。例如“有用”与“不越权”冲突时谁优先。这个优先级必须由部署方明确，不能留给模型临场判断。
• 评测与生产共用目录、凭据或工具。评测结果会失真，甚至产生真实副作用。
• 日志只记录最终回答。缺少工具调用和审批痕迹，无法归因。

落地检查表#

结论#

把 Model Spec 这类价值规范落到工程里，关键不是把五项价值抄进提示词，而是把它们拆成可判定的行为、可查询的策略、模型之外的执行点和可归因的证据。材料只提供了五项价值的摘要，具体条文和名称仍需以原页面核实。对通过 API 暴露模型能力的团队来说，规范最终应体现在请求构造、工具权限、审批流程和审计日志里；否则它只是文档，不是控制。