# 策展 · X (Twitter) 🔥🔥🔥 > 作者：mem0 (@mem0ai) · 平台：X (Twitter) · 日期：2026-05-14 > 原始來源：https://x.com/mem0ai/status/2054580022049198513 ## 中文摘要 # Codex CLI 的記憶運作機制 Codex CLI 內建了一個經過非同步摘要處理的記憶儲存庫，路徑位於 `~/.codex/memories/`。 這是一項第一方功能： - 相關文件可參考 developers.openai.com/codex - 程式碼已完全開源於 github.com/openai/codex 在這篇《In Context》文章中，我們將深入探討 Codex CLI 如何處理記憶。 Codex 是 OpenAI 的程式開發 Agent，目前有三種版本：CLI、IDE 擴充功能，以及整合在 ChatGPT 中的雲端 workspace。 由於 CLI 是文件記錄最詳盡的介面，且其記憶體內部的實作已經開源，因此我們將以此為例進行分析。以下大部分內容也適用於 IDE 擴充功能，因為它們共用相同的 `~/.codex/` 設定與記憶體配置。 --- ## 記憶體架構 Codex 的記憶體存放在單一目錄中：`~/.codex/memories/`。該目錄包含一組固定的 Markdown 檔案。這裡沒有使用 SQLite、沒有向量搜尋索引，也沒有任何不透明的二進位檔案（blob）。 主要的檔案如下： - `memory_summary.md`：下一個 session 會優先讀取的整合檢視。 - `MEMORY.md`：長篇的合併記憶檔，會在需要時透過 grep 進行搜尋。 - `raw_memories.md`：合併前的原始提取輸出。 - `skills//SKILL.md`：特定技能相關的記憶。 - `rollout_summaries/.md`：每個 session 的摘要，用於提供合併過程所需的資料。 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778725944451-iaHINUqqsbkAABkPFjpg.jpg) 這就是整個記憶層的全部內容。其餘部分則是負責填充這些檔案的管線（pipeline），以及從中提取資料的讀取路徑。 --- ## 記憶是如何寫入的 寫入路徑分為兩個階段。 第一階段是針對每個 rollout（部署/執行週期）。當一個 session 閒置足夠長的時間（預設為六小時）後，Codex 會啟動一個任務，根據嚴格架構的提取 Prompt 對對話進行取樣，將所有輸出內容通過秘密遮蔽（secret-redactor）處理，並將結果儲存在本地狀態資料庫中。此時，記憶目錄中尚未寫入任何內容。 第二階段是全域性的。它會取得一個全域鎖（儲存在狀態資料庫中），確保兩個合併處理程序不會同時執行。它會載入最近第一階段的輸出，將其同步到磁碟，檢查產生的 workspace 是否與現有內容有實質差異，只有在有差異時，才會產生一個獨立的合併子 Agent。該子 Agent 會讀取候選內容，決定哪些需要合併、哪些需要修補、哪些需要捨棄，並將差異寫回 `~/.codex/memories/`。 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778725944399-iaHINU0yUbYAEkXqZjpg.jpg) 這兩個階段都使用可配置的模型（第一階段使用 `extract_model`，第二階段使用 `consolidation_model`），且合併過程是作為一個獨立的子 Agent 執行，而不是與使用者的對話同步進行。 --- ## 記憶是如何載入的 在 session 開始時，Codex 會完整讀取 `memory_summary.md`，將其截斷以符合 5,000 個 token 的固定預算（這是一個定義在 read-path crate 中的常數，並非公開文件中的內容），並將結果注入到開發者指令中。該截斷後的摘要就是 Agent 預先載入的全部內容。 對於摘要中未包含的任何內容，Agent 會被指示直接對 `MEMORY.md` 執行 grep 搜尋。讀取路徑的模板會告訴 Agent：從摘要中提取關鍵字、搜尋 `MEMORY.md`、如果被指向則開啟相關的 rollout-summary 檔案，若無匹配則停止。整個搜尋預算被控制在極少數的步驟內。 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778725944422-diaHINU9rawAAnKmLjpg.jpg) 這裡沒有向量資料庫、沒有相似度搜尋、也沒有重排序步驟。這是刻意設計的純文字與子字串匹配機制。這種權衡的代價是：如果查詢語句與儲存的措辭關鍵字不重疊，就無法找到事實；但換來的是可預測性以及零檢索時間成本。 --- ## 控制機制 以下幾個配置選項控制了上述所有行為。在依賴此系統之前，了解這些設定非常重要。 - **預設關閉**：必須開啟主功能旗標 `features.memories`。一旦開啟，兩個子開關會控制執行時期：`generate_memories`（寫入）和 `use_memories`（讀取）。在功能啟用後，兩者預設皆為開啟。 - **閒置門檻**：`min_rollout_idle_hours`（預設為 6）設定了 session 在符合第一階段資格前所需的最小閒置時間。活躍的 session 永遠不會觸發此機制。 - **合併上限**：`max_raw_memories_for_consolidation`（預設為 256，上限為 4,096）限制了合併過程每次執行時所考慮的最近 rollout 數量。 - **老化機制**：`max_rollout_age_days`（預設為 30）會停止考慮超過此期限的執行緒進行記憶生成。`max_unused_days`（預設為 30）則會讓在此期間未被呼叫的記憶失去參與下一次合併的資格。 - **速率限制感知**：`min_rate_limit_remaining_percent`（預設為 25）會在使用者的 API 配額偏低時暫緩合併，確保背景任務不會佔用前台請求的資源。 - **秘密遮蔽**：內建的清理機制，確保任何記憶寫入磁碟前已過濾掉憑證。 - **地理限制**：推出時，記憶功能在歐洲經濟區（EEA）、英國或瑞士無法使用。這些地區的使用者完全無法存取此功能。 --- ## 限制所在 簡單來說：這個記憶系統並不穩健。它只是單一使用者的 Markdown 檔案，且受限於固定的 token 預算，大多數的失敗模式都源於此。 - **載入的硬性 token 上限**：`memory_summary.md` 在每個 session 開始時都會被截斷至 5,000 個 token。超過上限的任何內容都會被靜默捨棄。沒有警告，沒有日誌。Agent 只是單純看不到它。 - **僅限關鍵字的回退機制**：任何未進入摘要的內容，都必須能在 `MEMORY.md` 中透過字面上的子字串匹配找到。經過改寫的事實是不可見的。例如，「我們的部署指令是什麼？」不會找到「production deploys go through make ship-prod」，除非儲存的內容中包含這些確切的詞彙。 - **Grep 成本隨檔案大小增加**：`MEMORY.md` 是線性搜尋的。對於長期使用的使用者，累積了數個月的記憶後，每次搜尋的成本都會增加。 - **僅限生成的狀態，不可編輯**：文件將 `~/.codex/memories/` 定義為由 Codex 管理。手動編輯記憶並非支援的操作路徑。使用者若希望 Agent 永遠記住某些內容，應將其放入 `AGENTS.md`。 - **閒置門檻的脆弱性**：Session 需要閒置六小時才能符合合併資格。一個在連續程式開發衝刺（sprint）中工作的開發者可能永遠無法觸發此機制。 - **僅限本地狀態**：`~/.codex/memories/` 是針對每個使用者、每台機器的檔案系統狀態。沒有跨機器同步、沒有團隊共享、沒有遠端備份儲存。 - **地理限制**：推出時，記憶功能在 EEA、英國和瑞士被封鎖。 這些結構性限制在真實團隊的具體案例中顯得尤為重要。 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778725944432-iaHINJnEmbsAAu8Yipng.png) --- ## Mem0 如何整合 Mem0 是一個位於 Agent 與持久化儲存之間的記憶層。 針對 Codex，官方文件提供了 MCP 整合方式：docs.mem0.ai/integrations/codex。 Codex CLI 原生支援 MCP 伺服器。它們配置在 `~/.codex/config.toml` 中的 `[mcp_servers.]` 下。最簡單的 Mem0 設定如下： ``` [mcp_servers.mem0] url = "https://mcp.mem0.ai/mcp" bearer_token_env_var = "MEM0_API_KEY" ``` 這個單一區塊會向 Codex 暴露九個 MCP 工具：`add_memory`、`search_memories`、`get_memories`、`get_memory`、`update_memory`、`delete_memory`、`delete_all_memories`、`delete_entities`、`list_entities`。 Codex 的 Agent 會以與處理其他 MCP 工具相同的方式來使用它們。 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778725944575-iaHINVaNlbcAEtug4png.png) 底層的改變如下： - **持久化、跨機器的記憶**：本地 `~/.codex/memories/` 的限制消失了。相同的 Mem0 儲存庫會跟隨使用者跨越筆電、伺服器與 CI 環境。在新機器上無需從零開始重新生成。 - **跨工具記憶**：一個同時使用 Codex CLI 進行終端工作與 Cursor 進行編輯工作的開發者，可以將兩者指向同一個 Mem0 後端。在 Codex CLI session 中捕捉到的事實（例如：「staging 部署腳本會靜默吞掉錯誤，診斷時請優先使用 production 風格的輸出」）會出現在同一個專案下一次的 Cursor Agent 執行中。使用者無需在兩個工具之間複製任何內容。 - **語意回憶**：Mem0 透過嵌入（embedding）支援的搜尋來根據意義進行檢索。Codex 的原生回憶是完整讀取 `memory_summary.md` 並回退到對 `MEMORY.md` 進行 grep：雖然快速且可預測，但無法找到措辭與查詢不同的儲存事實。使用 Mem0，詢問「我們的部署指令是什麼？」即使詞彙不重疊，也能找到「production deploys go through make ship-prod」。 - **使用者隔離**：每個使用者的 `userId` 會劃分其記憶範圍。三個使用相同 Mem0 後端的隊友會各自擁有獨立的儲存庫。 - **沒有 5,000 個 token 的摘要上限**：檢索是針對實際儲存庫進行的語意搜尋排名，而不是載入單一摘要檔案。大型記憶庫可以持續使用，而不會為了符合開發者指令的預算而被截斷。 - **即時更新**：Mem0 在對話發生的同時寫入記憶，而不是等待六小時的閒置門檻。下一個 session 可以立即看到上一個 session 所教導的內容。 - **在不支援記憶功能的地區也能使用**：EEA、英國與瑞士的使用者可以獲得一個不依賴 Codex 地區性部署的記憶層。 Codex CLI 的記憶層是目前程式開發 Agent 領域中精心設計的方案：兩階段背景合併、秘密遮蔽、基於 grep 且 token 成本可預測的讀取路徑，以及端到端開源的管線。 如果你目前正在使用 Codex CLI，且上述任何限制讓你感到困擾，整合 Mem0 大約只需要一分鐘 [docs.mem0.ai/integrations/codex]。 --- In Context #9 本部落格是《In Context》系列的一部分，這是一個由 @mem0ai 撰寫的部落格系列，涵蓋 AI Agent 記憶與 context 工程。 @mem0ai 是一個智慧型、開源的記憶層，專為 LLM 與 AI Agent 設計，旨在跨 session 提供長期、個人化且具備 context 感知的互動。 - 在此取得免費 API key：app.mem0.ai - 或從我們的開源 GitHub 儲存庫自行部署 mem0。 ## 標籤 Codex, CLI, 記憶系統, 開源專案, 教學資源, OpenAI, Codex