用途：monitor 用于在单个回合内持续轮询某个可检查的条件，直到出现明确结果，而不是结束回合后只留下“我会盯着，好了告诉你”这类无法兑现的承诺。
主要能力：循环按 sleep→check→decide 重复执行；支持四种结果分类：DONE（完成）、NEEDS ATTENTION（需人工介入）、NOT YET（继续）、超时停止；默认间隔 60 秒、最长 2 小时，未明确说明时不超过 4 小时；用户中途发言优先级高于循环，可停止、修改参数或提问。
使用方式：先确定四个参数——检查对象（命令、URL、日志路径、进程名或 CI run id）、完成条件、需关注条件、间隔与最长时长。默认通过子代理执行循环，调用形式为 delegate(agent="self", context_depth="none", model_role="fast", instruction=...)，子代理指令必须自包含，并明确写入“SEQUENTIAL ONLY”要求：每次只做一次检查，等待结果后再决定下一次，禁止并行或批量检查。也可在需要用户实时观察、判断完成需要本会话上下文、或总时长不足约 1 分钟时改为内联执行。
适用场景：监视构建、CI 状态、进程、日志行、URL 或命令输出等具体且当前可检查的条件，且用户要求持续跟进而非一次性回答。
限制：子代理派发存在约 40 秒延迟，无法更早发现结果；子分钟级间隔意义不大；检查本身连续失败 2 次以上、条件已明确失败、两次细化后仍无法判断完成与否、或需要破坏性/不可逆决策时，应停止并上报；不要每次迭代都粘贴完整日志，优先使用退出码、grep -c、HTTP 状态码、tail 等小信号；最终消息首行须以 DONE、NEEDS YOU、GAVE UP 或 PAUSED 开头且不超过约 100 字符，因为通知正文取自首行。若系统给出迭代上限提醒，应视为提前停止并如实报告。