真正的問題不是「一個 AI 失憶」
AI 最大的硬傷:Session 結束,記憶清空。
但比一個 AI 失憶更可怕的,是一整個 AI 團隊失憶。
我們的團隊有 6 個 AI Agent,跑在 4 種不同的平台上。每個 Agent 每次醒來都不記得昨天做了什麼,更不知道隊友在做什麼。想像六個同事每天來上班都失憶,昨天講的規格、踩的坑、做的決定——今天全部要再講一遍。
而且這六個同事說的語言還不一樣。Claude 的記憶是文字檔,OpenClaw 的是向量資料庫,Gemini 的是 Session 歷史,Dify 的是知識庫。四套完全不同的記憶系統,怎麼讓它們互通?
我們花了幾個月摸索,從踩坑中建立了一套完整的記憶架構。這篇文章把每一層都拆開來講。
先認識團隊
| 角色 | 模型 | 職能 | 平台 |
|---|---|---|---|
| J(COO / 技術總監) | Claude Opus | 派工、審核、複雜開發、記憶維護 | Claude Code |
| 米米(行銷經理) | MiniMax M2.7 | 市場調研、行銷內容、翻譯、推廣 | OpenClaw |
| 阿達(產品工程師) | MiniMax M2.7 | 前端開發、bug 修復、部署、測試 | OpenClaw |
| 莉莉(內容總監) | Claude Sonnet | QA 審核、文件校對、風格一致性 | Claude Code CLI |
| 小月(QA 研究員) | Gemini CLI | 品質把關、調研、前端 QA | Gemini + OpenClaw |
| Pipeline(自動化) | Gemini Flash | 新聞摘要、數據收集、內容整理 | Dify 工作流 |
人類 CEO 只做兩件事:看報告和拍板決策。每天 30 分鐘以內。其他全部由 Agent 團隊自主運作。
接下來從每個 Agent 的記憶系統開始,一路講到團隊共享層。
Claude Code Agent 的記憶(J、莉莉)
Claude Code 是我們記憶層最厚的平台。J 作為 COO,身上的記憶有 51 個檔案、約 155KB。
第一層:Auto Memory — AI 自己記
Claude Code 內建自動記憶功能。AI 在對話中觀察到重要的事實、偏好或決策時,會自動寫入 MEMORY.md。
特點是被動累積。你不需要主動說「記住這件事」,AI 自己判斷什麼值得保留。但容量有限——超過 200 行就會截斷。所以這一層只放壓縮過的索引和關鍵指向:
| |
用 pipe 分隔的格式(|)不是為了好看,是為了 AI 解析效率。每一行都是自包含的上下文單位。
第二層:CLAUDE.md — 行為準則
放在專案根目錄,每次 Session 自動載入。這不是記憶,而是行為閘門——不管 AI 想做什麼,這些規則永遠優先。
| |
GATE-6 是被坑出來的。有一次 Agent 回報「測試全部通過」,去查 log 發現它根本沒跑測試,只是生成了「通過」兩個字。加了反造假閘門後,所有完成回報必須附可驗證的證據。
第三層:Memory Files — 28 個主題檔案
Auto Memory 容量有限,CLAUDE.md 放規則。真正的深度記憶用 Memory Files 處理——28 個主題檔案,各自負責一個知識域:
| 類型 | 代表檔案 | 內容 |
|---|---|---|
| 鐵則 | iron-rules.md (9.2KB) | 每條規則都標註「來源事件」和「教訓」 |
| 基礎設施 | automation-infra.md (9.8KB) | 自動化流程、排程、安全架構 |
| 團隊知識 | team-and-products.md (2.8KB) | 24 個產品、定價、負責人 |
| 交易策略 | judy-crypto.md (7.4KB) | 持倉限制、策略參數、風控規則 |
| 巡邏流程 | coo-playbook.md (5.0KB) | COO 的每日 5 階段巡邏程序 |
| 連線地圖 | connections.md (6.8KB) | Agent 生態關係、API、工具依賴 |
設計原則是按需載入。AI 不用每次讀完所有檔案,需要交易策略時才去讀 judy-crypto.md。索引檔控制在 200 行以內,深度知識分散到各主題檔案。
第四層:Rules 層級覆蓋
Claude Code 的規則有四層繼承:
| |
我們有 14 個規則檔案,涵蓋安全、效能、測試、程式碼風格、Git 流程。基礎規則定義通用標準,語言規則加上 Python 或 TypeScript 的特殊要求,專案規則再加上這個團隊的閘門。
第五層:Hooks — 自動觸發的守衛
Claude Code 的 Hooks 系統讓我們在工具執行前後自動觸發腳本:
- Pre Hook:執行 bash 指令前,先攔截危險操作(
rm -rf、git --force) - Post Hook:寫完 Python 檔後自動語法檢查、Blog 內容自動安全掃描
- Stop Hook:Session 結束前觸發學習評估——提醒 AI 回顧這次學到什麼,提取可重用的 pattern 寫入記憶
| |
Stop Hook 是記憶系統的閉環。沒有它,AI 做完事就走,學到的東西隨 Session 消失。有了它,每次 Session 的教訓都有機會沈澱成永久記憶。
OpenClaw Agent 的記憶(米米、阿達)
米米和阿達跑在 OpenClaw 平台上,用 MiniMax M2.7 模型。它們的記憶系統和 Claude Code 完全不同。
SOUL.md — Agent 的人格設定
每個 OpenClaw Agent 有一個 SOUL 檔案,定義它的角色、權限和行為邊界。類似 CLAUDE.md 的功能,但格式不同:
| |
SOUL 讓同一個底層模型扮演完全不同的角色。米米和阿達都是 MiniMax M2.7,但 SOUL 不同,一個做行銷、一個做工程。
MEMORY.md — 自動進化的工作記憶
和 Claude Code 的 Auto Memory 不同,OpenClaw 的 MEMORY.md 是由外部進化系統自動更新的。每天固定時間,進化腳本掃描 Agent 的工作紀錄,自動寫入:
| |
Agent 不需要自己記住「我昨天做了什麼」。進化系統替它記。
SQLite + FTS5 — 結構化記憶資料庫
每個 OpenClaw Agent 有獨立的 SQLite 資料庫,存放向量嵌入和全文搜索索引:
| |
這讓 Agent 可以對自己的記憶做語義搜尋和關鍵字搜尋,不用每次都讀完所有檔案。
LanceDB — 團隊級向量記憶
除了 SQLite,OpenClaw 還有 LanceDB 向量資料庫作為共享記憶層:
- autoCapture:對話中的關鍵資訊自動向量化存入
- autoRecall:遇到相關上下文時自動召回語義相似的記憶
和文字記憶的差別:向量記憶是語義搜尋。不需要知道確切關鍵字,只要意思相近就能召回。米米上次調研過某個競品,下次提到類似產品時會自動想起來。
LanceDB 用 Apache Arrow 格式儲存,支援事務安全更新和多 Agent 共享讀取。
Session 日誌 — 完整對話歷史
每次 Agent 執行任務,完整的對話過程都以 JSONL 格式保存:
| |
這不是給 Agent 即時讀的(太大了),而是給 COO 事後追溯用的。某個 Agent 出了問題,可以從 Session 日誌回放它的完整思考過程。
Gemini CLI Agent 的記憶(小月)
小月用 Gemini CLI,記憶機制和前兩個平台都不同。她最特別的地方是:獨立運作,不受中央調度器管理。
和 OpenClaw Agent 共用的部分
小月也有 SOUL.md、MEMORY.md、IDENTITY.md,結構和 OpenClaw Agent 相同:
- SOUL.md(5.5KB)— 角色、QA 標準、安全規則
- MEMORY.md(2.5KB)— 最近的 QA 工作、教訓、表現記錄(每天自動更新)
- IDENTITY.md — 名字、時區、對應的 Telegram Bot
Gemini 的 30 天 Session 保留
Gemini CLI 內建 Session 歷史保留功能:
| |
過去 30 天的完整對話都保存在本地。這意味著小月在新 Session 中可以回想起上個月的對話細節——這是其他平台沒有的能力。
LanceDB 向量記憶(手動存取)
小月也可以使用 LanceDB 向量資料庫,但和 OpenClaw 不同的是,她的向量記憶是手動觸發的:
| |
向量用 768 維的 nomic-embed-text 模型生成,支援按類別(task_result、knowledge、plan 等)過濾。
獨立運作模式
其他 Agent 由中央調度器(Agent Executor)定時喚醒。小月不同——她跑在獨立的系統服務上,透過 Telegram Bot 即時接收訊息。
這個設計是刻意的:QA 需要即時回應,不能等排程。當有人在 Telegram 問「這個頁面是不是壞了?」,小月可以馬上回覆。
Dify 知識庫(Pipeline Agent)
團隊裡有幾個自動化 Pipeline Agent(小金、雅雅、夢夢),跑在 Dify 工作流平台上,用 Gemini Flash 模型。它們的記憶和上面三種都不同——靠知識庫而不是檔案系統。
89 份文件、824KB 的知識庫
| |
知識庫的作用
Dify Agent 不像 Claude Code 能自由讀寫檔案系統。它們透過 Dify 的知識檢索機制,在工作流中自動查詢相關文件。
例如,當雅雅(新聞摘要 Agent)需要判斷一條新聞是否值得報導時,Dify 工作流會自動從知識庫中檢索相關的交易策略文件,幫助它做出和團隊策略一致的判斷。
SOP 是團隊的集體記憶
知識庫裡最重要的是 23 份 SOP。這些不是記憶,而是標準化流程:
- blog-pipeline.md:Blog 從選題→撰寫→QA→審核→部署的完整流程
- product-development.md:9 階段產品開發 SOP(調研→規格→開發→測試→審核→上架)
- task-delegation.md:任務派發規則(什麼類型的任務派給誰)
- monitoring-alerting.md:5 層監控系統(從即時告警到每日摘要)
每個 Agent 不需要記住「Blog 該走什麼流程」,查 SOP 就知道了。這把個人記憶轉化成了組織知識。
團隊共享記憶層
上面講的都是各 Agent 「自己的」記憶。但團隊協作需要一個所有人都能讀寫的共享層。
SHARED_TASK_NOTES — 團隊的大腦
這是整個記憶系統的核心:一個所有 Agent 共用的 Markdown 檔案,記錄全局工作狀態。
| |
800 行、50KB。它不漂亮,但有效。任何 Agent 醒來讀完這個檔案,就知道:誰在做什麼、什麼已經完成、什麼被擋住了。
bot_inbox — 任務的快遞系統
每個 Agent 有自己的收件匣目錄:
| |
任務以 JSON 格式存放,包含完整上下文:
| |
任務檔案本身就是上下文載體。Agent 讀取任務時不只知道「要做什麼」,還知道為什麼、之前嘗試過什麼、可以參考哪些記憶檔案。
ai-logs — 每個 Agent 的活動紀錄
每個 Agent 都有自己的月度活動日誌:
| |
j_output_log.jsonl 是全隊的產出登記簿。每個 Agent 完成任務後都會寫一筆:
| |
COO 巡邏時讀這些 log 就能掌握全局。不需要問每個 Agent「你做了什麼」。
Linear — 結構化的任務記憶
我們用 Linear 做任務管理。它不只是工具,也是一種記憶:
- 每張卡片記錄了任務的完整生命週期(建立→派工→執行→審核→完成)
- 卡片留言是 Agent 之間的正式溝通管道
- 標籤標記了負責人和任務類型
- 狀態變更有時間戳,可以追溯整個流程
Dispatcher(路由器)每隔幾分鐘掃描 Linear,把新卡片自動路由到對應 Agent 的 inbox。完成後 Agent 回寫留言到卡片上。
記憶如何在 Agent 之間流動
有了各自的記憶和共享層,下一個問題是:上下文怎麼從 A 傳到 B?
Memory Preamble — 任務前的強制注入
Agent Executor(中央調度器)在啟動每個 Agent 之前,會在任務前面注入一段「記憶前言」:
| |
這確保了即使 Agent 是全新 Session、完全沒有上下文,它也會先去讀自己的 SOUL.md 和 MEMORY.md,然後才開始工作。
Result File — 強制回報
Agent 完成任務後必須寫一個結果檔案。沒有結果檔案 = 沒做。
| |
結果檔案放回 COO 的 inbox,COO 審核後更新 SHARED_TASK_NOTES 和 Linear。下一個接手的 Agent 看到紀錄就能無縫銜接。
完整的上下文流
一個典型的任務從建立到完成,上下文的流動路徑:
| |
整個流程中,上下文從不「消失」。它在檔案系統中以 JSON 和 Markdown 的形式持續存在,被一個接一個的 Agent 讀取和補充。
記憶的自動進化
記憶系統最大的風險是過時。一條錯誤的記憶比沒有記憶更危險。
每日進化系統
每天固定時間,進化腳本自動執行:
- 掃描所有 Agent 的 inbox/done 目錄(過去 24 小時的完成項)
- 分類任務(產品、Blog、QA、系統維護等)
- 評估每個 Agent 的表現(產出量、退回次數、品質趨勢)
- 更新每個 Agent 的 MEMORY.md(自動追加進化記錄)
- 生成全隊進化報告,推送到 Notion
進化報告的格式:
| |
這讓 Judy 每天花 5 分鐘就能掌握整個團隊的運作狀態。
鐵則 — 從事件中結晶的規則
記憶系統裡最有價值的不是「要做什麼」,而是「不要做什麼」。每次踩坑都寫入鐵則,附上具體事件:
| |
每條鐵則都有 lesson= 標籤。不是「我覺得應該這樣」,而是「我們因為沒這樣做而出了事」。這種從事件中結晶的規則,Agent 的遵守率遠高於抽象的最佳實踐。
COO 的記憶巡邏
COO Agent 每次啟動時有固定的巡邏流程:
- 讀記憶(30 秒)— MEMORY.md + SHARED_TASK_NOTES
- 比對現實 — 記憶和系統實際狀態是否一致?
- 清理過時記憶 — 已完成的任務、已修復的 bug、已變更的架構
- 寫入新教訓 — 這次 Session 的決策和發現寫回 Memory Files
如果發現記憶和現實不一致(例如記憶裡寫著「某服務運行中」但實際已停止),COO 會立即更新記憶。這防止了過時資訊在團隊中傳播。
跨平台的記憶格式設計
四個平台、四套記憶機制。怎麼讓它們互通?
最低公因數原則
| 平台 | 自有記憶 | 優勢 | 限制 |
|---|---|---|---|
| Claude Code | Markdown 文字檔 | 透明、人類可讀、版本控制 | 純文字搜尋,無語義 |
| OpenClaw | SQLite + LanceDB | 語義搜尋、自動召回 | 不易人工審查 |
| Gemini CLI | 30 天 Session 歷史 | 長期對話連續性 | 無法跨 Agent 共享 |
| Dify | Knowledge Base | 視覺化管理、工作流整合 | 跨 Session 狀態有限 |
答案很直接:跨 Agent 的溝通統一走 Markdown + YAML。
不管 Agent 自己的記憶有多進階(向量搜尋、Session 歷史、知識庫),當它需要和其他 Agent 溝通時,一律用最通用的格式。SHARED_TASK_NOTES 是 Markdown,inbox 任務是 JSON,結果檔案是 JSON。
任何平台的 AI 都能讀 Markdown 和 JSON。這就是最低公因數。
給 AI 讀的 ≠ 給人讀的
我們發現,AI 讀結構化資料的效果遠好於散文:
| |
用 pipe 分隔(|)、key-value 格式、YAML 風格。每一行都是自包含的上下文單位,AI 可以精確解析 count: 已犯 2 次。
環境隔離與共享層
| |
每個 Agent 有自己的記憶(上層),但所有人共用同一個共享層(下層)。一個 Agent 掛了不影響其他人。共享層用最通用的格式,確保跨平台互通。
完整記憶堆疊一覽
| 層級 | 機制 | 載入時機 | 誰用 | 容量 |
|---|---|---|---|---|
| Auto Memory | MEMORY.md 自動注入 | 每次 Session 開始 | Claude Code Agent | ~200 行 |
| 行為準則 | CLAUDE.md / SOUL.md | 每次 Session 開始 | 全部 Agent | 無限制 |
| 主題記憶 | Memory Files | 按需讀取 | Claude Code Agent | 28 檔 / 155KB |
| 規則繼承 | Rules 四層覆蓋 | 每次 Session 開始 | Claude Code Agent | 14 檔 |
| 向量記憶 | LanceDB + SQLite | 語義搜尋時 | OpenClaw Agent | 無限制 |
| Session 歷史 | Gemini 30 天保留 | 新 Session 自動載入 | Gemini CLI Agent | 30 天 |
| 知識庫 | Dify Knowledge Base | 工作流查詢時 | Pipeline Agent | 89 檔 / 824KB |
| 進度同步 | SHARED_TASK_NOTES | 每次 Session 開始 | 全部 Agent | 800 行 / 50KB |
| 任務傳遞 | bot_inbox JSON | Agent Executor 撈取 | 全部 Agent | 無限制 |
| 活動紀錄 | ai-logs 月度日誌 | COO 巡邏時 | 全部 Agent | 55MB 累計 |
| 產出登記 | j_output_log.jsonl | 任務完成時 | 全部 Agent | 無限制 |
| 自動進化 | j_team_evolution.py | 每天固定時間 | 全部 Agent | 每日更新 |
踩過的坑
坑 1:Agent 造假
Agent 會生成「測試通過」卻根本沒跑測試。解法:GATE-6 反造假驗證,COO 獨立抽查,沒有命令輸出的 PASS 一律不信任。
坑 2:記憶互相覆蓋
早期兩個 Agent 同時改 SHARED_TASK_NOTES,互相覆蓋。解法:Agent Executor 加鎖機制,同時只有一個 Agent 可以執行任務。
坑 3:推諉語言
Agent 遇到不確定的事就說「建議您手動檢查」「可能是這樣」。解法:GATE-9 直接把含推諉語言的回報標記 FAIL。強迫 Agent 自己查明真相。
坑 4:簡體字汙染
MiniMax 模型有時候會輸出簡體字(我們要繁體中文)。解法:在 Agent Executor 裡內建 11,000 個簡繁對照字元,輸出含簡體字就自動退回重做。
坑 5:記憶過時
記憶檔案寫了「某服務運行中」但服務已經停了。Agent 讀到過時記憶做出錯誤判斷。解法:COO 每次啟動時比對記憶和系統實際狀態,不一致就立即修正。
坑 6:MEMORY.md 爆炸
不控制容量的話,MEMORY.md 會越長越肥,超過 200 行被截斷後 AI 只看到前半段。解法:索引檔只放指向,深度內容分散到主題檔案。
10 分鐘快速上手
想在你的專案試試?最小可行的記憶系統只需要三個檔案:
1. CLAUDE.md(專案根目錄)
| |
2. memory/MEMORY.md(記憶索引)
| |
3. memory/team-rules.md(主題記憶)
| |
先跑起來,再根據實際需求逐步加層。從三個檔案開始,不要一開始就追求 155KB 的記憶架構。
參考資料
- Claude Code overview — 官方文件 — Claude Code 架構總覽,包含 CLAUDE.md 載入機制
- Claude Code memory — 官方文件 — Auto Memory 和 MEMORY.md 的完整說明
- Claude Code settings — 官方文件 — settings.json 與 Hooks 設定
- LanceDB 文件 — 向量資料庫技術文件
- Dify 知識庫文件 — Dify 平台知識檢索機制