我给自己的服务器排过一个夜班表，内容是每晚检查一遍磁盘余量、看几条关键日志里有没有报错、确认证书还剩多少天。这张表以前是靠一个shell脚本加系统定时任务实现的，能跑，但只会按写死的逻辑跑：检查磁盘就看阈值，看日志就grep关键字，超出范围它就什么都做不了，第二天我看到的只是一行“磁盘使用率85%”。这类智能体最值得用的地方，就是把这条线往后延了一段——它能在检查完之后自己判断要不要做点什么。
不过要讲清楚它的调度是怎么跑的，否则你会把期望放错地方。按官方文档的说法，定时任务是网关进程内置的调度器，它持久化任务、到点唤醒智能体、并且可以选择把输出投递到聊天频道、Webhook或者干脆不投递。关键的一句是：调度器运行在网关进程里面，不在模型里面，网关必须处于运行状态，计划才会被触发。所以它不是“关机了也能干活”，而是“终端断开了它也照样干活”。
它把任务存在磁盘上，不怕重启
任务定义、运行状态和运行历史都持久化在共享的数据库里，重启不会丢计划；从旧版本升级过来时，还有一个命令可以把旧的配置文件导入并改名备份，导入之后再去改那个旧文件就不生效了，要用命令行或接口来改。这一点对夜班任务是刚需：定时任务一旦丢了，你不会发现，直到某天出问题才想起来“好像很久没收到报告了”。
调度方式有四种：指定一个时间点的一次性任务；按固定间隔重复，比如每十分钟、每小时、每天；用cron表达式的定时任务，可以带时区；还有一种是监视某条命令退出时触发。时间戳如果不写时区，会被当作UTC处理，想按本地时间跑就得显式给时区。这个细节很容易踩：你的“每天早上九点”如果在没设时区的情况下写成九点，实际跑的时间可能和你想象的不一样。
两个和标准cron不同的行为值得单独记住。第一，顶层的整点表达式会被自动抖动，最多错开五分钟，目的是避免大量任务在同一秒集中触发；如果你要求精确时间，可以强制关闭抖动，或者自己指定一个抖动窗口。第二，日期字段和星期字段同时写了具体值时，采用的是“或”逻辑而不是“与”——也就是说，“每月15号并且是周一”这种意思表达不出来，实际效果会变成“每月15号，以及每个周一”。这个坑来自标准cron的历史行为，写表达式时如果两个字段都不是通配符，就该重新想一遍你的本意。
任务跑在哪里也有讲究。一种是跑在主会话里，做法是排入一个系统事件，等到下一次心跳时执行，用的是主会话的上下文；另一种是隔离运行，单独跑一次智能体轮次，结果可以播报到某个频道或者不播报。给夜班用的建议是隔离运行：它不干扰你白天的主会话，跑完自己收摊，输出投到固定频道里，第二天你翻记录就能看到这一晚发生了什么。
隔离运行在收尾上做了不少事，这些恰恰决定了无人值守能不能放心。运行结束时会尽力关闭自己在这次计划里开出来的浏览器标签和进程，也会释放为这次任务创建的运行时实例，避免留下孤儿进程。它还会防备“回了个废话就当完成”的情况：如果第一次返回的只是“我来处理”“正在汇总”这类中间状态，而且没有后续的子任务负责最终答案，它会再追问一次要真实结果，然后再投递。任务级别的失败也计入错误，会触发失败通知，而不是被当成成功悄悄清掉。
超时这块分三种情况。隔离的智能体轮次任务，如果没有指定超时，先由调度器自带的六十分钟看门狗兜住，底层那套更长的超时根本轮不到生效；命令类任务默认十分钟。启动时如果发现有已经过期的隔离任务，它会被重新排期，而不是立刻补跑一遍，这样重启的那几分钟不会被一堆积压任务挤满。这些设定说明它是按“长期挂着跑”设计的，而不是按“点一次跑一次”设计的。
最后是排班本身。夜班任务不要排太密，检查类的半小时一次就够，报告类的每天一次，清理类的每周一次。每个任务的落点要能看出来“它到底做过什么”：不能只让它去看一眼，要让它输出结论，比如磁盘还剩多少、哪条日志出现了新错误、证书还有多少天。还有一个实际经验：让任务在出问题的时候才吵你，正常的时候静默。夜里三点收到“一切正常”的推送，比收到报警更快地教会你关掉通知。
用外部系统定时器去调命令行的时候，官方文档提醒要加一层硬杀兜底，比如给超时命令再配一个强制终止的时间，systemd那边则要留出停止的宽限期。原因很实际：智能体任务可能卡在一个外部调用上不动，没有兜底的话，下一次调度会撞上一次还没结束的运行，越堆越多。这类细节决定了你的夜班是替你干活，还是变成一个需要你照看的另一个系统。
A5创业网 版权所有