Codex Automations 和长任务：定时触发、heartbeat 与跨天任务怎么配

如果你经常把重复检查、PR 追踪、部署后回看、跨天跟进这些活儿交给 Codex，最先要解决的不是“能不能自动化”，而是“哪一类任务该怎么自动化”。Automations 不是把 Codex 变成永不休息的后台代理，而是让它在合适的时间、合适的边界里回来做一次明确的事。

一、先判断：这件事适不适合交给 Codex 自动跑

1.1 standalone/project automation：后台独立任务

standalone automation 和 project automation 都是后台独立任务，区别在于范围。standalone 不绑定具体项目；project automation 绑定到某个项目路径，适合围绕固定仓库重复执行。

这类 automation 每次触发都会新起一条独立执行。执行完以后，结果会进入 inbox 或 triage 队列；没有发现新内容时，可以自动归档。适用场景包括每周依赖更新检查、每天的 issue triage、部署后定期检查某个仓库的 review comments。

关键限制是它依赖本地环境：Codex app 所在机器必须开着，app 必须在运行，项目路径也必须还在。关机、休眠或 app 关闭后，它不会继续执行。长期无人值守的后台托管，不该走这一类。

1.2 thread automation (heartbeat)：同线程定期唤醒

thread automation 是 heartbeat-style recurring wake-up calls，附着在当前对话线程上。核心点是保留上下文：每次唤醒时，它会继续同一个对话，而不是新建一条独立执行。

它适合部署后的定期日志检查、跨天任务跟进、持续 triage。比如你让 Codex 每 10 分钟看一次部署日志，只在出现错误或完成信号时汇报，没变化就安静等待下一轮。这样的任务需要上下文延续，standalone automation 就不合适。

heartbeat 不是永久 daemon，也不是 forever loop。它是“定期唤醒 -> 检查 -> 汇报 -> 等待”的节奏。app 暂停或关闭后，heartbeat 也会停。

1.3 类型对比表

维度	standalone/project automation	thread automation (heartbeat)
运行位置	后台独立线程	当前对话线程
上下文保留	每次新建上下文	保留当前会话上下文
适用场景	重复性独立任务、issue triage、依赖检查	长任务跟进、持续 triage、部署日志检查、跨天任务
依赖条件	本地 app / 机器 / 项目路径必须存在	当前线程必须绑定
结果呈现	inbox / triage，无发现自动归档	当前对话窗口
停止方式	关闭 automation 状态开关	暂停或关闭 app

判断时先问：任务是不是需要保留上下文？需要的话用 thread automation。再问：任务是不是绑定具体项目？绑定的话用 project automation，不然就用 standalone automation。

二、判断什么任务适合自动化

不是所有重复活都适合 Automations。先看任务特征，再决定要不要交给它。

2.1 适合 Automations 的任务特征

适合 Automations 的任务通常有三个特征：重复性高、规则清楚、结果可验证。

重复性高的任务会周期出现，而且每次目标都差不多。比如每周一检查依赖更新、每天早上看 issue triage、部署后固定时间检查某个仓库。这样的任务，检查范围、判断标准和输出格式都可以先写死。

规则明确的任务尤其适合写成 prompt。比如“检查 package.json 里依赖版本，列出有新版本的包，给出升级建议”。这类任务的判断标准稳定，完全没必要每次都人工重述一遍。

可验证的输出也很重要。结果最好能回到 inbox / triage，没发现时自动归档，发现问题时给出明确下一步。这样你才知道自动化是帮你省事，还是只是换个地方制造噪音。

2.2 不适合 Automations 的任务特征

不适合 Automations 的任务，通常有四个特征：需要频繁人工判断、依赖外部状态频繁变化、prompt 还没稳定、或者必须长期无人值守。

需要频繁人工判断的任务，边界往往模糊。比如架构决策、复杂 bug 排查、临场权衡，这些都要求根据具体情况不断调整，不适合写死成 automation。

