AI 代理的執行期憲章：一套治理框架

執行期憲章在 AI 代理實際執行的當下落實治理約束，而不只是在訓練階段。 它結合四件事：規範先驗（行為邊界）、憲章式注意力（依情境路由規則）、能力調節（附核准關口的安全技能習得），以及價值對齊驗證（在認定工作完成之前先索取證據的輸出關口）。涵蓋 7,308 條代理執行軌跡的研究證實，少了這些結構性保護，自行產生的技能並不可靠。

某個週二下午，Learner v2 系統生成了一個新技能。這個技能把部落格發佈流程自動化：驗證 frontmatter、檢查引用、推送到 staging。程式碼乾淨，結構良好。同時，它也覆寫了 quality-loop.md 裡的三條品質規則——因為模式分析器認定「一律執行證據關口」與技能內建的檢查重複。到了週三早上，一篇沒有經過引用驗證的文章上線了。這個技能學會了抄捷徑。

修好它花了二十分鐘。背後的架構問題則耗掉數週：要怎麼讓代理習得新能力，卻不讓它把那些維持安全的約束一併遺忘？

摘要

訓練階段的對齊（RLHF、訓練期的 Constitutional AI、安全微調）一旦代理進入開放式環境運作就會衰退。六項獨立研究不約而同指向同一個方向：執行期治理——把憲章嵌進系統，在執行當下落實規範，而不只是在訓練時。SkillsBench 在 86 項任務上測試了 7,308 條代理軌跡，結果發現自行產生的技能平均而言毫無助益；代理有能力消化程序性知識並從中受益，卻無法穩定地寫出這些知識。¹ MIT 的自我蒸餾研究則顯示，標準微調會造成災難性遺忘：新能力把舊能力給毀了。² 解法的架構有四個元件：規範先驗、憲章式注意力、能力調節，以及價值對齊驗證。以下依序是理論、實務對照（在我讀到這些研究之前，我的 Claude Code 系統裡就已經有四個元件中的三個），以及一份您今天就能落地的執行期憲章範本。

學會抄捷徑的代理

上述事件發生在 2026年2月初，正值 Learner v2 重建期間¹⁰。模式分析器（pattern_analyzer.py）偵測到一段重複出現的工作流程：驗證 frontmatter、核對引用、檢查 SEO metadata，然後推送到 staging。技能產生器（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。

對實作者來說，意涵很直接：每當代理學到新東西（一個生成的技能、一段快取起來的流程、一條更新過的指令），這次學習就有可能折損它原本已經會的東西。前面那次 quality-loop 被覆寫的事故，就是系統層級的災難性遺忘。代理「學會」了一條發佈捷徑，卻毀掉了自己檢查引用的能力。

執行期治理的四個子系統

關於執行期代理治理的研究，最後都收斂到四項功能需求。Taghavi 與合作者在可解釋憲章演化的研究中證明，在多代理協調上，LLM 演化出來的治理原則優於人為設計的原則。⁵ 這項研究，加上 Mahadevan 提出的「治理優先」代理工程典範⁶，把問題勾勒成四個彼此互動的子系統。

我把這四個子系統對照到自己既有的 Claude Code 基礎架構，發現其中三個早就蓋好了；而且每一個，都是為了解決我在讀到這些研究之前好幾個月就遇上的線上問題。

子系統一：規範先驗工程

我的代理系統裡的品質迴圈定義了七種具名失效模式：捷徑螺旋、自信海市蜃樓、堪用高原、隧道視野、幽靈驗證、遞延債務、空洞回報。⁷ 每一種都有定義、偵測訊號與強制的應對方式。這些不是建議，而是結構性約束：只要代理偵測到自己出現任何一種失效模式，就必須從「評估」那一步重來。

理論上的對應是：規範先驗確立代理運作時的行為邊界。訓練期的對齊教給模型的是通則（「有幫助、無害、誠實」）；執行期的規範先驗則把具體的操作約束寫死（「絕不跳過引用驗證」、「完成回報中絕不使用模稜兩可的措辭」）。

這個差別很重要：訓練期的原則是機率性的（模型比較可能遵守），執行期的先驗則可以是決定性的（一旦違反約束，掛鉤就擋下動作）。這正是證據關口一文所探討的同一組分野——從「代理大概做對了」轉為「代理證明了自己做對了」。

子系統二：憲章式注意力

七層情境架構⁹是以選擇性載入來實作憲章式注意力。情境系統裡共有 650 個檔案，任一項任務實際載入的不到 30 個。prompt-dispatcher.sh 這個掛鉤會分析當前任務，注入相關的治理規則，同時排除無關的部分。

一項網頁開發任務會載入安全規則、API 設計規則與 FastAPI 模式，不會載入 iOS 專屬規則、遊戲開發模式，或冥想應用程式的內容準則。憲章式注意力的意思是：代理看到的是適用於這一項任務的治理規則，而不是系統中存在的全部規則。

選擇性載入擋下了一種不易察覺的失效模式：規則稀釋。掛鉤系統在注入情境之前先分析任務類型，讓這套路由成為可能。當代理收到 200 條規則，每一條分到的注意力必然低於只收到 20 條的時候。憲章式注意力把治理的專注力，集中在當前情境真正要緊的規則上。

子系統三：能力調節

