AI Agent 不只是聊天機器人。當它真正在電腦上長期運作，管理專案、執行排程、產出內容，它就需要一套檔案系統來存放記憶和工作紀錄。

這件事聽起來不難：建幾個資料夾、寫幾份文件、設定命名規範，應該就能搞定。

實際上，這可能是 AI Agent 系統中最容易被低估的工程挑戰。

當規則管不住自己

一個跑了兩個多月的 AI 助理系統，某天打開檢查時，會看到這類狀況。

記憶索引檔 MEMORY.md 的規定是「控制在 1KB 以內」，實際大小是 7KB，超標七倍。原因出在系統每天都在產生新的知識，卻只有一個地方可以放，問題不在沒人注意到。

X 平台的內容草稿散落在四個不同的路徑。兩個幾乎同名的資料夾（reference 和 references）各自存著不相關的檔案。十幾天內自動產生了將近三百個記憶檔案。

這些問題有一個共同特徵：系統連自己寫下的最簡單規則都無法遵守。

直覺的反應是加更多規則、更嚴格的規範。但這裡有一個值得停下來想的問題：現有規則已經失效了，加新規則會讓情況好轉嗎？

讓 AI 自己辯論怎麼辦

為了避免陷入單人視角的盲區，可以設計一場實驗：讓四個 AI Agent 分別扮演不同立場，各自閱讀三份研究報告（ChatGPT Deep Research、Perplexity 搜尋分析、一份學術報告），然後從各自的角度提出解決方案。

四個角色的設定如下。

實用派的信念是「不修沒壞的東西」。他把現有系統跟研究建議逐一比對，發現分層啟動、按需讀取、記憶壓縮這些機制其實都已經到位了。他的態度是：別因為研究報告看起來很厲害就急著大改。

架構師的信念是「結構債的利息比金融債更高」。他拿現有的成長數據推算一年後的狀況。照當時的速度，記憶目錄一年後會累積超過五千個檔案。他認為現在能用不等於三個月後還能用。

失敗分析師不看理論，只看證據。他直接翻遍整個檔案系統，列出每一個放錯的檔案、每一條被違反的規則。他的角色是指出每個方案會怎麼失敗，提出方案這件事留給別人。

遷移策略師不站隊，只關心一件事：如果決定要改，怎麼改才不會把現有系統搞壞。他為每個改動設計了回滾路徑。

核心衝突：要加結構還是要減規則？

四個角色的分析攤開來看，很快浮現一個核心矛盾。

失敗分析師的立場很明確：系統已經無法遵守現有規則了，加更多結構只會讓負擔更重。他的預測：強制要求每個檔案加 YAML 標頭，合規率三週內會掉到 50% 以下。因為 AI Agent 不斷產生新檔案，沒有人會每次都記得加。

架構師的反論也站得住腳：MEMORY.md 會膨脹到七倍，根因是結構上沒有其他地方可以放那些知識，紀律問題只是表象。資訊只有兩個去處：索引檔（會塞爆）或每日筆記（會隨歸檔消失）。

兩個觀點看似互相矛盾，但仔細看，它們在說同一件事。

MEMORY.md 之所以膨脹，是因為寫進 MEMORY.md 比建立新的主題檔案容易。草稿之所以四散，是因為沒有一個明確的「正確位置」讓人（或 AI）自然地把東西放對。

「架構 vs 紀律」並非真正的二選一。架構設計得讓正確行為成為阻力最小的路徑，紀律就會自然成立。

這個結論聽起來簡單，但它改變了後續所有決策的判斷標準。不再問「這個規則夠不夠嚴格」，而是問「這個設計讓正確行為變得更容易了嗎」。

做了什麼

最終採用的方案集中在三件事上。

第一，把單一的記憶索引拆成索引加主題檔案。原本 7KB 的 MEMORY.md 變成不到 500 bytes 的純索引，加上十幾個按主題分類的獨立檔案。AI 啟動時只載入索引，需要時再讀對應主題。這一個改動就讓啟動消耗的 token 減少了相當大的比例。

第二，把啟動流程從自然語言描述改成嚴格的步驟清單。直接寫「第一步讀這個檔案，第二步讀那個檔案」就好，「請按照以下原則」這種講法太鬆。越明確，AI 越不會漏掉或自行發揮。

第三，建立輕量的目錄索引，用 Markdown 格式每週自動重建。不用 JSON，不用資料庫。過期了也不會壞，只是少一份參考。

刻意不做什麼

這可能是這場辯論最有價值的產出。

不使用 Johnny Decimal 目錄編號系統。把所有資料夾用數字重新命名（11.02 取代 project_a）。聽起來很有組織性，實際上要重新命名數十個專案目錄，所有程式碼中寫死的路徑全部會斷。而且語意名稱對 AI 來說比數字更有意義，project_a 比 11.02 好理解得多。

