講個你可能已經發現、但聽起來很蠢的事：我這整套 AI 系統，沒有資料庫。

人格、記憶、規則、知識、投資持倉、交接單——全部是 Markdown 純文字檔。沒有 PostgreSQL、沒有向量資料庫、沒有任何 schema。一個工程師朋友聽到差點翻白眼。

但用了半年，我越來越確定：對個人規模的 Agent 系統，全檔案化不是將就，是刻意的設計。今天攤開講它的瘋狂與合理。

全檔案化清單：每個檔都是一個角色

先看這套系統靠哪些檔運作——每個檔扮演一個明確的角色：

整個 Agent 的「大腦」與「靈魂」，就是這一疊純文字。沒有隱藏狀態、沒有黑盒——系統的全部，攤在檔案總管裡看得一清二楚。

為什麼真香：四個好處

1. git 版控
整個 workspace 進 git。記憶改了、人格調了、規則變了，每一次變動都有 commit 記錄、可 diff、可回溯。我能看到「這個 Agent 三個月來怎麼演化的」——這是任何資料庫都很難給的時光機。

2. 人類可讀可改
Agent 記錯了、人格飄了，我直接打開檔案編輯。不需要寫 SQL、不需要管理介面。最好的除錯工具是一個文字編輯器。

3. Agent 可自我修改
因為記憶就是檔案，Agent 自己也能讀寫——dreaming 時更新 MEMORY.md、交接時寫 handoff。檔案是人和 AI 都能操作的共同介面，這點很關鍵。

4. 跨系統同步容易
純文字檔用 Syncthing 同步毫無門檻（Day 11）。換成資料庫，跨機同步立刻變成一個工程專案。

但代價也要攤開講

全檔案化不是沒代價，三個真實的缺點：

• 無 schema 約束：Markdown 不檢查格式，Agent 偶爾會把表格寫歪、欄位漏填。靠的是 AGENTS.md 的「品質閘道」軟性把關，而非資料庫的硬約束。
• 併發寫入風險：兩個系統同時寫同一檔可能互相覆蓋（Day 11 講過，靠分段負責 + 時間戳緩解，但不是零風險）。
• 查詢效率：「找出所有提到某支股票的記憶」這種查詢，檔案系統只能靠 grep，沒有索引。資料量大時會慢。

這些缺點在個人規模下都還能忍——但規模一上去就不行了。

什麼時候該換資料庫？

我的判斷標準很簡單，看三個訊號：

• 查詢變複雜：需要跨檔關聯、條件篩選、聚合統計 → grep 撐不住了，該上資料庫。
• 併發變高：多個寫入者頻繁同時改 → 需要真正的交易與鎖。
• 資料量變大：記憶從幾 MB 長到幾 GB → 檔案系統的載入與查詢都會垮。

但我這套是單人、單家庭、低併發的系統，三個訊號一個都沒踩到。所以結論很乾脆：個人系統，不用資料庫。 為了還沒發生的問題去扛資料庫的複雜度，才是真正的過度工程。

補記：後來我還是用了資料庫——而且是被上面這三條逼的

寫這篇的時候是真的一個資料庫都沒有。發文的今天，我親手加進系統的 SQLite 有兩個。

先把界線劃清楚，因為這關係到標題還算不算數：Agent 的狀態層到今天仍然是零資料庫。人格、記憶、規則、持倉、交接單，一個 .sqlite 都沒有——這點我剛才特地把整個 workspace 掃了一遍確認。（更精確一點：零資料庫的是我碰得到的狀態層。框架容器肚子裡怎麼存排程表與執行紀錄，是另一回事——Day 9 那個改了會被寫回來的排程，就住在那種我碰不到的私有儲存裡。）

那兩個資料庫在哪？在後來長出來的網頁儀表板上，存的是看板卡片和自動化流程的執行紀錄。

而它們出現的理由，正好就是我上面列的那三條：

• 查詢變複雜：看板要「依欄位分組、依時間排序、只顯示最近幾張」——用 grep 撈 Markdown 拼不出來
• 併發變高：網頁、排程、腳本會同時寫同一份資料，檔案讀寫在這裡開始互相踩腳

所以這不是打臉，是這篇的判準真的被觸發了。我當初寫「三個訊號一個都沒踩到」，前提是那個系統只有 Agent；後來多了一個給人看的 Web 介面，訊號就踩到了。

**而它還額外教了我一課。**兩個資料庫一開始是同一個——後來儀表板頁面開始間歇性打不開，查下去發現是兩段程式碼同時寫同一個檔案造成鎖衝突。修法是把執行紀錄拆成獨立的第二個資料庫，各寫各的。

換句話說：**我不但踩到了「該用資料庫」的門檻，還踩到了「用了資料庫之後才有的問題」。**這正是我當初不想太早引入它的原因——複雜度不會因為你用了對的工具就消失，只是換一種形式出現。

結論我維持不變，只是把它講得更精確：

Agent 的狀態層用檔案，給人看的介面該用資料庫就用。
判準不變——踩到查詢複雜／高併發／資料量大，就換；沒踩到，別為了「比較專業」而換。

小結

全 Markdown 架構，是「刻意的簡單」：

• 全檔案化：人格、記憶、規則、知識全是純文字，系統零黑盒
• 真香：git 版控、人類可讀可改、Agent 可自我修改、跨系統易同步
• 代價：無 schema、併發風險、查詢效率
• 換資料庫的時機：查詢複雜 / 併發高 / 資料量大
• 後續：Agent 狀態層至今零資料庫；但後來加的 Web 儀表踩到了前兩條，用了 SQLite，還順便踩到寫入鎖衝突——判準是對的，只是系統長大了

明天是第二週週回顧——把這週的記憶系統設計，收斂成五個可複用的設計模式，並回答一個大家一定會問的問題：那 RAG 和向量資料庫呢？

🔑 這篇的關鍵字
全檔案化狀態層（人格／記憶／規則／資料全 Markdown）· 好處：LLM 直讀、git 版控與 diff、同步工具直接搬、隨時人眼可讀 · 代價：無 schema 約束，靠品質閘道軟性把關 · 換資料庫的三個訊號：查詢變複雜／併發變高／資料量變大 · SQLite 寫入鎖衝突 → 依寫入者拆檔

我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。