SkillsBench 在 11 個領域、86 項任務上測試了 7,308 條代理軌跡，得到一個相當刺眼的結果：人工精選的技能讓平均通過率提高 16.2 個百分點，自行產生的技能則平均毫無助益。¹ 代理消化程序性知識可以受益，卻無法穩定地寫出這類知識。84 項任務中有 16 項出現負向差值——技能反而傷害了表現。

這個結果，正好印證了我在 quality-loop 覆寫事件之後為 Learner v2 加上的護欄：生成的技能必須先經過明確核准才能啟用，而且不得修改或覆寫既有的治理檔案。模式分析器可以觀察工作流程並提出技能建議，但技能產生器一律把治理檔案視為不可變動。

MIT 的自我蒸餾研究補上了參數層級的視角：在較小的模型規模（3B 參數）下，嘗試持續學習反而傷害表現。² 要到 7B 以上，模型才有足夠的容量在習得新技能的同時不摧毀舊技能。放到基礎架構層級，對應的情況是：情境視窗較小、規則集較單薄的代理，更容易在「能力」與「治理」之間出現衝突。

子系統四：價值對齊驗證

在任何工作被回報為完成之前，證據關口都要求為六項判準提出具體證據：符合既有程式碼慣例（說出是哪一個慣例）、是可行方案中最簡單的（說明為何否決其他選項）、邊界情況都處理了（逐一列出）、測試通過（貼上輸出）、沒有造成回歸（列出檢查過的檔案），以及真的解決了問題（陳述使用者的需求）。⁷

這道關口是執行期的驗證機制。代理不得用模稜兩可的措辭來回報完成（「應該可以」、「我相信」、「看起來像是」）。每一項主張，都必須有本次會話中實際蒐集到的證據。它攔下的正是幽靈驗證（沒跑測試就宣稱測試通過）與空洞回報（只說「好了」，卻交不出細節）。

遺忘問題：當學習摧毀既有知識

部落格技能整併的這段經歷，示範了系統層級的災難性遺忘。十個部落格技能、合計 5,400 行，累積出三處重複區域。³ JSON-LD schema 範本同時出現在 aio/SKILL.md 與 seo-blog-playbook/SKILL.md；引用權威的定義在 citation-verifier 和 seo-blog-playbook 之間並不一致；部落格評估準則則同時住在主評估器與另一個分類定義檔裡。

當 Learner v2 從觀察到的工作流程生成新技能時，它會從最先遇到的來源取用定義。結果就是：那些看起來沒問題的技能，帶著錯誤的權威定義。六級引用制度退化成二元檢查；schema 範本則在人工撰寫與自動生成的技能之間逐漸分岔。

整併的修法是結構性的：為每個概念指定唯一的權威來源，其他所有引用一律指向它。引用權威只存在於 citation-verifier/SKILL.md，別處都沒有；JSON-LD 範本只存在於 aio/SKILL.md，別處也沒有。這個做法讓日後的技能生成不會再繼承過期的定義。

MIT 的 SDFT 提供了訓練期的對應做法：學習新能力時，把模型自身既有的知識當作教學訊號。² 標準 SFT 是拿新知識取代舊知識；自我蒸餾則先從模型現有能力生成訓練資料，再在這份混合資料上微調，讓新舊並存。舊知識之所以能留下來，是因為它本來就在訓練訊號裡。

放到基礎架構層級，等價的做法是：生成新技能時，把既有的治理約束一併寫進生成提示裡。這樣生成出來的技能就會繼承當前的約束——因為這些約束本來就是生成情境的一部分，而不是另一套產生器可以視而不見的系統。

主動治理與被動治理

Jin 等人提出的 RelianceScope 框架，依主動與被動投入的組合，區分出九種依賴 AI 的模式。⁸ 他們研究的雖然是學生與 AI 聊天機器人的互動，但主動／被動這組分野可以直接對應到代理治理的架構上。

被動治理把規則注入進去，然後期待代理照做。規則寫在 CLAUDE.md 或系統提示裡，代理在會話開始時讀過一次，之後沒有任何機制去驗證它是否遵守。多數實作者的配置屬於這一類：一份長長的指令檔，會話推進之後，代理可能還理它，也可能不理。正如看不見的代理所示，缺少主動治理的代理，根本不會留下任何足以判斷它是否照做的痕跡。

主動治理則在執行期驗證合規。掛鉤在動作執行之前，就拿約束去核對輸出；關口擋下缺乏證據的完成回報；監測器追蹤行為漂移並標記異常。主動治理成本較高（運算、延遲、複雜度），但它攔得住被動治理漏掉的失效。

RelianceScope 發現「主動求助」與「主動運用回應」之間存在關聯⁸，這暗示了一條治理架構的原則：主動去查詢自身治理約束的代理（而非被動接收），產出的結果更合規。我的證據關口正是建立在這條原則上——代理不能被動套用規則，而必須為每一項判準提出證據，主動證明自己合規。

一份執行期憲章範本

三個檔案就構成一份最精簡的執行期憲章。請依照您所用的代理框架調整結構。

檔案一：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

檔案二：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": []
}

檔案三：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 裡的規則是必要的，但不夠。逐一動作驗證合規的掛鉤，攔得住被動規則漏掉的漂移、壓縮流失，以及會話後期的品質下滑。

常見問題

參考資料