AI coding agent 的額度，要留到驗證做完
假設一個小型 SaaS 的結帳頁，在切換幣別後顯示了錯誤的小數位。開發者請 coding agent 修正，幾分鐘後就拿到一份看起來合理的 patch。接下來還得拿不同幣別的測試資料檢查顯示結果，確認重新整理後狀態沒有跑掉，才知道這份改動能不能留下。偏偏 agent 的額度在這裡用完了。
畫面上已經有程式碼，工作卻停在最難回答的一步：它到底修好了沒有？
我會把這種情況當成派工問題，而不急著比較哪個方案比較划算。給 agent 的工作若只寫「修好幣別切換」，額度一旦中途耗盡，就很難判斷該繼續付費、換工具，還是自己接手。完成條件必須在開工前寫清楚，尤其是收尾那一段。
把可驗收的結果當成容量單位
一次任務至少要容納實作、必要檢查，以及檢查失敗後的處理。這不是要預估精確的 token 數，更不是假設每件事都能在固定輪數內修完；不同服務的計量方式與剩餘額度，本來就不一定清楚。要預留的是退路：如果 agent 無法做完，留下的東西能否由人驗證，或安全地縮成較小的工作？
回到結帳頁，派工可以先限在一條幣別切換流程，指定要比對的測試資料與預期顯示方式，要求交回改動檔案和實際跑過的檢查。暫時別把價格顯示修正和結帳狀態的大規模重構綁在同一個指令裡。前者做完後有明確的檢查點；兩件事混在一起，即使 patch 產生了，也不容易在額度見底時切開。
遇到測試失敗，可以給 agent 一次範圍明確的修正機會；如果容量已經不確定，先由人跑最關鍵的檢查，比繼續開新任務或增加平行 agent 更穩妥。這裡的「預留」不保證任務一定成功，只是避免生成程式碼用完所有餘裕，讓驗證變成無人負責的尾款。
可切換工具，不能轉移信任
Android Studio 的 Bring Your Own Agent 預覽，讓開發者透過 ACP 選用符合協定的 agent；遇到額度或表現問題，可以改選另一個。這對受單一工具限制的工作流很有用。不過，介面上的切換入口並不表示另一個 agent 已經知道前一個改了什麼，更不表示測試結果、訂閱額度或授權會跟著轉過去。
JetBrains Air 把跨 agent 的政策、成本可見性與稽核放進產品方向，提醒團隊：換工具和弄清楚花費、責任落點，是不同的問題。Coder 則提供自管 agent 工作與模型存取控制的另一種路徑；自己管理執行環境也不會讓成本自動消失。對小團隊而言，不必先建一套治理平台，但至少要能說明目前的工作停在哪裡。
如果結帳頁的額度已經用完，我會先把 patch 標成「待驗證」，盤點當前程式庫狀態，再決定要不要換 agent：
記下目前的版本與 diff，區分已修改、尚未修改的部分。
留下跑過的檢查指令與結果；沒跑的測試就明寫「未執行」，不要寫成通過。
列出下一步要核對的幣別顯示、重新整理後狀態，以及還需要人判斷的地方。
接手的人可以先用既有的測試資料核對幣別顯示，再跑窄範圍前端測試。如果仍有失敗，才把具體的失敗結果交給另一個 agent 處理。新工具應從現有檔案與檢查結果開始，而不是接收一句「上一個 agent 說快好了」就繼續寫。
停在清楚的位置，也是一種完成能力
額度不足時，合理的結果有時是縮小範圍，有時是交回人手，也可能是把未驗證的 patch 留在分支上暫停。這些決定都比默默把「已產生」當成「已修好」好。尤其碰到結帳流程，沒有證據就合併，比晚一點交付更難收拾。
下次把任務交給 agent 前，可以先問一個很小的問題：假如它在驗證前停下，我手上會有足夠的檔案、指令和結果，把這件事接完嗎？若答案是否定的，現在就該縮小任務，而不是等額度歸零再想辦法。