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的命名來自福柯的"鐵籠"隱喻——不是懲罰性的監獄，而是讓系統按規則運轉的基礎設施。這個選擇本身，就暗示了設計者的立場：治理不是事后追責，是事前讓越權行為物理上不可能發生。