Multi-Agent 記憶架構：讓你的 AI Agents 不再各自為政

問題：四個 Agent，四座孤島

我的日常工作流裡有四個 AI agent，各自住在不同的環境，各自維護自己的記憶：

Agent	位置	負責什麼	記憶怎麼存
Claude Code	MacBook（本地）	coding、專案管理	`~/.claude/projects/*/memory/MEMORY.md`
OpenClaw	VPS	daily briefing、聊天式更新、自動調研	MEMORY.md + daily logs
n8n	VPS	webhook automation、Slack 通知	workflow state
Notion	Cloud	結構化資料庫（專案、OKR、影片企劃）	databases

看起來很完整對吧？問題是——它們彼此不說話。

每天早上 OpenClaw 幫我整理好 briefing，但我打開 Claude Code 開始寫程式時，它完全不知道今天的重點是什麼。反過來也一樣，昨天 coding session 做完的進度，OpenClaw 隔天的 briefing 裡完全沒有。

這不是功能缺失的問題，是架構設計的問題。

真正的痛：Context Switching 的隱形成本

Context switching 最貴的部分，不是切換視窗，而是「腦中的狀態要重新載入」。

對人類來說是這樣，對 AI agent 也是。每次開一個新的 Claude Code session，我得花前五分鐘把「現在這個專案做到哪了」「今天最重要的事是什麼」「有哪些 blocker」重新餵一遍。有些是 MEMORY.md 已經記了的，但更多是散落在 OpenClaw 的對話紀錄、Notion 的專案頁面、甚至昨天 Slack 的某則通知裡。

我開始想：有沒有可能讓 agent 之間共享 context，像一個團隊共用一份會議紀錄？

研究：社群已經驗證的 Pattern

在動手設計之前，我花了時間研究社群裡其他人怎麼解決這個問題。幾個有趣的發現：

1. Markdown as Shared Memory

這是最多人驗證有效的方式，而且意外地簡單。不需要 vector DB、不需要 embedding pipeline，就是純文字 Markdown 檔案。為什麼？因為：

可讀：人和 AI 都能直接讀
可版控：丟進 git 就有完整歷史
Agent 原生支援：幾乎所有 AI agent 都能讀寫 Markdown

2. Per-Repo 文檔 + INDEX.md Master Registry

一個常見的結構是在每個 repo 底下維護 workspace/projects/ 目錄，每個專案一組文件，再用 INDEX.md 當全域索引。Agent 啟動時讀 INDEX 就知道有哪些活躍專案。

3. Hot / Warm / Cold 三層記憶

不是所有資訊都值得永久保存。一個實用的分層是：

Hot：MEMORY.md，最近 7 天的 context，每次 session 直接載入
Warm：每 6 小時自動 consolidate，把細節壓縮成摘要
Cold：Daily logs，永久保存但不主動載入，需要時再查

4. n8n Data Table 當記憶層

Agent One 案例裡，用 n8n 的 Data Table（就 5 欄）取代了整套 vector DB。欄位大概是 key、value、category、timestamp、ttl。夠用、好維護、不需要額外基礎設施。

5. AGENTS.md 跨工具標準

Linux Foundation 正在維護的 AGENTS.md 規範，嘗試定義一個讓不同 AI agent 都能讀的專案描述格式。雖然還在早期，但方向值得關注。

架構設計：混合式，各取所長

研究完之後，我決定不走「單一 hub」路線（例如全部丟 Notion 或全部丟某個 vector DB），而是讓每個工具做它最擅長的事：

┌─────────────────────────────────────────────────┐
│                   Notion                         │
│         結構化資料 Source of Truth                │
│        （專案、OKR、ideas、影片企劃）              │
└──────────────────────┬──────────────────────────┘
                       │ API sync
┌──────────────────────┼──────────────────────────┐
│                    n8n                           │
│              Event Bus / 調度層                   │
│       （觸發同步、通知、webhook 串接）              │
└────────┬─────────────┼────────────┬─────────────┘
         │             │            │
    ┌────▼────┐   ┌────▼────┐  ┌───▼──────┐
    │ OpenClaw │   │  Git    │  │  Slack   │
    │ 24/7     │   │  Repo   │  │  通知    │
    │ Agent    │◄──► Memory  │  └──────────┘
    │          │   │ Exchange │
    └────┬─────┘   │  Layer  │
         │         └────▲────┘
         │              │
         │         ┌────┴──────┐
         └────────►│Claude Code│
                   │ Deep Work │
                   │  Agent    │
                   └───────────┘

為什麼是混合式？ 因為每個工具的強項不同：

Notion 擅長結構化資料，拿來當 project 和 OKR 的 source of truth 最合適
Git repo 是天然的版控系統，當 memory exchange layer 不需要額外建設
n8n 本來就在做 event-driven automation，讓它當 message bus 順理成章
OpenClaw 是 24/7 跑著的 autonomous agent，適合做 briefing 和主動調研
Claude Code 是 deep work 時段的主力，專注在 coding 和架構設計

