一人公司的 AI 記憶架構：為什麼百萬上下文依然失憶？

作者：蔡正信 數位教練 ＆ OpenClaw 系統架構組
適用對象：一人公司創業者、AI 顧問、高階知識工作者、全棧 AI 工程師
核心主題：AI 記憶工程、上下文優化、雙層畫像快取、動態時序調和、成本控制

1. 痛點診斷：為什麼百萬 Token 上下文依然解決不了 AI 失憶？

許多人在使用 Claude Code、Cursor、ChatGPT 或各種 AI Agent 時，常常遇到令人沮喪的情境：
– 早上花了半小時跟 AI 講清楚專案架構與變數命名規則；下午開個新會話，它又是一張白紙，所有的背景約定又得重新交代一次。
– 許多人以為這是大模型的宿命，或者寄望於「等模型上下文視窗做到 100 萬、1000 萬 Token，把所有歷史對話全塞進去不就解決了嗎？」

這恰恰是 AI 工作流設計中最大的迷思！

盲目塞滿上下文的三大殘酷代價：

1. 中間迷失 (Lost in the Middle)：
   注意力機制不是無限均勻的。當關鍵資訊被埋在長達數十萬 Token 的中間層時，LLM 的事實回憶精確度會雪崩式下滑。
2. 算力與帳單成本雪崩：
   上下文不是免費的。每次提問，整段數十萬 Token 的歷史都必須重新計費。在一人公司或小企業中，這會輕易擊穿每日 API 預算（例如 OpenClaw 設定的每日 NT$16.67 預算護欄）。
3. 查出矛盾讓模型瞎猜：
   真實世界的事實是隨時間動態變化的。全量堆疊歷史只會讓新舊衝突的事實同時呈現在 Prompt 中，導致 Agent 陷入決策癱瘓。

核心定論：記憶做得好，帳單數字是會變的。真正的解法是讓系統知道該記住什麼、該忘掉什麼，而不是無腦塞入更多 Token。

2. 核心認知翻轉：記憶 (Memory) ≠ 檢索增強生成 (RAG)

在建構一人公司的 AI 系統時，必須先釐清「文件檢索」與「使用者記憶」的本質鴻溝：

結論：向量資料庫解決的是「找文件」，記憶層解決的是「懂使用者」。指望 RAG 順便解決記憶，就像指望硬碟搜尋順便幫你做個人特質快取一樣不合時宜。

3. Supermemory 給一人公司的四大架構啟示

Supermemory（由 20 歲創始人 Dhravya Shah 發起的開源專案，在 LongMemEval 等多項記憶基準奪冠）展示了一套極致優雅的工程解法：

啟示一：時序事實圖譜與動態調和 (Dynamic Dreaming)

• 記憶內部維護時序關係，每條事實皆帶時間戳。
• 具備背景動態引擎（Dynamic Dreaming），在空閒時重新審視事實、調和矛盾，把過期狀態推翻重寫。「記憶的技術難點從來不是『存』，而是『改』」。

啟示二：主動遺忘機制 (Proactive Forgetting & TTL)

• 「記得多，不如忘得乾淨。」
• 隨口說的臨時對話（例如「我明天有考試」、「幫我看這個臨時報錯」）具備生命週期（TTL），過期自動作廢，噪音永遠不會沉澱為永久記憶。沒有衰減機制的記憶庫，三個月後就會退化成無法檢索的垃圾場。

啟示三：雙層使用者畫像主動注入 (Active Supply)

• 傳統方案每次對話現查向量庫，耗時 300ms 且容易查偏。
• Supermemory 將畫像拆為兩層：
• 靜態層 (Static Tier)：長期穩定的事實（角色定位、工程偏好、常用工具、安全規範）。
• 動態層 (Dynamic Tier)：最近的短期焦點（正在修復的 Bug、進行中的專案契約）。
• 每次會話開始，僅需 50ms 一次性注入約 720 Tokens，將上下文佔用壓縮了 99.4%！模型開口之前就已經知道你是誰、你在做什麼。

