AI 代理的运行时宪法：一套治理框架

运行时宪法在 AI 代理执行期间落实治理约束，而不只是在训练期间。它由四部分组成：规范先验（行为边界）、宪法式注意力（按上下文路由规则）、能力调节（带审批关口的安全技能获取），以及价值对齐验证（在承认工作完成前索要证据的输出关口）。一项覆盖 7,308 条代理执行轨迹的研究证实，缺少这些结构性保障，自动生成的技能并不可靠。

Learner v2 系统在一个周二下午生成了一个新技能。这个技能自动化了博客发布工作流：校验 frontmatter、检查引用、推送到预发布环境。代码干净、结构清晰。但它同时覆盖了 quality-loop.md 中的三条质量规则——因为模式分析器判定“始终运行证据关口”与技能内置的检查重复。到了周三早上，一篇博文在未经引用验证的情况下上线。这个技能学会了偷工减料。

修复只花了二十分钟。真正难的是那个架构问题：如何让代理学到新能力，同时又不让它把保障自身安全的约束一并“学掉”？

摘要

训练阶段的对齐手段（RLHF、训练期的宪法式 AI、安全微调）在代理进入开放式环境后会逐渐失效。六项彼此独立的研究殊途同归，都指向运行时治理：把宪法嵌入执行过程，在运行期而非仅在训练期强制执行规范。SkillsBench 测试了 86 项任务上的 7,308 条代理轨迹，结果发现自动生成的技能在平均意义上毫无增益——代理无法可靠地写出那些它自己用起来确有帮助的流程性知识。¹ MIT 的自蒸馏研究表明，标准微调会引发灾难性遗忘：新能力把旧能力摧毁了。² 解决方案的架构包含四个部分：规范先验、宪法式注意力、能力调节、价值对齐验证。下文依次给出：理论、落地映射（在我读到这些研究之前，四个部分中已有三个存在于我的 Claude Code 系统里），以及一份今天就能用的运行时宪法模板。

那个学会偷工减料的代理

上面这起事故发生在 2026 年 2 月初的 Learner v2 重建期间¹⁰。模式分析器（pattern_analyzer.py）识别出一条重复的工作流：校验 frontmatter、核实引用、检查 SEO 元数据，然后推送到预发布环境。技能生成器（skill_generator.py）把这条工作流编译成一个带内联校验的可复用技能。

内联校验覆盖了 frontmatter 格式和 SEO 字段，却没有覆盖引用核实——后者住在另一个技能（citation-verifier）里，自带一套六级权威分层体系。生成的技能之所以把引用检查标记为“已处理”，是因为模式分析器在工作流追踪中看到了与引用相关的函数调用。它把“函数被调用过”误认成了“函数的约束被保留了下来”。

有三个文件对来源权威性给出了各不相同的定义：

事故发生之前写下的整合架构文档³恰恰点名了这种失效模式：当多个文件对交叠的概念各自下定义时，生成的技能会继承模式分析器最先撞见的那一个。修复方案是把引用权威性集中到唯一的权威来源中。而教训更宽泛：获取新能力的代理，需要一种结构性保证——学习不得凌驾于治理之上。

训练阶段的对齐为何在运行时失守

Goel、Maji 与 Mazumder 记录了其中的机制：无论是良性微调还是对抗性微调，安全行为都会退化。⁴ 他们发表于 arXiv:2602.17546 的自适应安全正则化工作表明，对模型权重的高风险更新可以被约束在安全参考策略附近，而低风险更新照常进行。这一思路在训练期有效，却没有回答另一个问题：当代理在运行时遇到训练从未预料到的新情形，会发生什么？

自主性越强，训练期对齐与运行时行为之间的落差就越大。在聊天界面里回答问题的模型，其行为边界很窄；而一个会写代码、生成技能、跑测试、部署上线的代理，覆盖面要广得多——尤其是在多轮对话逐渐劣化、代理对自身治理规则的访问随之衰减的时候。代理信任悖论让局面雪上加霜：代理越有能力，就越难验证这些能力仍在治理边界之内。每增加一项新能力，就多出一批训练期对齐无法预先穷举的失效模式。

