Scheduled tasks、codex exec 与 Hooks：无人值守之前先证明可控

凌晨两点，失败流程不会自己变聪明

一个脚本手工跑十次会失败一次。你把它设成每天执行，以为省掉了重复劳动。第二天醒来，输出目录多了几十份重复文件，没人知道哪次算成功。

自动化从来不只复制成功，它也忠实复制歧义。

无人值守是稳定流程的奖励，不是试运行方式。 这节课会跟着一次每日内容检查，比较 scheduled task、codex exec 和 hook，并为每次运行留下可恢复账本。

三种自动化不解决同一个问题

能力	适合	主要风险
Scheduled tasks	按时间在桌面或 Web 后台重复运行用户工作流	机器离线、环境变化、重复副作用、无人审查
codex exec	在脚本、CI 和管道中非交互运行 Codex	输出解析、退出状态、权限过宽、秘密进入日志
Hooks	在 Codex 生命周期事件上运行确定性脚本	不可信脚本、阻断主循环、敏感输出

Scheduled task 由时间触发，codex exec 由程序触发，Hook 由生命周期事件触发。Skill 可以被前两者复用，但不会自动提供调度。

自动化准备度门槛

在启用无人值守前，必须回答：

1. 手动流程是否连续成功三次；
2. 输入是否可验证且有时间/版本边界；
3. 同一运行重复两次会不会产生重复发送、重复写入或重复扣费；
4. 输出成功和失败是否机器可判断；
5. 需要人决定的情况能否暂停；
6. 如何停止、回退和追踪每次运行；
7. 权限是否只覆盖必要目录、域名和工具。

任意两项不清楚，保持手动。

Scheduled tasks 的现实边界

官方页面当前区分 Web 与 Desktop 的运行环境。Web 不等同于直接访问你的本地目录；Desktop 任务可能依赖本机在线，并可在项目或独立 worktree 中运行。产品支持变化快，创建前回查当前页面。

一个安全任务示例：

每个工作日 09:00 检查公开项目的只读状态。
只读取指定来源，生成本地草稿，不发送消息。
若来源不可用、字段缺失或与上次差异超过阈值，标记需人工复核。
每次输出 run-id、来源时间、结果路径、检查和错误。
不要修改远程对象。

第一次和前几次运行必须人工查看，不能设完就忘。

codex exec 的可观察输出

非交互模式用于 CI 或脚本。官方文档强调 stdout 与 stderr、JSONL 或结构化输出等接口。设计时：

• 用明确 schema 限制结果字段；
• 用退出状态区分成功、任务失败和基础设施失败；
• 日志中不输出令牌或敏感文件；
• 默认只读，需要写入时显式最小授权；
• 保存 prompt 版本、输入版本、Codex 版本和 run-id。

调用者不能只搜“success”字符串。应验证输出 schema、预期文件、测试和 diff。

Hooks 的确定性边界

Hooks 适合会话开始加载状态、工具调用前执行政策检查、结束时记录摘要等确定性步骤。它不适合承担需要复杂推理的主任务。启用仓库提供的 hook 前必须阅读代码和配置；不受信任的 hook 可能执行任意本地命令。

Hook 输出也可能进入会话或日志，避免写秘密、完整个人数据和不必要路径。

幂等、去重和副作用

为每次运行定义幂等键，例如：

workflow + source-period + input-hash + output-version

运行前检查该键是否已经成功。草稿可覆盖到临时路径，发送、发布、付款、创建远程对象则必须有更严格的去重与人工批准。失败重试要有上限和退避，不能无限重复副作用。

三次验证

1. 正常输入：输出正确且证据齐全；
2. 相同输入重跑：不会创建重复外部结果；
3. 故障输入：安全停止，错误可诊断，不留下半完成状态。

再手动停止并恢复一次，证明你知道控制入口。若只有“正常一次成功”，自动化仍未验收。

完整案例：把每日健康报告自动化

