一個沒有人答得出來的問題
問一個運行長期 AI agent 的團隊一個簡單的問題：它記得你公司的哪些事情？這些記憶是什麼時候改變的？
大多數團隊答不出來。在目前的技術堆疊中，agent 記憶是「寫入為主、讀取不透明」的。事實從各個工作階段不斷累積，由 agent 自己摘要整理，然後悄悄影響 agent 之後做的每一個決定。當 agent 在第三個月開始出現不同的行為時，沒有任何紀錄能告訴你是哪一條被記住的「事實」變了、什麼時候變的、又是什麼改變了它。
對個人助理來說，這只是個小怪癖。但對一個負責草擬客戶訊息、安排工作或餵送審批佇列的 agent 而言，這是一個治理缺口：agent 的記憶是每一個受治理輸出背後未經稽核的輸入。
記憶整理已成原生功能，治理卻還沒有
Agent 平台在這方面進展飛快。排程式記憶整理——一個背景程序，讀取記憶儲存區和近期的工作階段歷史，然後重寫記憶以合併重複項目、刪除過時條目、彙整模式——如今已是前沿技術堆疊的原生能力。它確實有用：未經整理的記憶會劣化，一個要在六個月互相矛盾的筆記上推理的 agent，表現必然比擁有乾淨記憶庫的 agent 差。
但原生的整理功能是一個黑盒子。整理器讀取所有內容，重寫它認定過時的部分，卻不留下任何可審閱的編輯紀錄。從治理的角度來看，這是一個無人看管、卻擁有寫入權限的程序，而它寫入的正是你所有其他控制機制的輸入層。
受治理的記憶整理長什麼樣子
我們本週為 JieGou 代管 agent 推出了排程式記憶整理——建立在原生能力之上，並包覆了原生功能所欠缺的治理層：
- 受保護的命名空間。 記憶儲存區的部分區域對整理器完全禁止存取。營運狀態、跨 agent 共享情境、以及對話串層級的紀錄，都不能被整理流程重寫——無論模型多麼確信它們已經「過時」。
- 每個週期的硬性上限。 每次整理都有邊界：總操作次數有固定上限，刪除次數的上限更低。不存在任何一種情境，會讓一次失控的週期在一夜之間改寫 agent 的整個世界觀。大規模變更需要許多個週期，也就意味著許多次審閱的機會。
- 乾跑預覽。 整理週期可以在預覽模式下執行，產出完整的變更提案，但不實際套用任何一項。新部署會一直以乾跑模式運行，直到操作者看過幾個週期的判斷品質為止。
- 可稽核的差異記錄。 每一項實際套用的變更都會被記錄為可審閱的差異：合併了什麼、取代了什麼、刪除了什麼，以及哪些工作階段促成了這次變更。本文開頭的那個問題——它記得什麼？什麼時候改變的？——在任何時間點都有具體的答案。
同一個版本還加入了雙軌成果評分：在 agent 工作階段內產出的工作，由原生評分器在階段內評分；在階段外產出的草稿，則走我們的評審通道。每一份 agent 的工作成果都會得到評分；記憶整理與成果證據落在同一套稽核體系之中。
為什麼這件事的意義超越功能本身
這裡有一個值得點名的模式。隨著 agent 平台日趨成熟，過去屬於整合者工作範圍的能力——記憶、評分、排程——正在變成原生基本元件。這是好事。模型層及其基本元件正在成為大宗商品化的基礎設施。
不會大宗商品化的，是治理外殼：範圍限定、上限、審批關卡、可重播的紀錄。原生記憶整理只會讓一個不受治理的 agent 更擅長不受治理。對任何讓 agent 接觸真實客戶資料的團隊來說，真正的營運問題不是該不該使用原生基本元件——該用，就用——而是每一個會寫入 agent 狀態的基本元件，是否都留下了稽核員、保險核保人、或未來的你自己能夠審閱的證據。
只透過有上限、有差異記錄、可重播的操作來改變的記憶，就是我們的答案。如果你目前的 agent 堆疊無法給你一份「上個月記得的內容 vs. 今天記得的內容」的差異報告，那麼最好在這些記憶變得舉足輕重之前，先把這件事修好。