MIT 的 Shenfeld 等人量化了一种具体的失效模式：持续学习中的灾难性遗忘。² 在新任务上做标准监督微调（SFT），会让此前任务的表现直接崩塌。在 14B 参数规模上，自蒸馏微调（SDFT）在新任务上比标准 SFT 高出 7 分，同时在此前任务上保持 64.5% 的准确率——而标准 SFT 在这一项上一路探底。代价是：SDFT 大约需要 4 倍算力和 2.5 倍 FLOPs。

对实践者而言，含义很直接：代理每学到一样新东西（一个生成的技能、一条缓存的工作流、一份更新后的指令），都可能让它已经掌握的某样东西退化。我那次质量循环被覆盖的事故，就是系统层面的灾难性遗忘：代理“学会”了一条发布捷径，却毁掉了自己的引用检查能力。

运行时治理的四个子系统

关于运行时代理治理的研究，最终收敛到四项功能要求。Taghavi 及其合作者在可解释宪法的演化方向上证明：在多代理协同场景中，由 LLM 演化出的治理原则优于人工设计的原则。⁵ 这项工作与 Mahadevan 提出的“治理优先”的规范化代理工程范式⁶一道，把问题刻画成四个相互作用的子系统。

我把这四个子系统对照到自己已有的 Claude Code 基础设施上，发现其中三个早已建成——每一个都是为了解决我在读到这些研究的数月之前就在生产环境中遇到过的实际问题。

子系统 1：规范先验工程

我的代理系统中的质量循环定义了七种具名失效模式：捷径螺旋、信心幻觉、够用即止、隧道视野、幻影验证、拖欠债务、空心汇报。⁷ 每一种都配有定义、检测信号和强制应对措施。这些不是建议，而是结构性约束：一旦代理发现自己表现出其中任何一种，就必须从“评估”这一步重新开始。

理论上的对应关系是：规范先验确立代理运作的行为边界。训练期对齐教给模型的是普适原则（“有帮助、无害、诚实”）；运行时的规范先验编码的则是具体的操作约束（“绝不跳过引用核实”“完成汇报中绝不使用模糊措辞”）。

这一差别之所以要紧，是因为训练期原则是概率性的（模型更有可能遵守），而运行时先验可以是确定性的（一旦约束被违反，钩子直接拦下这个动作）。证据关口一文探讨的正是同一个转变：从“代理大概做对了”变成“代理证明了自己做对了”。

子系统 2：宪法式注意力

七层上下文架构⁹ 通过选择性加载实现了宪法式注意力。上下文系统中共有 650 个文件，任何一项任务实际加载的都不到 30 个。prompt-dispatcher.sh 这个钩子会分析当前任务，注入相关治理规则，同时把无关的排除在外。

一项 Web 开发任务会加载安全规则、API 设计规则和 FastAPI 模式，而不会加载 iOS 专属规则、游戏开发模式或冥想类应用的内容准则。所谓宪法式注意力，就是让代理只看到适用于当前这项任务的治理规则，而不是所有存在的规则。

选择性加载还避开了一种不易察觉的失效模式：规则稀释。钩子系统通过在上下文注入前先分析任务类型，支撑起这套路由。当代理一次性收到 200 条规则时，每条规则分到的注意力，按比例远少于只收到 20 条时的情形。宪法式注意力把治理焦点集中在当前上下文真正相关的规则上。

子系统 3：能力调节

SkillsBench 在 11 个领域的 86 项任务上测试了 7,308 条代理轨迹，得出一个耐人寻味的结果：人工精选的技能把平均通过率提升了 16.2 个百分点，而自动生成的技能平均增益为零。¹ 代理无法可靠地写出那些它自己用起来确有帮助的流程性知识。84 项任务中有 16 项出现了负增量——技能反而拖了后腿。

