Agent 睡覺也在跑之後，我學到的幾件事
最近把幾個 agent 改成排程後台跑，結果某天早上起來發現它跑了一整晚、把一個 API 的 quota 全部打完了。沒有壞掉，邏輯也沒錯，就是靜默地做了我沒預期到的量。
那次之後我認真重新想了一下，個人開發者在跑 autonomous agent 的時候，到底要在哪些地方設防線。
整理成幾個我現在實際在用的做法：
第一個是停止條件要硬編，不要信任 agent 自己知道「夠了」。我現在的習慣是跑任何會 loop 的流程前，先設三個上限：時間上限、iteration 數上限、費用上限（用 token count 估）。三個只要觸一個就強制停。這個聽起來很基本，但我以前就是嫌麻煩跳過，然後就出事了。
第二個是 structured logging 比你想像的重要。agent 的行為不像一般程式那麼線性，出問題的時候 stack trace 常常沒什麼用，你需要的是「它在做哪個決策的時候走錯方向」。我現在每個 action 都會 log：輸入是什麼、為什麼選這個 tool、輸出結果、下一步是什麼。有了這個，事後 debug 才有辦法做。
第三個是 dry run 模式。跑新流程之前，我會先讓 agent 跑一次「只描述要做什麼，不實際執行」的版本，確認它的行動計劃跟我預期的一樣，再開真的。這個做法在 agentic engineering 的討論裡被歸類在比較進階的「human-in-the-loop checkpoint」，但其實實作很簡單，就是在 system prompt 加一段 + 把所有有副作用的 action 先 mock 掉。
最後一個是通知機制。我現在跑的 agent 如果超過 5 分鐘沒有 progress（沒有新 action log），或者 error rate 超過某個閾值，會自動發通知給我。不需要很複雜，一個 webhook 打 Telegram 就夠了。重點是我睡著的時候它還是有機會叫醒我。
說到「levels of agentic engineering」這個概念，我覺得蠻有用的分類框架。新手容易直接跳到最複雜的 fully autonomous 模式，但其實大多數場景在 semi-autonomous 就夠了，而且 debug 和維運成本差很多。先把 level 1、2 做好，再考慮要不要往上走。
我現在跑的幾個 agent 穩定多了，但說實話還是不敢完全放手。每次看到早上的 log 都還是會捏一把冷汗。（這大概就是個人開發者的日常）
作者：AutoKitty