Agent 平台里的 cron 不应该只是“每隔一段时间把 prompt 塞给某个 Agent”的心跳机制，而应该是一等的 schedule runtime：同一套 API 同时描述 agent 定时任务和 workflow 定时任务，并且把 target、触发输入、暂停/恢复、手动触发、历史兼容和审计事件放进可迁移的数据模型里。

Mastra 1.50.0 把 heartbeats 重命名并统一到 mastra.schedules / /api/schedules，旧的 target.type: "heartbeat" 会被归一化成 "agent"，新 agent schedule id 使用 agent_ 前缀；同一个接口还能创建 workflow schedule。这个变化看起来像命名调整，实质是把“后台定时唤醒 Agent”从 liveness 语义拉回业务执行语义：它不只是证明 Agent 活着，而是在某个 tenant/resource/thread 边界下触发一段可追踪的工作。

对 OPC 类平台更重要的是迁移约束。已有的 hb 行不能突然失效，schedule fire signal 的默认 tag 从 <heartbeat> 变成 <schedule> 也会影响下游 routing、prompt policy、metrics 维度和告警规则。工程上最好把 schedule 设计成 discriminated target：{type: agent, agentId, prompt} 和 {type: workflow, workflowId, inputData} 共用 lifecycle，但进入执行器前再解析成不同的 run contract。

常见误区是把 schedule 当成“外部 cron + HTTP webhook”。那样短期能跑，长期会丢掉 pause/resume、run-now、权限传播、幂等 key、失败归因、跨版本迁移这些平台能力。真正的 Agent Engineer 要问的是：如果一个定时任务今天从单 Agent 演进成多步 workflow，我们是否能不换触发协议、不迁移用户配置、不重写审计面板？