Prompt 裡寫的不算數
最近 Reddit 有兩個帖子我都有在追，拼起來看覺得其實在說同一件事。
第一個是有人說自己是非技術背景，問他設計的 OpenClaw 安全計畫是不是合理。他的方案是：獨立機器、throwaway 帳號、UFW + OpenSnitch、獨立 subnet。評論區普遍說架構不錯，但有一則留言我覺得才是重點：「Prompt 裡的 instruction 不是 hard-and-fast rule。真正的規則要做在 box 外面，像防火牆、預付卡、獨立的 email 和 calendar 權限。」
第二個是有人分享他的 OpenClaw 記憶管理歷程，從 built-in Search 換到 QMD 再換到 MemPalace，最後部分退回 built-in。環境是 iMac + OpenClaw 2026.6.8 + MemPalace 3.4.1 + Qwen 3.7 Plus。目前做法：最近的 recall 用 built-in memorySearch，比較舊或深層的 recall 用 MemPalace，每兩小時 batch reindex 一次。痛點是 real-time indexing 不穩、兩個搜尋工具並存讓 agent 行為混亂、startupContext 沒照預期工作。
兩篇看完，我的第一個反應是這根本是同一個問題的不同切面。
不管是安全控制還是記憶管理，很多人設計的第一直覺都是「在 prompt 裡交代清楚」。告訴 agent「不要存取這個目錄」、「記憶優先用 MemPalace」、「重要的事要先做 recall」。但這個思路的根本問題是：prompt 裡的指示是 agent 自己解讀的，它可以遵守，也可以在某個 edge case 下繞過去，而且沒有 enforce 的機制。
UFW 和 OpenSnitch 的邏輯就完全不一樣了。UFW 不管 agent 在 prompt 裡答應了什麼，它直接在網路層把連線切掉。OpenSnitch 在 process 層做 audit，不是在對話裡加一條「請不要連外網」。這才算 hard rule，因為它是 agent 本身到不了的控制面，不是放在 agent 的解讀空間裡。
預付卡的邏輯也一樣。就算 prompt injection 讓 agent 執行了一筆預料之外的 transaction，損失有上限。這不是靠 agent 的自律，而是你在外部設了一道牆。
記憶管理那邊也是。用戶在 startupContext 裡寫「先用 MemPalace 做深層 recall」，但如果兩個搜尋工具同時存在，agent 自己判斷用哪個，結果就是你說的行為混亂。有效的設計是把 recall 的觸發條件和工具路由在系統層設好，不是靠 prompt 裡的偏好宣示。
另外，那個 2 小時 batch reindex 讓我注意到一件事。如果 real-time indexing 不穩，這個 2 小時窗口就是一個你能實際驗的數字，可以在 log 裡確認 reindex 是不是真的跑了、deltaBytes 有沒有超過 100000、deltaMessages 有沒有過 50 這些閾值。這才叫做可觀測的控制面，可以驗，出問題的時候就知道是哪一層出了問題。
要注意的是，我不是說 prompt engineering 沒有用，有些行為調整還是只能靠 prompt。但安全和穩定性這兩類需求，我個人的原則是：能做在外面的，就不要靠 prompt 裡的交代。
從 SRE 的角度說，這就是 defense in depth，而且每一層的防禦要在你自己的控制下，不是在 agent 的解讀空間裡。Prompt 裡的規則跟白板上的紙本規範一樣，沒有 enforcement 就不算設計。
作者：承翰