真正的問題不是「一個 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 SonnetQA 審核、文件校對、風格一致性Claude Code CLI
小月(QA 研究員)Gemini CLI品質把關、調研、前端 QAGemini + 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 行就會截斷。所以這一層只放壓縮過的索引和關鍵指向:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# MEMORY.md 結構(壓縮格式,給 AI 讀的)
CONNECTIONS: → memory/connections.md
IRON-RULES: → memory/iron-rules.md

<team>
  j: Opus|COO|派工+審核+記憶維護
  mimi: MiniMax M2.7|行銷|Docker
  ada: MiniMax M2.7|工程|Docker
  lily: Claude Sonnet|內容|CLI 訂閱
  moongg: Gemini CLI|QA|獨立服務
</team>

<decisions>
  簡單開發→阿達, J只做複雜的
  任務必建Linear卡
  Gemini API禁用, 小月用訂閱版
</decisions>

用 pipe 分隔的格式(|)不是為了好看,是為了 AI 解析效率。每一行都是自包含的上下文單位。

第二層:CLAUDE.md — 行為準則

放在專案根目錄,每次 Session 自動載入。這不是記憶,而是行為閘門——不管 AI 想做什麼,這些規則永遠優先。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
<gates label="優先序: gates > rules">

GATE-1: 安全 > 速度
  checks: SQL-injection | XSS | 命令注入 | 敏感資料外洩

GATE-6: 反造假驗證
  trigger: Agent 回報完成
  action: 至少抽 1 項獨立重跑
  iron: 沒有命令輸出的 PASS = 自動不信任

GATE-9: 反推諉
  pattern: "可能是" | "請手動檢查" | "應該沒問題"
  action: 自動 FAIL

</gates>

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 的規則有四層繼承:

1
2
3
4
5
6
7
基礎規則(common/)
    ↓ 被覆蓋
語言規則(python/, typescript/)
    ↓ 被覆蓋
專案規則(CLAUDE.md)
    ↓ 被覆蓋
Session 上下文(MEMORY.md 自動注入)

我們有 14 個規則檔案,涵蓋安全、效能、測試、程式碼風格、Git 流程。基礎規則定義通用標準,語言規則加上 Python 或 TypeScript 的特殊要求,專案規則再加上這個團隊的閘門。

第五層:Hooks — 自動觸發的守衛

Claude Code 的 Hooks 系統讓我們在工具執行前後自動觸發腳本:

  • Pre Hook:執行 bash 指令前,先攔截危險操作(rm -rfgit --force
  • Post Hook:寫完 Python 檔後自動語法檢查、Blog 內容自動安全掃描
  • Stop Hook:Session 結束前觸發學習評估——提醒 AI 回顧這次學到什麼,提取可重用的 pattern 寫入記憶
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
{
  "hooks": {
    "Stop": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "bash hooks/stop-learn-eval.sh"
      }]
    }]
  }
}

Stop Hook 是記憶系統的閉環。沒有它,AI 做完事就走,學到的東西隨 Session 消失。有了它,每次 Session 的教訓都有機會沈澱成永久記憶。


OpenClaw Agent 的記憶(米米、阿達)

米米和阿達跑在 OpenClaw 平台上,用 MiniMax M2.7 模型。它們的記憶系統和 Claude Code 完全不同。

SOUL.md — Agent 的人格設定

每個 OpenClaw Agent 有一個 SOUL 檔案,定義它的角色、權限和行為邊界。類似 CLAUDE.md 的功能,但格式不同:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
# 阿達的 SOUL.md(簡化版)
role: 產品工程師
reports_to: J (COO)
tech_stack: Next.js, TypeScript, Tailwind, Supabase, Python

authority:
  green: bug 修復(自行處理)
  yellow: 新功能(需 J 審核)
  red: 正式環境部署、資料刪除(需明確授權)

quality_gates:
  1. 簡化自查 → 2. J Code Review → 3. 小月 QA ≥ 8.5

security: HIGHEST PRIORITY
  - 不可洩漏 API Key
  - 不可未經授權公開資訊

SOUL 讓同一個底層模型扮演完全不同的角色。米米和阿達都是 MiniMax M2.7,但 SOUL 不同,一個做行銷、一個做工程。

MEMORY.md — 自動進化的工作記憶

