三个 Coding Agent 怎么等长任务

01 · The question

轮询本身没有错，模型陪着轮询才贵

这次问题来自一张 Grok 终端截图。Agent 已经工作了九分多钟，输入框上方还挂着 1 monitor still running。主会话看起来停了，后台的监控却没有消失。它像是在等 monitor 自己结束，随后再继续做事。

两分钟的测试查几次状态，影响可能不大。训练、视频生成或大型构建运行半小时以后，查询方式就值得单独看：shell 定时查进程只消耗本地资源，模型反复调用工具则还会增加请求、上下文和推理开销。轮询频率相同，参与等待的组件可能不同。

为避免混淆，下面把本地检查、模型查询和事件触发分别列出。

例如，每 45 秒通过 SSH 查询 worker，可以一直由脚本完成。只有脚本报告状态变化时才调用模型，与每次检查后都让模型判断是否继续等待，消耗的模型回合数不同。

02 · Grok Build

Grok 把等待交给 monitor，主会话等输出

Grok Build 的公开代码中，配置注册表把 Feature::AutoWake 映射到 features.auto_wake，默认开启。后台命令完成、subagent 返回或 monitor 产生事件后，空闲会话可以继续执行。

Monitor 工具的说明写得很直接。脚本的每一行标准输出都会成为一次主 Agent 唤醒。说明同时要求脚本控制输出量，只打印完成、失败或取消这类值得处理的状态。原始日志不能整段灌进去，带管道的过滤还要用行缓冲，免得事件在用户态缓冲几分钟。

截图里的 GPU 监控脚本正好符合这个设计。它每 45 秒通过 SSH 进入机器和容器，检查四个 worker。全部完成时打印 ALL_DONE，进程提前消失时打印 WORKERS_DEAD，其余时间保持安静。

while true; do
  check_workers

  if all_finished; then
    echo ALL_DONE
    exit 0
  fi

  if workers_died_early; then
    echo WORKERS_DEAD
    exit 1
  fi

  sleep 45
done

截图中的脚本仍在每 45 秒轮询，只是没有在每次检查后输出。全部完成或进程异常时，它才打印状态，让 Grok 检查后续产物；等待期间，用户仍可继续输入其他问题。

03 · Claude Code 2.1.241

Claude Code 先整理 stdout，再把通知放进主队列

Claude Code 没有公开同等范围的 CLI 源码。只看 Agent SDK 类型，可以知道 Monitor 接受哪些字段，却看不到进程怎样启动、输出怎样进入会话。我对本机安装的 2.1.241 可执行文件做了只读静态检查，没有执行未知代码，也没有附加调试器或拦截网络。

目标文件位于 ~/.local/share/claude/versions/2.1.241。它是 arm64 Mach-O，可执行文件大小为 325,055,632 字节。SHA-256 如下。

1495eb7c42d3b4451f5f1cd38b6d498d22a4a38c802bc2be5c1cf1795e64820d

这个哈希与 Anthropic 随 Agent SDK 0.3.241 发布的 darwin-arm64 清单一致。清单对应 Claude Code 2.1.241，Git 提交为 c87e2742fc9ad269ec8920460d00a091b1e410f0。文件签名的标识是 com.anthropic.claude-code，签发方为 Anthropic PBC。

实际代码藏在 __BUN 段里

这个 Mach-O 有一个约 255 MB 的 __BUN 段，里面保存了 Bun 打包后的 JavaScript。变量名经过压缩，Monitor 的入口、stdout 回调和消息队列仍能连成一条可达路径。下面是几个关键函数在文件里的字节偏移。

命令型 Monitor 从 MTT.call 进入 PTT。PTT 调用 QFe 启动 Bash，把 PBi.onData 交给 onStdout，随后用 U3t 把任务登记为 type: "local_bash" 和 kind: "monitor"。

onStdout: p.onData
// ...
kind: "monitor"

stdout 怎样合并成通知

SDK 的注释说每一行 stdout 都是事件。实际实现多了本地整理。HSl 按换行切开内容，非空行成为事件候选。短时间内连着到达的几行可以合成一条通知，原始缓冲区也有硬上限。

PBi 还维护速率桶：允许短时间连发 10 次，之后每两秒恢复一个名额。超限持续 30 秒时，客户端停止 Monitor 并生成内部提示。这些限制控制进入通知队列的事件量，因此监控脚本不宜直接转发全部训练日志。

next 决定事件什么时候进入模型

xwe 生成 Monitor event，再调用 enqueuePendingNotification。下面的两个队列字段说明它采用哪种通知优先级。

mode: "task-notification",
priority: "next"

主查询循环调用 getCommandsByMaxPriority("next")，把通知折进待发送的消息。最高优先级的 now 可以中止当前查询，Monitor 使用的 next 通常会等当前回合走到边界。它不需要模型反复查询，也不会在 stdout 一有字符时就打断正在进行的请求。

