DeepSeek Harness 定时任务指南：提醒、记录与持久化

DeepSeek Harness v0.1.7-rc.2 已包含定时任务与时间上下文能力。当前发布包中这组功能默认关闭，需要手动启用。启用后，Agent 可以创建一次性提醒、固定间隔任务、每日或每周任务，以及 Cron 规则；任务由 Host 持久化，即使原 Session 没有保持在内存中，也能在到期时把后续消息送回原会话。

需要先明确一个边界：DSH 的“执行记录”目前记录的是消息是否成功送入 Session Inbox，不等于模型已经完成任务，也不等于用户收到了系统通知。

启用前先确认版本与组件

1. 使用 DeepSeek Harness v0.1.7-rc.2 或对应源码版本。
2. 在插件或功能配置中启用 Schedule、Time Context 与对应界面入口。
3. 重启或重新载入 Profile 后，确认 Agent 能看到创建、查询、修改与删除定时任务的工具。
4. 先创建一个几分钟后的测试提醒，验证 Host 时间、时区与 Session 投递。

发布说明与源码中的组合配置存在差异：子系统已经进入代码，但 rc.2 发布包的默认体验仍是关闭状态。因此不能仅凭源码中存在 Schedule 组件，就假定所有安装会自动启用。

支持哪些时间规则

本地日历规则会保存 IANA 时区。跨时区旅行、夏令时切换或服务器时区变化时，应检查任务保存的时区，而不是只看界面显示的小时数。

任务是怎样持久化的

Schedule Store 由 Host 管理，任务数据与某个 Session 是否正在加载分离。记录包含原始 Session ID、时间规则、启用状态、最近一次投递回执与有限的投递历史。Host 重启时只恢复仍处于活动状态的计时器。

任务到期后，Host 通过 Session Controller 将普通 Follow-up 写入原 Session。即使 Session 当时是冷的，也可以先写入 Inbox，等会话重新运行时处理。

投递成功不等于任务完成

当前回执确认的是 Follow-up 已经持久化到 Session Inbox。它不证明：

• 模型已经开始或完成运行；
• 外部 API、脚本或浏览器操作已经成功；
• 用户收到了桌面或邮件通知；
• 最终输出满足业务条件。

因此，“运行记录”更准确地说是投递历史。重要任务还应在实际工作流中增加完成条件、失败记录与外部监控。

重启、漏跑与重复投递

重复任务在 Host 离线一段时间后恢复时，只投递最近一个已经到期的周期，不会把所有错过的周期逐条补跑。这可以避免离线一天后突然生成大量积压消息。

Session Inbox 与 Schedule Store 属于不同存储，写入不是原子事务。如果进程恰好在 Inbox 写入成功、但 Schedule 回执尚未落盘时崩溃，恢复后可能再次投递。因此业务动作应尽量具备幂等性，例如用“任务 ID + 计划时间”作为去重键。

修改、删除与历史保留

• 修改任务采用乐观校验；编辑期间如果刚好发生一次投递，旧编辑可能被拒绝，需要重新加载后再保存。
• 删除是硬删除，会同时移除任务与投递历史，没有回收站。
• 当前没有单独的暂停状态；不想继续运行时应删除或按界面提供的启用状态处理。
• 默认历史保留受天数与记录数双重限制，架构默认值为 30 天和 200 条，可由 Host 配置调整。

删除前建议保存任务规则、原始提示词与需要保留的运行证据。

实用测试流程

1. 创建一个 5 分钟后的单次提醒，记录任务 ID。
2. 关闭页面但保持 Host 运行，确认消息进入原 Session。
3. 创建一个短周期重复任务，观察投递历史与下一次时间。
4. 重启 Host，确认活动任务恢复且不会补发所有错过周期。
5. 让任务执行一个具有外部副作用的测试动作，并验证去重设计。
6. 删除测试任务，确认它与历史一起消失。

适合与不适合的场景

定时任务适合提醒、周期检查、生成报告草稿和把后续工作重新送回 Agent。对于支付、删除、自动发布或其他高风险动作，应增加人工确认、幂等键与独立审计，而不是把“已投递”当作“已完成”。

相关阅读

• DeepSeek Harness v0.1.7-rc.2 更新
• DeepSeek Harness 动态工具与 KV Cache
• DeepSeek Harness 安全边界

参考资料

• DeepSeek Harness v0.1.7-rc.2 Release
• Host schedule storage architecture
• Schedule hard delete and bounded history
• Web schedule composition