Agent 記性很差？ 如何讓不同電腦上的 Agent 進行 context 同步
本篇是「Codex 和 Claude Code 雙修」系列的第 7 / 7 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
這題我斷斷續續搞了一個月。一開始以為把檔案同步到另一台電腦就好了，後來才發現：程式碼到了，不代表新對話裡的 agent 知道上次做到哪。
所以我後來分開處理：先同步檔案，再想辦法讓 agent 讀到最新進度。
檔案同步：最簡單的那一半
程式碼和文件，我用現成工具同步。Google Drive、Dropbox 或 GitHub repo 都是可以考慮的做法，挑適合自己檔案類型的就好。麻煩的是接下來這件事。
上下文同步：你以為 Agent 很笨，其實是它每次重開機
Agent 本質上是 stateless 的。每開一個新對話，它都從零開始——這不是 bug，是設計。
你覺得它「笨」「記性差」，多半是因為每次都要把「上次做到哪、為什麼這樣決定、下一步是什麼」重新貼一遍。換一台電腦更慘，連要貼的素材都在另一台上。
我現在會把進度寫進 Markdown，讓新對話有資料可以接著看。檔案分成三層：
CURRENT_WORK.md（主入口）：只放 3–5 個 active 專案，每個 5–6 行，寫「停在哪 + 下一步」。刻意保持短，因為它每天都要讀。project_status_<專案>.md：單一專案的最新狀態，細節放這。handoff.md：只有大型專案才需要，記決策、風險、驗證細節這種「為什麼」的東西。
開新對話時我只要打一句「開工」，agent 自動把這三層讀進來，幾秒就接上狀態，不用再貼歷史。
整套設計不是把舊對話搬來搬去，而是讓每個新 session 都從同一份外部狀態重新載入：
flowchart TB
subgraph machines["不同電腦只負責同步檔案"]
A["電腦 A"]
B["電腦 B"]
end
R["Private Git repo<br/>跨機器的 source of truth"]
A <-->|"git pull / push"| R
B <-->|"git pull / push"| R
R --> C["CURRENT_WORK.md<br/>現在停在哪、下一步做什麼"]
C --> D["project_status_專案.md<br/>單一專案的最新細節"]
D --> E["handoff.md<br/>決策、風險、驗證證據"]
E --> F["Claude Code<br/>用 CLAUDE.md 的 @ import 載入"]
E --> G["Codex<br/>用 AGENTS.md / memory 載入"]
F --> H["新的 session 接續工作"]
G --> H
H --> I["收工或交接前<br/>更新停點與證據"]
I --> R
整個流程要做完才有用：同步 repo、讓 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，能少維護一支腳本就少一支。下次開對話，只要它讀到最新檔案，就有進度可以接。
用了一陣子後，遇到的兩個問題
坑一：merge conflict 是常態。 兩台電腦都在改同一份 CURRENT_WORK.md，又靠 git 同步，衝突遲早會來——尤其這份檔案每個 session 都在變。我的處理方式是：CURRENT_WORK.md 用「per-machine 區塊」分開寫，或乾脆接受偶爾手動 resolve；handoff.md 盡量 append-only（往下加、不改舊的），衝突機率就低很多。這部分還是得處理，不會因為用了 Git 就自動解決。
坑二：停點過期，比沒有記憶更糟。 如果你忘了更新停點，agent 會「很有信心地」進入一個錯誤的狀態——confidently wrong，比它老實說「我不知道」還危險。所以收工前要更新檔案，下面會說我怎麼安排交接。
Codex 和 Claude Code 怎麼協作
我在公司環境同時跑 Codex 和 Claude Code。我讓它們讀同一份進度檔，省得每改一件事，就要去另一個資料夾再補一次。
修正：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 留存，再對人類口頭補一句話交接。這條規則同時擋掉上面的「坑二」：每次交接都更新進度，可以減少隔天或換電腦後接錯工作的情況。
這裡也順手修掉一個我原本的自我矛盾：我除了 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 講得更細。
收工前，把進度留給下一次
現在換電腦或換 agent，我不用再翻整段對話找進度，先讀那幾份檔案就能接著做。Git 衝突還是偶爾要解，進度也得記得更新，但比每次重講一遍省事多了。
說起來，就跟我在螢幕旁貼便條紙差不多。怕下次忘記，先寫下來再收工。
