AI Engineering
Codex wait_agent 的 Token 黑洞：空輪詢如何反覆計入父層 Context
Codex 多代理的成本異常可能來自父代理每 30–60 秒重入模型、重送龐大 context，而不是 subagent 本身。社群 636k token 案例有官方 GitHub issues 的同類證據支持，但數字仍屬個別 trace。
2026年9月8日1 分鐘閱讀👁 12
Codex / Multi-Agent Cost
真正燒額度的可能不是子代理，而是父代理一直醒來問「好了嗎？」
Threads 作者回報兩次 luna 子代理期間，4 次空輪詢重新處理 636k input tokens。這個精確數字是個別 telemetry；但 OpenAI Codex GitHub 已有多個同類 issue：wait/status timeout 會讓父代理重新進入模型、帶入大段 cached context，再發出下一次等待。
成本形成方式
1. 子代理仍在跑
父代理呼叫 wait_agent，預設或短 timeout 到期時回傳 timed_out。
2. 父模型被喚醒
即使沒有新結果，也可能重新取樣一次，重新讀取龐大父層 conversation prefix。
3. 反覆輪詢
每 30–60 秒一次，長任務會累積大量 cached input；有折扣不代表免費，絕對量仍可耗盡配額。
官方 issue 證據：#35259 回報 wait/status-only turns 佔一個完整 usage window 原始 token 量 19.8%；#36379 主張把預設等待由 30 秒提高到 5 分鐘；#41875 進一步建議與 GPT-5.6+ 至少 30 分鐘 prompt-cache TTL 對齊。這些仍是 GitHub issue／使用者 telemetry，不等於官方已承諾所有版本都採用同一修正。
實務修法
- 優先使用事件完成通知；不要用高頻 busy polling。
- 需要等待時，一次給數分鐘，而不是每 30 秒喚醒父模型。
- 父代理等待期間做其他獨立工作；完成訊息回來再整合。
- 長命令放在 subprocess／background process 內，工具只回傳 bounded summary。
- 記錄每個 parent turn 的 cached input、uncached input、output 與 tool-only turn，別只看總 token。
- 限制最大 fan-out、等待總時長與重試次數，避免「代理管理代理」比工作本身更貴。