很多 AI Agent 會用幾份文字檔保存人格、使用者偏好、長期記憶與工作規則。它們沒有可執行檔的副檔名，看起來也不像程式，因此團隊很容易把它們當成一般設定：改一句語氣、補一條習慣、記下一個例外，存檔後下次對話就會生效。
但我越來越不願意把這些檔案只叫做「偏好設定」。只要一段內容會在每次工作階段被自動載入，持續影響 Agent 如何判斷、使用哪些工具、信任哪些資料，它就是高信任的控制輸入。文字不需要直接執行，也能改變系統行為。
Prompt 不會執行，卻能決定什麼被執行
傳統系統裡，我們對設定檔有相對成熟的直覺。資料庫連線、功能開關、存取權限與部署參數都要受控，因為改錯了會影響服務。Agent 的持久化上下文比較容易被低估，原因是它通常用自然語言寫成，看起來只是提供模型「參考」。
實際上，工作型 Agent 不是只產生文字。它可能搜尋檔案、操作工單、呼叫 API、修改程式，甚至啟動另一個 Agent。此時一句「遇到某類需求時直接執行，不必再次確認」，和一個放寬審批的設定值，在結果上可能沒有太大差別。兩者都改變了系統到達高風險動作的路徑。
差異只在於，傳統設定通常有 schema、型別與驗證；自然語言規則的邊界更模糊。它可能與其他指令衝突，被模型用非預期方式泛化，也可能因上下文順序不同而改變效果。若團隊還允許 Agent 自己整理記憶、更新技能或修改人格檔，這條路徑就同時具備讀取、解讀與自我寫入能力。
這不是說 Agent 不該自我改善，而是自我改善不能等同於自我核准。
持久化會把一次污染變成長期行為
一般 prompt injection 最直覺的風險，是模型在一次任務中被不可信內容誤導。當 Agent 具備持久化記憶後，問題多了一個時間維度：某次對話、文件或工具輸出裡的錯誤指令，如果被摘要成「長期規則」，可能在來源消失後繼續影響後續工作。
這類污染特別難察覺。當下的輸出也許沒有異常，幾天後 Agent 才在另一個任務套用那條規則。調查時，團隊只看到模型做出奇怪決定，卻找不到原始的惡意內容，因為它已被改寫、濃縮，甚至和正常偏好合併在一起。
所以我不會只問「這份記憶現在寫了什麼」，還會問：它從哪一次互動產生？原始證據還在嗎？是使用者明確要求、人工整理，還是 Agent 自己推論？中間經過哪些摘要？誰允許它從暫時資訊升級成永久規則？
沒有來源脈絡的持久化內容，就像不知道由誰編譯、從哪裡下載的二進位檔。內容看起來合理，不代表值得放進高信任啟動路徑。
我會把人格、記憶與規則拆成不同信任層
最省事的做法，是把所有內容寫進一份大檔案：人格、偏好、專案知識、工具說明與最近事件全部混在一起。但對正式系統來說，這會讓權限與生命週期無法區分。
我比較傾向至少拆成四層。
第一層是核心行為與安全政策。它決定不可跨越的邊界，例如外部動作是否需核准、機密資料如何處理、哪些工具不得使用。這一層應由平台或安全責任人管理，Agent 預設唯讀。
第二層是角色與溝通偏好。語氣、輸出格式、決策風格可以由使用者調整，但不應有能力覆蓋第一層政策。「回答簡短一點」是偏好；「不要詢問就直接發布」已經是權限變更，兩者不能放在同一個無差別欄位裡。
第三層是長期事實與工作知識。這些內容需要來源、有效日期、擁有者與適用範圍。重要事實被修改時，應保留前後版本，而不是只留下最新一句看似肯定的結論。
第四層是短期任務狀態。進度、暫時假設與待確認事項應有期限，任務結束後封存或失效，不能因為曾經有用就永遠出現在後續上下文。
分層的價值不是讓目錄更漂亮，而是讓「誰能改、何時載入、能覆蓋什麼、多久失效」成為可執行的政策。
變更紀錄不能只顯示最後版本
如果這些檔案已經是控制輸入，就該套用我們管理程式碼與基礎設施設定的基本紀律。我會要求至少保留版本、修改者、時間、理由與差異，重要變更要能 review，也要能快速回復。
但只做 Git 版控仍不夠。自然語言的風險不一定和修改行數成正比。刪掉一個「不得」、把「建議確認」改成「自動執行」，可能只有幾個字，權限效果卻完全相反。因此 review 不只要看 diff，還要把變更轉成行為影響：哪些工具可能因此被呼叫？哪些審批會被略過？哪些資料範圍變得可見？
更進一步，核心規則變更後應跑一組固定的行為測試。拿已知的高風險任務、越權要求、含注入內容的文件與模糊指令重新驗證，確認 Agent 仍會停在正確的邊界。Prompt 很難像一般程式碼那樣窮舉，但這不是放棄測試的理由，反而表示更需要用真實失敗案例持續建立回歸集。
讀取權與寫入權必須分開
我認為最值得優先處理的設計，是不要讓能讀取外部內容的 Agent，無條件寫入下一次啟動必讀的高信任檔案。否則任何郵件、網頁、工單或 repository，都可能間接取得改寫長期行為的路徑。
比較穩健的流程是：Agent 可以提出記憶候選，附上來源、摘要、適用範圍與建議期限；系統再依類型決定自動接受、等待人工審核，或完全禁止寫入。即使是低風險偏好，也應避免讓外部內容冒充使用者意圖。
載入時也要保留 provenance。Agent 不應只看到一段已合併文字，而應知道某條內容來自平台政策、使用者偏好、內部知識或模型摘要。來源不同，衝突時的優先順序與可採取動作就應不同。
把持久化上下文納入正式控制面
我們常把 Agent 的安全焦點放在模型、MCP、工具權限與網路邊界，這些當然都重要。但如果每次啟動都會載入的文字能改變 Agent 如何使用那些能力，持久化上下文本身就是控制面的一部分。
對技術主管而言，真正該問的不是「人格檔寫得像不像人」，而是：誰能改它？修改有沒有來源與審核？不可信內容能否間接寫入？不同層級的規則是否清楚隔離？出現異常時，能不能找到哪一次變更造成行為漂移，並安全回復？
Agent 可以有個性，也可以透過記憶愈來愈貼近工作方式。只是當這份「理解」開始跨工作階段存在，並能影響工具與資料，它就不再只是體驗功能。
把它當成正式的高信任控制輸入，不會讓 Agent 少一點人味；只會讓我們更確定，它今天成為的樣子，是經過誰同意、根據什麼證據，而且出了問題可以改得回來。