防静默任务调度方法、系统及程序产品与流程

本发明涉及人工智能，特别是涉及一种防静默任务调度方法、系统及程序产品。

背景技术：

1、现有面向大语言模型智能体的防静默任务调度方案，通常基于传统定时任务框架进行构建，包括操作系统级cron服务、通用作业调度器（如apscheduler、celery beat等开源框架），以及云原生批处理平台（如分布式工作流调度引擎）。其基本工作模式为：调度器按预设时间表触发脚本或进程，由该脚本或进程调用大语言模型接口完成智能分析、内容生成、知识库更新等业务逻辑，执行结果写入日志文件，依赖运维人员定期人工检查。

2、部分现有方案引入简单的心跳监控，通过定期探测服务进程是否存活来判断系统健康状态；另有方案设置任务超时告警，当任务运行时长超过阈值时向运维渠道发出通知；还有方案在任务完成后向消息通知渠道推送成功通知，但任务未完成时同样静默，缺乏主动感知机制。

3、在本地推理服务资源管理方面，常见做法是在服务器启动时即加载模型、保持常驻运行，以降低任务调用延迟；或完全依赖外部托管云端大语言模型接口，不涉及本地模型的生命周期管理。

4、上述现有技术方案在实际工程场景中暴露出若干深层问题，其中最难排查的是静默失败。传统调度框架只能感知进程级别的存活状态，无法触达逻辑执行层。以常见的分布式工作流调度引擎为例，其内置的任务重试与 sla 告警机制仅针对任务进程本身：当大语言模型接口返回空响应、知识库写入被静默丢弃、推理超时被异常捕获后直接跳过时，调度框架完全无从感知。这类失败往往无声无息。运维人员有时要到第二天查日志才发现昨晚的知识库更新任务压根没跑出有效结果，进程退出码是0，什么告警都没有，数据已经悄悄陈旧了数小时。

5、漏跑的问题同样缺乏自动补救。系统重启、网络抖动、依赖服务短暂中断，都可能导致定时任务在预期窗口内未被执行。apscheduler等框架提供的`misfire_grace_time`机制仅控制单次漏跑的容忍窗口，并不具备对积压漏跑的限速能力。假设服务器维护了两小时，重启后多个积压任务同时触发，系统资源会在短时间内被大量并发请求打满，补跑本身变成了新的故障源。

6、还有两类结构性问题在长期运行中持续积累。其一是执行记录与调度配置的不一致：两者分散存储，写回失败或并发竞争都会导致配置中的“上次执行时间”与实际执行记录对不上，进而引发重复触发或遗漏触发，且不一致状态会在无人察觉的情况下越堆越多，溯源极为困难。其二是本地推理服务的资源管理混乱：大语言模型推理服务对计算资源的占用不可忽视，常驻运行模式在任务间隔期持续空转；多任务并发时各自独立启动推理实例、互相不感知、资源不释放，最终耗尽系统可用资源。

7、此外，现有方案在异常处理上只支持单向告警推送。当调度系统检测到需要人工介入的情况时，运维人员收到通知后无法直接通过即时通讯工具回复指令来触发执行，只能登录系统手动操作。更关键的是，告警发出后如果用户没有响应，系统既没有超时机制，也没有自动降级策略，任务就这样一直挂着，等待一个不知道什么时候才会来的人工确认。

8、因此，亟待发明一种新的防静默任务调度方法，以解决现有技术无法自动发现和修复静默失败的问题。

技术实现思路

1、有鉴于此，本发明实施例提供一种防静默任务调度方法、系统及程序产品，至少部分解决现有技术中存在的问题。

2、本发明的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本发明的实践而习得。

3、为了实现上述目的，本发明实施例提供如下技术方案：

4、根据本发明实施例的第一方面，提供了一种防静默任务调度方法，所述方法包括：

5、按照预设周期对任务配置集合中的各条任务进行三重过滤，输出通过三重过滤的待触发任务，向执行记录数据库幂等写入待触发任务对应的幂等键和等待状态执行记录，并向宿主守护层异步发送执行通知，所述幂等键包括任务标识和触发时间窗口；

6、在接收到执行通知后，针对存在等待状态执行记录的待触发任务，调用对应的处理器执行所述待触发任务，得到任务执行结果。

7、在一些实施例中，所述任务配置的字段包括任务标识、cron表达式、触发类型、冷却期、补追窗口、主机约束以及执行时间戳；

8、所述三重过滤包括主机约束检查、冷却期检查以及触发类型匹配，所述主机约束检查用于过滤非本节点任务，所述冷却期检查用于防止同一任务在冷却期内被频繁重复触发，所述触发类型匹配用于判断任务触发类型是否与预设类型相匹配。

9、在一些实施例中，在接收到执行通知后，针对存在等待状态执行记录的待触发任务，调用对应的处理器执行所述待触发任务，得到任务执行结果，包括：

10、在接收到执行通知后，对存在等待状态执行记录的待触发任务进行预检查处理，判断本地推理服务是否正在运行；

