Automations 与 Scheduled Skills 深度解析：把稳定工作流交给 Codex 定时运行
TL;DR
Automation 解决“什么时候运行、在哪运行、结果去哪”的问题，Skill 解决“按什么流程做”的问题。官方 Codex app Automations 文档说明，自动化任务可以在后台按计划运行；有发现会进入 inbox/Triage，没有可报告内容则可自动归档；项目级自动化要求运行本地 Codex app 的机器保持开机、Codex 正在运行、所选项目仍在磁盘上。Git 仓库里的自动化可以在本地项目中运行，也可以在新的 worktree 中运行。自动化可显式调用 Skill，例如在 prompt 中写 $skill-name。
不要把不稳定判断直接自动化。正确路线是：人工跑通流程，沉淀 Skill，评测触发和执行，设计调度、沙箱、worktree、输出和责任人，再小范围运行。Automation 会把流程缺陷定时放大；在没有 owner、验收标准和失败路径前，它不是省事工具。
读者定位
本文面向技术负责人、研发效能团队、平台工程师，以及准备把 Codex 从个人交互扩展到周期性检查的开发团队。你应该已经理解 Skills 的定位，知道 Skill 评测 要覆盖欠触发、误触发和执行失败。本文讨论怎样把稳定 Skill 放进自动化运行，而不是讲普通日程提醒。
如果你的团队还没有稳定的人工流程，不要从 Automation 开始。先让人手动调用 Codex 完成三到五次真实任务，把 prompt、输入、输出、失败原因和人工修正记录下来。自动化应当接管成熟流程，不该替你探索流程。
问题：重复任务为什么不能直接靠复制 prompt
团队里有很多周期性任务：每天检查失败 CI、每周扫依赖风险、发布日前做配置和迁移检查、定期检查文档链接、每月整理安全 backlog、跟踪长时间运行的 PR review。靠人复制 prompt 有几个问题。
第一，触发依赖记忆。负责人请假或忘记，任务就不会发生。第二，输入不稳定。不同人复制的 prompt 版本不同，结果也不同。第三，输出不可追踪。结果散在个人会话、Slack 或本地文件里，后续没人知道哪些风险已经处理。第四，权限容易漂移。一次手动任务可能在高权限本地目录运行，下一次又在另一个环境运行。第五，成本不可见。没有统一记录，很难知道自动化是否真的节省时间。
但直接把 prompt 丢进 Automation 也会出问题。一个模糊任务“每天帮我看看仓库有没有问题”会产生大量噪声；一个有写权限的自动化可能改动开发者正在编辑的文件；一个依赖网络或私有连接器的任务在后台失败后无人处理；一个没有输出格式的任务进入 Triage 后仍要人重新判断。Automation 本身不是治理，它要求你先把治理设计好。
心智模型：Automation 是带运行位置和收件箱的 Codex 任务
可以把一个自动化任务拆成六个要素。
调度：什么时候运行。可以是固定周期，也可以是 Codex app 支持的自定义计划。官方文档提到自定义 schedule 可以使用 cron syntax。
上下文：是否从新 prompt 开始，还是附着到当前 thread。官方文档把 thread automations 描述为附着在当前线程上的 heartbeat 式唤醒，适合保留同一会话上下文的跟进任务；standalone automation 更适合每次独立运行的周期检查。
运行位置：在本地项目目录运行，还是在新的 worktree 运行。Git 仓库中 worktree 能把后台变更和开发者未完成工作隔离；非 Git 项目则直接在项目目录运行。
权限：使用什么沙箱、是否允许写文件、是否需要网络、是否允许操作本机应用。官方文档说明 Automations 使用默认沙箱设置；只读模式下需要修改文件、网络访问或操作应用的工具调用会失败；启用 full access 会提高后台任务风险。
流程：具体怎样做。这里应使用 Skill，而不是在 automation prompt 里维护一大段流程。
归档与处理：结果进入 Triage、自动归档、指派责任人，还是继续唤醒同一 thread。没有处理路径的自动化会变成固定噪声源。
这个模型能帮你把“定时跑 Codex”变成可治理系统。调度不等于流程，流程不等于权限，权限不等于责任。
官方机制和边界
官方 Automations 页面给出了几条对工程设计很有影响的事实。
第一，自动化在后台运行，并把发现加入 inbox/Triage；如果没有可报告内容，可以自动归档。这说明输出要足够短、可判断、可接手。不要让自动化每次输出一篇长散文。
第二，项目级自动化依赖本地 Codex app 所在机器。机器要开机，Codex 要运行，项目要仍在磁盘上。它不是无条件云端定时任务。团队设计时要考虑谁的机器承载任务，机器休眠、路径变更、磁盘清理和 app 退出都会影响运行。
第三，Git 仓库可以选择本地项目或新 worktree。选择本地项目会直接影响当前 checkout；选择 worktree 可以隔离后台变更。周期性检查、会写报告、可能生成修复分支的任务，优先考虑 worktree。只读查询且需要当前未提交状态时，才考虑本地项目。
第四，模型和 reasoning effort 可以用默认设置，也可以显式选择。对高频低风险巡检，不一定需要最高配置；对发布检查、安全审计和迁移风险，应显式提高质量要求，并要求可验证证据。
第五，Automations 可以使用 Codex 可用的 plugins 和 skills。官方文档建议为了可维护和可共享，用 Skill 定义动作、工具和上下文；在 automation prompt 中写 $skill-name 可显式触发。
哪些任务适合自动化
适合自动化的任务通常有五个特征：输入稳定、输出可验收、失败可降级、风险可控、责任人明确。
文档类任务很适合早期试点。比如每周检查 docs/ 内部链接、生成断链报告、标出需要人工处理的文件。这类任务以读取为主，输出明确，写入需求可以限制在报告文件或 Triage。
CI 诊断适合半自动化。比如每天汇总过去 24 小时失败 job，分类为依赖、测试、环境、超时、疑似 flaky，并给出证据。它可以减少人工筛查，但不要自动修复所有失败。修复仍需人确认或单独触发。
发布检查适合在流程稳定后自动化。发布日前固定检查配置变更、迁移、回滚、文档、测试和已知风险。它适合显式调用 $release-readiness Skill，并要求输出阻塞项和未确认项。
依赖巡检适合定期运行，但要谨慎写权限。自动发现过期或高风险依赖可以；自动升级生产依赖并合并则风险高。可以先让 Automation 只生成报告，后续由人决定是否开修复任务。
安全 backlog triage 可以自动化初筛，但不应替代安全 owner。自动化可以去重、分类、补充证据，最终优先级和修复策略仍要人类负责。
不适合自动化的任务也很清楚：需求模糊、判断开放、成功标准不稳定、需要大量组织协调、失败代价高、权限边界不清的任务。比如“每天帮我重构核心模块”“自动优化架构”“发现并修复所有安全问题”都不适合无人值守。
从 Skill 到 Automation 的迁移步骤
第一步，手动运行并记录。至少执行三次同类任务，记录输入、输出、命令、失败原因和人工修正。不要用模拟数据替代真实仓库状态。
第二步，沉淀 Skill。把流程放到 SKILL.md，长规则放 references/，确定性检查放 scripts/，输出模板放 assets/。description 要可路由，但自动化 prompt 中建议显式写 $skill-name，减少路由不确定。
第三步，做 Skill 回归。用正例、反例和执行失败用例验证触发和输出。自动化会反复运行，任何误触发、路径错误和权限失败都会重复出现。
第四步，选择运行模式。独立周期检查用 standalone automation；需要保留同一会话上下文、持续跟进某个部署或 PR 的任务，用 thread automation。需要隔离文件改动的 Git 仓库任务，优先 worktree。
第五步，设定最小权限。只读检查用 read-only。需要生成报告或修改非核心文件时使用 workspace-write。full access 只应在隔离环境、清楚风险、有人审计的场景使用。
第六步，设计输出。报告至少包含运行时间、项目、分支或 worktree、检查范围、命令、发现、未验证项、建议动作、责任人或处理截止时间。Triage 收件箱里的结果应能被人快速判断，不需要再问 Codex“这是什么意思”。
第七步，试运行和校准。前几次运行不要看“有没有报告”就算完成，要检查是否漏掉关键证据、是否误报太多、是否在错误目录运行、是否写了不该写的文件。
真实工作流案例：每周文档链接检查
一个文档仓库希望每周检查内部链接并生成报告。先手动 prompt：
检查 docs 目录里的内部相对链接，列出不存在的文件或锚点。不要修改文件，只输出报告。
手动跑几次后，把流程沉淀为 docs-link-audit Skill：
docs-link-audit/
SKILL.md
scripts/
check-internal-links.sh
assets/
link-audit-report.md
Skill 里写清：默认只读；从仓库根目录运行；脚本只检查内部链接，不检查外部链接；脚本失败时手工抽样检查最近变更文件；输出按阻塞、非阻塞、无法确认分类。
Automation prompt 可以写：
Use $docs-link-audit every Monday at 09:00. Check docs/ only. Run in a background worktree if available. Do not edit files. If broken links are found, report file path, link target, and suggested owner. If nothing is found, archive the run.
这个任务适合自动化，因为输入稳定、只读、输出可验收、失败代价低。即使脚本失败，也能报告失败原因。后续如果团队希望自动开修复 PR，再单独设计写权限、分支命名、review 和回滚策略。
真实工作流案例：PR babysitting
另一个场景是长时间运行的 PR。作者希望 Codex 每 15 分钟检查一次 CI、review comments 和冲突状态，直到 PR 可合。这个任务更适合 thread automation，因为上下文需要保留同一 PR 的状态、前次判断和待办。
Skill 可以叫 pr-babysit，流程包括读取 PR 状态、检查 CI、读取新 review comments、分类是否需要行动、必要时建议修复。Automation 应写清“不要自动 push，除非用户在当前线程明确授权”，并规定遇到新失败时回到 thread 报告。这样 Codex 不是每次重新开始，而是作为同一线程的 heartbeat。
风险在于权限和噪声。CI 抖动、评论更新和网络失败都可能频繁触发报告。输出应有节流策略，例如只在状态变化时报告；连续相同失败只更新摘要；无法访问 GitHub 时报告一次并等待下次。
操作清单
- 任务是否已经人工稳定跑通三次以上。
- 是否已有可评测 Skill，而不是把长 prompt 直接放进自动化。
- 是否明确 standalone automation 还是 thread automation。
- Git 仓库任务是否优先使用 worktree 隔离后台改动。
- 本地项目自动化是否考虑机器开机、Codex 运行和项目路径存在。
- 沙箱权限是否从最小权限开始。
- 是否写清网络、MCP、连接器和本机应用需求。
- 输出是否能进入 Triage 后被人接手。
- 没有发现时是否可以自动归档。
- 前几次运行是否有人复核并校准误报、漏报和权限问题。
权衡与风险
Automation 能减少重复劳动，也会制造周期性噪声。一个每小时误报的任务比手动 prompt 更烦。早期应该控制频率、范围和输出长度。
Worktree 能隔离改动，但不是免费。多个后台 worktree 会占用磁盘和构建缓存，也可能让依赖安装、环境变量和本地服务状态与主 checkout 不一致。任务要写清工作目录假设。
只读沙箱安全，但能力受限。需要生成报告或修复文件时，必须开放写权限。开放写权限前，要确认输出路径、分支策略和人工 review。full access 的后台任务风险高，不应成为默认。
Thread automation 能保留上下文，但长期线程也会累积历史。任务应定期总结状态，避免把旧信息当成当前事实。Standalone automation 每次更干净，但需要 prompt 和 Skill 自带足够上下文。
模型和 reasoning effort 也有成本权衡。高频巡检不一定需要最高配置；高风险发布检查不应只按便宜选择。任务模板应记录模型选择理由，方便后续复盘。
常见误区
误区一：把 Automation 当成 Skill。Automation 负责调度和运行环境，Skill 负责流程。
误区二：先自动化再补流程。自动化会放大模糊流程，不会让流程自动成熟。
误区三：默认写本地项目目录。后台任务容易和开发者未提交改动冲突，Git 仓库优先考虑 worktree。
误区四：没有 owner。Triage 里出现发现后，必须有人处理。无人处理的自动化只是噪声。
误区五：权限给太大。后台任务应从只读开始，逐步放开。
误区六：忽略本地运行前提。项目级自动化依赖机器、Codex app 和磁盘项目状态。
自动化运行手册：上线前要写清的字段
每个 Automation 都应有一份短运行手册，哪怕只有一个 Markdown 表格。手册不是为了文档好看，而是为了出问题时能快速判断谁处理、停不停、怎么恢复。
第一，任务身份。包括名称、目标、所属项目、负责人、备份负责人、创建日期、最近复核日期。负责人要能决定禁用、调整频率或改权限。
第二，调度策略。包括运行频率、时间窗口、是否使用 cron、自定义时区、是否允许节假日运行。高噪声任务不要放在团队无人值守的时间段。发布相关任务要和发布节奏对齐。
第三，运行位置。写明本地项目、worktree、临时目录还是非 Git 目录。Git 仓库还要写明 worktree 命名、清理策略和磁盘占用预期。直接在本地项目运行的任务，要说明是否会读取未提交改动。
第四，权限和工具。写明沙箱、是否写文件、是否需要网络、是否需要 GitHub/Slack/Linear/MCP、是否操作本机应用。权限变化必须 review，不应由某次临时失败随手放大。
第五，输入和输出。输入范围要固定，例如只检查 docs/，只看最近一次失败 job，只看特定发布分支。输出字段要固定，例如阻塞项、非阻塞风险、无法确认项、建议 owner。Triage 中的结果要能被人直接接手。
第六，失败处理。脚本失败、网络失败、连接器未授权、项目路径不存在、机器休眠、权限不足时，任务应怎样报告，是否自动重试，连续失败几次后禁用或通知 owner。
这些字段能让 Automation 从“一个定时 prompt”变成可运维任务。没有运行手册，自动化失败后团队只能翻聊天记录和猜配置。
噪声控制：让自动化少打扰人
自动化的主要敌人是噪声。一次误报可以接受，每天重复误报会让团队忽略所有报告。噪声控制要从设计阶段做起。
第一，限制范围。不要让任务每次扫描全仓库，除非确有必要。按目录、分支、最近变更、发布范围或失败 job 缩小输入。范围越窄，误报越少，输出越可处理。
第二，区分变化和重复。对 PR babysitting、CI 监控、依赖巡检这类任务，只有状态变化时才报告；连续相同失败可以合并为摘要。否则 Triage 会被同一问题刷屏。
第三，设置严重度门槛。只把阻塞项、高风险项或需要人工确认的项送到 inbox；低风险信息可以归档或写入周期报告。
第四，输出未确认项而不是猜测。网络失败、权限不足、日志缺失时，Automation 不应生成看似确定的结论。清楚报告“无法验证”比误报安全。
第五，定期复核。每个 Automation 每两到四周看一次：是否仍有价值，是否误报多，是否 owner 还在，是否 Skill 过期，是否频率需要调整。自动化不是设置后永久运行。
噪声控制的目标不是不报告，而是让每次报告都值得人看。团队信任来自长期低噪声，而不是一次华丽输出。
权限升级流程：从只读到写入
自动化权限应逐步升级。第一阶段只读报告，验证任务能稳定找到问题。第二阶段允许写报告文件或评论草稿，但不修改业务代码。第三阶段在 worktree 中生成候选 patch 或 PR，由人 review。第四阶段才讨论更高自动化，且要有明确回滚和审计。
每次升级都要回答五个问题：这次写权限解决什么具体痛点；写入范围是否限制；失败后怎样恢复；谁 review 输出；如何记录改动和命令。答不清就不要升级。
对于生产配置、数据库迁移、权限规则、安全修复，自动化即使能生成修改，也应默认停在人类审批前。Codex 可以准备证据和候选 patch，责任仍在工程 owner。
运行复盘：自动化是否还值得保留
Automation 上线后要定期复盘，否则很容易留下没人看的后台任务。复盘可以按三类问题进行。
第一类是价值问题。过去一段时间内，它发现了多少真实问题，节省了多少人工检查，是否提前暴露风险。如果多次运行都没有发现，可能是任务范围太窄，也可能是频率太高，或者这个检查已经没有价值。
第二类是质量问题。报告是否可处理，误报是否多，是否漏掉关键问题，是否经常因为权限或路径失败。质量问题要回到 Skill、脚本、权限和运行位置修，而不是只改调度时间。
第三类是运营问题。Triage 中的发现是否有人处理，owner 是否还在，处理是否有 SLA，连续失败是否通知到人。自动化产生发现但没人接手，比不运行更糟，因为团队会误以为有人在看。
复盘结论应有动作：保留、降频、扩大范围、收窄范围、改 Skill、改权限、换运行位置、暂停或删除。不要让“以后再看”成为默认结果。周期性任务需要周期性维护。
对成熟团队，可以给每个 Automation 设置健康状态：绿色表示近期有价值且低噪声，黄色表示需要调整，红色表示应暂停。这个状态比单纯列出任务清单更能帮助团队控制后台复杂度。
如果一个自动化要写文件，还要复盘产生的 diff。是否总是改同一类小问题，是否经常需要人工重写，是否会和开发者未提交改动冲突。写入型自动化只有在 diff 小、验证清楚、review 负担低时才值得保留。
复盘时也要看时间窗口。一个任务在工作时间低噪声，放到夜间可能无人处理；一个任务在发布周有价值，平时可能只是重复提醒。频率应跟工作节奏匹配。
延伸阅读
GitHub 原文：34-automations-scheduled-skills.md