啟示四：工程韌性 —— 透明代理與 Fail-Open

• 記憶服務若故障或逾時，原始請求透明轉發給 LLM 提供商。
• 記憶掛了，對話不掛；將可靠性永遠置於功能之前。

4. 評估任何記憶系統的「三問黃金框架」

未來當你要為團隊、個人或客戶評估任何記憶產品（如 Mem0, Zep, Letta, 或官方內建記憶功能）時，請使用這三個問題來檢驗：

flowchart TD
    Q1{"1. 它會不會更新？"}
    Q1 -- 否 --> Fail1["只是靜態文字庫"]
    Q1 -- 是 --> Q2{"2. 它會不會遺忘？"}
    Q2 -- 否 --> Fail2["三個月後變成噪音垃圾場"]
    Q2 -- 是 --> Q3{"3. 它給不給得動？"}
    Q3 -- 被動等搜 --> Pass1["及格：傳統查詢型記憶"]
    Q3 -- 主動 50ms 注入畫像 --> Pass2["卓越：現代主動記憶系統"]

1. 它會不會更新？
   事實會過期，系統能否識別新事實並推翻舊事實？
2. 它會不會遺忘？
   是否具備 TTL 衰減機制，能主動清理臨時噪音？
3. 它給不給得動？
   是每次被動等你去搜尋，還是能在會話啟動瞬間主動注入雙層畫像？

🧠 AI 深度分析與重點總結

1. 一人公司記憶組件的「分工黃金三角」

一人公司不應該把所有記憶塞在同一個籃子裡，而應採階梯式分工：
1. 即時供給層（Active Profile 快取）：50ms 讀取、小於 800 Tokens，負責提供靜態角色與當前動態焦點，解決會話失憶。
2. 長期知識層（Heptabase / 01.Docs）：結構化卡片、深度思考資產、append-only 零刪除，由人類與特工共同沉澱。
3. 靜態資料檢索層（LanceDB / RAG）：負責幾百萬字的大型書籍、法規手冊檢索，只讀不改。

2. 算力預算與綠色 AI

在一人公司營運中，AI 不是展示品，而是需要算投資報酬率（ROI）的生產工具。透過「雙層畫像快取」將上下文開銷壓縮 90% 以上，不僅守住每日微型算力預算，更徹底消除了 Agent 的理解漂移（Context Drift）。

🎯 對 OpenClaw / Hermes 系統的落地行動指南

為了將本教案的方法論落實到真實日常運作中，一人公司可依循以下四步落地 SOP：

步驟一：固化你的靜態畫像 (Static Profile)

• 建立或精煉你的 IDENTITY.md，字數嚴格控制在 300 字內。
• 明確寫下你的身分定位、常用技術棧、不可跨越的安全紅線與溝通風格偏好。

步驟二：建立動態焦點快照 (Dynamic Focus Snapshot)

• 維護一份極輕量的 CURRENT_FOCUS.json（或 CURRENT_FOCUS.md，< 500 字）。
• 每次完成重大任務或每日工作開始時，更新目前的進行中專案、未完成任務契約與短期約束。
• 使用 scripts/memory/active_profile.py 驗證組裝時間是否在 50ms 內。

步驟三：實施時序衝突調和 (Dynamic Dreaming)

• 定期執行 scripts/governance/memory_dreamer.py 掃描規則。
• 當發布新版 SOP 或作業規則時，主動在舊規則標記 [DEPRECATED]，避免多版本規則混雜干擾 Agent 判斷。

步驟四：實施暫存資料安全歸檔 (Proactive Forgetting)

• 對於日常除錯、一次性測試產生的 scratch 暫存檔，設定 7 天 TTL 生命週期。
• 超期檔案透過腳本自動安全歸檔至 01.Docs/archive/scratch_expired/，既能保持工作區清爽無噪音，又嚴格遵守資產 append-only 零刪除鐵律。