AI 工具會來來去去，真正該設計的是底下的資料庫
我花了一整天調查主流的 Agent 架構，以為會選出一套最佳方案。過程中我自己的三次提問，把命題從「選哪種架構」一路推到「怎麼設計一個不被 AI 工具綁住的個人知識系統」。這篇記錄這三次認知轉向怎麼發生、我歸納的四層架構長什麼樣、以及為什麼我認為真正該花時間的是最底下那一層。
我原本要選一套最好的 Agent 架構
這天的起點很單純：為了解決「每週寫一篇文章流程不順」，我想研究 2026 年主流的 Agent 架構該選哪一種。Claude 很快列出四種主流做法 — 扁平委派、Supervisor + Specialists、Pipeline、Knowledge Hub + Stateless Workers — 然後要進壓力測試。
我在這裡踩了第一次煞車。還沒討論完就要壓測，是要測什麼？而且我擔心的問題根本不是架構選型 — 我真正擔心的是資料庫越長越大，token 會爆、模型會錯亂。這個基礎問題沒解，挑哪種架構都一樣。
一問下去，整天的走向就變了。
三次被自己的提問推著走的轉向
第一次轉向：從「選架構」到「解知識膨脹」
我回頭要 Claude 搜「知識膨脹」的實際解法。這一搜就跑出 5 種疊加技術：Progressive Disclosure、Hot Cache、Sub-Agent 隔離、Handle Pattern、Lint 機制。根據搜到的實作案例，這 5 種疊加之後，token 消耗可以壓到原本的 1/15。
這時候我意識到第一件事：我原本要選的「架構」，在「知識膨脹怎麼管」這個更基礎的問題面前是次要的。先有資料管理的方法，架構才有發揮的空間。
第二次轉向：我做的事是不是 OpenClaw？
解完知識膨脹，Claude 模擬我「每週寫一篇文章」的流程，列出 8 個具體痛點、給出對應解法。看起來很完整。
我在這裡又煞車：「等等，我們現在做的事情，是不是就是在重建 OpenClaw？」
OpenClaw 是最近冒出來的一個設定 — 它想做的是跨 channel、always-on 的 AI 操作介面。我問完這個問題，Claude 承認前一輪方案是「為現在剛剛好」型 — 解了眼前的痛點，但沒考慮需求會自己長。比對之後確認 OpenClaw 跟我規劃的系統在方向上重疊 70%，但規模和目的不同。
到這裡，我還是可能選 OpenClaw、也可能選自己做。問題還沒真正被問對。
第三次轉向：工具是外殼，資料庫才是資產
Claude 給我 X / Y / Z 三個採用 OpenClaw 的情境選擇題。這時候我腦中有個句子浮出來，我把它打出去：
「我的問題是自媒體是長久的，不是 9 月停。資料庫痛點是整理損耗，不是跨裝置。OpenClaw 未來會死，我們要做好龍蝦跟資料庫之間的保護就好。只要管好資料庫，未來不管換哪一個模型或外殼都可以套上去。」
這句話打出去之後，問題被重新定義了。
命題不再是「用不用 OpenClaw」，也不是「選哪種架構」。命題是：怎麼設計一個資料庫，讓它在未來任何 AI 工具底下都可以無痛接上、整理成本最低。
這才是真正要解的問題。前兩輪都在解次要問題。
我歸納的四層架構
先聲明：這不是什麼業界既有名詞。這是我把這次搜尋到的東西、加上自己的思考，歸納出一個我看得懂的框架。但歸納的基礎 — MCP 作為跨工具協議、Markdown 作為開放資料格式、Obsidian 作為事實標準的呈現層 — 這些是 2026 年已經在發生的事，不是我編的。
由下而上四層：
- Layer 1 — 核心資料層：純 Markdown + 你的本地硬碟。開放格式、結構化、不綁任何工具。這層死了你才真的死。
- Layer 2 — 呈現與操作層：Obsidian 或類似工具。把 Markdown 變成可瀏覽、可連結、可編輯的介面。Obsidian 不是唯一解，但我觀察下來它在 2026 年接近事實標準。
- Layer 3 — 協議層：MCP（Model Context Protocol），Anthropic 推的開放協議。它讓 AI 工具可以直接讀寫 Layer 1 的資料，不需要手動複製貼上。這層是讓整個系統「工具無關」的鑰匙。
- Layer 4 — AI 工具層：Claude Code、Claude Desktop、ChatGPT、Gemini、OpenClaw，或公司給你的任何內部 AI。這層會來來去去、會死會變，沒關係。
三個設計目標對到這四層：
- 「資料庫是核心資產」 → Layer 1
- 「
值得多說一句的是 Layer 3。很多人聽到 MCP 會以為是進階功能，但在我看來它是解鎖整個系統「工具無關」的關鍵。沒有 MCP，「未來可以換模型」只是願景；有 MCP，今天就能跑。根據 Anthropic 和各家工具的公開資料，目前 MCP-compatible 的 client 涵蓋 Claude Desktop、Claude Code、ChatGPT Desktop、Cursor、Windsurf、Gemini CLI、OpenAI Codex、IntelliJ — 這份清單還在長。
我的觀點：真正要練的是看出「結構 vs 外殼」的能力
這次討論最讓我有感的，不是結論本身，是三次轉向都是我自己推出來的。
我原本以為這是一個「研究 → 選型 → 套用」的任務。後來發現它其實是一個「每次 AI 給我看起來完整的答案，我都要停下來問：這是不是真正的問題？」的任務。
三次轉向對應的是三個層級的重新定義：
- 第一次：從具體痛點退回到底層機制（知識膨脹不解，架構選型沒意義）
- 第二次：從工具評估退回到設計哲學（要不要用 OpenClaw vs 我到底在設計什麼）
- 第三次：從當下需求退回到長線判斷（9 月之前能用 vs 未來十年都能用）
我不是工程師。我靠 Claude Code 驅動所有執行。但 AI 工具再強，它會卡在一個地方 — 它不會主動幫你後退一步問「你現在在解的是真正的問題嗎？」這件事只能人做。
這也是我轉 AI PM 一直在想的事：工具會一直變、會一直被新的取代。在這個環境下，PM 的價值不在「我會用哪個工具」，而是在「我看得出哪些是結構、哪些是外殼」。結構值得花時間設計，外殼值得隨時換掉。
這篇文章本身就是這個判斷力的實證。等系統建完，我未來求職面試時能講的不會是「我學會用 MCP」或「我試了某個 Agent 架構」，而是：我在 AI 工具快速翻新的 2026 年，親手設計了一套讓工具來來去去都不痛的個人知識系統，並驗證這個設計哲學在自媒體、求職、未來換公司的場景下都成立。
如果你也想開始，第一步做什麼
四層架構聽起來複雜，其實可以拆成三步低門檻的行動。這邊給的是方向，不是完整教學。
第一步，把你的資料 Markdown 化、存在本地。不管你現在用 Notion 還是 Evernote，先挑一小塊（例如最近三個月的工作筆記）匯出成 Markdown、存在自己硬碟的一個資料夾。這一步就解決 Layer 1。格式開放、本地存、可搜尋，這些東西你不會失去。
第二步，試一次 MCP 連接。找一個你現在在用的 AI 工具（Claude Desktop、Claude Code 都可以），跟著官方文件跑一次「讓這個工具讀取你剛才建的 Markdown 資料夾」。跑通一次你就會知道 Layer 3 在做什麼。這一步不用碰程式碼，設定檔層級就能搞定。
第三步，養成「AI 討論結果寫回本地」的習慣。每次跟 AI 討論完有結論的事，複製貼回你的 Markdown 資料夾。這個習慣是整個系統能累積的前提 — 否則你每次討論都會消失在對話記錄裡。
三步做完你就有一個最小可運作版本。之後要換 Obsidian、要架更複雜的 MCP server、要評估 OpenClaw，都是 incremental 的事。不做這三步，買再多工具也沒用。
常見問題
我不是工程師，這套東西我做得起來嗎？
可以。我自己就不是工程師，系統的執行大部分是靠 Claude Code 幫我做的。關鍵不是寫程式能力，是你有沒有清楚定義自己要什麼。上面那三步門檻都是設定檔等級，不用寫程式。真正難的是維持「把結論寫回本地」的習慣，這跟技術無關。
我已經用 Notion / Evernote，要全部搬過去嗎？
不用。這不是二選一的事。你可以繼續用 Notion 做協作或視覺化筆記，但把「你真正在意、會反覆查、會被 AI 用的核心內容」Markdown 化。我自己的判斷標準是：如果這份資料未來十年你還會需要，就該放 Markdown。如果是三個月內的協作、之後會過期，留在 Notion 沒差。
MCP 跟 RAG 差在哪？
不同層的東西。RAG 是一種在 AI 回答前把相關資料找出來、塞進 context 的技術流程。MCP 是一種讓 AI 工具可以標準化地「連接到外部資料源」的協議 — 它可以用來實作 RAG，也可以用在很多其他場景（例如讓 AI 直接讀寫你的本地資料夾、操作你的日曆、查資料庫）。簡單講：MCP 是怎麼接、RAG 是接上之後要做什麼的其中一種。