为什么 AI 代理不遵守规则 — 物理治理的必要性

Source: Dev.to

开始的事实

一个代码库中有超过 130 KB 的治理文档。
AI 代理读取并确认了这些文档，却在下一次调用工具时违反了它们。

这不是指令的失败。这是架构的失败。

为什么文字规则会失效

当前对 AI 代理治理的标准做法是：在提示中写一条规则。

规则

• 永不编辑 evals/ 目录
• 禁止对 00_Management/ 进行写操作

这些规则存在结构性缺陷。文字规则只在读取时生效。 它们假设代理会选择遵守，但没有机制在执行时强制这种选择。

这就是为什么 rm -rf / 需要确认标志，而不是一份政策文档。物理约束在执行时生效，而文字规则在读取时生效——时机错误。

验证污染问题

如果代理能够评估自己的输出，它就可能污染评估标准——不是有意为之，而是把生成阶段的失效模式带入评估阶段。一个始终通过测试的系统可能是一个测试根本不起作用的系统。

AOS 的定义

AI Operating Standard（AOS） 为共享代码库中的 AI 代理操作定义了最小的物理约束层。它由三个组件组成。

1. 区域 — 对每条路径进行分类

2. 角色 — 不重叠的职责

三种角色：Architect（架构师）、Executor（执行者）、Sovereign（主权者）。
代理 必须不 超出其分配的角色行动。当触及角色边界时，代理停止并上报给人类。

3. 物理强制 — 在执行时拦截

PreToolUse 钩子在文件系统访问发生前阻止写操作。

• 写入 Oracle 区域 → 退出 2（调用从不执行）
• 破坏性模式（sed -i、perl -i、truncate） → 退出 2

不假设代理的善意；物理法则强制合规。

参考实现：iron_cage

iron_cage 是 AOS 的参考实现。它通过 Claude Code 的 PreToolUse 钩子系统实现了 §§ 4.1–4.5。

iron_cage 背后是一种叫做 Type‑91 Governance 的设计原则：

• 取证隔离 — 防篡改的物理证据链
• 物理隔离 — 代理无法修改自己的评估标准

脚本是表层；架构更为深层。AOS 是标准，而 iron_cage 证明了它可行。

规范（AOS‑v0.1）

将规范喂给代理

规范不仅写给人类阅读。AOS-v0.1.md 以 §0：机器阅读指令 开头。将该规范加载到代理的上下文窗口，使代理能够在规范层面理解它不应做什么。

不是 “因为提示里说不要做 X”。
而是 “因为规范将其定义为具有物理强制机制的硬约束，所以不要做 X”。

这正是 AOS 的第二个设计意图：读取规范的代理会自我约束。

为什么是现在

到 2026 年，“如何信任 AI 代理生成的内容”仍未解决。大多数团队仍尝试用提示来解决，但缺少物理治理层的标准。必须有人来定义它——AOS 正是这种尝试。

这只是草案

AOS v0.1 仍不是完整的标准。欢迎提交问题、拉取请求和实现报告。

代码库：