關鍵決策：那些「為什麼不」

架構設計最有價值的部分，往往不是「選了什麼」，而是「為什麼不選那個」。

為什麼 MVP 先做 OpenClaw → Claude Code 單向同步？

因為這是最痛的方向。每天早上的 context loading 是最頻繁、最浪費時間的瞬間。如果 Claude Code 一啟動就知道今天 briefing 的重點，光這個就能省下大量的「暖機時間」。

為什麼用 Git repo 而不是 Notion 作為 exchange layer？

兩個原因：

Agent 原生支援 git——Claude Code 可以直接讀 repo 裡的檔案，不需要任何 adapter
Notion API 有 rate limit 和延遲，git pull 是毫秒級的

為什麼不用 Mem0 或 vector DB？

Markdown 夠用。認真的，在這個場景下：

記憶內容是結構化文字（briefing、session summary），不是需要語意搜尋的長文
可讀性很重要——我要能直接打開檔案看內容、手動修正
不需要額外的基礎設施成本和維護負擔

Vector DB 在需要語意搜尋大量非結構化資料時很強，但對「四個 agent 共享每日 context」這個場景，是 overkill。

MVP：Daily Context Bridge

說到做到，MVP 就是一個 cron job：

OpenClaw cron (09:00)
    → 產出 daily-briefing.md
    → git commit + push
    → Claude Code session start 時自動讀取

就這樣。沒有 event bus、沒有 webhook、沒有 vector DB。一個 cron job、一次 git push、一份 Markdown。

內容格式大概長這樣：

# Daily Briefing — 2026-03-22

## 今日重點

- [ ] Multi-agent memory 架構文章完稿
- [ ] Mystery Shopper 前端 bug fix（P1）

## 昨日進度（from Claude Code session）

- statusline 色彩升級完成
- 新增 Mystery Shopper project memory

## Blockers

- VPS 儲存空間快滿了（剩 2GB）

## 值得注意

- n8n 有 3 個 workflow 昨天失敗（已自動重試成功）

Claude Code 啟動時讀到這份檔案，立刻知道今天該優先做什麼、昨天的 context 是什麼、有哪些地雷要注意。

Phase 路線圖

MVP 不是終點，但它是驗證方向的起點：

Phase	做什麼	解決什麼
Phase 1 (MVP)	OpenClaw → Claude 單向同步	早上的 context loading
Phase 2	Claude 收工 → session-summary.md → OpenClaw	雙向同步，隔天 briefing 能包含昨天 coding 進度
Phase 3	n8n 作為 message bus，event-driven 完整架構	即時同步，任何 agent 的狀態變化都能觸發通知

Phase 1 可能這周就能上線。Phase 3 可能永遠不需要做——如果 Phase 2 就解決了 95% 的問題的話。

反思

技術面

Markdown 比你想的更強大。 我們常常預設「AI 記憶」需要 vector DB、embedding、複雜的 retrieval pipeline。但在「多 agent context 共享」這個場景，純文字 Markdown 有三個殺手級優勢：可讀、可版控、agent 原生支援。不是說 vector DB 不好，是要選對場景。

三層記憶的時效性很重要。 不是所有資訊都值得放在 Hot layer。今天的 briefing 是 Hot，上周的 session summary 是 Warm（consolidate 後的摘要就好），上個月的 daily log 是 Cold（歸檔但不佔 context window）。記憶管理的核心不是「記住更多」，而是「知道什麼時候該忘」。

心態面

最難的不是設計完美架構，而是克制自己不要一開始就設計完美架構。

我承認，畫出那個 event-driven、n8n message bus、四個 agent 全連通的架構圖時，心裡是很興奮的。但冷靜下來想：真正最痛的問題是什麼？是每天早上開 Claude Code 時不知道今天的重點。一個 cron job + git push 就能解決 80% 的問題。

先做 80%，再決定剩下 20% 值不值得做。這不只適用於 multi-agent 架構，幾乎適用於所有系統設計。

給想做類似事情的人

如果你也有多個 AI agent 想串起來，我的建議是：

先盤點你的痛點——哪兩個 agent 之間的 context gap 最讓你痛？
從單向同步開始——不要一開始就想做 event-driven 雙向同步
Markdown first——除非你有明確的語意搜尋需求，否則不需要 vector DB
Git 是最好的 exchange layer——版控、diff、merge 都是免費的

Multi-agent 時代的基礎設施還在成形中。與其等一個完美的框架出現，不如從最簡單的方式開始，用 cron + git + Markdown 把你的 agents 連起來。

畢竟，一個能用的 MVP 永遠比一張漂亮的架構圖更有價值。