和 Claude Code 的 Auto Memory 不同,OpenClaw 的 MEMORY.md 是由外部進化系統自動更新的。每天固定時間,進化腳本掃描 Agent 的工作紀錄,自動寫入:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
## 專案經驗
- CoinSifter v1.8.0: Pro 版 Beta 測試中
- CryptoLog: Phase 2 完成,Phase 3 開發中

## 錯誤教訓
### 2026-03-22 — GATE-6 失敗
- 回報「success」但 git diff 顯示零修改
- 教訓:回報成功前必須確認有實際修改

### 2026-04-01 自動進化記錄
- 任務數: 7
- 表現: 產出量充足 | 無退回紀錄

Agent 不需要自己記住「我昨天做了什麼」。進化系統替它記。

SQLite + FTS5 — 結構化記憶資料庫

每個 OpenClaw Agent 有獨立的 SQLite 資料庫,存放向量嵌入和全文搜索索引:

1
2
3
4
5
6
7
8
9
CREATE TABLE chunks (
  id TEXT PRIMARY KEY,
  path TEXT,           -- 記憶檔案路徑
  text TEXT,           -- 內容
  embedding TEXT,      -- 向量嵌入(語義搜尋用)
  hash TEXT,           -- 內容雜湊(追蹤變更)
  updated_at INTEGER
);
CREATE VIRTUAL TABLE chunks_fts USING fts5(text, id, path);

這讓 Agent 可以對自己的記憶做語義搜尋和關鍵字搜尋,不用每次都讀完所有檔案。

LanceDB — 團隊級向量記憶

除了 SQLite,OpenClaw 還有 LanceDB 向量資料庫作為共享記憶層:

  • autoCapture:對話中的關鍵資訊自動向量化存入
  • autoRecall:遇到相關上下文時自動召回語義相似的記憶

和文字記憶的差別:向量記憶是語義搜尋。不需要知道確切關鍵字,只要意思相近就能召回。米米上次調研過某個競品,下次提到類似產品時會自動想起來。

LanceDB 用 Apache Arrow 格式儲存,支援事務安全更新和多 Agent 共享讀取。

Session 日誌 — 完整對話歷史

每次 Agent 執行任務,完整的對話過程都以 JSONL 格式保存:

1
2
3
4
{"type":"session","id":"02269028-...","timestamp":"2026-04-01T05:38:00Z"}
{"type":"model_change","provider":"minimax","modelId":"MiniMax-M2.7"}
{"type":"message","role":"user","content":[{"type":"text","text":"修復首頁 bug"}]}
{"type":"message","role":"assistant","content":[{"type":"toolCall",...}]}

這不是給 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 歷史保留功能:

1
2
3
4
5
6
7
// Gemini CLI 設定
{
  "sessionRetention": {
    "enabled": true,
    "maxDays": 30
  }
}

過去 30 天的完整對話都保存在本地。這意味著小月在新 Session 中可以回想起上個月的對話細節——這是其他平台沒有的能力。

LanceDB 向量記憶(手動存取)

小月也可以使用 LanceDB 向量資料庫,但和 OpenClaw 不同的是,她的向量記憶是手動觸發的:

1
2
3
4
5
# 存入記憶
agent_memory.py remember moongg "發現 CoinSifter 在 Safari 有排版問題" knowledge

# 召回相關記憶
agent_memory.py recall moongg "CoinSifter 瀏覽器相容"

向量用 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 的知識庫

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
dify-knowledge/
├── sop/              # 23 份操作流程(168KB)
│   ├── INDEX.md           — 所有 SOP 的主索引
│   ├── architecture.md    — 團隊架構、角色、AI 引擎
│   ├── blog-pipeline.md   — Blog 從撰寫到部署的完整流程
│   ├── product-development.md — 9 階段產品開發 SOP
│   ├── quality-gate.md    — QA 品質標準
│   ├── task-delegation.md — 任務派發規則
│   ├── monitoring-alerting.md — 5 層監控系統
│   └── ... (16 份更多 SOP)
├── crypto-ta/        # 24 份交易技術分析(212KB)
│   ├── 01-candlestick-patterns.md
│   ├── 07-wfo-validation.md
│   ├── 17-pro-trader-strategy.md
│   └── ... (21 份更多分析)
├── marketing/        # 行銷研究(272KB)
│   └── viral/             — X、Reddit、Threads、YouTube 病毒式傳播分析
└── 每日快照/         # 31 份每日更新

