用途
hang-check 针对的场景是：一个被派发的后台子智能体可能卡住——它停止推进却始终不返回。该技能安装一个周期性检查，用来捕捉真正的卡死（hang），同时不打扰运行缓慢但仍在工作的智能体。其核心原则是依据证据而非时钟判断：单凭已用时间从来不能证明卡死，因为一次耗时较长的编译、模型加载或远程等待，若只看计时器，看起来与卡死的智能体完全一样。
适用场景
- 一个或多个后台子智能体正在运行，且可能运行较久。
- 用户要求看门狗、hang 检查，或“如果某个智能体卡住了就告诉我”。
不适用场景：没有活跃的后台子智能体时；逐轮驱动单个前台任务时；用户希望实时逐事件日志流时（此时应使用 Monitor 工具）。
定时器
- 使用 CronCreate 建立周期性检查，使用 CronDelete 移除。
- 在第一个被监视的子智能体启动时，只设置恰好一个周期性任务。一个看门狗覆盖所有活跃智能体，不要设置第二个。
- 每 10-15 分钟一次适合大多数工作；只有当智能体完成得很快时才缩短间隔。
- 任务提示会重新进入本技能：“Run hang-check: review each active subagent's status, recent output, and file activity; investigate any agent that looks stuck; remove the timer if no subagents remain active.”
- 记录返回的任务 ID 以便清理。
- CronCreate 任务会在 7 天后自动过期；如果被监视的工作可能运行更久，需告知用户。
证据与判断
每次检查时，对每个活跃智能体最多读取三类信号：
- 智能体状态：通过 TaskList / 智能体状态查看，取值为 running、completed 或 errored。
- 最新输出：查看最新若干行（TaskOutput 或输出文件），判断是否在推进。
- 文件活动：在相关工作区查看新增或变更的文件 / mtime（修改时间），需视情况而定。
文件活动只有在预期智能体会改动文件时才算证据。一个正在调研、阅读或等待远程调用的智能体，即使健康也可能没有任何文件变更；不要把缺少文件变更当作卡死。
只要任一相关信号在推进，就视为健康：不要干预。若所有相关信号都静默，且静默时长相对该任务的节奏异常地长，则怀疑卡死：进行调查，但先不要停止它。“异常地长”是相对于任务而言，而不是固定数值。
先调查再停止
在动手处理疑似卡死的智能体之前：
- 完整阅读其最新输出。一段堆栈跟踪、一个等待输入的提示，或一行“downloading...”都会改变诊断结论。
- 检查它是否正合理地阻塞在一个长时间操作上。
- 当预期应有文件时检查文件 mtime：几秒前刚被改动的文件意味着工作仍在进行，即使 stdout 没有输出。
只有在证据确认确实卡死后，才对智能体执行 TaskStop。不要自动重新派发它：需要决定是恢复、替换还是取消该工作。当任务已过时、已被另一个智能体完成、重复执行不安全，或依赖非幂等操作时，重新派发是错误的。报告证据显示了什么，而不仅仅是采取了什么动作。
清理
每次检查后，如果没有子智能体仍处于活跃状态，使用记录的任务 ID 通过 CronDelete 移除定时器，并用 CronList 确认，确保没有遗留的看门狗继续触发。只有在派发了新的子智能体时才重新设置。
工作流程
- 确认一个或多个后台子智能体处于活跃状态；若没有，停止。
- 设置一个周期性 CronCreate 看门狗；记录任务 ID。
- 每次触发时，为每个活跃智能体读取相关证据信号。
- 对在推进的智能体不做干预；标记所有相关信号都静默的智能体。
- 对每个被标记的智能体，先调查再行动。
- 对确认卡死的智能体执行 TaskStop，然后决定恢复、替换还是取消。
- 没有子智能体仍活跃时，用 CronDelete 删除定时器；并用 CronList 确认。