11、若本地推理服务正在运行，则进行执行流程；

12、若本地推理服务未在运行，则采用指数退避策略进行重试启动；

13、若退避重试启动成功，则进行执行流程；

14、若退避重试启动失败，则降级至云端大语言模型配置，进入执行流程；

15、进入执行流程后，调用对应的处理器执行所述待触发任务，得到任务执行结果；

16、将所述任务执行结果写回所述执行记录数据库并更新任务配置中的执行时间戳字段。

17、在一些实施例中，以第一预设哨兵周期触发，根据任务的cron表达式和冷却期参数，计算任务的最晚预期完成时间；

18、判断执行记录数据库中的任务是否超出最晚预期完成时间；

19、若执行记录数据库中的任务未超出最晚预期完成时间，则未监控到异常；

20、若执行记录数据库中的任务超出最晚预期完成时间，则查询任务在预设宽限期内是否存在执行成功记录；

21、若任务在预设宽限期内不存在执行成功记录，则将任务上下文提交至预设大语言模型进行裁决，得到结构化处置建议，所述结构化处置建议为立即补跑、延迟执行或忽略；

22、若任务在预设宽限期内存在执行成功记录，则不将任务上下文提交至预设大语言模型进行裁决。

23、在一些实施例中，以第二预设哨兵周期触发，根据预设补追窗口参数进行多周期漏跑检测，根据检测结果生成补跑请求，所述补跑请求受单次最大补跑数量上限约束。

24、在一些实施例中，根据作为主证据的所述执行记录数据库中任务的成功条目和作为副证据的任务配置的执行时间戳进行异常审计并区分异常类型，所述异常类型包括写回遗漏和真实执行缺失；

25、对存在写回遗漏的任务进行配置字段补写修正；

26、对存在真实执行缺失的任务进行限速自愈补跑。

27、在一些实施例中，按照第三预设哨兵周期检查任务执行结果的执行时间戳；

28、判断任务执行结果的最后修改时间是否超出预设时间阈值；

29、若任务执行结果的最后修改时间超出预设时间阈值，则触发对应任务的补跑程序，并推送即时通讯告警；

30、若任务执行结果的最后修改时间未超出预设时间阈值，则不触发对应任务的补跑请求。

31、根据本发明实施例的第二方面，提供了一种防静默任务调度系统，所述系统包括：

32、轻量扫描层，用于按照预设周期对任务配置集合中的各条任务进行三重过滤，输出通过三重过滤的待触发任务，向执行记录数据库幂等写入待触发任务对应的等待状态执行记录，并向宿主守护层异步发送执行通知，幂等键包括任务标识和触发时间窗口；

33、宿主守护层，用于在接收到执行通知后，针对存在等待状态执行记录的待触发任务，调用对应的处理器执行所述待触发任务，得到任务执行结果。

34、在一些实施例中，所述专职哨兵模块包括监控哨兵、心跳哨兵、审计哨兵以及产物校验哨兵；

35、所述监控哨兵用于以第一预设哨兵周期触发，根据任务的cron表达式和冷却期参数，计算任务的最晚预期完成时间；

36、判断执行记录数据库中的任务是否超出最晚预期完成时间；

37、若执行记录数据库中的任务未超出最晚预期完成时间，则未监控到异常；

38、若执行记录数据库中的任务超出最晚预期完成时间，则查询任务在预设宽限期内是否存在执行成功记录；

39、若任务在预设宽限期内不存在执行成功记录，则将任务上下文提交至预设大语言模型进行裁决，得到结构化处置建议，所述结构化处置建议为立即补跑、延迟执行或忽略；

40、若任务在预设宽限期内存在执行成功记录，则不将任务上下文提交至预设大语言模型进行裁决；

41、所述心跳哨兵用于以第二预设哨兵周期触发，根据预设补追窗口参数进行多周期漏跑检测，根据检测结果生成补跑请求，所述补跑请求受单次最大补跑数量上限约束；

42、所述审计哨兵用于根据作为主证据的所述执行记录数据库中任务的成功条目和作为副证据的任务配置的执行时间戳进行异常审计并区分异常类型，所述异常类型包括写回遗漏和真实执行缺失；

43、对存在写回遗漏的任务进行配置字段补写修正；

44、对存在真实执行缺失的任务进行限速自愈补跑；

45、所述产物校验哨兵用于按照第三预设哨兵周期检查任务执行结果的执行时间戳；

46、判断任务执行结果的最后修改时间是否超出预设时间阈值；

47、若任务执行结果的最后修改时间超出预设时间阈值，则触发对应任务的补跑程序，并推送即时通讯告警；

48、若任务执行结果的最后修改时间未超出预设时间阈值，则不触发对应任务的补跑请求。

49、根据本发明实施例的第三方面，提供了一种计算机程序产品，所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算程序，所述计算机程序包括程序指令，当所述程序指令被计算机执行时，使该计算机实现如上任一项所述的一种防静默任务调度方法的步骤。