此为历史版本和 IPFS 入口查阅区，回到作品页
Ryan Vale
IPFS 指纹 这是什么
作品指纹

AI agent 有記憶之後，團隊要先決定哪些事可以被記住

Ryan Vale
·
·
以前聽到「AI 記住我的偏好」，我大多會把它當成貼心功能。例如我不喜歡某種測試寫法、專案習慣用某個命名方式、PR 說明要照固定格式。這些事每次都重新講，確實很煩。如果工具可以記住，少一點重複溝通，聽起來很合理。

以前聽到「AI 記住我的偏好」，我大多會把它當成貼心功能。

例如我不喜歡某種測試寫法、專案習慣用某個命名方式、PR 說明要照固定格式。這些事每次都重新講，確實很煩。如果工具可以記住，少一點重複溝通，聽起來很合理。

但 coding agent 的記憶一旦進到 repo、CLI、團隊協作裡，事情就變得不太一樣。

它不再只是「我的助理比較懂我」。它會開始影響下一次修 bug 時 agent 怎麼判斷架構，下一次補測試時它以為哪些檔案不能碰，下一次重構時它會把哪一段過去的決策當成前提。

這時候，記憶就不是便利功能而已。它比較像一種會自動被帶進工作的文件，而且不一定每個人都看得見。

個人偏好和 repo 事實不能混在一起

GitHub 最近更新 Copilot Memory 的控制方式，其中一個值得注意的地方，是它更明確區分 user-level preference 和 repository-level fact。

這個區分很重要。

「我喜歡 PR summary 先寫風險」是個人偏好。「這個 repo 的部署流程不能跳過 migration check」是團隊事實。前者錯了，通常只是使用者自己覺得不順；後者錯了，可能會讓整個團隊之後都被錯誤前提拖著走。

小團隊最容易忽略這件事，因為大家平常靠默契在工作。兩三個人都知道的規則，常常不會被正式寫下來。以前這只是溝通成本問題；現在如果 agent 也參與開發，這些口頭默契可能會被寫進 memory、repo instruction 或某個看起來像設定檔的地方。

那就要問清楚：這句話到底是誰的偏好，還是專案規則？

如果是偏好，它不應該強迫整個團隊。如果是專案規則，它就不該只存在某個人的聊天記錄裡。

repo instructions 是文件，不是聊天備忘錄

現在很多 agent 工具都開始支援 repository custom instructions、`AGENTS.md`、path-specific instructions 這類機制。這其實是好事，因為它把一部分「agent 應該知道什麼」搬到可以被版本控制、可以被 review 的地方。

但它也帶來一個很現實的問題：團隊會不會把這些檔案當成正式文件來管理？

如果 `AGENTS.md` 裡寫著「修改 billing 相關程式碼時一定要補 integration test」，那它其實跟工程規範沒有差太多。它會影響工具行為，也會影響人怎麼驗收 agent 產出的 diff。

這種東西不應該是誰順手加一句就算數。

比較好的做法，是把 agent instructions 當成 repo 裡的一級文件。修改它要走 code review。內容要盡量穩定、具體、可驗證。不要把還在討論中的產品方向、某個人的臨時喜好，或「上次好像是這樣做」這種半熟結論寫進去。

我會把它想成給 agent 看的 README，但責任仍然在人身上。它不是讓團隊逃避文件工作的捷徑，而是讓文件工作的成本更有回報。

關掉記憶，不等於清掉記憶

GitHub 這次更新裡，repo admin 可以在 repository level 停用 memory。這聽起來像一個簡單的開關，但它提醒了另一件事：停用和刪除不是同一件事。

某些既有 facts 可能不會因為你關掉新記憶就自動消失。這很合理，因為產品在資料保留、使用者控制、範圍切換上通常要拆開處理。但對團隊來說，這代表你不能只問「能不能關掉」，還要問「以前記住的東西在哪裡、誰能看到、怎麼刪」。

這一點在小團隊更容易被低估。