依赖外部状态频繁变化的任务也要小心。比如实时监控某个生产服务，状态变化太快，更适合专业监控工具，而不是 Automations。

还没验证过的 prompt 也不要直接自动化。先手动跑几轮，把规则、范围和输出打磨稳，再考虑沉淀成 automation。

长期无人值守的任务更不应该直接交给 project-scoped automation。它依赖本地 app、机器和项目路径，机器一关就停，不是云端托管方案。

2.3 任务适配判断表

任务类型	是否适合	判断依据	推荐方案
每周依赖更新检查	是	重复性高、规则明确、可验证	standalone automation 或 project automation
每日 issue triage	是	可进 inbox、无发现可归档、prompt 稳定	standalone automation 或 thread heartbeat
部署后定期日志检查	是	同线程跟进、保留上下文	thread automation
架构决策	否	需要频繁人工判断、边界模糊	手动对话
复杂 bug 排查	否	需要根据具体情况调整	手动对话
实时监控	否	依赖外部状态频繁变化	专业监控工具
长期无人值守托管	否	project-scoped automation 依赖本地环境	CI 或 Cloud 方案
尚未验证的自动化流程	否	prompt 不稳定、手动执行不一致	先手动稳定，再沉淀

判断流程很简单：先看 prompt 稳不稳，再看任务要不要保留上下文，最后看是不是需要长期云端托管。

三、创建第一个 standalone/project automation

3.1 创建流程

1. 先把任务写清楚。范围、输入、输出、成功条件和停止条件都要明确。
2. 选 automation 类型。独立重复任务用 standalone；固定仓库的重复任务用 project automation。
3. 选运行位置。Git 仓库优先用 worktree，减少对当前编辑区的影响。
4. 设定频率。分钟级任务要写清楚停止条件，别让它无限唤醒。
5. 先试跑几轮。确认输出稳定，再切到正式频率。

3.2 worktree vs local project 怎么选

运行位置	隔离程度	适用任务	风险提示
worktree	隔离修改，不影响当前工作目录	会改文件、会写代码、会提 PR 建议的任务	出错通常只污染独立工作树，方便回收
local project	没有隔离，直接在当前目录执行	只读检查、报告生成、依赖 triage	可能影响正在编辑的文件

Git 仓库里的修改型任务，优先用 worktree。只有明确只是读文件、做检查、发报告的时候，才考虑 local project。

四、创建 thread automation (heartbeat)

4.1 创建流程

1. 先确认当前对话已经在处理一个长任务。
2. 再把 thread automation 绑到这条对话上。
3. 写清楚每次唤醒要检查什么、什么情况下汇报、什么情况下沉默。
4. 规定停止条件，比如成功、失败、超时、或者超过某个轮次。
5. 先用小频率跑几轮，确认不会刷屏，再进入正式节奏。

4.2 heartbeat prompt 模板示例

每 10 分钟检查一次部署日志，只在以下情况汇报：

1. 出现错误信号（包含 "error"、"failed"、"exception"）
2. 出现完成信号（包含 "deployed"、"success"、"completed"）
3. 超过 30 分钟仍未完成

汇报格式：
- 状态：[进展中 / 成功 / 失败]
- 关键日志片段：[最多 3 行]
- 下一步建议：[如果有]

无变化时沉默，不输出任何内容。

这个 prompt 把检查范围、输出边界、停止条件都写清了。它不会每次醒来都复述“检查完成”，也不会把无变化状态刷成一堆噪音。

五、安全配置：sandbox、approval policy 与团队治理

5.1 sandbox 与 approval policy 设置

Automations 默认跑在 sandbox 里。sandbox 决定了它能碰到哪些文件、能不能越界、要不要额外授权。对后台自动化来说，默认越小越稳。

sandbox 模式	权限范围	适用场景	风险级别
read-only	只读，无写权限	纯检查、分析任务	低
workspace-write	工作区内可读写，外部动作需授权	日常自动化、改文件、提 PR	中
danger-full-access	系统访问不受限	隔离环境或高度信任任务	高