进程退出以后，ALm 等到命令结果，YIl 根据退出状态生成完成、失败或停止通知，仍以 task-notification 和 next 进入同一个队列。中途事件和最终完成由此汇到一处。

04 · Codex 0.149.1

Codex 把一次 poll 等得很久，下一次仍由模型发起

Codex 的实现可以直接在公开 Rust 源码里追。我没有用不断变化的 main 分支代替本机版本，检查的是 rust-v0.149.1 标签，对应提交 ff29a44391deccde0aba0f8390337d7f3c319ea4。

write_stdin 处理器把空输入定义为后台 poll。继续进入 process_manager.rs，空输入会走单独的等待范围。

if request.input.is_empty() {
    time_ms.clamp(
        MIN_EMPTY_YIELD_TIME_MS,
        self.max_write_stdin_yield_time_ms,
    )
} else {
    time_ms.min(MAX_YIELD_TIME_MS)
}

unified_exec/mod.rs 给出的空查询下限是 5,000 毫秒，默认后台终端上限是 300,000 毫秒。本机配置同样是五分钟。一次空查询因此可以挂住很久，原始命令若在这段时间结束，当前 poll 能直接拿到最终状态。

长 poll 减少了短间隔查询，但续接仍由工具调用推动。若当前回合已经交还用户，这里检查的普通后台终端完成路径通常只更新状态，不会单靠退出事件创建新模型回合。

源码里还能看到一个 awaiter.toml。它把后台终端上限提高到一小时，并要求 awaiter 重复调用工具，逐步增加等待时间。agent/role.rs 上方写着 Awaiter is temp removed，整段角色注册已经注释。0.149.1 默认角色表没有启用它，普通后台终端继续走 write_stdin。

05 · Side by side

三家都能等，模型参与等待的程度不同

对截图这类长任务，我更倾向让普通进程先等明确条件，再由 Grok 或 Claude Code 的 Monitor 通知模型。Codex 的长 poll 也能减少查询频率，但两种方式实际省下多少请求，需要结合任务时长和等待参数测量。

这个偏好限于文中检查的版本和监控场景。Grok 的公开代码展示了事件语义，Claude Code 的二进制包含输出整理与入队逻辑，Codex 的 Rust 源码则能直接追踪 poll；本文没有据此比较三款工具的整体能力。

06 · Practical watcher

长任务监控脚本应该尽量少说话

事件驱动也会被坏脚本拖累。训练进度每变一次就打印，Monitor 便会不断制造事件。实用的 watcher 只关心能改变 Agent 下一步动作的条件。

while true; do
  if test -f output/final.json; then
    echo DONE
    exit 0
  fi

  if ! kill -0 "$worker_pid" 2>/dev/null; then
    echo FAILED
    exit 1
  fi

  sleep 30
done

远端接口可按响应时效设置检查间隔，本地文件和进程另行处理；使用管道时还要留意行缓冲与 stderr。脚本应只报告会改变下一步动作的状态，否则事件通知也会变成高频查询。

07 · Boundary

Monitor 适合一段会话，长期作业仍要调度系统

Grok 和 Claude Code 的 Monitor 都受会话生命周期约束。关闭终端以后，后台任务不会随着恢复会话自动重建。Codex 的后台 terminal session 也不适合承担跨设备、跨重启的长期可靠运行。

半小时训练、一次 CI、一个 PR 状态或当前会话里的日志观察，很适合交给 Monitor。几天后的定时任务、机器重启后还要继续的训练、需要审计和重试的生产作业，应该交给 CI、守护进程或调度系统。Agent 接收终态，再做解释和后续动作。

这次先定位了等待和通知发生的位置。还需要继续追问：进程结束以后，事件只更新了界面，还是进入模型输入并开启了下一回合？后续检查会沿这条路径展开。

08 · Sources

源码与版本依据

• Grok Build Monitor 工具实现Monitor 描述、后台任务和 stdout 处理管线
• Grok Build 后台任务说明Monitor 事件、输出控制和 still-running 状态
• Grok Build AutoWake 配置features.auto_wake 的默认值和注册位置
• Claude Agent SDK 0.3.241 发布清单Claude Code 2.1.241 的平台二进制校验值
• Claude Agent SDK Monitor 类型公开输入、输出和超时契约
• Claude Agent SDK 后台任务消息类型任务通知与最终状态
• Codex 0.149.1 的 write_stdin 处理器空输入作为后台 poll 的入口
• Codex 0.149.1 后台终端等待实现空查询的等待范围
• Codex awaiter 配置独立 awaiter 的轮询方式
• Codex 默认角色注册0.149.1 中 awaiter 暂时移除的状态