先假設自己在說謊：怎麼稽核一整支 AI agent 艦隊
我們讀完 Antonio Gulli 的《Agentic Design Patterns》，照著書把一人公司的 AI agent 艦隊做了一遍。21 個設計模式，一個一個對照著實作：路由、反思、記憶管理、多代理協作、資源感知、評估監控。做完那份清單，感覺很好，每一格都打了勾。
然後我們做了一件大部分教學不會做的事：假設這些勾全部是假的，逐章去查。
這個稽核有個規矩，就是不相信任何自我宣稱。文件說「已實作」不算數，要拿出最後一次真的跑起來的時間、真的產出的東西、真的被呼叫的紀錄。查不到，就是空殼。
結果很難看。宣稱「已實作」的 14 章，沒有一章是完全乾淨的。
病歷摘要
同一份系統，攤開來是這些樣子。
招牌會死。第 6 章規劃，我們最拿得出手的 agent-meeting.py，稽核一查已經死了三個月，沒有任何 timer 在叫它，只剩一個封存用的空殼掛在那裡好看。
數字會灌水。第 3 章平行化，對外講「六品牌並行」，實際只有一個 brand gateway 活著，其餘五個是遷移之後留下的空殼。
名字會騙人。第 20 章優先排序，聽起來很聰明，稽核真相是它只有靜態排程加輪替加限流，沒有任何一行在做價值排序。唯一那支評分腳本根本沒 timer，從不執行。
監控會在最需要的時候沉默。第 11 章，我們裝了一整套告警，但兩次最痛的帳單都發生在「有監控」的情況下，因為門檻設得太鬆，錢從底下溜過去，警報沒響。
連評估系統自己都會幻覺。第 19 章，我們做了 LLM 評審去抓「答錯」，結果評審把一個答對的系統判成錯，還推了一個 CRITICAL 去罵它。
最貴的一章是第 16 章。gateway 一週燒的錢，98.8% 花在一遍遍重讀歷史，真正產出佔 1.2%。
為什麼把這些公開
按常理，發現自己做的東西一半是死的，應該默默修好、然後只講修好之後的版本。市面上的 AI agent 教學九成是這樣寫的：乾淨的架構圖、完美的流程、看起來一切都照計畫運作。
我們決定反過來，把稽核報告本身變成教材。原因很實際：真實的 agent 系統就長這樣。宣稱的功能有一半是死的，招牌是擺著好看的，監控在災難時沒響，學習迴路每晚勤奮地跑卻學到 0。你去看任何一個跑了幾個月、沒人天天盯的自動化系統，八成都是這副樣子。假裝它完美，對正在踩同樣坑的人沒有任何幫助。
一個誠實的稽核報告，比一張漂亮的架構圖有用。
照著做：對你自己的系統來一次
這套稽核你可以直接套用。核心只有一句：不相信任何自我宣稱，只認執行證據。
01 假設每個「已完成」都是假的 列出你系統裡所有你以為在運作的功能，然後把它當成待證明的假設，不是已知的事實。心態對了，稽核才做得下去。
02 查最後一次真的跑起來是什麼時候 招牌功能最容易死得無聲無息。看它的 timer 還在不在、log 最後一筆是多久以前。
# 這個服務最後真的跑是什麼時候
systemctl --user list-timers | grep 你的服務
ls -la --time-style=long-iso 你的服務.log # 看 log 最後更新時間
紅旗：招牌功能的 log 停在幾週甚至幾個月前。
03 查它有沒有真的產出東西 timer 在叫，不代表有產出。分開驗「有沒有在跑」和「跑出來的東西對不對」。
# 有跑不等於有產出，數一下真實輸出
grep -c 'produced\|posted\|wrote' 你的服務.log
紅旗：執行次數很多，真實產出接近 0。
04 對外的數字，回去對帳 你講給別人聽的規模（幾個並行、幾個 agent、處理了多少），逐一回去數實際活著的有幾個。 紅旗：對外的數字，比你數得出來的實際活著的多。
自我稽核清單
- 每個「已完成」的功能，你有它最後一次真的執行的證據嗎
- 招牌功能，log 最後一筆是多久以前
- timer 有在叫的服務，真的有產出，還是只是空跑
- 對外講的數字，回去數過實際活著的有幾個嗎
- 監控門檻，是不是鬆到災難能從底下溜過去
- 有沒有一個你以為還在用、其實已經死掉的招牌功能
這一篇的四句話
- 不相信自我宣稱，只認執行證據。文件說做到不算數，log 說了算。
- 招牌功能最容易無聲死掉，因為沒人會去質疑招牌。
- 有 timer 在動，不等於有在產出。分開驗「在跑」和「跑對」。
- 誠實的稽核報告，比漂亮的架構圖有用。這也是這整個系列的寫法。
這是《Agentic Design Patterns》× 龍蝦艦隊系列的開場。接下來 21 篇，我們一章一章把稽核攤開：書怎麼講、我們以為做到了什麼、稽核打臉出什麼真相、最後怎麼修或怎麼承認還沒修。這個系列的可信度，來自我們願意公開自己打臉自己。