Agent定时任务设计：执行步与检查点拆分

想让 AI 编程任务每天定时跑，关键步骤还要自己点头确认——这两件事拼起来是四层设计问题，不是一个问题。选错层的典型症状：用 cron 调起一整段对话却没有验收口；或者把能写成脚本的巡检每次都丢给模型烧额度。本文把"自动"拆成四种形态，给一套可落地的触发与闸口设计。

先分清你要的是哪种自动

四种形态，需求不同解法完全不同：

1. 到点提醒——不需要 Agent，系统闹钟即可；
2. 到点跑固定脚本——输入输出确定就不用模型：每天跑测试套、每周归档依赖 diff、工作日汇总昨日提交记录，cron 或系统任务计划搞定。原则：能写成确定命令的，不要每次让模型再想一遍；
3. 到点派会判断的 Agent 任务——需要读上下文、做判断、产出非固定格式结果时才上：触发器接到 Agent 任务，配好触发节奏、工作区、错过补跑和"上次未跑完则跳过"；
4. 多步流程中途要人拍板——需要"执行步 + 检查点"结构，这是下文重点。

执行步与检查点的拆分原则

可自动推进的写成执行步，必须人闸的写成检查点，每步声明"自动进入下一步"或"等确认"。判断标准一条：不可逆或对外可见的节点设闸，其余放行。

典型的六步骨架：列改动范围（自动）→ 确认范围（闸）→ 改代码跑测试（自动）→ 审 Diff（闸）→ 写变更说明（自动）→ 合并或放弃（闸）。适合设闸的节点就四类：看 Diff、确认依赖变更、合并发版前放行、权限与对外文案。检查点越多不等于越安全——闸设在不可逆处，日常节点全闸只会把人训练成无脑点确认。

实现层面一个值得借鉴的安全设计：工作流固定在隔离副本中运行，不直接改工作目录——流程跑错也不会污染项目，验收通过再落盘。步骤指令支持变量占位引用运行时目标，同一模板可复用到不同任务。

定时器的运行边界

桌面级定时器有一条硬边界必须写进运维手册：应用关到系统托盘时任务和定时器通常继续跑；完全退出后定时器不会触发。长时间无人值守要么保持应用常驻托盘，要么换机器级方案（系统定时或 CI）。

两个配套机制值得标配：错过补跑（应用没开时错过的定时任务，下次启动补一次）和防重复（上次任务未完成时跳过本次触发，避免任务堆积并发执行）。无人值守场景的验收就盯这两条：故意关掉应用跑过触发点，重开后确认补跑；再故意让任务超时长跑，确认下一次触发被跳过。

对照表与两条边界

形态	要不要模型	适合	无人值守依赖
本地提醒	否	通知类	系统通知
本地脚本	否	确定命令	看日志
定时 + Agent	是	要判断要摘要	应用是否在跑
执行步 + 检查点	部分步骤	多步要人闸	还要人在场点头

两条边界收尾：定时器和检查点不能替代 Diff 审查与测试——它们是流程编排，不是质量保障本身；权限确认不等于安全沙箱，Agent 执行的是真实命令，高危操作的人工闸必须保留。选型顺序永远是先分层再上工具：提醒归系统、确定命令归脚本、判断归 Agent、不可逆归人工。