背景

文件名：2025-11-08_1_register-clock-trigger.md 创建于：2025-11-08_00:38:54 创建者：ASUS 主分支：main 任务分支：未创建 Yolo模式：Off

任务描述

插件框架需要支持在插件执行阶段注册并定期触发的clock回调。

项目概览

当前架构通过Architecture.Register管理插件生命周期，但缺少可用的定时调度机制。必须分析如何安全地触发插件提供的clock回调。

分析

目前 PluginInterface.execute 在 Architecture.Register 中仅绑定 wake_up，插件自行决定何时启动定时任务；原先取得 register_clock() 的逻辑已移除。框架缺乏任何定时任务持久化结构，需要扩展 Database 或新增表来保存待执行任务及其计划执行时间。调度接口需要符合 register_clock(callback, time) 一次性延时调用模型，回调若要持续执行需自行再次注册。任务触发误差需从 ProjectConfig 读取配置，服务器重启后所有已到期任务应立即执行，未到期任务需按剩余时间继续等待。时间单位为毫秒，每个插件可以同时注册多个延时任务，不设并发限制，需确保调度层能最大限度向插件开放自由度。延时任务执行必须由独立的事件循环系统负责，插件实例不应自行保存或执行任务；事件循环应按配置误差间隔检查到期任务，并在执行任务时支持回调中继续注册新任务而不引发并发竞态。

提议的解决方案

扩展数据库，在 scheduled_tasks 表中保存任务ID、回调标识、序列化参数、执行时间（毫秒时间戳）和状态，确保重启后恢复。
新增 ClockScheduler 模块，独立读取数据库、按配置误差间隔扫描到期任务并执行，执行前后更新任务状态并记录结果。
在 PluginInterface 中实现 register_clock，将插件提供的回调标识与延迟毫秒数交给调度器；插件可传递payload以便执行时还原上下文。
在 FastAPI 应用启动时创建并启动调度器后台任务，停止时优雅关闭；从 ProjectConfig 读取调度周期等配置。
设计回调解析器，通过模块/类/函数标识和payload反射执行回调；允许回调内部再次注册延时任务而不影响调度循环。

当前执行步骤："1. 创建任务文件"

任务进度

2025-11-08_01:14:21

已修改：PWF/CoreModules/database.py PWF/CoreModules/clock_scheduler.py PWF/CoreModules/plugin_interface.py PWF/Application/web.py PWF/Convention/Runtime/GlobalConfig.py
更改：创建持久化延时任务表与CRUD接口；实现独立调度器并集成FastAPI生命周期；为插件提供register_clock封装；配置默认调度参数。
原因：满足延时任务持久化与独立事件循环需求，支持重启恢复。
阻碍因素：无
状态：未确认

2025-11-08_01:22:21

已修改：PWF/Convention/Runtime/GlobalConfig.py
更改：撤回 scheduler 默认配置写入，保持 ProjectConfig 原始行为。
原因：遵循架构约束，避免上游配置被功能耦合。
阻碍因素：无
状态：未确认

最终审查

待补充

3.1 KiB Raw Blame History Unescape Escape

背景