GitHub 在 2026 年 5 月 26 日更新 Copilot Memory，重點是把 AI 記憶從「方便功能」推向「需要被管理的企業能力」。Copilot Memory 仍屬 public preview，並向所有付費 Copilot plan 開放，但今次新增的控制項已經很接近企業落地時真正會遇到的問題。
第一個改動是刪除指引更清楚。當使用者要求 Copilot 忘記某些內容時，系統會指向正確位置讓使用者移除該項 memory，並在可投票的位置下調相關 memory。這看似細節，但對 AI 使用者信任很重要：如果系統會記住偏好或 repo 事實，使用者必須知道如何查看和移除。
第二個改動是 repository-level off switch。repository admins 現在可以在既有 Copilot feature controls 中關閉某個 repo 的 Copilot Memory。關閉後，repo-level facts 不會再被儲存或讀取；不過 GitHub 亦說明，既有 facts 不會因此自動刪除，而 user-level preferences 亦不受影響。
第三個改動是 Copilot CLI 加入 /memory 指令。使用者可以透過 /memory on 啟用、/memory off 關閉，或 /memory show 查看目前狀態，而且選擇會跨 session 保留。這對開發者工作流很實際，因為 AI agent 越來越常在 terminal 和 IDE 之間切換。
第四個值得留意的地方，是 capture time 的 scope 提示更明確。store_memory permission prompt 會說明即將儲存的是 user-level preference，還是 repository-level fact。前者只對個人跨 repo session 可見，後者則可被同一 repository 的 contributors 使用。這個邊界很關鍵，因為個人習慣和團隊事實的治理方式不應混在一起。
AI agent 要真正進入團隊工作，記憶能力幾乎不可避免。沒有記憶，agent 每次都要重新理解 repo 習慣、架構、風格和流程；但有記憶，就會帶來資料保留、權限、錯誤記憶、跨人共享和刪除責任。GitHub 今次的更新，正是在補這條治理鏈。
對企業採用 AI 編碼工具來說，這條新聞的訊號很清楚：未來要管理的不只是 prompt、模型和工具權限，還包括 AI 記住了甚麼、由誰批准、在哪個範圍可見、何時可以關閉，以及如何刪除。AI 記憶會由使用體驗功能，逐步變成合規與營運管理的一部分。