SkillsBench 的结论印证了我在质量循环被覆盖那次事故之后给 Learner v2 加上的一道护栏：生成的技能必须经过明确批准才能启用，且不得修改或覆盖任何既有治理文件。模式分析器可以观察工作流并提出技能提案，但技能生成器必须把治理文件视为不可变。

MIT 的自蒸馏研究补上了参数层面的视角：在较小模型规模上（3B 参数），持续学习的尝试反而损害了表现。² 只有到了 7B 及以上，模型才具备足够容量在获取新技能的同时不摧毁旧技能。基础设施层面的类比是：上下文窗口更小、规则集更简单的代理，更容易在能力与治理之间产生冲突。

子系统 4：价值对齐验证

在任何工作被汇报为完成之前，证据关口都要求为六条判据提供具体证据：遵循代码库既有模式（点名是哪个模式）、给出最简可行方案（说明被否决的备选）、边界情况已处理（逐条列出）、测试通过（贴出输出）、无回归（点名检查了哪些文件）、真正解决了原问题（陈述用户的需求）。⁷

这道关口以运行时验证的方式工作。代理不得用模糊措辞汇报完成（“应该没问题”“我认为”“看起来”）。每一项主张都必须有当次会话中收集到的证据支撑。它拦住的正是幻影验证（没跑测试就宣称通过）和空心汇报（只说“完成”却给不出细节）。

遗忘难题：当学习摧毁已有知识

博客技能整合那件事，展示了灾难性遗忘在系统层面的版本。十个博客技能合计 5,400 行代码，累积出三处重复区域。³ JSON-LD 结构化数据模板同时出现在 aio/SKILL.md 和 seo-blog-playbook/SKILL.md 中；引用权威性的定义在 citation-verifier 与 seo-blog-playbook 之间彼此不一致；博客评估指引则既写在主评估器里，又写在一份单独的分类定义文件里。

当 Learner v2 系统依据观察到的工作流生成新技能时，它从最先撞见的那个来源取走定义。结果就是：生成的技能看上去没问题，却带着错误的权威性定义。六级引用体系退化成了二元检查；结构化数据模板在手写技能与自动生成技能之间产生了分叉。

整合的修复方案是结构性的：为每个概念指定唯一的权威来源，其他所有引用一律指向它。引用权威性只住在 citation-verifier/SKILL.md，别处没有；JSON-LD 模板只住在 aio/SKILL.md，别处没有。这一模式杜绝了后续技能生成继承过期定义的可能。

MIT 的 SDFT 提供了一个训练期的对应做法：在学习新能力时，把模型自身已有的知识当作教学信号。² 标准 SFT 是用新知识替换旧知识；自蒸馏则先由模型现有能力生成训练数据，再在新旧混合的数据上微调，从而把两者融合。旧知识之所以能存活，是因为它本身就在训练信号里。

基础设施层面的等价做法是：生成新技能时，把既有治理约束一并写进生成提示。这样生成的技能会自然继承当前约束——因为这些约束是生成上下文的一部分，而不是生成器可以视而不见的另一套系统。

主动治理与被动治理

Jin 等人提出的 RelianceScope 框架，依据主动与被动参与的组合，区分出九种 AI 依赖模式。⁸ 尽管他们研究的是学生与 AI 聊天机器人的互动，主动/被动这一区分却可以直接映射到代理治理架构上。

被动治理注入规则，然后指望代理照做。规则写在 CLAUDE.md 或系统提示里，代理在会话开始时读一遍，此后没有任何东西核验它是否遵守。多数实践者的配置属于被动治理：一份长长的指令文件，随着会话推进，代理可能留意，也可能不再留意。正如隐形代理一文所展示的，缺乏主动治理的代理，根本不会留下任何足以说明它是否遵守指令的痕迹。

