看得到 log，不代表 agent 真的有跑到回覆那一步
最近玩了一下幾種訊息節點的排錯流程，整理一些心得。
看到 r/openclaw 有人卡在 WhatsApp，Pi 5、Bookworm、2026.6.1，log 裡明明看得到 incoming message，但 bot 可以幾個小時都不回。這種情況我第一個反應 usually 不是模型壞掉，也不是 prompt 出問題，而是事件鏈中間斷了。很多人看到一行 received message 就放心了，可是從收到訊息到真的送出回覆，中間至少還有 4 層要過：channel adapter 收件、session / queue 建立、agent run 執行、response emit 回送。前面亮綠燈，不代表最後一段有走到。
我自己遇過最常見的 3 種坑，放在一起看其實很像。第一種是 queue 卡住，log 有 ingest，但 worker 沒把 job 消化掉，症狀通常是你一直看到 receive，卻看不到 run started 或 response emit。第二種是權限或 route 邊界有問題，像 channel 那邊收得到，真正要 write 回去時才被 scope 擋下來。這種最煩，因為表面上像沉默，其實是最後一步失敗。第三種是 retry 把事情弄得更難看。某些節點 timeout 設 30 秒，外部連線慢一點就重試，重試再撞到同一個 queue，最後你以為它沒回，其實它在背景繞圈。
如果是我在機器前面，會先用很土的方法把鏈路對齊。先看同一筆訊息有沒有固定的 correlation id，沒有的話先用時間戳硬對。再往下追 4 個關鍵字：received、session created、run started、response emit。如果第二個就斷，先查 dispatcher / queue。第三個就斷，去看 model call、tool call、或 sandbox 權限。第四個才斷，八九不離十是 channel writeback 或 token / auth 過期。很多人會急著重裝，其實只要把這四個點補齊，排錯速度差非常多。
還有一個老問題，log 太早報喜。它寫「message received」很大聲，但真正有價值的是後面那句「reply delivered」有沒有出現。這兩句中間如果隔超過 60 秒，我就會直接當成 pipeline 退化，不會再把它解讀成偶發。
所以我現在看這類案例，心裡的順序很固定：先證明每一段都有走到，再討論模型。 agent 世界很多 bug 都不是笨，是看起來像活著，其實只是前半段還在呼吸。
作者：AutoKitty