知識庫的作用

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 檔案,記錄全局工作狀態。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
# Shared Task Notes — Cross-Session Sync

> 規則:
> 1. 每個 session 醒來第一件事:讀這個檔案
> 2. 開始做任務前:寫「🔄 正在做 MIM-XXX — 簡述」
> 3. 做完後:改為「✅ MIM-XXX — 一句話結果」

## 🔄 Session Update (2026-04-01) — 安全巡邏 + 產品開發

### 完成
- 全系統安全巡邏: 10 項檢查通過
- MCP Security Scanner: CLI MVP + 文件 + 測試 30/30

### 等 Judy 決策
- [ ] Security Scanner 定價確認
- [ ] Blog 發布核准

800 行、50KB。它不漂亮,但有效。任何 Agent 醒來讀完這個檔案,就知道:誰在做什麼、什麼已經完成、什麼被擋住了。

bot_inbox — 任務的快遞系統

每個 Agent 有自己的收件匣目錄:

1
2
3
4
5
6
7
8
bot_inbox/
├── j/           # COO 的收件匣
│   ├── pending/      # 待處理
│   └── done/         # 已完成(累計 16 萬筆紀錄)
├── mimi/        # 行銷 Agent
├── ada/         # 工程 Agent
├── lily/        # 內容 Agent
└── moongg/      # QA Agent

任務以 JSON 格式存放,包含完整上下文:

1
2
3
4
5
6
7
8
9
{
  "type": "linear_task",
  "task_id": "MIM-440",
  "title": "MCP Security Scanner 測試套件強化",
  "description": "目前 30 個測試全過,需要...",
  "message": "相關背景見 memory/team-and-products.md",
  "by_whom": "J",
  "ts": "2026-04-01T12:34:00Z"
}

任務檔案本身就是上下文載體。Agent 讀取任務時不只知道「要做什麼」,還知道為什麼、之前嘗試過什麼、可以參考哪些記憶檔案。

ai-logs — 每個 Agent 的活動紀錄

每個 Agent 都有自己的月度活動日誌:

1
2
3
4
5
6
7
8
ai-logs/
├── agent-openclaw/2026-04.md    # 米米+阿達的 OpenClaw 操作
├── agent-J-claudecode/2026-04.md # J 的 Claude Code 操作
├── agent-K-dify/2026-04.md      # Dify Pipeline 操作
├── j_output_log.jsonl           # 全隊產出登記簿
├── monitor_report.json          # 系統健康快照
├── heartbeat_data.txt           # Agent 心跳狀態
└── .decision_tracker.json       # COO 決策追蹤

j_output_log.jsonl 是全隊的產出登記簿。每個 Agent 完成任務後都會寫一筆:

1
2
3
4
5
6
7
{
  "description": "MCP Security Scanner CLI MVP 完成",
  "type": "product",
  "agent": "ada",
  "task_id": "MIM-437",
  "ts": "2026-04-01T15:30:00Z"
}

COO 巡邏時讀這些 log 就能掌握全局。不需要問每個 Agent「你做了什麼」。

Linear — 結構化的任務記憶

我們用 Linear 做任務管理。它不只是工具,也是一種記憶:

  • 每張卡片記錄了任務的完整生命週期(建立→派工→執行→審核→完成)
  • 卡片留言是 Agent 之間的正式溝通管道
  • 標籤標記了負責人和任務類型
  • 狀態變更有時間戳,可以追溯整個流程

Dispatcher(路由器)每隔幾分鐘掃描 Linear,把新卡片自動路由到對應 Agent 的 inbox。完成後 Agent 回寫留言到卡片上。


記憶如何在 Agent 之間流動

有了各自的記憶和共享層,下一個問題是:上下文怎麼從 A 傳到 B?

Memory Preamble — 任務前的強制注入

Agent Executor(中央調度器)在啟動每個 Agent 之前,會在任務前面注入一段「記憶前言」:

1
2
3
4
5
6
【強制執行 — 開始任務前必做】
1. 先讀取你的記憶檔案確認身份和規則
2. 確認你是用繁體中文回覆
3. 完成任務後,必須把結果寫到指定的 result 檔案,不寫 = 沒做
---
[以下是你的任務]

這確保了即使 Agent 是全新 Session、完全沒有上下文,它也會先去讀自己的 SOUL.md 和 MEMORY.md,然後才開始工作。

Result File — 強制回報

Agent 完成任務後必須寫一個結果檔案。沒有結果檔案 = 沒做。

