在使用 /loop 和 Cron 调度系统时，每个任务在其生命周期中会经历多种不同的状态。正确理解这些状态是进行有效监控的前提。当系统中运行着多个并发的循环任务时，掌握每个任务所处的状态可以帮助我们快速定位问题、评估系统健康度，并做出合理的调度决策。
| 状态 | 状态标识 | 含义 | 典型场景 |
|---|---|---|---|
| 运行中 | running |
任务当前正在执行，尚未完成 | 循环任务正在执行提示词、调用外部 API 或处理数据 |
| 等待中 | waiting |
任务已调度，等待下次触发时间 | Cron 任务在两次执行之间的空闲期，等待特定时间点触发 |
| 已完成 | completed |
一次性任务已成功执行完毕 | 单次 Cron 任务或已被手动停止的 /loop 会话 |
| 失败 | failed |
执行过程中出错、超时或发生异常 | API 调用超时、脚本执行出错、网络中断导致任务中断 |
| 已停止 | stopped |
被用户手动或系统自动终止 | 用户主动结束 /loop 会话，或系统检测到异常后自动停止 |
当任务处于运行中状态时，表示系统正在处理该任务的执行逻辑。对于 /loop 任务而言，这意味着 AI 正在执行提示词中的指令——可能是查询数据、分析结果或生成报告。长时间处于运行中状态未必是异常，但如果某个任务的单次执行时间远超历史平均水平，就需要引起注意。一般来说，大多数常规任务在几秒到几分钟内完成，长期处于运行中的任务可能存在死循环、外部依赖阻塞或资源耗尽等问题。
等待中状态是循环任务的"常态"。一个健康的 /loop 任务在大部分时间里都应该处于等待中状态，这表示任务按计划在正常进行。等待中的任务会在后台由调度器管理，系统会记录其下一次触发时间。如果任务一直停留在等待中而从未进入运行中，可能意味着调度器出现了问题——比如触发条件被意外修改、系统时钟偏差或调度队列阻塞。
失败状态通常表示任务在自动执行过程中遇到了错误——可能是外部服务不可用、脚本抛出了未捕获的异常、或者执行超时达到系统限制。失败的任务可能会根据配置自动重试。而已停止状态则代表任务的终止是人为或系统策略触发的——用户手动结束了 /loop 会话、管理员取消了 Cron 作业、或者系统清理策略终止了长期运行的任务。理解这两种状态的区别有助于制定正确的恢复策略：失败的任务通常可以自动恢复，而已停止的任务往往需要人工介入决定是否重新启动。
CronList 是监控系统中获取所有任务状态的核心接口。通过它，我们可以批量获取当前正在运行和已调度的所有任务信息，包括每个任务的状态、触发时间、执行次数等关键数据。定期轮询 CronList 是实现自动监控的基础。
调用 CronList 工具或命令可以获取当前所有循环和定时任务的完整列表。这个列表通常包含每个任务的唯一标识符、任务名称/描述、当前状态、创建时间、最后执行时间、下次触发时间以及累计执行次数等信息。建议将这些数据缓存到本地监控系统中，用于趋势分析和历史对比。
CronList 返回的数据通常是结构化的 JSON 或表格形式。解析这些数据时，需要重点关注以下几个字段：
单个任务的状态 snapshot 只能反映瞬间情况，真正的健康判断需要结合历史数据和上下文。以下是一些常用的健康判断规则：
建议使用一个独立的监控 /loop 任务来定期巡检所有任务的状态。这个"监控之眼"任务本身应该简单、轻量、高频率，专门用于检查其他任务是否健康。巡检频率建议设置为 5-15 分钟，既能及时发现异常，又不会对系统造成过大负担。巡检时，监控任务会调用 CronList 获取所有任务状态，然后逐一应用健康检查规则，发现异常时发出告警。
执行频率是衡量循环任务是否正常工作的核心指标之一。每个 /loop 或 Cron 任务都有其期望的执行频率——例如每 5 分钟执行一次、每小时执行一次。当实际执行频率偏离预期时，往往意味着调度系统或任务本身出现了问题。频率监控的核心目标是确保每个任务按照其配置的时间间隔稳定执行。
检查任务触发频率的最直接方式是比较 实际执行间隔 与 配置间隔。对于固定间隔的 /loop 任务，理想情况下实际间隔应该接近配置值（考虑到 10% 的随机抖动）。通过记录每次执行的时间戳，计算相邻两次执行的时间差，就可以得到实际执行间隔序列。如果实际间隔与配置间隔的偏差持续超过正常范围，说明调度可能存在问题。
执行频率异常通常表现为以下几种形式：
当检测到执行频率偏离预期时，需要根据偏离的程度和持续时间触发不同级别的告警：
| 偏离程度 | 判定标准 | 告警级别 | 响应动作 |
|---|---|---|---|
| 轻微偏离 | 间隔超过预期值 20%-50% | 警告 (Warning) | 记录日志，持续观察 |
| 中度偏离 | 间隔超过预期值 50%-100% | 严重 (Critical) | 通知运维人员，检查调度器状态 |
| 严重偏离 | 间隔超过预期值 100% 以上 | 紧急 (Emergency) | 立即介入，检查系统是否正常，考虑重启任务 |
频率趋势分析可以帮助我们在问题恶化之前发现隐患。通过收集长期的历史执行间隔数据，可以绘制出每个任务的执行频率趋势图。趋势分析的关键指标包括：
异常状态检测是状态监控系统的核心功能。它的目标是在问题发生的早期就自动发现并告警，避免小问题演变成系统性故障。一个完善的异常检测系统应该覆盖多种异常模式，并能够根据严重程度自动触发相应的处理流程。
任务执行失败是不可避免的——外部 API 可能暂时不可用、网络可能出现波动、系统资源可能短暂耗尽。因此，单次失败通常不足以触发告警。真正需要关注的是 连续失败 的模式。当某个任务连续失败达到预设阈值（通常为 3-5 次）时，这说明问题不是偶发性的，而是存在持续性的故障。
需要注意的是，对于高频任务（如间隔小于 5 分钟的任务），连续失败的阈值可以适当提高（如 5-10 次），因为高频任务有更多机会自我恢复。对于低频任务（如间隔大于 1 小时的任务），阈值应该降低（如 2-3 次），因为每次失败都意味着更长的修复周期。
有时候任务既没有标记为失败，也没有被停止，但就是不再触发了。这种情况往往比明显的失败更危险，因为它不容易被常规的失败监控发现。检测这种"静默死亡"的方法是比较任务的 上次执行时间 与 当前时间，计算出自上次执行以来的时间间隔。如果这个间隔超过了配置间隔的某个倍数（通常为 2-3 倍），任务可能已经无声地停止了。
任务执行时间的异常增长是一个重要的前置预警信号。即使任务每次都成功执行，但如果执行时间在持续增长，往往预示着底层依赖正在恶化——数据库查询越来越慢、外部 API 响应时间增加、或者内存泄漏导致垃圾回收时间变长。通过记录每次执行耗时并计算移动平均线（如最近 5 次执行的平均耗时），可以构建出执行时间的趋势曲线。
每个任务都应该有一个合理的超时时间——超过这个时间仍未完成，系统应该强制终止并标记为失败。超时任务的数量统计可以帮助评估系统的整体健康度。如果系统中超时任务的数量在短时间内急剧增加，可能意味着存在系统性的问题，如底层基础设施故障、API 服务大面积中断或网络分区。
当系统中同时运行多个 /loop 或 Cron 任务时，资源使用监控变得至关重要。多任务并行执行会带来资源竞争，如果不加控制，一个任务可能耗尽系统资源，导致其他任务饥饿甚至整个调度系统崩溃。资源监控的目标是确保每个任务都能获得其所需的资源，同时系统的总体资源使用保持在安全范围内。
资源竞争是多任务环境中最常见的问题。当多个任务同时执行时，它们会竞争 CPU 时间片、内存空间、网络带宽和磁盘 IO。资源竞争的典型表现包括：
监控资源竞争的关键是在任务级别跟踪资源使用指标，并结合系统级别的总体指标进行分析。
CPU 和内存是最核心的两类计算资源。对于每个任务，应该监控其 CPU 使用率（包括用户态和内核态）和内存占用（特别是常驻内存集 RSS）。需要关注的关键模式包括：
建议为每个任务设置 CPU 和内存的使用上限。当达到上限时，系统应该自动限制任务资源或触发告警。例如，可以为每个 /loop 任务设置最大 CPU 使用率 50% 和最大内存 512MB 的限制。
磁盘 IO 和网络 IO 通常是任务性能的瓶颈所在。与 CPU 和内存不同，IO 资源的影响往往是全局性的——一个任务的大量 IO 操作可能会拖慢所有其他任务的执行。在监控 IO 时，需要特别关注以下指标：
| IO 类型 | 关键指标 | 异常信号 | 影响范围 |
|---|---|---|---|
| 磁盘读 | 读 IOPS、读吞吐量、读延迟 | 读延迟突增 10x 以上 | 所有依赖磁盘的任务 |
| 磁盘写 | 写 IOPS、写吞吐量、写延迟 | 写延迟持续升高，IO 队列深度增加 | 所有依赖磁盘的任务 |
| 网络发送 | 发送速率、连接数 | 连接数过高导致端口耗尽 | 调用外部 API 的任务 |
| 网络接收 | 接收速率、连接延迟 | 接收数据量异常增大 | 依赖外部数据源的任务 |
当系统中运行的任务数量达到一定规模时，即使每个任务的资源消耗都不高，累计的资源使用也可能非常高。因此，需要实施主动的资源限制策略：
核心要点总结：循环任务的状态监控是一个系统工程，涵盖任务状态分类、状态获取与巡检、执行频率监控、异常状态检测和资源使用监控五大方面。通过建立完善的状态监控体系，可以及时发现任务执行中的异常，在问题恶化之前进行干预。监控的关键在于建立基线、设定阈值、趋势分析和自动告警的完整闭环。最终目标是实现系统的自我诊断和自我修复，最大限度地减少人工介入的需要。