最近在維護幾個 AI 自動化流程時，我又踩到一個看起來很小、其實很煩的點：很多 Agent 不是因為模型不夠聰明而出錯，而是因為它手上的「操作知識」已經過期了。
這件事有點像公司裡那種放在共享資料夾的 SOP。剛寫完時大家都覺得很清楚，半年後工具換版、欄位改名、流程多一個例外，結果新人照著做反而爆炸。差別只是，AI Agent 爆炸時通常還會很有自信地把錯誤流程跑完。這比人類新人更可怕，因為它不會一邊做一邊露出「我是不是怪怪的」的表情。
Skill 不是提示詞，是操作層的一部分
我以前會把 Agent 的 skill 或 runbook 想成「比較長的 prompt」。裡面寫一下工具怎麼用、哪些坑不要踩、輸出格式長怎樣。聽起來很合理，對吧？
但跑久了就會發現，這個理解太輕了。
真正有用的 skill 比較像作業系統裡的 driver 或 service configuration。它不是拿來裝飾模型的，而是直接決定 Agent 會不會把事情做對：要先讀哪個檔案、缺資料時能不能 fallback、什麼情況要停止、產出後要怎麼驗證、遇到舊資料要怎麼判斷是否仍有效。
也就是說，skill 不是「知識庫」而已，它其實是 Agent 的操作層。
人類工程師看到一段過期文件，可能會停下來懷疑：「欸這個指令是不是舊的？」Agent 不一定。除非你明確把「發現文件不對時要修它」寫進流程，否則它很可能只是繞路、猜測、硬做，最後留下一個看似完成但其實脆弱的結果。
知識會腐爛，而且腐爛得很安靜
技術文件最麻煩的地方，不是它會錯，而是它錯的時候通常不會大叫。
一個 API response 結構改了，文件不會自己亮紅燈。一個 CLI 的參數換了，runbook 不會自動跳出通知。一個排程任務多了一個例外情境，舊的操作步驟還是安靜地躺在那裡，看起來跟昨天一樣可靠。
AI Agent 的技能庫也是一樣。更慘的是，它通常會被大量重複使用。某個小錯誤如果沒有被即時修正，就會變成「可重複的錯誤能力」。
我現在會把這種東西分成三種狀態：
- 有效知識：剛驗證過，能直接依賴。
- 可疑知識：大致方向對，但遇到邊界條件要保守。
- 腐爛知識：曾經對，現在照做會害人。
問題在於，很多團隊只管理「有沒有文件」，很少管理「文件目前是哪一種狀態」。這就像只看服務有沒有啟動，卻不看 health check。畫面是綠的，但使用者已經在尖叫了。
flowchart TD
A[Agent 執行任務] --> B{照 skill 操作}
B --> C[成功並驗證]
B --> D[失敗或發現例外]
D --> E{是一次性問題嗎}
E -->|不是| F[修正 skill / 補 pitfall]
E -->|是| G[記錄但不污染流程]
F --> H[下次任務使用新知識]
C --> H
G --> H
最重要的機制：錯一次，就把錯誤制度化
這句話聽起來有點怪。錯誤為什麼要制度化？
我的意思不是把錯誤流程固定下來，而是把「避免再次犯錯」這件事制度化。
如果 Agent 今天因為某個前提過期而繞了一大圈，最差的做法是只把這次任務修好，然後結案。因為下一次同類任務來，它還是會踩同一個坑。更慘的是，下一次可能沒有人在旁邊看。
比較好的做法是：只要發現 skill 不完整，就立刻把新規則補回去。不是下週整理，不是有空再說，而是當下修。因為錯誤剛發生時，脈絡最完整，知道它為什麼錯、錯在哪、怎麼驗證才算修好。
這其實很像 production incident review。只是以前我們修的是服務、監控、告警；現在還要修 Agent 的操作記憶。
對技術主管來說，這個觀念很重要。導入 AI 自動化不是把一堆 prompt 丟進資料夾就結束，而是要建立一套「知識維運流程」：
- 每次執行前，知道該載入哪份 skill。
- 每次失敗後，判斷是工具問題、資料問題，還是 skill 過期。
- 每次修正後，有最小驗證方式確認不是亂補。
- 每隔一段時間，清掉重複、衝突、已廢棄的規則。
不然 skill library 會慢慢長成一個很恐怖的東西：每份文件都曾經有用，但沒有人知道哪份現在還能信。
不要把所有經驗都塞進去
當然，另一個極端也很危險：什麼都想記。
AI 很擅長整理，所以很容易讓人產生錯覺：既然可以記，那就全部記下來。每一次例外、每一次 workaround、每一次臨時決策，都塞進 skill。短期看起來很勤勞，長期就是把 Agent 餵成一隻迷路的章魚。
好的 skill 應該像好的程式碼：保留抽象後仍然有用的規則，刪掉只對單一場景成立的雜訊。
我會問三個問題：
- 這個教訓下次真的會重複出現嗎？
- 它能不能被寫成可操作的判斷，而不是一句情緒性的提醒？
- 它會不會跟現有規則衝突，讓 Agent 更難決策？
如果答案不清楚，那它可能比較適合放在日誌或回顧，不適合升級成 skill。不是每一個血淚都值得變成制度。有些血淚只是提醒我今天咖啡喝太少。
Agent 可靠性的核心不是「更會想」，而是「更會改正自己」
這幾個月我越來越覺得，AI Agent 的可靠性不能只看模型有多強。模型當然重要，但在真實工作流裡，很多失敗其實發生在模型之外：資料源變了、工具行為變了、檔案位置變了、預設假設變了。
如果 Agent 的知識不能跟著現場更新，再強的模型也只是在很努力地執行過期指令。
所以我現在看一套 Agent 系統，會特別注意它有沒有三個能力：
第一，能不能在動手前載入正確上下文。第二，能不能在遇到錯誤時保守處理，而不是硬猜。第三，能不能把這次學到的東西回寫到未來流程。
前兩個決定單次任務會不會成功，第三個才決定系統會不會變好。
這也是我覺得 AI 自動化最有趣的地方。它不像傳統自動化，寫完腳本後就期待環境不要變。Agent 系統更像一個會持續長大的工作夥伴，但前提是：你要給它一套乾淨、可維護、能修正自己的技能庫。
不然它不是長大，只是長毛。還會掉毛。很麻煩。
結語
如果要用一句話收斂這次的教訓，我會說：不要只維護 Agent 的工具，也要維護 Agent 對工具的理解。
工具會更新，流程會變形，例外會累積。skill library 如果沒有維護機制，就會從加速器變成地雷區。它一開始幫你省時間，後來開始幫你製造很難追的錯。
對我來說，這也是技術管理在 AI 時代多出來的一塊工作：不是只問「我們有沒有用 AI」，而是問「AI 犯過的錯，有沒有讓系統變得更聰明」。
如果沒有，那它只是每天用全新的算力，重複昨天的坑而已。這就有點奢侈了。