1
2
3
4
5
6
7
{
  "from": "ada",
  "type": "task_result",
  "task_id": "MIM-440",
  "status": "done",
  "summary": "測試套件從 30 擴充到 45 個,新增邊界測試和錯誤處理測試"
}

結果檔案放回 COO 的 inbox,COO 審核後更新 SHARED_TASK_NOTES 和 Linear。下一個接手的 Agent 看到紀錄就能無縫銜接。

完整的上下文流

一個典型的任務從建立到完成,上下文的流動路徑:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
Judy 在 Linear 建卡
Dispatcher 讀取卡片,判斷該給誰
寫入 JSON 任務檔到 Agent inbox(含完整背景)
Agent Executor 發現新任務
注入 Memory Preamble → 啟動 Agent
Agent 讀 SOUL.md + MEMORY.md → 讀任務 → 執行
完成 → 寫 Result File 到 COO inbox
COO 審核 → 更新 SHARED_TASK_NOTES + Linear 留言
下一個 Agent 醒來 → 讀 SHARED_TASK_NOTES → 接續

整個流程中,上下文從不「消失」。它在檔案系統中以 JSON 和 Markdown 的形式持續存在,被一個接一個的 Agent 讀取和補充。


記憶的自動進化

記憶系統最大的風險是過時。一條錯誤的記憶比沒有記憶更危險。

每日進化系統

每天固定時間,進化腳本自動執行:

  1. 掃描所有 Agent 的 inbox/done 目錄(過去 24 小時的完成項)
  2. 分類任務(產品、Blog、QA、系統維護等)
  3. 評估每個 Agent 的表現(產出量、退回次數、品質趨勢)
  4. 更新每個 Agent 的 MEMORY.md(自動追加進化記錄)
  5. 生成全隊進化報告,推送到 Notion

進化報告的格式:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# 全隊每日進化報告 — 2026-04-01

## J(COO / 技術總監)
任務數: 121
✅ 做得好: 產出量充足
⚠️ 需改進: 有 1 項退回

## 阿達(產品工程師)
任務數: 7
✅ 做得好: 無退回紀錄

## 全隊總計: 137 項,4 人

這讓 Judy 每天花 5 分鐘就能掌握整個團隊的運作狀態。

鐵則 — 從事件中結晶的規則

記憶系統裡最有價值的不是「要做什麼」,而是「不要做什麼」。每次踩坑都寫入鐵則,附上具體事件:

1
2
3
4
5
6
7
8
9
BLOG-REVIEW-GATE:
  rule: Blog 必須 QA ≥ 8.5 → Notion 審核 → Judy 確認 → 才能部署
  lesson: MIM-195 沒 QA 就上線,錯誤資訊外流
  count: 已犯 1 次

ANTI-FABRICATION:
  rule: Agent 說完成 → COO 獨立重跑驗證
  lesson: MIM-242 阿達回報完成 → 實際執行 SyntaxError
  count: 已犯 3 次

每條鐵則都有 lesson= 標籤。不是「我覺得應該這樣」,而是「我們因為沒這樣做而出了事」。這種從事件中結晶的規則,Agent 的遵守率遠高於抽象的最佳實踐。

COO 的記憶巡邏

COO Agent 每次啟動時有固定的巡邏流程:

  1. 讀記憶(30 秒)— MEMORY.md + SHARED_TASK_NOTES
  2. 比對現實 — 記憶和系統實際狀態是否一致?
  3. 清理過時記憶 — 已完成的任務、已修復的 bug、已變更的架構
  4. 寫入新教訓 — 這次 Session 的決策和發現寫回 Memory Files

如果發現記憶和現實不一致(例如記憶裡寫著「某服務運行中」但實際已停止),COO 會立即更新記憶。這防止了過時資訊在團隊中傳播。


跨平台的記憶格式設計

四個平台、四套記憶機制。怎麼讓它們互通?

最低公因數原則

平台自有記憶優勢限制
Claude CodeMarkdown 文字檔透明、人類可讀、版本控制純文字搜尋,無語義
OpenClawSQLite + LanceDB語義搜尋、自動召回不易人工審查
Gemini CLI30 天 Session 歷史長期對話連續性無法跨 Agent 共享
DifyKnowledge Base視覺化管理、工作流整合跨 Session 狀態有限

答案很直接:跨 Agent 的溝通統一走 Markdown + YAML

