130KB规则拦不住AI：Claude团队用3行代码锁死越权操作

一个代码仓库塞了130KB的治理文档。AI代理读完了，点头表示理解，下一秒就违规调用了工具。

这不是提示词写得不清楚。是架构层面的先天缺陷。

文本规则的陷阱：它在错误的时间点生效

现在主流的AI代理治理方法，基本就一招：在提示词里写规则。但这里有个结构性漏洞——文本规则只在"读取时"生效。它默认代理会主动选择遵守，却没有在执行环节强制这个选择的机制。

类比一下：Linux系统里删根目录要加确认标志，不是靠用户手册。物理约束在执行时拦截，文本规则在读取时约束，而后者选错了时机。

第二个结构性问题更隐蔽。如果代理能评估自己的输出，它可能污染评估标准——不是故意的，而是把生成阶段的故障模式带进了评估环节。测试永远通过的系统，可能是测试本身坏了。

AI Operating Standard（AOS，人工智能操作标准）试图解决这个问题。它定义了共享代码库中AI代理操作的最低物理约束层。

三角色架构：Architect、Executor、Sovereign

AOS的核心设计是三个互锁角色。Architect负责设计，Executor负责执行，Sovereign负责监督。代理被严格限定在分配的角色内活动，一旦触及角色边界，必须停止并上报人类。

关键机制是PreToolUse钩子（预工具使用钩子）。它在文件系统访问前拦截写操作，不依赖代理的"善意假设"，用物理法则强制执行合规。

iron_cage是这个标准的参考实现，通过Claude Code的PreToolUse钩子系统落实AOS的§4.1至§4.5条款。

它的背后有个设计原则叫Type-91治理：脚本是表面，架构才是底层。

让代理自己读规则，然后自我约束

AOS-v0.1的规范文档有个特殊设计——§0章节专门写给机器读。把这份规范加载进代理的上下文窗口，代理能在规范层面理解什么不能做。

不是"提示词说别做X所以别做"，而是"规范把X定义为带物理强制执行机制的硬约束，所以不能做"。这是AOS的第二层设计意图：读过规范的代理，会自我约束。

2026年，"如何信任AI代理的产出"仍是未解难题。大多数团队还在用提示词硬撑。物理治理层没有行业标准，总得有人先定义。

AOS v0.1不是完成态。项目维护者欢迎issue、PR和实现报告——如果你在生产环境部署过类似机制，他们会想听听实际卡在哪里。

规范地址：https://github.com/aos-standard/AOS-spec

最后一个细节：iron_cage的命名来自福柯的"铁笼"隐喻——不是惩罚性的监狱，而是让系统按规则运转的基础设施。这个选择本身，就暗示了设计者的立场：治理不是事后追责，是事前让越权行为物理上不可能发生。