改一下Agent文件,就能让你的Codex长任务节约25%的Token😲?话说最近经常用Codex跑一些长期任务,在目标模式下,感觉Token消耗比以前高了,即便有重置,有时候也顶不住。后面在推特上看到一个帖,简单说就是在长任务中,Codex并不是等那些执行的程序或者子代理完成了这一轮的任务才开始下一轮的回复,而是会每隔30秒主动去询问程序是否已经完成工作,然后每一次主动询问都会完整地载入原来的上下文,导致大量的Token浪费。 你可以把以下这一句话发给你的Codex,然后让他避免这个行为。把定时轮询延长到3分钟一次。(但是如果这期间loop任务已经完成了,它也会被主动触发回复;主要的影响是如果子任务卡死了,codex发现的时间也要从30秒延长到3分钟😂)
→x原文:
x.com👉我的改进版(丢给你的codex):
检查我们的codex在运行过程中是否有以下问题:“最近版本新增的 JS tool,在执行异步任务时默认高频等待。任务明明还没跑完,模型却被一遍遍叫醒,Token 就这么白白烧掉了。”
如果有,把以下内容添加到全局 agent.md:
## Long-running asynchronous work
- Empty `write_stdin` polls and `functions.wait` MUST use
`yield_time_ms >= 180000`; prefer `300000` when intermediate output
is not needed.
- A `functions.exec` cell awaiting nested tools MUST set a first-line
`// @exec` pragma. Its outer `yield_time_ms` must exceed the nested
critical-path wait by at least 30000 ms: use the maximum for parallel
waits and the sum for sequential waits.
Example for one 300000 ms nested wait:
`// @exec: {"yield_time_ms": 330000, "max_output_tokens": 10000}`
- One initial wake to receive an `exec_command` session ID is acceptable.
After that, use long status-only polls.
- Put frequent status checks inside one bounded child-process loop.
Do not wake the model for every polling interval.
- Set an overall timeout or deadline for every long-running workflow.
- Do not apply long waits to non-empty `write_stdin` calls, interactive
prompts, or genuinely time-sensitive decisions.
- Give one progress update before waiting. Do not wake the model merely
to report that work is still running.
- These tools return early when the process or cell completes.