手动流程已经稳定：读取健康端点、比较最近成功时间、文章数和错误状态，生成一份只读报告。现在比较三种自动化表面：

需求	Scheduled task	codex exec	Hook
每天定时运行并回到任务列表	合适	需要外部调度器	不合适
在 CI 中输出结构化 JSON	不合适	合适	不合适
每次工具调用前阻止危险命令	不合适	不合适	合适

三者可以组合，但不要重复承担同一责任。例如 Scheduled task 负责时间，Skill 负责业务流程，MCP 负责读取数据；Hook 只做确定性安全检查。

自动化前的手动准备度

至少连续三次记录：

输入是否稳定：
输出是否可机器或人工审查：
失败能否分类：
重复运行是否产生重复副作用：
需要哪些权限：
什么情况下必须停止：
谁接收失败通知：
怎样从上次成功点恢复：

如果“失败后人工随便看看”仍是主要恢复策略，就不适合无人值守。

幂等与去重

假设报告可能因重试运行两次。使用稳定运行键：

run_key = report_type + source_date + source_version

生成前检查该键是否已成功；重复运行可以更新同一草稿或明确跳过，不能发送两份。对于会创建外部资源的工作流，还要记录外部 ID 和状态。

可观察输出

自动化结果至少包含：

• run ID、开始与结束时间；
• 输入范围与来源版本；
• 成功、部分成功或失败；
• 生成的文件或外部对象；
• 未处理项和下一次重试条件；
• 使用的权限与未执行动作。

“任务已完成”无法支持诊断。codex exec 进入流水线时，优先使用稳定字段或 schema，而不是让下游解析自然语言。

一份最小运行记录

{
  "run_id": "daily-health-2026-07-31",
  "status": "partial",
  "source_version": "2026-07-31T00:00:00Z",
  "created": ["reports/2026-07-31.md"],
  "warnings": ["primary sync has no completed cursor"],
  "external_writes": []
}

稳定字段让告警、重试和人工复核使用同一事实，而不是猜一段自然语言是成功还是失败。

从 dry run 到真实运行

1. 用固定样例 dry run，不访问外部写接口；
2. 用当前只读数据运行，人工核对报告；
3. 人工触发一次真实草稿流程；
4. 连续观察前三次计划运行；
5. 再决定是否扩大范围或增加写动作。

自动化的第一版最好只生成草稿和证据，不发送、不部署、不删除。

故障诊所

现象	原因	恢复
重试生成两份报告	缺少幂等键	按输入版本去重，记录外部对象 ID
定时任务读不到本地文件	运行表面没有该上下文	改用可访问项目或连接来源
Hook 阻塞所有命令	规则过宽且无正负样例	缩小事件与匹配条件，增加绕不开的说明
自动化悄悄使用旧资料	没有 freshness gate	过期时失败或标记，不继续生成“当前”报告
失败后无限重试	没有次数和退避	设置上限、错误分类和人工接管点

知识检查

一个每周报告流程刚手工成功一次，可以直接设为定时发送吗？不应。先稳定输入、验证、缺失处理、幂等和失败恢复；第一阶段只生成可审查草稿。

自动化真正节省的不是点击次数，而是把已经证明可靠的判断、检查和停止条件稳定重复。仍依赖临场猜测的流程，应继续留在有人监督的任务里。

先证明人工流程可重复，再关掉灯

挑一个准备自动化的任务，连续人工跑三次。记录输入、输出、耗时、失败和重复执行结果。

只要幂等、观察或停止条件有一项说不清，就继续有人值守。少一次点击不值钱，能在失败后知道发生了什么才值钱。

完成检查

• 选型基于触发方式，不基于新奇程度
• 手动流程已稳定三次
• 输入、输出、退出状态和日志可观察
• 幂等键、重试上限和副作用审批明确
• 运行使用最小文件、网络和工具权限
• 已验证重复运行、故障与停止恢复