你同時開了幾個 Claude Code 或 Codex Session。它們都改好了程式，接著要編譯、跑測試，卻得輪流等同一個編譯槽。有個 Agent 每隔一會兒就查一次日誌：「輪到我了嗎？」日誌還是那一句等待訊息，它卻已經多跑了一個模型回合。
等候本身不花 token；反覆叫醒 Agent 查進度才會。 Clawdline 的 Heavy Work callback 把這段等待交給本機常駐服務。Agent 可以先停下來，等指令執行完畢，再由通知叫回來看結果。
把測試交出去，Agent 先停下來
在 Go 專案裡，Agent 可以這樣跑測試：
clawdline heavy -- go test ./...heavy 會等編譯槽與可用記憶體。資源一到，才執行測試。如果 Root Session 當下得排隊，Clawdline 預設會把指令交給 callback，讓 Agent 結束這一輪。螢幕出現 callback <id> started，而指令以 76 結束，就表示交接成功；記下 ID，等完成通知。若以 75 結束，表示等候逾時，測試尚未執行。
這段期間，你可以從 Session 狀態看出它在等 callback 的結果。它不需要你回覆，也不需要另一個 Agent 替它盯著編譯槽。
那一晚，98 次查詢可以省下來
我們查看 Clawdline 在台灣時間 2026 年 10 月 6 日 20:00 到 7 日 04:00的紀錄。相鄰兩段半小時內，各有 14 個不同 Session 發出編譯或檢查指令。整晚 408 次成功取得編譯槽的請求中，有 239 次等了至少五秒。
再看 Agent 怎麼度過這些等待。我們從 Claude Code 和 Codex 找出 29 組反覆查看同一份背景編譯或檢查日誌的紀錄。原作法共查了 127 次，輸入與輸出合計 15,045,273 個 token。如果每組改成完成後才回來查一次，就只需 29 次。以下用每組最後一次查詢的實際用量，估算那一次完成查核。
| 同一批 29 組等待 | 模型回合 | 輸入＋輸出 token | 相對用量 |
|---|---|---|---|
| 反覆查詢，實際紀錄 | 127 次 | 15,045,273 | 100% |
| 完成後查一次，Callback 估算 | 29 次 | 3,869,321 | 25.7% |
少掉 98 次查詢，估計少用 11,175,952 個 token，也就是這批等待回合的 74.3%。 這個比例只比較同一批等待回合；編輯程式、寫測試等工作沒有算進來。
Token 省在哪裡
編譯槽不會因 callback 而提早釋出。差別在於誰負責等：本機常駐服務可以一直等，不必把「還沒好」送進模型。Agent 每少問一次，就少一次重新帶著對話脈絡讀日誌的回合。等候越久、原本查得越頻繁，這個差別越明顯。
已經開始的 CI 工作也可以交給 callback 等結果，例如：
clawdline callback --title "CI run ended" --timeout 45m -- gh run watch RUN_ID --exit-status把 RUN_ID 換成真正的執行 ID，並確定 gh 能從自己的設定讀到登入資料。callback 不會帶走 Agent 的整份環境變數。需要 Agent 邊看輸出邊決定下一步的工作，則留在可互動的 Session。Heavy Work 自動交接目前用於排隊中的 Root Session；macOS 與 Linux 可以使用 callback，Windows 目前尚未支援。
通知到了，讀一次結果
完成通知帶回 callback ID。Agent 執行 clawdline task show <id>，看退出碼與輸出末段，再決定下一步。測試失敗就讀錯誤，成功就接著驗收。通知負責把 Agent 叫回來；工作是否已審查與落地仍由後續流程確認。
下次測試在等編譯槽，看到 callback ID 就讓 Agent 停下來。等結果到了，再查一次。