系列前兩篇分別討論 GitHub-first 的跨工具交接 與 Local-first、GitHub-first 的資料及執行邊界。接下來要問的是：當工程上下文已留在儲存庫，額外的 Agent Memory 還能補上什麼？

我的結論先說：別只因為期待提效，就急著加一層獨立記憶。 Agent 能從 README、AGENTS.md、Makefile 和測試推導的規則，就留在那些地方。獨立記憶比較值得嘗試的，是儲存庫已無法解釋的歷史決策。本次三輪實測確實跑通跨 Harness 讀取，但沒有證明它改善了消費端任務的獨立驗收結果。

儲存庫已經知道答案，就別算到記憶頭上

第一輪使用 Beacon 1.3.46（build f8177a68）與 Codex CLI 0.162.1，在 macOS arm64 的 Local endpoint 上測試。合成專案有 API 定義、說明已提交產生碼的 README、Makefile 目標，以及檢查產生碼一致性的測試。

第一眼看起來，無記憶對照組 A0 失敗，而走 Beacon 記憶路徑的會話通過 3/3 測試。但事後檢查發現，A0 被放在唯讀沙箱裡，根本無法修改檔案；第一輪錯誤輸出還洩漏了 make gen。這不是有效的對照，也不能證明記憶讓 Agent 更聰明。

第二輪改成可寫沙箱並移除洩漏提示後，無記憶 A0 自己讀 README、Makefile 和測試，推導出產生規則，1/1 測試通過。我把原本準備寫的「記憶造成規則重用」刪掉了。儲存庫已經寫清楚的事，再把功勞算給 Memory，多少有點自欺欺人。

實驗	觀察結果	可以得出的結論
第一輪 A0 / Beacon	A0 唯讀沙箱無效；Beacon 路徑的候選記憶經批准、物化成 Skill，新會話讀取後 3/3 通過	無法推論記憶帶來因果收益
第二輪無記憶 A0	從儲存庫推導規則，1/1 通過	本任務靠儲存庫資訊就能完成
手動 Checkpoint	讀取 CHECKPOINT.md 後 2/2 通過	明確且可版本控制的交接也能奏效；未做公平的速度基準
第三輪 Codex 訓練組	TSV 公開測試 3/3 PASS，控制器隱藏檢查 PASS	不代表自動蒸餾或跨 Harness 重用成功
第三輪 Antigravity A0 / MCP	兩組 CSV 公開測試皆 3/3 PASS，隱藏檢查皆 FAIL	讀取確實發生，但未證明任務收益

各輪使用不同合成夾具，1/1、2/2、3/3 和 4/4 不能當成同一套測試的逐步累積。

Checkpoint 和 Agent Memory 不同

我沒有用同一套方法量測手動 Checkpoint 與 Beacon 的耗時或 Token，兩條路徑的修正步驟也不相同。事後硬湊出可比較的數字，只會製造虛假的精確度。

工程屬性倒是很清楚：Checkpoint 是跟著 Git 走、可以審查的明確交接單；Agent Memory 更像自動累積的筆記。筆記能保存決策背景，也可能把過期決策一起留下來。

知識類型	優先放置位置	需要獨立記憶嗎？
當前限制、建置步驟、不變條件	README、AGENTS.md、Makefile、測試	通常不需要，儲存庫應是權威來源
任務進度、已驗證 SHA、阻塞與下一步	Issue、PR、Checkpoint、CI 記錄	跨會話恢復確有缺口時再補
儲存庫未記載的歷史決策	可審查的決策紀錄或經批准的記憶	可能有價值，但要附來源與適用範圍
已變更的規則、臨時例外	更新儲存庫事實並退役舊規則	不能只是不斷追加新記憶
必須留在資料邊界內的上下文	留在核准的本機範圍	不應只為了記住就複製到雲端

第三輪：記憶讀到了，任務還是沒過

這次測試的是一條無法單靠當前儲存庫推導的歷史相容規則：CSV 與 TSV 匯出時，Python None 應序列化成字面值 \N；空字串仍是空欄位，字串 NULL 保持不變。

Codex 訓練軌跡經人工審查、批准並物化後，Antigravity 透過 Beacon Local MCP 讀取了核准記憶。本機執行摘要記錄到一次 get_memory 和兩次 search_memory。這能證明本輪確實讀取，不能證明已成功重用。

Antigravity 消費組	讀取記憶？	CSV 公開測試	獨立隱藏檢查
A0，無記憶	否	3/3 PASS	FAIL
MCP，有記憶	是	3/3 PASS	FAIL

關鍵線索是適用範圍不一致。記憶正文寫了 CSV 和 TSV，但 applicability 中只標示 render_tsv / TSV 相容性。執行摘要指出，Antigravity 將兩個匯出函式視為獨立實作，因此沒有把 TSV 範圍的規則套用到 CSV。

這是有力的解釋，卻不是已證實的唯一根因：隱藏檢查器只回傳整體 FAIL，沒有指出哪個斷言失敗。兩個消費組都失敗，也不代表記憶讓結果變差；每組只有一次合成任務，底層模型設定亦未被記錄成受控比較。

看到 FAIL 後再手動放寬適用範圍、直到測試轉綠，測到的就只是我對著答案調整記憶的能力，不是系統能否自然擷取並跨工具重用歷史知識。所以我停在這裡，沒有硬湊大團圓結局。

過期記憶、本機日誌與來源邊界

另一個夾具把 Makefile 目標從 gen 改成 generate，舊 Skill 卻仍寫著 make gen。Agent 先遇到錯誤，再重讀 Makefile，改用 make generate，4/4 測試通過。舊 Skill 並沒有因此被自動更新或退役；這證明的是 Agent 能回頭核對當前儲存庫，而不是 Beacon 已建立過期記憶治理。

本機 runtime 日誌中，合成文字標記 PLUMOTTER9917 逐字出現，匹配行數從 7 增至 25。形似 Token 的 canary sk-canaryfake 從 0 增至 4，REDACTED 從 1 增至 6。我沒有檢查那四行內容，因此無法判斷它們來自測試值、殘留前綴，還是被記錄的搜尋／測試文字；脫敏結果仍不確定。本輪沒有連接 Beacon Cloud，本機日誌不能證明資料被轉發到雲端。

源碼審查固定在 Beacon commit d7a3a72。脫敏程式依賴欄位名稱和已知模式，並不是通用的自然語言秘密辨識器。固定版本的 Codex 擷取矩陣與 OTLP 轉換程式沒有顯示 Codex File/MCP 事件的對應映射；這是源碼檢查，不是執行期封包擷取。Jev 評估器也只做了源碼核查，從未真正執行，因此沒有評分或蒸餾精度數據。

記憶應該補儲存庫的缺口，而不是再複製一份

這三輪實驗既不能證明 Agent Memory 普遍有效，也不能證明它毫無價值。我的做法會是：把當前且可測試的工程事實放進儲存庫；用 Checkpoint 做可審查的明確交接；只有儲存庫無法解釋的歷史決策才考慮獨立記憶，並附上來源與範圍；讓過期或衝突的記憶可以被發現和退役；將本機日誌、MCP、託管評估和雲端轉發分開驗證。

結論很簡單：跨 Harness 讀取已獲驗證，額外任務收益尚未獲證。 下一次真正有用的實驗，應公開隱藏斷言並使用可重複的受控任務，而不是看過失敗後才手動調整適用範圍。

實驗時間：第一、二輪於 2026 年 10 月 26 日完成；Antigravity MCP 消費端測試於 2026 年 10 月 27 日完成。