怎麼發現你的招牌 agent 其實早就死了
幾個月前我在《我們讓 4 隻 AI Agent 在 Discord 上開會》裡，把「它們每天早上自己開會、自己看數據、自己提建議」寫成我現在每天在做的事。這篇要回頭查那支招牌開會 agent 的最後執行時間：它已經三個月沒開過一場會了，而我一直以為它天天在開。程式碼沒壞，不等於它還活著。
《Agentic Design Patterns》第 6 章講規劃。核心一句話：agent 面對複雜任務，要先把它拆成有順序的多步計畫，再一步步執行，而不是一口氣硬幹。
我們讀完，心想這章我們有王牌。艦隊裡有一支 agent-meeting.py，四個角色每天開一場會：讀艦隊數據、讀昨天的會議記憶、讀跨 agent 訊號，然後產出當天的討論、萃取出行動指令寫回訊號匯流排，給明天當計畫。這是我們對外最愛秀的一支，多步規劃的活招牌。然後我們對自己做了一次對抗式稽核。這一章的難堪是：這支招牌 3 個月沒跑過了，而我們一直以為它每天都在開會。
招牌攤開來，是一具擺著好看的殼
第一刀砍在「它最後一次真的跑是什麼時候」。腳本檔本身停在 2026-04-03，之後一個字沒動過。這還能解釋成「寫好了就沒再改」，所以我們去翻它自己寫出來的東西：會議記憶檔 meeting_memory 一共 14 筆，最後一筆的日期，也是 2026-04-03。它不是懶得改，是那天之後，一場會都沒開過。到今天，整整 3 個月。
第二刀更狠：為什麼會死？因為根本沒有東西在叫它。我們掃過全部 23 個 systemd timer，沒有一個叫 meeting，沒有一個叫 agent。再把整個艦隊目錄 grep 一遍「agent-meeting」，除了它自己，只撈到一支躺在 _archive/ 裡的 wrapper，內容就一行 exec python3 agent-meeting.py。一支封存資料夾裡的殼，套著另一支沒人呼叫的殼。沒有 timer、沒有 service、沒有 cron，這支「每天開會」的 agent，上一次被觸發是三個月前有人手動敲了一次。
值得講清楚它「不是」什麼：程式碼沒壞、跑起來會動、Gemini 金鑰還在、Discord webhook 還通。你今天手動執行它，它照樣開一場漂漂亮亮的會。壞的不是它會不會跑，是沒有任何一根線在拉它跑。招牌 artifact 最危險的狀態，就是這樣：它完好無損地擺在那裡，而你腦裡的印象停在它上線那天。
先花幾分鐘查你自己的招牌功能
01 它最後一次真的執行，是什麼時候 別問「它會不會跑」，問「它最近一次跑是哪天」。查腳本檔的修改時間，再查它寫出來的資料檔最後一筆的日期，兩個一起看。
# 腳本最後被動過是多久以前（死腳本會停在某一天）
stat -c "%y %n" ~/.openclaw/scripts/你的招牌.py
# 更硬的證據：它產出的資料檔，最後一筆是哪天
python3 -c "import json;m=json.load(open('.../data.json'))['records'];print(m[-1]['date'])"
紅旗：最後一筆停在幾週前、幾個月前，而你還在對外講它「每天在跑」。
02 有沒有任何 timer / cron 真的在叫它 會不會跑，跟有沒有人叫它跑，是兩回事。列出所有排程，用腳本名去搜，再全域 grep 一遍看誰引用它。
# 有沒有排程真的在觸發它
systemctl --user list-timers --all | grep -i 你的招牌
crontab -l | grep -i 你的招牌
# 全域搜引用：除了它自己，還有誰在呼叫它
grep -rIl "你的招牌" ~/.openclaw/
紅旗：list-timers 一條都沒有；grep 只撈到它自己，外加一個躺在 _archive/ 或 old/ 的 wrapper。沒有觸發源＝它不會自己醒來。
03 它宣稱的步驟順序，跟實際跑的順序一樣嗎
規劃的重點是順序。把腳本從頭讀一遍，標出「決定要做什麼」和「蒐集依據」各在第幾行。我們的 autopost 對外宣稱「先研究、再選題」，實際打開來，選題那行是用時鐘取餘數（POST_SLOT % 題庫數）先把題目定死了，研究那步在後面，而且抓哪個網址還是照著已經定好的題目去挑。順序是反的：不是研究完再決定寫什麼，是先決定寫什麼、再抓資料來填。
# 找「決定題目」和「做研究」各在第幾行，看誰先
grep -nE '選題|pillar|PILLAR=|research|summarize' 你的招牌.sh
紅旗：決定要做什麼那行，排在蒐集依據那行之前。你的「先規劃後執行」其實是「先拍板後補作業」。
招牌功能體檢清單
對你自己最得意的那支 agent 或腳本跑一遍：
- 它最後一次真的執行是哪天，你答得出來嗎（不是「它會跑」，是「它上次跑」）
- 有任何 timer / cron / service 在觸發它嗎，還是只能靠人手動敲
- 全域 grep 它的名字，除了自己還有誰引用，那些引用是活的還是躺在
_archive/ - 它產出的資料檔，最後一筆的日期新鮮嗎
- 它宣稱的步驟順序（先研究後選題），跟原始碼從上到下的實際順序對得上嗎
- 你對外介紹它時的印象，是這週驗證的，還是它上線那天的快照
這一章的四句話
- 招牌 artifact 可能只是擺著好看。程式碼沒壞不等於它還活著，要問的是「上一次真的跑是哪天」。
- 會不會跑，跟有沒有東西在叫它跑，是兩回事。沒有 timer、沒有 cron，再漂亮的 agent 也只是等人手動敲的殼。
- 宣稱的步驟順序要跟原始碼對帳。先拍板再補研究，不是規劃，是倒著跑還講得像正著跑。
- 對招牌功能的印象，最容易停在上線那天。每隔一陣子親手驗一次它的觸發源和最後執行時間，別讓記憶當現況用。
原始碼位置：~/.openclaw/scripts/agent-meeting.py（招牌規劃 agent，最後執行 2026-04-03，無 timer 觸發）；唯一引用它的是 ~/.openclaw/scripts/_archive/discord-agent-chat.sh（封存資料夾裡的 wrapper）。順序反轉的證據在 ~/.openclaw/scripts/moltbook-autopost.sh（pillar 由時鐘取餘數先定，research 在後）。
這是《Agentic Design Patterns》× 龍蝦艦隊系列。我們照書把一人公司的 AI agent 艦隊系統化，然後對自己做對抗式稽核。宣稱做到的每一章，都被重新驗證過一次，也把查法和改法整理成你能照著跑的步驟。這個系列的可信度，來自我們願意公開自己打臉自己。