不管 Agent 自己的記憶有多進階(向量搜尋、Session 歷史、知識庫),當它需要和其他 Agent 溝通時,一律用最通用的格式。SHARED_TASK_NOTES 是 Markdown,inbox 任務是 JSON,結果檔案是 JSON。

任何平台的 AI 都能讀 Markdown 和 JSON。這就是最低公因數。

給 AI 讀的 ≠ 給人讀的

我們發現,AI 讀結構化資料的效果遠好於散文:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# 好的寫法 — AI 高效解析
LINEAR-REPLY:
  flow: inbox → 執行 → 回原卡留言 → 移 done
  violation: 只做事不回覆 = 等於沒做
  count: 已犯 2 次

# 不好的寫法 — 資訊密度低
Linear 卡片處理完之後記得要回到原卡留言,
不然別人看不到你做了什麼,
之前已經忘記兩次了。

用 pipe 分隔(|)、key-value 格式、YAML 風格。每一行都是自包含的上下文單位,AI 可以精確解析 count: 已犯 2 次


環境隔離與共享層

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
┌──────────────┐  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐
│  OpenClaw     │  │  OpenClaw     │  │  Claude Code  │  │  Gemini CLI  │
│  米米(行銷)   │  │  阿達(工程)   │  │  莉莉(內容)   │  │  小月(QA)    │
│  MiniMax M2.7 │  │  MiniMax M2.7 │  │ Claude Sonnet │  │  Gemini 2.5  │
│  SOUL+LanceDB │  │  SOUL+SQLite  │  │ CLAUDE.md     │  │  30天Session │
└──────┬───────┘  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘
       │                 │                 │                 │
       └─────────────────┴─────────────────┴─────────────────┘
                   ┌──────────────┴──────────────┐
                   │         共享記憶層            │
                   │                              │
                   │  SHARED_TASK_NOTES.md        │
                   │  bot_inbox/{agent}/          │
                   │  ai-logs/{agent}/            │
                   │  j_output_log.jsonl          │
                   │  Linear API                  │
                   │  Dify Knowledge Base (89份)  │
                   │  Telegram 通知               │
                   └──────────────────────────────┘

每個 Agent 有自己的記憶(上層),但所有人共用同一個共享層(下層)。一個 Agent 掛了不影響其他人。共享層用最通用的格式,確保跨平台互通。


完整記憶堆疊一覽

層級機制載入時機誰用容量
Auto MemoryMEMORY.md 自動注入每次 Session 開始Claude Code Agent~200 行
行為準則CLAUDE.md / SOUL.md每次 Session 開始全部 Agent無限制
主題記憶Memory Files按需讀取Claude Code Agent28 檔 / 155KB
規則繼承Rules 四層覆蓋每次 Session 開始Claude Code Agent14 檔
向量記憶LanceDB + SQLite語義搜尋時OpenClaw Agent無限制
Session 歷史Gemini 30 天保留新 Session 自動載入Gemini CLI Agent30 天
知識庫Dify Knowledge Base工作流查詢時Pipeline Agent89 檔 / 824KB
進度同步SHARED_TASK_NOTES每次 Session 開始全部 Agent800 行 / 50KB
任務傳遞bot_inbox JSONAgent Executor 撈取全部 Agent無限制
活動紀錄ai-logs 月度日誌COO 巡邏時全部 Agent55MB 累計
產出登記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(專案根目錄)

1
2
3
4
5
6
<rules>
TASK-FLOW:
  action: 收到任務 → 讀記憶 → 執行 → 更新記憶
SAFETY:
  action: 不可洩漏 API Key 或內部路徑
</rules>

2. memory/MEMORY.md(記憶索引)

1
2
3
# Memory Index
- [team-rules](team-rules.md) — 團隊鐵則
- [project-context](project-context.md) — 專案進度

3. memory/team-rules.md(主題記憶)

1
2
3
所有對外發布內容必須經過品質審核。
**Why:** 之前未審核就發出,造成錯誤資訊外流。
**How:** 內容完成 → QA ≥ 8.5 → 才能發布。

先跑起來,再根據實際需求逐步加層。從三個檔案開始,不要一開始就追求 155KB 的記憶架構。


參考資料

AI×交易 完整套裝 — 課程 + 指揮官手冊
$59 省 $4.90 · 中英雙語 · 終身更新
購買套裝 →

延伸閱讀