[Feature]: Quartz-based Scheduler Extension for AgentScope Java

[LoM-Klein]

Is your feature request related to a problem?

• Small and medium deployments need a lightweight, reliable scheduler with local or JDBC persistence without relying on external systems.
• The current XXL-Job integration suits distributed scheduling but introduces operational overhead for single-node or simple setups.
• Many teams need precise fixed-delay semantics (run next after completion + delay), along with pause/resume and fine-grained status queries, which are not covered by simple task schedulers.
• Example frustration: needing a simple “every 5 minutes after completion” job with a clean agent state and recoverable schedules across restarts, but having to bootstrap a dedicated XXL-Job stack or accept non-persistent in-memory timers.

Describe the solution you'd like

• A new module agentscope-extensions-scheduler-quartz that implements the existing AgentScheduler interface and works out-of-the-box with Quartz:

  • Supports CRON , FIXED_RATE , FIXED_DELAY scheduling modes mapped from ScheduleConfig .
  • Provides pause/resume/cancel operations and rich status querying (trigger state, next/previous fire times, misfire status).
  • Offers two storage modes:
    • RAMJobStore for lightweight, non-persistent single-node runs.
    • JDBC JobStoreTX/CMT for persistence and robust recovery across restarts.
  • Honors clean-state execution by creating a fresh Agent per run, aligning with BaseScheduleAgentTask .
  • No changes to core interfaces. Integration uses existing extension points.

• Key design elements:

  • QuartzAgentScheduler implements AgentScheduler : entry point for scheduling, cancellation, querying, and shutdown.
  • QuartzScheduleAgentTask extends BaseScheduleAgentTask : adds pause/resume/status methods (available via cast) while keeping the core API stable.
  • AgentQuartzJob implements Job, InterruptableJob : executes one agent run, supports runtime interrupt.
  • AgentJobFactory : injects runtime objects (e.g., toolkit/hooks) resolved from factories to keep persisted payloads serializable ( AgentConfig + ModelConfig ).
  • Fixed-delay semantics implemented via “single-shot trigger + reschedule on job completion” for exact behavior.
    Describe alternatives you've considered

• Spring TaskScheduler : lightweight and easy but lacks persistence, robust recovery, and enterprise-grade scheduling features.

• Using Quartz as an external microservice: adds deployment and operational complexity; the proposal keeps it embedded and simple to configure.

• Relying solely on XXL-Job: great for distributed scheduling with an admin console, but overkill for single-node or simple persistent schedules.

• Emulating fixed-delay with fixed-rate: does not guarantee “completion + delay” semantics and can overload systems when execution time varies.
  Additional context

[AlbumenJ]

Ref #369