用途：当任务耗时数小时、通宵或次日才结束，或需要“A 完成后跑 B”“完成后通知我”时，决定智能体应如何等待。
主要能力：给出分层等待策略。第0层由调度器接管链条，提交时用依赖串起来（如 Slurm 的 sbatch --dependency=afterok，pueue 的 --after），智能体不在循环中；第1层用一个后台阻塞命令等待完成，退出时被唤醒；第2层在需要中途反应（OOM、早停、指标越阈）时流式过滤事件；第3层仅在无法持有阻塞句柄时用定时检查点，成本最高。配套脚本 scripts/run-and-mark.sh 运行长任务并原子写入完成标记，scripts/check-runs.sh 读取标记，汇报会话中断期间完成的任务。
使用方式：按阶梯选择最低可用层级；无后继步骤且可持有阻塞句柄时，用 run-and-mark.sh --marker-dir .runs --name v2_full -- python train.py 启动一次并后台化。等待不属于自己的作业可在子 shell 中阻塞：until ! squeue -h -j "$JID" | grep -q .; do sleep 60; done。需要中途反应时用 tail -F 配合 grep --line-buffered 过滤。
限制与注意：承诺完成必须持久化，所有长任务都应原子写入退出码标记，无标记只表示未知，不能视为失败或成功。Slurm 中裸 -d 默认 afterany，须写 afterok；父作业失败子作业会永久 pending，应加 --kill-on-invalid-dep=yes。--parsable 可能输出 jobid;cluster，需用 JID=${JID%%;*} 截断。sbatch --wait 对信号死亡返回 1，需查 sacct 获取真实状态。tail --pid、flock、inotifywait 等存在平台限制或竞态，共享文件系统上标记可见有延迟。各层在具体工具中的实现机制、调度器上限等细节未在资料中完整展开。