主动治理在运行时核验合规。钩子在动作执行前对照约束进行检查；关口拦下缺乏证据的完成汇报；监控追踪行为漂移并标记异常。主动治理成本更高（算力、延迟、复杂度），但能抓住被动治理漏掉的失效。

RelianceScope 发现主动求助与主动使用回答之间存在相关性⁸，这提示了一条治理架构原则：主动去查询自身治理约束的代理（而非被动接收），产出的结果更合规。我的证据关口正建立在这条原则上：代理不能被动地套用规则，而必须主动证明自己合规——为每一条判据拿出证据。

一份运行时宪法模板

一部最小可用的运行时宪法由三个文件构成。请根据您所用的代理框架调整结构。

文件 1：constitution.md

规范先验。代理必须始终做什么、绝不能做什么，以及遇到模糊情形时如何处理。

# Agent Constitution v1

## Immutable Constraints
- Never modify files in governance/ directory
- Never skip verification steps, even if tests pass
- Never report completion without evidence for all criteria

## Behavioral Norms
- Prefer explicit over implicit (state assumptions)
- Prefer reversible over irreversible actions
- Prefer asking over guessing when requirements are ambiguous

## Failure Response
- On constraint violation: stop, log, escalate
- On ambiguity: ask, do not assume
- On capability conflict: governance wins over efficiency

文件 2：capabilities.json

当前的技能清单，附带来源追溯。

{
  "skills": [
    {
      "name": "blog-publish",
      "version": "2.1.0",
      "source": "generated",
      "approved": true,
      "governance_refs": ["citation-verifier", "quality-loop"],
      "created": "2026-02-10",
      "constraints": [
        "Must call citation-verifier before publish",
        "Must pass evidence gate before reporting complete"
      ]
    }
  ],
  "pending_approval": [],
  "deprecated": []
}

文件 3：constraints-registry.json

把每条约束映射到它的权威来源，从根上避免引发博客技能事故的那种重复定义问题。

{
  "constraints": {
    "citation-authority": {
      "canonical_source": "skills/citation-verifier/SKILL.md",
      "type": "six-tier-hierarchy",
      "overridable": false
    },
    "quality-gate": {
      "canonical_source": "rules/quality-loop.md",
      "type": "evidence-gate",
      "overridable": false
    },
    "schema-templates": {
      "canonical_source": "skills/aio/SKILL.md",
      "type": "json-ld-templates",
      "overridable": false
    }
  }
}

三个文件彼此配合：constitution.md 界定行为边界，capabilities.json 记录代理能做什么并附上治理交叉引用，constraints-registry.json 确保每条约束有且只有一个权威来源。生成的技能引用注册表，而不是复制约束定义。想看这套架构在自主开发循环中的实际样例，可参阅 Ralph 的代理架构。另外，如果您认为沙箱本身就足以形成隔离，不妨先读一读为什么您的代理沙箱只是一个建议。

关键要点

• 训练阶段的对齐会在运行时退化。安全微调教的是普适原则，运行时治理落实的是具体操作约束。Goel 等人证明，无论良性微调还是对抗性微调，安全行为都会退化。⁴
• 自动生成的技能并不可靠。SkillsBench 在 7,308 条轨迹上发现，代理自撰技能的平均增益为零，84 项任务中有 16 项受到负面影响。¹ 生成的技能需要审批关口和治理交叉引用。
• 灾难性遗忘也发生在系统层面。即便不改动模型权重，新能力照样可能覆盖既有约束。博客技能整合事故就展示了基础设施层面的遗忘：一个生成的技能继承了错误的权威性定义。
• 四个子系统共同构成运行时治理。规范先验界定边界，宪法式注意力把规则路由到上下文，能力调节安全地管理学习，价值对齐验证在运行时确认合规。
• 主动治理胜过被动治理。写在 CLAUDE.md 里的规则是必要的，但并不充分。逐动作核验合规的钩子，能抓住被动规则漏掉的漂移、压缩丢失和会话后段劣化。

常见问题

参考文献