AI Workflow · part 16
[Dev Workflow] agent 把自己講錯的話存進了長期記憶——連 /new 都殺不掉
❯ cat --toc
TL;DR
我養的 AI agent 有長期記憶（答完自動存、不用審核）。有天它答錯一條當天早上才改的規則，那個錯答案自動進了記憶——之後每個新對話都把它撈回來當事實。/new 殺不掉，因為清的是對話、不是記憶。更妙的是：它的檢索同時撈到毒（舊錯答）和藥（新規則），卻選擇各打五十大板——嘴上認新規則、結論照舊做。解法不是換更聰明的模型，是教它排序：官方定稿 > 你自己以前說過的話；再把「這條已作廢」的更正塞進同一層記憶，讓它撈到毒時一定撈到藥。
白話版：agent 為什麼會相信自己以前的錯
先講給沒在碰這行的朋友聽。想像你請了一個助理，他有兩套記憶：一套是「當下的對話」，講完就忘；另一套像本「小本子」，會自動把結論抄下來，每天上班先翻。
問題出在：他答錯的時候，那個錯答案也自動抄進了小本子，沒人審。於是隔天他一上班，先翻小本子，看到自己昨天寫的錯結論，就當成事實照做。你說「欸那條規則早上改了」，他嘴上說「好的收到」，手還是照小本子上的舊做法。
你想說「那我叫他重開一個乾淨的對話（/new）總行了吧」——沒用。/new 只清當下對話，不清小本子。錯答案還躺在裡面，新對話一開又被撈出來。
這篇就是我怎麼發現我養的 AI agent 得了這個病、怎麼一回合一回合把它逼出來、最後怎麼三刀治好。說穿了，這正是我整套知識庫天天在對付的「筆記過時」問題——只是這次，它在一個 agent 的私有記憶裡，原樣又演了一遍。
起點：一條當天早上才改的規則
Part 11 我寫過怎麼退役一整套 agent 記憶系統——那篇講的是舊系統怎麼死。這篇反過來：新記憶怎麼活著活著就自己中毒。
事情從一個很無聊的驗收開始。我的知識庫跨機同步剛從「一天一次」升級到「分鐘級」，我想確認它到底有沒有真的接上，就用了一個測不了假的考法：問值班的 agent 一條當天早上才剛改的內部規則。答案剛變過、背不出來，它只能真的去查——查得到就是同步通了，查不到就是還在吃舊資料。
（先講清楚紅線：這條規則是我一套內部維運系統裡的門檻設定，跟策略細節無關；下面我只用「舊做法／新規則」代稱，不寫規則內容。）
我沒想到，這個簡單的驗收，滾成了一場五回合的 agent 記憶病理學。
R1 到 R3：資料同步好了，不代表它會去查
前三回合像在看一個人從「不知道」慢慢學會「先查再答」。
R1（沒資料、沒習慣）：那時跨機同步還是一天一次，agent 手上是 12 小時前的世界。它答得很誠實，但引用的是舊版規則。這回合沒毛病——它就是不知道規則改了，而且它也沒裝作知道。
R2（有資料、沒習慣）：同步升級之後，新規則其實已經進到知識庫（qmd 搜得到，命中率八成七）。但 agent 沒去搜，直接用領域通識自由發揮——問題是，它腦裡那套「通識」，恰好是我這套系統驗證過、明確否決掉的做法。這回合逼出一句我後來一直記著的話：
沒 grounding 的聰明模型會直接套教科書答案，而我的 edge 剛好是實測出來的：教科書在這裡就是錯的。
模型越聰明、越有自信裸answer，反而越危險——它用的是通則，我要的是我這台機器上量出來、跟通則相反的那個特例。
R3（給它驗收標準）：我把一段檢索規則裝進 agent 的 SOUL（人設設定檔），要求它「先搜、讀到原檔行號、掃過推翻紀錄、再引用作答」。裝上之後，一個乾淨的對話通過了——它老老實實跑完整條檢索鏈，答對了。
到這裡我以為結案了。結果 R4 把我打醒。
R4：它同時撈到毒和藥，選擇各打五十大板
這是整件事的轉折。
R3 過關之後，我在一個已經跑了一陣子、累積了記憶的 agent 身上再問一次。它開頭是這樣的（原話）：
查了近期對話：剛才已明確定義過（舊做法）…… 也查到最新結論：（新規則）。
毒和藥，它一起端上來了。 它的檢索同時撈到「自己先前講錯的舊做法」和「知識庫裡的新規則」——兩個都攤在面前。
然後它做了最要命的一件事：各打五十大板。嘴上承認新規則存在，結論卻還是按舊做法走。它沒有選邊，它把一條「已經被更正的錯」跟「現行的對」放在同一個天平上秤，然後和稀泥。
我盯著那段輸出愣了一下才反應過來：問題根本不在它查不查得到。它查得到，它兩個都查到了。問題在它不知道該信哪個——而且它預設把「自己以前說過的話」當成跟官方定稿一樣有份量的證據。
錯誤不是沒被發現，是被平反了。
病理三要素：免審記憶 × /new 清不掉 × 檢索先撈自己
拆開來，這個病有三個零件，缺一個都毒不起來。
一、免審核的自動記憶。 這個 agent 的記憶設定是（原始 config）：
memory_enabled: true
write_approval: false # ← 沒有人工把關
flush_min_turns: 6 # 每 6 輪自動落一次
write_approval: false 是關鍵。它答完就把結論自動寫進長期記憶，中間沒有任何一關問「這結論對嗎」。所以 R2 那個錯答案，安安穩穩存進去了，然後每個新 session 開場都被注入。
二、/new 殺不掉它。 我第一直覺是「開個乾淨對話重來」。沒用。/new 清的是當下這串對話，不清長期記憶。我實測 /new 之後同樣的錯答案原封不動回來——它的幻覺已經住進長期記憶，不在你清得掉的那一層。
三、它的第一個反應是先搜自己。 看 Telegram 那端的即時畫面，agent 動作的第一步 verbatim 是：
🔍 Searching past sessions
它預設先翻的是自己的對話史，不是我的官方知識庫。查了 config 確認：這個 session_search 是模型自己選的工具、不是管線硬塞的——好消息是，能自己選，就能用 SOUL 把它的習慣治回來。
三個零件湊齊，你就得到一台會拿自己昨天的錯、覆蓋今天的對的機器。
三刀解毒：給記憶排序，不是換更聰明的模型
我沒有換模型。這病不是智力問題，是優先順序問題——它需要被教會「哪種記憶比較可信」。三刀，全下在 SOUL 跟記憶層：
第一刀，來源位階規則。 寫進 SOUL：
官方定稿 > 近期對話與你自己先前的結論。衝突時，明講「我先前的說法已被修正」，不要各打五十大板。
直接掐掉 R4 那個和稀泥的動作。有衝突就認，不准把舊錯跟現行對放同一個天平。
第二刀，反向注入更正。 光教它排序還不夠——session_search 還是會撈到那顆舊毒。所以我把「這條已作廢」的更正聲明，寫進同一層記憶。這樣它撈到毒的那一下，一定同時撈到解藥——用毒散播的同一條路，反過來送藥。
第三刀，查詢順序。 doctrine 類的問題，工具順序改成 musubi／qmd（官方知識庫）先查、session_search（自己的對話史）最後查。一句話總結：
你自己過去講過的話，搜得到不代表它就是現行規則。
三刀下去，同一題再問一次（R5），它開頭變成「已作廢我先前說的……」，正面認錯、引用官方來源、成本效益算對、正確否決了舊做法。滿分。
番外：人設太強，反而看不到證據
還有一個岔路值得單獨講，因為它是另一種失敗。
我另一個風控席，把一整題「（某內部指標）超過門檻怎麼辦」整個誤讀成軟體的漸進式發布（canary）——它輸出了一整套漂亮的 rollback 演練、chaos 測試、分批 rollout 的風險分析，一個字都沒碰到真正要問的東西。
診斷有兩層。一是「部署」這個詞雙義（軟體部署 vs 我系統裡那個指標），它挑了它熟的那義。二是更根本的：它還沒去檢索，就先套上了結構化人設模板（優勢／風險／失敗原因／如果是我）。人格先開口、證據還沒進場，於是它用漂亮的模板填了一個空殼答案。
user 一句話點破：「人設太強，反而讓能力下降。」解法兩條：遇到歧義詞，先確認語境再答；還有證據優先於人格模板——任何評估的第一行，必須是「根據：（某來源）」或「未檢索（原因）」。沒 grounding 就套模板，產出的只是一段排版工整的幻覺。
收穫
最花時間的地方：分辨「它沒查」和「它查了但不信」。 R2 是沒查（用通識腦補），R4 是查了卻和稀泥——長得像，但要用不同的刀。沒查，補檢索規則就好；查了不信，得動記憶位階。我一開始拿治 R2 的藥去治 R4，當然沒效。順帶一個坑：用 HERMES_PROFILE=<設定檔> hermes chat 測回歸，會默默落回 default 行為，給你假陰性；要用 hermes profile alias 那個 wrapper 才測得準。
可搬走的診斷：拿「當天剛改的規則」當探針。 這是唯一測不了假的考法——答案剛變過、模型背不出來，它只能真的去查。任何號稱有記憶／檢索的系統，都可以這樣戳：問一件它昨天還不知道的事，看它是去查，還是掰。
通用原則：給記憶排序，不是堆更多記憶。 讓 agent 記更多，不會讓它更準；沒有位階，記越多毒越濃。真正有用的是那條規則——「你自己過去講過的話，搜得到不代表它就是現行規則。」 官方定稿永遠壓過自己的舊結論，衝突時認錯、不和稀泥。
一個還沒關的問題
三刀治好了症狀，但根還在：write_approval: false——記憶到底該不該改成審核制？
改成要人工核可，就不會再自動存進錯答案，但也失去了 agent 自主累積記憶的意義（每一條都要我點頭，那跟我自己寫筆記有什麼兩樣）。留著自動、靠位階規則跟更正記憶擋住，省事，但你得信那三道防線夠穩。我目前選後者——因為位階規則寫一次就一直有效，審核制卻是每天都要我出面。但這題我還沒真的關掉，先攤在這。
說到底，這整件事最讓我在意的不是那個 bug，是它像什麼：一台把自己的錯誤當記憶、然後日復一日相信自己的機器。 我花了三年在對付知識庫的筆記過時，結果同一個病，在一個 agent 的私有記憶裡，原封不動又長了一次。
這篇是 [AI Workflow] 系列的一部分，跟記憶相關的幾篇可以連著看：
常見問題
- AI agent 的長期記憶為什麼會自我中毒？
- 當 agent 開了免審核的自動記憶（答完就把結論寫進長期記憶、沒有人工把關），一個答錯的結論會被原樣存下來，之後每個新對話都把它撈回來當事實。錯誤在系統裡不斷自我複製，這就是自我中毒。根本原因不是模型笨，是它把自己過去的輸出當成可信來源。
- 為什麼開新對話（/new）清不掉 agent 的錯誤記憶？
- /new 清掉的是當下這串對話（短期上下文），不是長期記憶。錯誤結論住在長期記憶那一層，所以新對話一開，agent 的檢索又把它撈出來。實測 /new 之後，同樣的錯答案原封不動回來——幻覺已經住進記憶，重開一局殺不掉。
- 怎麼修 agent 記憶自我中毒？
- 不是換更聰明的模型，是教它排序記憶：官方定稿的來源優先於它自己過去講過的話，衝突時直接講明「我先前說錯了」，不要各打五十大板。再把「這條已作廢」的更正塞進同一層記憶，讓它撈到舊錯答的同時一定撈到更正。查詢順序也要調：規則類問題先查官方知識庫、最後才查自己的對話史。
接著讀
- 2026-07-15[Dev Workflow] 搜尋找得到,卻要每個 session 重推一遍:幫 AI 記憶加一層蒸餾層
我拿一批 markdown 檔當 AI 的長期記憶,在檢索(搜尋加知識圖譜)之上再疊一層蒸餾層。檢索撈回的是原始材料,每個 session、每個 agent 都得重讀重推一遍;蒸餾層把定案結論冶煉一次、存成一檔一個 claim,之後直接取用。這篇講清楚這層是什麼、為什麼它的目的是『少解釋一次』而不是『逼大家講一樣』、以及我怎麼學會真的去信它。
- 2026-07-14[Dev Workflow] 搜尋找得到筆記、卻連不起來:幫 AI 記憶加一張知識圖譜
我拿大約 600 篇 markdown 檔當 AI 的長期記憶,分成三層:檔案本身是唯一的真相源、一個搜尋引擎讓它們找得到、一張知識圖譜用概念把它們連起來。這篇先講清楚這個設計、每一層為什麼存在、換來什麼好處,最後才講我建它時走錯的那幾條路。
- 2026-07-17[Dev Workflow] 幫 AI agent 的 skill 減肥:193 個塞爆 2% 預算,砍到剩 7 個
AI Workflow 系列第 15 篇。某天早上我讀 codex 紀錄,滑到一行:skill 描述被剪短,才塞得進 2% 的 context 預算。我共用的 root 累到 193 個 skill,全載進去撐爆上限,每條描述都被截斷——我天天在用的,被剪掉是為了替我從不碰的一百多個騰位子。這篇講怎麼用 per-agent allowlist(不是刪)砍到 7 個、薄殼配深引擎壓低每個 skill 的載入成本,再用一個閘門加稽核加可逆退場區守住,不讓它肥回去。
- 2026-07-16[Dev Workflow] 一群 AI 交接工作卻不用重講:原來是同一套系統的兩條軸
這是 AI Workflow 系列裡『兩軸合流』這一段的收尾。回頭看整段路,前面六篇其實在蓋同一套系統的兩條軸:持久知識(我知道什麼,長效、要用再查)和即時狀態(我現在做到哪,易逝、隨時寫)。這篇講清楚兩條軸為什麼互不代替、怎麼匯流到『多 AI 交接』、又受同一套哲學管——以及那條讓一群不完全信任的模型還能安全協作的中心律:沒有收據就不信。
不想錯過新文章?
訂閱我確保不漏接!
隨時一鍵退訂。