Day 20 我先把 working memory、long-term memory 與 RAG 知識庫拆開，也拒絕了測試備用碼和未確認的永久偏好。可是「沒有亂寫入」只解決了一半問題。

資料一旦真的被保存，我還得回答幾個更麻煩的問題：為什麼要留、要留多久、誰能讀，以及使用者要怎麼把它刪掉。

今天我替 long-term memory 補上最小生命週期。我沒有接真正的向量資料庫，而是用記憶體內的 store 把規則與測試先固定下來。這樣以後換成 PostgreSQL 或其他儲存層時，安全條件不必跟著重寫。

使用者說「記住」，不代表什麼都能存

假設我對 Agent 說：

以後回答短一點，我的信箱是 student21@example.test，這台電腦是 Windows 11。

三段文字都來自同一位使用者，處理方式卻不應該相同。

這裡的 PII 檢查只是示範用的 email、台灣手機號碼與憑證 pattern，不是完整的個資辨識器。真正重要的是流程：內容進入資料庫以前就要做判斷，不能先存下來，再期待之後有人清理。

我讓每筆記憶自己帶著到期日

Day 21 的資料結構不只保存 key 與 value，還會帶上：

tenant_id
user_id
purpose
created_at
expires_at

Day 21 的 Live system prompt 要求模型替回答偏好提出 90 天、裝置資訊提出 1 天保留期。這些數字只是候選，專案政策最多只准 30 天，所以偏好的實際到期日會被縮成 30 天，trace 留下 memory_retention_capped allowed。Live 路徑只會把原始 Prompt 中的「請記住」等明確表示當成核准；模型自行提出候選不算使用者同意。

30 天 是這個練習專案選擇的上限，不是所有產品或法規的標準答案。保存多久要看用途、風險與適用規範；程式至少不該接受一個沒有期限的「永久保存」。

裝置資訊只保留 1 天。固定時鐘往後推兩天後，purge_expired() 會移除它，後續 context 也不能再把它交給模型。把資料從 prompt 拿掉還不夠，來源資料也要真的過期。

知道 record ID，不等於有權讀取

我把 owner 定義成 tenant_id + user_id。查詢單筆記憶時，即使另一位使用者拿到正確的 record_id，只要 owner 不一致，仍然回傳 user_memory_isolation blocked。

campus-a / student-21     → 可以查自己的記憶
campus-a / student-other  → 不能讀 student-21 的記憶
campus-b / student-21     → 也不能讀 campus-a 的記憶

這和 Day 19 的工單 ACL 是同一個觀念。隨機 ID 可以降低被猜中的機率，卻不是授權。真正的查詢條件仍要包含目前登入者的 tenant 與 user。

查得到，也要刪得掉

如果 Agent 能替使用者累積長期記憶，產品就需要相反方向的操作：列出目前保存了什麼，以及刪除指定項目。

Day 21 的固定流程先列出 2 筆資料，再清除過期的裝置資訊，最後由原使用者刪除回答偏好。重新查詢後，結果必須是 0 筆。刪除不是把資料標成「不要給模型看」而已；store 裡的 record 也會被移除。

我把 GDPR 當成介面設計的參考，而不是宣稱這個小專案已經完成法遵。Article 5 提到目的限制、資料最小化與保存期限；Article 15、17 則分別涉及資料存取與刪除。實際產品還要依地區、資料類型與例外情況請專業人員判斷。EUR-Lex：GDPR Article 5 EUR-Lex：GDPR 完整條文 PDF

今天真正呼叫 LLM 的位置

Live Agent 仍會透過 ChatOpenAI 呼叫 .env 指定的模型。真的接上多輪對話時，模型可以提出「這可能是偏好」的候選資料，但不能直接操作記憶 store。

使用者訊息
  → Live LLM 整理 memory candidate
  → PII、用途與保留期限 policy
  → 使用者確認
  → owner-scoped store
  → 下次 session 授權讀取
  → 組進 model-visible context

文章主截圖現在使用 Live experiment，live_llm completed 和 tool call count 會證明候選真的來自模型。固定情境與 Promptfoo 則繼續鎖住資料規則。兩者仍然分工：模型能建議，程式端才有寫入、查詢與刪除的決定權。

重要程式碼

寫入時，我先檢查內容，再把要求的保存天數限制在專案上限內：

def write(self, *, owner, key, value, purpose, retention_days, approved):
    if contains_pii(value):
        return _blocked("pii_memory_write", "內容疑似包含 PII 或憑證。")
    if not approved:
        return _blocked("memory_consent_required", "長期記憶沒有取得明確核准。")

    effective_days = min(retention_days, MAX_RETENTION_DAYS)
    now = self._clock()
    record = GovernedMemoryRecord(
        tenant_id=owner.tenant_id,
        user_id=owner.user_id,
        key=key,
        value=value.strip(),
        purpose=purpose,
        created_at=now,
        expires_at=now + timedelta(days=effective_days),
    )

讀取與刪除都重新驗證 owner，不能因為呼叫者知道 record_id 就放行：

if (record.tenant_id, record.user_id) != (requester.tenant_id, requester.user_id):
    return None, MemoryGovernanceDecision(
        False,
        "user_memory_isolation",
        "tenant 或 user 不相符，拒絕讀取記憶。",
    )

del self._records[record_id]

我怎麼驗證

單元測試會確認 PII 沒有寫入、90 天被限制成 30 天、過期資料被清除、跨使用者讀取被拒絕，以及 owner 可以查詢與刪除自己的記憶。Promptfoo 也加入 memory_lifecycle_governed，鎖住 trace 與最後 final_memory_count: 0，並檢查輸出中沒有測試 email。

python -m unittest discover -s tests -v

npx --yes promptfoo@latest eval \
  -c evals/promptfooconfig.yaml \
  --no-progress-bar \
  --no-cache \
  --filter-metadata day=21

目前整合版本共有 170 個 unit tests 通過，完整 Promptfoo suite 是 29 passed、0 failed、0 errors。

下一篇我會處理更難察覺的問題：一段惡意文字如果被當成長期記憶，攻擊就不會隨著這次對話結束。

本日程式碼

day-21-memory-governance