# 工程上下文已經留在 GitHub，Agent 還需要獨立記憶嗎？Beacon 與 Checkpoint 實測

> Canonical: https://vxi.me/zh-tw/posts/beacon-local-memory-capture-causality/
> Locale: zh-tw
> Published: 2026-10-27
> Updated: 2026-10-27
> Markdown: https://vxi.me/zh-tw/posts/beacon-local-memory-capture-causality.md

<figure class="agent-memory-cross-harness-hero not-prose" lang="zh-tw">
<picture><source media="(prefers-reduced-motion: reduce) and (max-width: 640px)" srcset="/images/posts/agent-memory-cross-harness-beacon/agent-memory-counterexample.mobile.still.zh-tw.svg" type="image/svg+xml"><source media="(prefers-reduced-motion: reduce)" srcset="/images/posts/agent-memory-cross-harness-beacon/agent-memory-counterexample.still.zh-tw.svg" type="image/svg+xml"><source media="(max-width: 640px)" srcset="/images/posts/agent-memory-cross-harness-beacon/agent-memory-counterexample.mobile.zh-tw.svg" type="image/svg+xml"><img src="/images/posts/agent-memory-cross-harness-beacon/agent-memory-counterexample.zh-tw.svg" alt="Antigravity 無記憶組與 MCP 記憶組的公開 CSV 測試皆為 3/3 PASS，但兩組獨立隱藏檢查皆 FAIL。記憶正文涵蓋 CSV 與 TSV，適用範圍卻只標示 TSV；這是候選解釋，不是已確認根因。" width="1200" height="700" loading="eager" fetchpriority="high" decoding="async" style="display:block;width:100%;height:auto"></picture>
<figcaption style="font-size:0.8rem;line-height:1.5;opacity:.78;margin-top:.35rem">兩組公開測試都通過，獨立隱藏檢查卻都失敗；適用範圍不一致是可能解釋，並非已證實根因。</figcaption>
</figure>

系列前兩篇分別討論 [GitHub-first 的跨工具交接](https://vxi.me/posts/github-first-ai-coding-context-handoff-workflow/) 與 [Local-first、GitHub-first 的資料及執行邊界](https://vxi.me/posts/local-first-vs-github-first-architecture/)。接下來要問的是：當工程上下文已留在儲存庫，額外的 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](https://github.com/Asymptote-Labs/agent-beacon/tree/d7a3a72fdc0a864655cf2e85fb7de5ba974cde72)。[脫敏程式](https://github.com/Asymptote-Labs/agent-beacon/blob/d7a3a72fdc0a864655cf2e85fb7de5ba974cde72/pkg/asymptoteobserve/privacy.go#L322-L395)依賴欄位名稱和已知模式，並不是通用的自然語言秘密辨識器。固定版本的 Codex 擷取矩陣與 OTLP 轉換程式沒有顯示 Codex File/MCP 事件的對應映射；這是源碼檢查，不是執行期封包擷取。Jev 評估器也只做了源碼核查，從未真正執行，因此沒有評分或蒸餾精度數據。

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

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

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

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