越管越亂：當自然語言規則成為 Agent 開發的惡性循環

在建構 AI Agent 的過程中，我們常直覺地透過撰寫越來越詳盡的自然語言規則來約束其行為，期望打造出更可靠、更安全的系統。然而，這種作法正將我們推向一個難以維護的困境，也就是「指令膨脹」（Instruction Bloat）。當規則文件變得臃腫不堪，系統不僅沒有變得更可控，反而更加脆弱、成本更高。本文將深入探討這個問題的根源，並說明為何我們需要跳脫純文字規則的框架，尋找更根本、更有效率的 Agent 控制機制，從「提示工程師」轉變為真正的「系統架構師」。

為什麼 Agent 的「紀律檔案」會越寫越長？

當我們開始建構一個 Agent 時，通常會從一個簡單的 system prompt 或是一個規則檔案開始。無論你將它命名為 CLAUDE.md、.cursorrules 或是 AGENTS.md，其本質都是一樣的：用自然語言寫下「該做什麼」與「不該做什麼」。一開始，這套方法非常有效。例如，我們可以輕易地加入一條規則：「禁止直接使用 sed -i 指令，所有檔案修改都必須透過 diff review。」

問題在於，隨著 Agent 在實際應用中犯下越來越多預期之外的錯誤，我們的規則文件也隨之快速膨脹。在我個人維運的一個私有專案中，這個用來約束 Agent 行為的「紀律檔案」，累積至今已超過 130KB。這相當於一本短篇小說的篇幅，裡面充滿了各種邊界條件、例外處理和行為禁令。這種天真的作法，最終只會通往一個充滿補丁、難以維護的死胡同。

為什麼單靠文本規則注定會失敗？

試圖用一本厚厚的規則手冊來完全控制一個大型語言模型，其根本性的錯誤在於我們誤解了模型的運作方式。LLM 並不像傳統程式那樣，對指令進行確定性的解析與執行；它是在一個高維的機率空間中尋找最有可能的回應。這導致了幾個難以克服的問題：

• 脆弱性與不確定性：自然語言充滿了模糊性。一條規則在某個情境下有效，換個情境或稍微改變問法，就可能完全失效。你禁止了 sed -i，Agent 下次可能會改用 perl 或 Python 來繞過。這種行為上的不一致性，讓系統變得極度脆弱。研究也指出，當上下文過長時，模型很容易忽略中間部分的指令，這種現象被稱為 「Lost in the Middle」。
• 維護的詛咒：當規則數量達到數百條時，沒有人能完全理解所有規則之間的交互作用。為了修復一個 bug 而新增的規則，很可能與既有規則產生衝突，從而引發新的、更隱蔽的錯誤。這形成了一個「打地鼠」式的惡性循環，開發者疲於奔命，系統的複雜度卻有增無減。
• 失控的成本與延遲：更長的 prompt 意味著更高的 API 成本與更慢的反應速度。當你的規則文件動輒數萬個 token，每一次與模型的互動都變得非常昂貴。即便我們擁有像 Claude 3 Opus 這樣支援 200K context window 的模型，濫用 context window 不僅不經濟，也無法從根本上解決問題。

我們不是在建構一個更聰明的系統，只是在為一個不完美的系統貼上無窮無盡的語言學補丁。

我們該如何跳脫指令膨脹的陷阱？

既然純粹依賴自然語言規則是一條走不通的路，那我們該轉向何方？答案是：將控制機制從「語言層」下沉到「系統層」。我們需要的是更結構化、更具確定性的方法，而不是更多的文字。這代表我們需要改變思維，從寫規則手冊，轉向設計一個健全的系統架構。

以下是幾個更具實踐意義的方向：

1. 結構化的環境約束 (Environmental Constraints)
與其在 prompt 中告訴 Agent「不要做某件事」，不如直接在它運行的沙箱環境中移除做這件事的能力。例如，與其告訴它不要用 sed -i，不如提供一個不包含 sed 指令，或是一個需要二次確認才能覆寫檔案的客製化 shell 環境。這是一種釜底抽薪的作法，遠比口頭警告來得有效。

2. 針對性的模型微調 (Fine-tuning)
對於重複出現的行為模式，與其不斷在 prompt 中加註提醒，不如透過微調（Fine-tuning）將這些期望的行為「寫入」模型本身。技術如 RLHF (Reinforcement Learning from Human Feedback) 或 DPO (Direct Preference Optimization) 雖然投入成本較高，但能更根本地塑造模型的行為傾向，效果遠比 prompt engineering 更加穩固。

3. 模組化與分層的 Agent 架構
與其讓一個萬能的 Agent 遵循一本萬言書，不如將複雜任務拆解，交給多個各司其職的專用 Agent。例如，可以有一個專門負責程式碼生成的 Agent、一個專門負責檔案操作的 Agent、以及一個負責最終審核的 Agent。每個 Agent 的 prompt 都會非常簡潔、目標明確，大幅降低了指令膨脹的風險。像是 CrewAI 這類的框架，就是為了促進這種協作式架構而設計的。

4. 程式化的輸出護欄 (Programmatic Guardrails)
當我們需要 Agent 產出特定格式或符合某些規範的回應時，與其用自然語言描述這些規範，不如在 Agent 的輸出端加上一個程式化的驗證層。例如，使用 Guardrails AI 或類似工具，強制 Agent 的輸出必須符合指定的 JSON schema 或 Pydantic 模型。驗證失敗就直接拒絕或要求重試，這比任何自然語言的格式要求都來得可靠。

總結來說，指令膨脹是 Agent 開發初期常見的陷阱。它看似簡單直覺，卻會隨著系統的成長而演變成一場災難。真正的解決之道，不在於寫出更完美的自然語言指令，而在於建立一個從根本上限制、引導 Agent 行為的系統。這需要我們從語言的藝術家，轉變為務實的系統工程師。

延伸閱讀

• テキストのルールだけでLLMエージェントを制御しようとすると「規律ファイルの肥大化」を招くので、もっと別の方法を探るべき (原始靈感來源)
• Constitutional AI: Harmlessness from AI Feedback (Anthropic 提出的另一種透過原則來引導模型的方法)

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。