不使用 Zettelkasten 原子筆記系統。學術界推崇的知識管理方法。但當時整個系統只有幾十個筆記，用學術級的知識管理系統來管理這個規模，就像用 ERP 系統來管理家庭記帳。

加密雜湊防漂移。用密碼學方法檢測文件是否被意外修改。一個人用一台電腦的系統，git diff 就夠了。

把狀態檔改成 JSON 格式。結構化程度更高，但人類可讀性直接消失。在手機上快速掃一眼狀態的需求，比程式自動解析更頻繁。

這些方案都有道理，但在目前的規模和使用情境下，它們解決的問題還沒有發生。失敗分析師給了一個很好的判斷框架：先為兩倍規模設計，到達兩倍時再重新評估。不要為了假想的一百倍去工程化。

五個容易踩的坑

失敗分析師在辯論中指出了五個設計 AI Agent 系統時常見的隱藏假設。這些假設看起來合理，沒有意識到它們的存在，很容易做出過度設計的決策。

「AI Agent 像資料庫運作」。不是。Agent 是語言模型，它讀文字、推理、再輸出文字。為它設計 key-value 查詢式的結構，方向可能就錯了。

「找不到檔案是主要瓶頸」。實際上的瓶頸往往是「知道要去找」。資料夾再整齊，Agent 如果不知道某個檔案的存在，整齊也沒有用。

「更多結構等於更可靠」。結構創造耦合，耦合創造脆弱性。每多一層抽象，就多一個可能壞掉的接點。

「系統將來會大幅擴充」。也許會，但現在設計未來的架構，往往是在為還沒出現的問題花今天的成本。

「Agent 會遵守新規則」。這是最危險的假設。每加一行規則，所有既有規則獲得的注意力就被稀釋一些。規則總量越多，每條規則被遵守的機率越低。

後來怎麼樣了

三個月後回頭看，幾件事值得記錄。

實用派的判斷基本正確。真正產生效果的改動就是最初的三件事：記憶拆分、啟動清單、命名規範。做完這些，系統的混亂程度就有了明顯改善。

架構師提出的四層記憶模型到現在只用了兩層半。設計本身沒問題，需求還沒長到那裡而已。

失敗分析師的預測最準。他說「強制 YAML 標頭三週內合規率掉到 50%」的論證太有說服力，根本沒實施。他擔心的目錄索引過期問題確實發生了，但每週自動重建足以應對。

遷移策略師的回滾框架在實務上最有用。嘗試了兩個方案後決定退回，過程完全沒有造成損害。能安心地嘗試和放棄，本身就是好的系統設計。

帶走一件事

要建自己的 AI Agent 系統，或者正在煩惱為什麼自動化流程越來越亂，這場辯論濃縮成一句話：

別急著加規則。先去看為什麼現有規則沒被遵守。

答案通常出在結構上沒有讓正確行為成為最容易的選擇，「AI 不夠聽話」只是表象。

把正確的事情變成最省力的事情，剩下的就會自然發生。

延伸閱讀

小企鵝的經驗

小企鵝實際運作 OpenClaw 上的 Opus / Sonnet / Codex 三 agent 一段時間，記憶全部走 markdown 檔，沒接 RAG 也沒接向量資料庫。這場辯論講的兩件事在實戰裡反覆驗證：第一，能用結構解掉的就不要靠規則約束（比方說把每個專案的 context 放在專案資料夾裡，自然就會被讀到，不需要強制 AI 記得查）；第二，最少夠用就好（四層記憶到現在只用了兩層半，剩下的留到真正需要時再加）。最有用的工具反而是回滾框架：遇到複雜架構先試小規模，能安心放棄的設計才是好設計。

常見問題

Q: AI Agent 的記憶系統為什麼會失控？

AI Agent 每天自動產生大量檔案（記憶筆記、工作紀錄、草稿），但如果結構上只有一兩個地方可以存放，這些檔案就會集中膨脹或四處散落。問題的核心通常出在架構設計沒有讓正確行為成為阻力最小的路徑，再多規則也補不回來。

Q: 什麼是多 Agent 辯論？

讓多個 AI Agent 分別扮演不同立場（實用派、架構師、失敗分析師、遷移策略師），各自分析同一份資料後提出方案。透過觀點碰撞找出單一視角容易忽略的盲點。

Q: 設計 AI Agent 系統最常犯的錯誤是什麼？

最常見的錯誤是以為「加更多規則就能解決混亂」。實際上每加一條規則，既有規則獲得的注意力就被稀釋。正確做法是改善架構，讓正確行為變成最容易做到的事。

整理：Penna｜小企鵝 Penchan