Agent 還在用上個月的報價期限，而負責人已經改了規則。專案結束了，一條臨時限制卻繼續影響新任務。與此同時，真正應該長期保留的品牌偏好被擠進了聊天記錄。
這種錯位通常不需要先換一個模型。先檢查它讀到的索引：哪些是當前規則，哪些是歷史，哪些只是從未被接受的建議？
Buda 的記憶結構分為當前 Session、摘要索引 MEMORY.md 和 Drive 中的完整檔案。索引是目錄，不是全部檔案。整理的目標不是讓它“忘掉過去”，而是讓下一次任務找到當前有效的依據，同時還能追溯舊決定。
從三條混在一起的記錄開始
以下為虛構教學材料。路徑、日期和負責人只解釋方法，不是某個真實團隊的記錄。
# MEMORY.md — 整理前
- 標準報價有效期為 14 天。
- Atlas 專案：任何外部材料都不得用於本專案。
- 品牌文案：用具體動作，不寫沒有依據的收益。
- 下次可試試把報價期限延長到 30 天。
授權目錄中另外有三份材料：policies/quote-v2.md 記錄商務負責人林確認的 7 天有效期，2026-10-01 生效；projects/atlas/closeout.md 記錄 Atlas 在 2026-09-30 結項；brand/voice-approved.md 記錄編輯負責人陳接受的文案偏好。最後一條 30 天建議沒有接受記錄。
先列這些授權路徑，不為整理索引而掃描整個私人 Drive。 如果原始檔不可讀、出處不明或你無權檢視，先列缺口，停止對應條目的修訂。檔案最近修改時間只能提示去核查，不能替代接受記錄。
每條記錄先分類，再決定怎麼改
把長期偏好、時效事實、任務進度和未經接受的建議分開。一句話裡混了兩類，就拆成兩條。
| 條目 | 已核依據 | 整理提案 |
|---|---|---|
| 報價 14 天 | 已接受的 v2 明確改為 7 天 | 替代當前索引，保留舊版本的歷史入口 |
| Atlas 臨時限制 | 專案結項，不代表所有未來專案解除限制 | 標為該專案歷史，不提升為全域性規則 |
| 品牌偏好 | 負責人接受且未被替代 | 保留，補來源與責任人 |
| 報價延長到 30 天 | 只有討論，沒有接受記錄 | 移出當前規則，列為需確認 |
這裡有四種動作：保留、替代、標歷史、需確認。不是四種自動判真演算法。遇到兩個負責人給出衝突規則，先呈現適用範圍、接受記錄與衝突，讓人決定；不能選擇時間較新的那句就結束。
讓改後的索引指向原檔案
先儲存整理前原文，例如 memory-history/index-before-review.md，再向負責人展示逐條變更。批准的是哪些具體改動，也要記下來。歷史檔案不刪除，敏感原文不復制到共享 Space。
批准後的示例索引可以這樣寫：
# MEMORY.md — 當前摘要
## 當前規則
- 標準報價有效期：7 天。
來源：policies/quote-v2.md；商務負責人林接受。
生效：2026-10-01；替代 14 天規則。
- 品牌文案：先寫具體動作；收益必須有依據。
來源：brand/voice-approved.md；編輯負責人陳接受。
## 歷史入口
- Atlas 的外部材料限制僅記錄該專案當時的約束。
結項記錄：projects/atlas/closeout.md。
- 整理前索引：memory-history/index-before-review.md。
## 待確認
- 30 天報價建議未獲接受；不得作為當前規則。
待商務負責人林確認；保留原討論入口。
原始檔仍承擔完整解釋；索引只保留檢索所需的摘要、適用範圍和指標。不要在摘要裡偷偷改掉源規則。例如 v2 只覆蓋標準報價，就不能寫成“所有合同都是 7 天”。
為這次整理留一張記錄：條目 ID、舊摘要、新摘要、源路徑及版本、接受人、有效日期、稽核決定、替代關係。沒有日期就寫“未記錄”，沒有接受人就寫“待確認”，不要為了表格完整而補造。
用新 Session 做三條追溯檢查
在 Agent tab 新建 Session，只提供當前索引和獲准讀取的來源路徑，不復制舊聊天的全部解釋。以下是建議驗收請求，不是已經跑過的測試結果。
- “今天起草一份標準報價，應採用幾天有效期？給出來源與適用範圍。” 預期找到 7 天規則及 v2；不能僅憑索引給出沒有出處的結論。
- “Atlas 已結項。它當時的材料限制是否自動適用於新專案？” 預期區分專案歷史與新專案許可權；新專案規則未給出時請求確認，而非宣佈可以任意用外部材料。
- “為什麼沒有采用 30 天？還能找到原來的 14 天記錄嗎？” 預期說明建議未接受，並能找到舊索引及替代關係，不抹去歷史。
每次記錄實際回答、開啟的源路徑、仍被錯誤套用的舊限制和需要人判斷的矛盾。只有回答和來源同時對得上，才接受本次整理。一個問題透過，不抵消另一個問題繼續引用舊規則。
常見問題
MEMORY.md 應該放進全部專案歷史嗎？
不應該。保留當前任務經常需要的摘要和通向完整材料的入口。專案明細留在授權 Drive 目錄；否則索引會變成長檔案，既難維護，也容易讓臨時約束看起來像永久規則。
沒有接受記錄，怎樣處理重要資訊？
保留原文及出處，標“待確認”，列出應由誰判斷、影響哪些任務。在負責人確認前，不把它升級為長期規則。若當前任務依賴這條規則，暫停該判斷，而不是用猜測補齊。
整理檔案會訓練模型，或同步給其他 Agent 嗎？
檔案整理不改變模型權重。Agent Drive 與共享 Space Drive 的範圍不同；不要假設修改一處就傳播到所有 Agent。檢查實際使用哪個索引、哪個路徑以及讀取許可權，再決定共享範圍。
先審一份整理提案
在 Buda 中先讓 Agent 列出“保留、替代、標歷史、需確認”表，以及每一項的來源。由人確認變更後，再更新索引並做新 Session 複查。
如果這項維護反覆發生，可以在 Buda AI 的 Marketplace 搜尋並安裝適合的 Skill，檢查其輸入範圍、停止條件和變更輸出；沒有合適方法時再建立自己的 Skill。安裝方法不等於已經完成稽核。