這個 19 系統系列的最後一章稍微延遲了一下，但遲到總比不到好。
我一直在鑽研的 19 個系統中，有六個通用模式構成了這個系列的核心。寫作時的品質投入。隨事實流動的來源追溯。RRF 融合的混合檢索。基於熱度提升的分層儲存。明確的上下文預算。在 Agent 表面使用工具而非注入。每個模式都值得獨立成篇，因為至少有三個系統各自獨立地採用了相同的原則。
通用模式到此為止。從這裡開始，新興模式登場。
本文探討八個尚未達到通用門檻的模式，它們出現在一到兩個系統中，其實作方式明顯在解決真實問題，因此很難相信它們會持續罕見。其中七個出現在剛好一個系統中。一個出現在兩個系統中，距離晉升只差一次採用。第一個會獲得最深入的探討，因為它最重要。
由於出現得早，其中一些可能永遠不會普及。但更糟的是太晚：你在 2026 年打造了一個系統，卻因為某個綜合分析認為某個特性是「一次性奇技」而沒有實作儲存層授權，然後在 2027 年就在 Hacker News 上看到一個提示注入的展示。
儲存引擎是唯一真正的權威
前一篇文章論證了 Agent 應該掌握工具。給它一個 SQL 工具後，立刻出現一個問題：是什麼阻止它查詢不該查詢的資料表？
那些直覺的做法早已被實踐證明，而且全都是錯的。
提示層級指令：「你不被允許讀取 conversations 資料表。」對合作模型有效，但一旦模型誤讀指令、認為禁令不適用於當前任務、或處於越獄狀態，就完全失效。
應用層級過濾：sql_query 工具包裝模型的 SQL，解析其中是否有禁止的資料表引用，在傳遞給資料庫前拒絕查詢。對天真模型有效，但一旦模型引用資料表名稱、使用 ATTACH、利用包裝器與資料庫之間的解析不一致、或透過其他地方定義的視圖繞過，就會失效。
僅限 ORM 中介存取：Agent 從不接觸原始 SQL，而是呼叫型別方法。這個方法有效，直到系統增加了除錯工具、分析工具、遷移工具，或「讓 Agent 聯結兩個資料表」的功能，此時規則就會被打破，且破損狀態不會被發現。
簡而言之：這些都不是真正的強制執行，而是提示。一個真正想要實現子 Agent 隔離的系統，必須讓儲存引擎本身拒絕讀取，而不是上層的應用層。這是能力安全模型對作業系統資源施加的原則：核心說不，而不是應用程式說不。這也是 PostgreSQL 的列級安全對多租戶 SaaS 施加的原則：策略存在於資料庫中，而不是 ORM 中，因為「建置新微服務的工程師忘了套用租戶過濾條件」這類錯誤，只有儲存引擎的策略才能排除。
second-brain 是語料庫中第一個實作範例。它的範圍資料庫有三層，每一層都是必要的，但單獨一層都不夠。
每個範圍 Agent 一個全新的記憶體內 SQLite 連線。建構子開啟 :memory:，並以唯讀模式附加真實資料庫。Agent 的連線沒有真實的主綱要，除了下一層放入的資料外，沒有其他可讀取的內容。
主綱要中的 TEMP VIEW 指向來源中允許的資料表。視圖定義來自 Agent 的設定檔，可以編碼列級遮罩或列級過濾器。視圖名稱驗證器可防止透過設定檔注入惡意資料表名稱。
一個 SQLite C API 授權器鉤子，拒絕任何不透過視圖讀取來源綱要的請求。這個鉤子在 SQLite 即將執行任何讀取之前觸發，甚至在最佳化器解析資料表名稱之前。視圖主體內部的讀取是允許的，因為視圖本身就是範圍過濾器。頂層讀取會對照該範圍建立的視圖名稱集合進行檢查。任何直接讀取來源綱要的行為都將被無條件拒絕。
LLM 可以隨意撰寫任何 SQL。它可以引用資料表名稱、使用 UNION、使用 ATTACH、使用 SQLite 的完整語法。但它無法成功從不在允許清單中的資料表讀取任何一行，因為授權器在 C 層級、資料表名稱解析之前就攔截了讀取。應用層級的過濾器可以被繞過，但儲存引擎的授權不行。
大約 50 行標準庫 Python 程式碼。沒有額外的依賴、沒有額外的程序、沒有綱要遷移。每次查詢的額外開銷是每個讀取一個 C 回呼，相對於查詢本身的成本可以忽略不計。這個模式可以乾淨地與其他一切組合：Agent 的工具註冊表仍然可以設定功能開關，視圖定義仍然可以編碼列級遮罩，對話歷史仍然可以在寫入時遮罩。這些層都不會因為儲存層的強制執行而削弱，反而會得到加強。
關鍵在於這個框架：19 個系統中的其他所有安全模式都是提示，而儲存引擎才是真正的權威。
另外三個值得提及的模式
非同步清理的競爭保護 (llm-wiki)
背景記憶維護本質上與前台使用者操作存在競爭條件。針對專案 A 啟動的清理，卻在專案 B 上完成，這會同時破壞兩個專案。它將 A 的決策移到了 B 的審閱儲存庫中，或者將 B 的項目標記為已解決但使用的是 A 的資料。這是一類容易引入、難以偵測、且幾乎無法乾淨復原的錯誤，因為受損的狀態看起來是合法的。
llm-wiki 執行一個兩階段的背景審閱迴圈，並在每個讓出點重新檢查兩個競爭保護訊號：一個由專案切換處理器觸發的中止訊號，以及一個與 UI 儲存庫中當前專案的路徑比較。只要任一檢查失敗，清理就會在未套用決策的情況下中途返回。佇列端的專案切換握手指令完成了整個環節：在清除記憶體之前將當前專案的狀態刷新到磁碟，將正在處理的項目恢復為待處理狀態，中止正在進行的 LLM 呼叫和中途的清理判斷，然後才寫入已暫停專案的路徑。
核心的元模式可以總結為：在可確定的地方用確定性方法，必要時用 LLM，並處處確保可中止。兩階段結構讓 LLM 遠離那些簡單存在性檢查就能處理的情況。競爭保護則讓兩階段都可中止。這兩者的結合是所有系統中任何背景記憶維護迴圈的模板。
自動降級的空操作建構子 (graymatter)
程式庫 API 設計存在一個反覆出現的張力。最簡單的「Hello World」希望程式庫直接可用，一行建構，一行呼叫。而最穩固的生產環境姿勢則希望它在建構時大聲失敗，並拋出一個呼叫者無法忽略的結構化錯誤。
graymatter 選擇了靜默失敗，但透過一項原則將這個取捨轉變為生產力。建構子永遠不回傳錯誤。如果初始化失敗——bbolt 被鎖定、資料目錄不可寫、向量儲存無法開啟——它會記錄到 stderr 並回傳一個降級的 Memory 物件，其所有方法都是空操作。生產環境的呼叫者在信任該控制代碼之前，會透過 Healthy() 進行驗證。這個程式庫可以用 go get 安裝，三行程式碼就能匯入，並且在示範中能正常運作。而 Healthy() 則是生產環境的原則稅。
這個模式讓程式庫可以安全地嵌入到具有自己啟動儀式的 Agent 工作框架中。一個在啟動時呼叫 [graymatter.New](https://graymatter.new/)(...) 的 Agent 工作框架，忽略錯誤路徑（因為根本沒有錯誤路徑），然後繼續執行，就能在正常路徑下獲得可用的記憶層，而在資料目錄唯讀時獲得無記憶的後備方案。無論哪種情況，工作框架都能啟動。這是一種特定的防禦性組合，是失敗大聲的建構子無法提供的，除非在每個嵌入點都明確處理錯誤。
影子模式的去重偵測 (mem9)
每個實作重複抑制的系統都必須選擇一個餘弦相似度閾值。0.95 以上幾乎肯定是重複。0.7 以下幾乎肯定不是。中間的空間則充滿爭議，而正確的臨界值取決於嵌入模型、領域、查詢分佈，以及在這個特定系統中誤報與漏報的成本。
根據直覺選一個然後上線，這個誘惑難以抗拒。但 mem9 沒有這麼做。它對每個事實都執行去重偵測查詢，將餘弦分數記錄到 Prometheus 直方圖中，但不採取任何行動。閾值的設定會推遲到生產資料證明其合理性為止。「先發布觀察結果，而不是啟發式規則。」
同樣的邏輯適用於每個記憶系統中所有需要設定閾值的決策：重新排序的閾值、召回信心截止點、層級提升的熱度門檻、洞察合併的相似度門檻。19 個系統中的大多數都用猜測值來出貨。而 mem9 則是延遲設定閾值。這項原則很少見，但結果更好。
另外四個，更為緊湊
每個租戶的實體資料庫隔離 (mem9)。
mem9 不在共用儲存庫上使用 WHERE tenant_id = ? 過濾器，而是透過 TiDB Zero 為每個租戶佈建一個獨立的 TiDB 叢集。隔離發生在儲存引擎端。應用程式無法意外地跨租戶查詢，因為根本沒有共用儲存庫可以查詢。這是與儲存層授權相同最終狀態的一個較粗粒度的版本：由引擎而非應用程式強制執行隔離。過去讓這種做法不切實際的基礎設施成本已經不復存在。TiDB Zero 可以自動佈建。Neon 對 PostgreSQL 也提供相同功能。Cloudflare D1 對 SQLite 也是如此。
帶有明確上下文預算的來源對話裝飾 (mem9)。
檢索到的記憶是一個字串：「使用者偏好 Postgres。」正確、簡潔，但沒有上下文就無法驗證。mem9 將原始對話輪次作為裝飾附加，根據查詢進行評分，並以一個預算三元組為上限：最低分數、每個記憶的限制、總限制。讀取「使用者偏好 Postgres」的 Agent 會同時看到使用者說「我們試過 MongoDB，但聯結查詢讓我們吃不消，所以上個季度我轉到了 Postgres」的那個輪次。不需要第二次工具呼叫。驗證依據就在結果中。先決條件已經普及：來源追溯加上混合檢索。19 個系統中的大多數都可以在兩天內實作這個模式。
purpose.md 作為第四個檔案 (llm-wiki)。
Karpathy 的 LLM Wiki 模式有三個標準檔案：原始來源、Wiki 工作集、以及 schema.md 用於結構規則。llm-wiki 增加了第四個：purpose.md，由使用者填寫，並內嵌到系統進行的每個 LLM 呼叫中。每個攝取提示、每個生成提示、每個聊天檢索都會讀取它。效果是一個穩定的方向性先驗，調節所有下游行為。LLM 無論如何都會讀取系統提示。加入使用者的意圖不需要額外成本，卻能提升一切。大多數其他系統中缺少這個做法，比 llm-wiki 中有它更難解釋。
AGENTS.md 作為權威性 Agent 合約 (Tolaria, OpenContext)。
大多數帶有 AGENTS.md 或 CLAUDE.md 的儲存庫將其視為一個提示檔案。而 Tolaria 和 OpenContext 則將其視為一份合約，每個有約束力的條款都配有機械檢查，如果 Agent 違反就會導致建置失敗。「不要跳過 pre-commit 鉤子」不是一個禮貌的請求，而是一個由 CI 強制執行的規則。「測試覆蓋率必須維持在閾值以上」不是一個指導方針，而是一個測試執行器會中止的障礙。提示可以被忽略，但由檢查支援的合約則不能。已經有兩個系統這樣做了。再多一個，它就能晉升。
哪些模式會優先普及
儲存層授權將最先普及。這是來源分析中最有信心的預測。任何授予子 Agent SQL 存取的記憶系統，如果沒有儲存層強制執行，都離機密洩漏只差一次提示注入。基礎設施已經到位。SQLite 從 2000 年代初就有 set_authorizer。PostgreSQL RLS 已經是主流。LanceDB 和 ClickHouse 也有自己的策略鉤子。障礙不在技術，而在認知。second-brain 提供了實作範例。下一代管理 API 將會複製這項原則，因為替代方案是站不住腳的。
來源對話裝飾將第二個普及。先決條件已經普及。實作只需要兩個查詢加上一個預算。對 Agent 端的資訊增益足夠大，以至於先在某個管理 API 中推出此功能的服務，在基於來源對話驗證答案的能力上，會明顯優於後推出的服務。複製的壓力很大。graymatter 已經有每個事實的來源，supermemory 有譜系，Hindsight 有完整的對話追溯。它們任何一個都離這個模式只差一個 PR。
自動降級的空操作建構子將第三個普及，而且會在另一個語言中。Go 的文化條件讓這個模式安全。下一個採用者不太可能是 Python（其文化對異常過於熱衷），但可能是 Rust。這是一個程式庫 API 設計的選擇，而不是記憶體的選擇，它會在「示範美學加生產原則」是正確取捨的地方傳播開來。
影子模式部署是一匹黑馬。技術上非常簡單，文化上卻很難。如果第二個系統在用它作為閘控之前先對閾值進行儀器化，這個模式就會立即晉升，然後第三、第四個會在一個發布週期內跟進，因為一旦展示出來，工程的便利性將無可反駁。
其餘四個各自取決於特定的部署形態變得更為常見。當更多系統發展出多對話並行性時，競爭保護就會普及。當受監管的企業客戶開始要求時，每個租戶的實體隔離就會普及。當 Karpathy 的 LLM Wiki 範式獲得第三或第四個實作時，purpose.md 就會普及。當「Agent 是同事」這個框架成為主流的 Agent 工作樞紐比喻時，AGENTS.md 作為合約就會普及。沒有哪個是不合理的，但也沒有哪個是確定的。
結論
貫穿所有八個模式的統一主線是相同的立場：應用層不是一個可信賴的隔離邊界。儲存層授權是每個 Agent 的表現形式。每個租戶的實體資料庫是每個租戶的表現形式。AGENTS.md 作為合約是每個 Agent 行為的表現形式。根據這個預測，這個語料庫的下一個迭代將會以這個名稱包含一個新的通用模式。
前一篇文章論證了 Agent 應該掌握工具並決定要檢索什麼。而這篇文章探討的是當 Agent 將那些工具轉向你未曾預料的方向時，什麼能夠真正約束住它。六個通用模式是共識。這裡的八個是共識下一步將去向何處的領先指標。儲存層授權是領先指標中的領先指標，而錯過它的代價，就是那種會出現在 Hacker News 上的代價。