approval policy 控制遇到高风险操作时要不要继续请求授权。

approval policy	行为	适用场景
on-request	按需请求更高权限	需要一点自主性但仍要人工把关
never	完全自动执行，不提示用户	自动化脚本或非交互环境

建议默认用 workspace-write + rules/allowlist，避免 full access + unattended。后者一旦配宽了，出错空间很大。

5.2 团队治理建议

团队可以通过 requirements.toml 把权限和 sandbox 固定下来，避免每个人随手开太大。

[agent]
approval_policy = "never"
sandbox = "workspace-write"

这类配置的目标不是“什么都不给”，而是“默认收紧，只在确实需要时再放开”。

六、三个可以直接改的自动化模板

6.1 每周依赖巡检

• 触发频率：每周一次
• 使用位置：Git 仓库优先 worktree
• 成功输出：列出可升级依赖和建议优先级
• 停止条件：没有可升级项时只记一条简短结果
• 权限边界：只读或轻量写入报告

6.2 部署后 heartbeat 跟进

• 触发频率：每 10 分钟一次，最多 30 分钟
• 使用位置：thread automation
• 成功输出：部署成功、失败或超时摘要
• 停止条件：出现成功信号、失败信号，或者超时
• 权限边界：只读日志，不碰生产环境

6.3 每日 issue / PR triage

• 触发频率：每天一次
• 使用位置：standalone automation 或 thread heartbeat
• 成功输出：把需要人工处理的条目送进 inbox
• 停止条件：没有新内容就沉默
• 权限边界：默认 workspace-write，尽量不要全权访问

七、自动化失败时先查这 6 件事

1. Codex app 是否还在运行，机器有没有休眠。
2. 项目路径是否还存在，worktree 是否被移动或删除。
3. sandbox 有没有把写文件或网络操作拦住。
4. thread automation 是否真的需要保留上下文。
5. worktree 是否堆太多，需要清理。
6. prompt 里有没有写清“什么时候停、什么时候汇报”。

八、FAQ 清单

8.1 Automations 是定时任务还是一直跑的 agent？

它更像定时或周期性唤醒的后台任务。每次唤醒后执行检查、处理、汇报，然后回到等待状态，不是 forever loop。

8.2 standalone/project 和 thread automation 有什么区别？

standalone/project automation 是后台独立任务，每次新建执行，结果进 inbox / triage。thread automation 是同线程 heartbeat，会保留当前会话上下文。

8.3 什么任务适合 Automations，什么任务不适合？

适合的是重复性高、规则明确、可验证的任务。不适合的是需要频繁人工判断、依赖外部状态频繁变化、或者 prompt 还没稳定的任务。

8.4 worktree vs local project 怎么选？

修改型任务优先 worktree，减少对当前编辑区的影响。只读检查、报告类任务可以用 local project。

8.5 app 关了、电脑休眠后还会跑吗？

不会。project-scoped automation 依赖本地 app、机器和项目路径，app 关掉或机器休眠后就停了。

8.6 什么时候该用 Computer Use？

只有必须直接操作 GUI、没有 API 或 web 接口可走时才值得用。能用普通代码完成的，通常不需要 Computer Use。

8.7 怎么控制成本和频率？

把频率设到够用就好，别盲目加密唤醒；用 /status 看状态；给每个 automation 写清停止条件；并尽量避免过密轮询。

九、总结

Computer Use、内置浏览器、Automations，这三类能力解决的是不同层的问题。Automations 适合把“稳定、可验证、重复”的工作交给 Codex 在后台跑；thread automation 适合跟进跨天长任务；worktree 和 sandbox 则负责把风险控制住。

最稳的顺序永远是：先判断任务适不适合自动化，再选运行位置和权限，最后再调频率。先把人类能做对的流程写稳，再让 Codex 帮你把它跑得更久一点。