大家常常覺得自己沒有企業那種治理需求，所以不用弄得太正式。可是 stale memory 不會因為團隊小就比較不危險。它的麻煩之處，是它不一定會讓工具立刻壞掉。

它可能只是讓 agent 繼續使用舊的資料夾結構。

它可能只是讓 agent 以為某個 package 還在用。

它可能只是讓 agent 每次都避開一個其實已經可以修改的模組。

這些錯誤不會像測試失敗那樣醒目。它們會慢慢變成「為什麼 agent 每次都往奇怪方向走」的背景噪音。

所以刪除流程要先設計，而不是出事後才找。至少要知道記憶在哪裡列出、誰有權限刪、什麼時候要清、清完之後怎麼確認 agent 不再使用舊前提。

有些東西一開始就不該被記住

記憶治理最難的地方，不是把所有東西分類得很漂亮。真正難的是承認：有些資訊根本不該進入 agent memory。

客戶名稱、內部成本、臨時 token、還沒公開的商業計畫、某個人的工作習慣、還沒被團隊確認的架構方向，這些都不適合被寫成長期上下文。

有人可能會說，agent 本來就會在工作時看到一部分資訊，記住或不記住差別有那麼大嗎？

差別在時間。

短期上下文是這次任務需要它知道。長期記憶是未來任務也會被它帶著走。兩者的風險完全不同。

我比較喜歡用一個簡單標準判斷：如果這句話被一個新同事下個月拿來當正式規則，你會不會覺得合理？

如果不合理，就不要放進 repo memory 或團隊 instruction。它可能只適合留在 issue、PR discussion、任務描述，甚至根本不該交給 agent。

memory policy 應該跟 sandbox 放在同一張檢查表

談 agent 安全時，大家比較容易注意到 sandbox、network、approval、credentials。這些當然重要。OpenAI 和 Anthropic 最近都把 agent 的執行邊界講得很清楚：工具能寫哪裡、能不能連網、哪些動作需要人確認、log 能不能追到原因，這些會決定 agent 能不能被信任。

但 memory 其實也在同一張圖上。

因為它決定 agent 之後會帶著哪些前提工作。

權限限制的是 agent 能做什麼。記憶影響的是 agent 以為自己應該怎麼做。前者比較像門鎖，後者比較像工作手冊。只管門鎖、不管手冊，仍然會出問題。

小團隊不用把這件事做成很重的制度。可以從幾條低成本規則開始：

  • 只有穩定、已經被團隊同意的慣例，才放進 repo instructions

  • 所有 instruction 變更都走 code review

  • 個人偏好留在 user-level，不要冒充專案規則

  • 每個月固定清一次 agent memory 和 instructions

  • 敏感資料只放在正式 secret 或權限系統裡，不寫進長期記憶

  • 對重要任務，要求 agent 在 summary 裡列出它依賴了哪些 repo 規則或假設

這些做法不華麗，但很實用。它們的目的不是讓 agent 變得保守，而是讓團隊知道它的上下文從哪裡來。

可管理的記憶才是效率

我不覺得 agent memory 是壞事。相反，它可能是 coding agent 真正變好用的關鍵之一。

沒有記憶的 agent 很容易像每次都重新入職。你要一直提醒它專案怎麼跑、測試怎麼下、哪些檔案不能碰、哪種改法以前踩過雷。這很浪費。

但有記憶的 agent 也可能像一個很有自信的老員工，腦中裝著一堆過時規則，還不一定會告訴你它是從哪裡學來的。

真正好的狀態，不是讓 AI 神祕地「自己都知道」。那很省事，也很危險。

比較值得追求的狀態，是讓團隊可以看見它知道什麼、討論哪些事該留下、刪掉哪些過時內容，並且把團隊級規則放到能 review 的地方。

agent memory 最後會不會變成效率，不取決於它記得多不多。

取決於它記住的東西，團隊能不能管理。

不可管理的記憶只是另一種技術債。而且很麻煩的是，它會在每一次看似正常的 agent 回答裡，慢慢收利息。

Source notes

CC BY-NC-ND 4.0 授权