Agent 記性很差？ 如何讓不同電腦上的 Agent 進行 context 同步
本篇是「Codex 和 Claude Code 雙修」系列的第 7 / 7 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
這題我斷斷續續搞了一個月，踩掉不少坑，最後能濃縮成一句話：
把「檔案同步」和「上下文同步」分開，它們是兩件事。
會卡住，通常是因為把這兩件事混在一起想。拆開之後，一半的問題會自己消失。
檔案同步：最簡單的那一半
程式碼、文件這種「檔案」的同步其實沒什麼好講：Google Drive、Dropbox、一個 GitHub repo，挑你順手的就好。這部分是 solved problem，不是你真正的痛點。
真正的痛點是下一段。
上下文同步：你以為 Agent 很笨，其實是它每次重開機
Agent 本質上是 stateless 的。每開一個新對話，它都從零開始——這不是 bug，是設計。
你覺得它「笨」「記性差」，多半是因為每次都要把「上次做到哪、為什麼這樣決定、下一步是什麼」重新貼一遍。換一台電腦更慘，連要貼的素材都在另一台上。
解法不是去期待 agent「記得」，而是讓結構化的 markdown 幫它 reload。我現在用三層：
CURRENT_WORK.md（主入口）：只放 3–5 個 active 專案，每個 5–6 行，寫「停在哪 + 下一步」。刻意保持短，因為它每天都要讀。project_status_<專案>.md：單一專案的最新狀態，細節放這。handoff.md：只有大型專案才需要，記決策、風險、驗證細節這種「為什麼」的東西。
開新對話時我只要打一句「開工」，agent 自動把這三層讀進來，幾秒就接上狀態，不用再貼歷史。
跨機器：用一個 private repo 當單一真相
三層檔案我放在一個 GitHub repo（我叫它 claude-memory），兩台電腦都 clone 它。Google Drive 也能做到同步，但 GitHub 多了 diff history，改了什麼一目瞭然，對「決策記錄」這種東西特別有用。
一個容易漏掉的點：這個 repo 一定要 private。 裡面裝的是你專案的內部決策、風險、還沒公開的進度，不是能隨便攤在外面的東西。
至於「怎麼讓 agent 讀到這些檔案」，這裡我要修正一個自己一開始的做法——
我原本寫了一支 sync 腳本，把檔案「灌」進 agent 的 local memory 目錄。後來發現大多數情況不必這麼麻煩，因為工具本身就有原生機制：
- Claude Code 的
@import 支援絕對路徑。你可以在~/.claude/CLAUDE.md或專案的CLAUDE.md裡直接寫@~/repos/claude-memory/CURRENT_WORK.md，clone 一次之後就自動載入，不用每次手動同步。 - Codex 現在有原生 memory：session 開始會整份讀
memory_summary.md，需要細節時再 grepMEMORY.md。結構跟我手刻的三層幾乎一樣。
換句話說，你手刻的三層 markdown 是很好的內容結構，值得留著；但「載入」這一步可以交給工具原生的 import / memory，少維護一支腳本。而且兩家工具都在往「原生 memory」補齊——這反而印證了 stateless 的方向沒錯：與其讓模型記得，不如讓外部檔案記得。
兩個沒人會先告訴你的坑
坑一：merge conflict 是常態。 兩台電腦都在改同一份 CURRENT_WORK.md，又靠 git 同步，衝突遲早會來——尤其這份檔案每個 session 都在變。我的處理方式是：CURRENT_WORK.md 用「per-machine 區塊」分開寫，或乾脆接受偶爾手動 resolve；handoff.md 盡量 append-only（往下加、不改舊的），衝突機率就低很多。這是這套系統真實存在的 friction，別假裝沒有。
坑二：停點過期，比沒有記憶更糟。 如果你忘了更新停點，agent 會「很有信心地」進入一個錯誤的狀態——confidently wrong，比它老實說「我不知道」還危險。所以檔案的鮮度其實是這套系統的單點失敗。下面 Q2 的 baton 規則就是在擋這件事。
Codex 和 Claude Code 怎麼協作
我在公司環境同時跑 Codex 和 Claude Code。協作的第一原則跟上面一樣：共享 source of truth，不要分資料匣。 分了，你就要兩邊維護重複資訊，只會更累。
修正：frontmatter tag 是「約定」，不是「機制」
我一開始想用 markdown frontmatter tag 來區分「誰看哪份檔」，像這樣：
---
agents: [claude, codex]
codex_tier: summary
---這裡要老實講一個我踩過的誤解：這兩家工具都不會自動解析這種自訂 frontmatter。
- Codex 是靠走訪
AGENTS.md（從 git root 往下逐層串接）決定讀什麼，不看agents:或codex_tier:。 - Claude Code 是靠
CLAUDE.md階層加上@pathimport 決定讀什麼，同樣不看這些 tag。
也就是說，照上面那樣寫，兩家其實都會把整份檔讀進去，tag 完全沒作用，除非你另外寫一支腳本去解析它、或在 prompt 裡明講「請遵守 frontmatter」。如果你只是把它當成「給人看的註記」那沒問題；但別誤以為它會自動分流。
真正能「一份真相、兩家都吃」的做法，是用工具原生的慣例：
- 寫一份
AGENTS.md放兩邊共用的 repo 規則（Codex 原生讀，Cursor、Aider 等工具也吃這套）。 CLAUDE.md只寫@AGENTS.md加上 Claude 專屬的補充——Claude Code 不直接讀 AGENTS.md，但可以@import進來。
這樣是工具自動載入、真正單一真相，不靠任何 tag 約定。這一段我在 Claude Code 與 Codex 共用專案規則 有更完整的拆解。
分工：不是誰比較強，是誰適合這一步
一個月觀察下來，我的實際分工是：
- Claude Code——規劃、多步推理、cross-cutting 的 design review、UI，偏「想清楚再動手」。
- Codex——執行力強、code edit 快、腳本批改、Windows 工作流（有些需求還是得在 Windows 上操作）。
但「誰上場」與其看誰強，不如看任務的權限、風險和工作介面來決定，這部分我另外寫過一篇 Claude Code 和 Codex 怎麼分工。
baton 規則：交接前先寫進檔案
跨 agent 接手前，先把「做到哪、下一步」寫進 markdown 留存，再對人類口頭補一句話交接。這條規則同時擋掉上面的「坑二」：因為每次交接都逼你更新停點，跨日、跨機器就不會 drift。
這裡也順手修掉一個我原本的自我矛盾：我除了 CURRENT_WORK.md，還手動維護一份超精簡的 CURRENT_WORK.codex.md——但這其實違反了「不要維護兩份重複資訊」的原則。後來我改成讓精簡版從主檔衍生（用腳本產，或用上面 AGENTS.md 的分層讓它自動精簡），而不是手動同步兩份。如果你也想給 Codex 一份更短的版本，記得讓它是「產物」不是「複本」。
三角 review：拉一個 fresh eye 進來
想比較同一個 task 兩家的差異，最簡單就是同題目同時丟、對比結果。
我做過更進一步的：在 design review 階段，刻意拉 Claude 網頁版當第三隻眼，去看 Claude Code + Codex 產出的架構。那次 Claude 網頁版抓出 8 條 cross-cutting 的結構性風險，是另外兩邊都沒看到的。原因不是它比較聰明，而是它的上下文是乾淨的、被迫重新建立假設——這跟交叉 review 有效的理由是同一個。關於「兩個 agent 互相 review 為什麼有效、又為什麼不是雙重保證」，我在 讓 Claude Code 和 Codex 互相 Review 講得更細。
一句話總結
把 source of truth 設計成跨對話、跨機器、跨 agent 都能 reload，上面那些 friction 就會自動少一大半。剩下的（merge conflict、停點鮮度）不會消失，但都有明確的處理方式。
Agent 不需要記得，讓檔案幫助它記得。
就跟我們人類一樣，大腦不是用來記得任何事，所以我們平常會寫筆記、螢幕旁也佈滿便條貼不是嗎? (笑)
