跳到主要内容

本文为非官方中文翻译，内容以 OpenAI 官方英文文档为准。
官方来源：https://developers.openai.com/codex/app/automations

自动化

为重复发生的 Codex 任务安排计划

在后台自动执行重复任务。Codex 会将发现添加到收件箱；如果没有需要报告的内容，则会自动归档该任务。你还可以将自动化与 skills 结合使用，以处理更复杂的任务。

对于项目范围的自动化，应用需要保持运行，并且所选项目需要在磁盘上可用。

在 Git 仓库中，你可以选择让自动化在本地项目中运行，或在新的 worktree 上运行。这两种选项都会在后台运行。worktree 会将自动化产生的更改与尚未完成的本地工作分离，而在本地项目中运行则可能修改你仍在处理的文件。在非版本控制的项目中，自动化会直接在项目目录中运行。

你也可以将模型和推理强度保留为默认设置；如果你想更精细地控制自动化的运行方式，也可以显式选择它们。

包含计划和提示词字段的自动化创建表单

管理任务​

你可以在 Codex 应用侧边栏的自动化面板中找到所有自动化及其运行记录。

“Triage” 部分充当你的收件箱。带有发现结果的自动化运行会显示在那里，你还可以筛选收件箱以显示所有自动化运行或仅显示未读项。

独立自动化会按计划启动全新的运行，并在 Triage 中报告结果。当每次运行都应彼此独立，或者一个自动化需要跨一个或多个项目运行时，请使用它们。如果你需要自定义频率，请选择自定义计划并输入 cron 语法。

对于 Git 仓库，每个自动化都可以在你的本地项目中运行，或在专用的后台 worktree 上运行。如果你希望将自动化更改与尚未完成的本地工作隔离开来，请使用 worktree。如果你希望自动化直接在主 checkout 中工作，可以使用本地模式，但请注意它可能会更改你正在积极编辑的文件。在非版本控制项目中，自动化会直接在项目目录中运行。你可以让同一个自动化在多个项目上运行。

自动化使用你的默认沙箱设置。在只读模式下，如果工具调用需要修改文件、访问网络或与电脑上的应用交互，则会失败。启用完全访问时，后台自动化会带来更高的风险。你可以在 Settings 中调整沙箱设置，并使用 rules 有选择地将命令加入允许列表。

自动化可以使用与 Codex 相同的插件和 skills。为了让自动化更易维护，并便于团队间共享，请使用 skills 来定义动作，并提供工具和上下文。你可以在自动化中使用 $skill-name 来显式触发某个 skill。

让 Codex 创建或更新自动化​

你可以在普通的 Codex 线程中创建和更新自动化。描述任务、计划，以及该自动化是应保持附着在当前线程上，还是启动全新的运行。Codex 可以起草自动化提示词、选择合适的自动化类型，并在范围或频率变化时更新它。

例如，你可以要求 Codex 在此线程中于部署完成期间提醒你，或者要求它创建一个独立自动化，以定期检查某个项目。

Skills 也可以创建或更新自动化。例如，一个用于照看 pull request 的 skill 可以设置一个循环自动化，通过 GitHub 插件检查 PR 状态并修复新的审查反馈。

线程自动化​

线程自动化是附着在当前线程上的心跳式周期性唤醒调用。当你希望 Codex 按计划持续返回同一对话时，请使用它。

当计划任务应保留线程上下文，而不是每次都从新的提示词开始时，请使用线程自动化。

线程自动化可以使用基于分钟的间隔来进行活跃的后续跟进循环，也可以使用每日或每周计划，以便你在特定时间进行检查。

线程自动化适用于：

  • 检查一个长时间运行的命令，直到其完成
  • 轮询 Slack、GitHub 或其他已连接来源，并且结果应保留在同一线程中
  • 提醒 Codex 按固定频率继续审查循环
  • 运行由 skill 驱动且使用插件的工作流，例如检查 PR 状态并处理新的反馈
  • 让聊天持续聚焦于某项正在进行的研究或分诊任务

当每次运行都应彼此独立、需要跨多个项目运行，或者希望发现结果在 Triage 中显示为独立的自动化运行时，请使用独立自动化或项目自动化。

创建线程自动化时，要让提示词具有持久性。它应描述 Codex 每次在线程被唤醒时应做什么、如何判断是否有重要内容需要报告，以及何时停止或向你请求输入。

测试自动化​

在为自动化安排计划之前，先在普通线程中手动测试提示词。这有助于你确认：

  • 提示词清晰且范围正确。
  • 所选或默认的模型、推理强度和工具表现符合预期。
  • 生成的 diff 便于审查。

开始安排运行后，请检查最初几次输出，并根据需要调整提示词或频率。

自动化的 worktree 清理​

如果你为 Git 仓库选择了 worktree，频繁的计划可能会随着时间推移创建大量 worktree。归档你不再需要的自动化运行，并避免固定运行，除非你打算保留它们的 worktree。

权限和安全模型​

自动化在无人值守的情况下运行，并使用你的默认沙箱设置。

  • 如果你的沙箱模式是 read-only，当工具调用需要修改文件、访问网络或与电脑上的应用交互时，会失败。请考虑将沙箱设置更新为 workspace write。
  • 如果你的沙箱模式是 workspace-write，当工具调用需要修改工作区之外的文件、访问网络或与电脑上的应用交互时，会失败。你可以使用 rules 有选择地将可在沙箱外运行的命令加入允许列表。
  • 如果你的沙箱模式是 full access，后台自动化会带来更高的风险，因为 Codex 可能在不询问的情况下更改文件、运行命令并访问网络。请考虑将沙箱设置更新为 workspace write，并使用 rules 有选择地定义 agent 可在 full access 下运行哪些命令。

如果你处于受管环境中，管理员可以使用管理员强制要求来限制这些行为。例如，他们可以禁止 approval_policy = "never"，或者限制允许的沙箱模式。请参阅 管理员强制要求（requirements.toml）。

当你的组织策略允许时，自动化会使用 approval_policy = "never"。如果管理员要求不允许 approval_policy = "never"，自动化会回退到你所选模式的审批行为。

示例​

自动创建新的 skills​

扫描过去一天中所有 `~/.codex/sessions` 文件，如果在使用某些 skills 时存在任何问题，就更新这些 skills，使它们更有帮助。只处理个人 skills，不要处理仓库 skills。

如果有任何我们经常在做、且做起来比较困难、值得保存为 skill 以加快未来工作的内容，那我们就这么做。

当然，不需要觉得必须更新任何内容——只有在有充分理由时才更新！

如果你有做任何修改，请告诉我。

随时了解你的项目最新进展​

查看最新的远程 origin/master 或 origin/main。然后为过去 24 小时内涉及以下内容的提交生成一份管理层简报

格式与结构：

- 使用丰富的 Markdown（工作流 H1 分节、副标题使用斜体、按需使用水平分隔线）。
- 前言可以写成类似“这是 <directory> 过去 24 小时的简报：”
- 副标题应写为：“按工作流分组并标注负责人的叙述式说明。”
- 按工作流分组，而不是逐个列出每次提交。工作流标题应为 H1。
- 为每个工作流写一段简短的叙述，用通俗语言解释这些更改。
- 在更易读时使用项目符号和加粗
- 可以按人员列出项目符号，但请将他们的名字加粗

内容要求：

- 内联包含 PR 链接（例如 [#123](...)），不要使用“PRs:”标签。
- 不要包含 commit hash 或“Key commits”部分。
- 一个工作流下出现多个 PR 没问题，但避免按每次提交列项目符号。

范围规则：

- 仅包含当前 cwd（或等效主 checkout）内的更改
- 仅包含过去 24 小时的提交。
- 如有帮助，可使用 `gh` 获取 PR 标题和描述。
  也可以随意拉取 PR 审查和评论

将 automations 与 skills 结合来修复你自己的 bug​

创建一个新的 skill，尝试通过创建一个新的 $recent-code-bugfix 来修复由你自己提交引入的 bug，并将其存储在你的个人 skills 中。

---
name: recent-code-bugfix
description: 查找并修复当前作者在过去一周内于当前工作目录中引入的一个 bug。当用户希望从其最近更改中主动修复 bug、当提示为空，或当被要求分诊/修复由其最近提交导致的问题时使用。根因必须直接映射到作者自己的更改。
---

# Recent Code Bugfix

## 概述

查找当前作者在过去一周内引入的一个 bug，实现修复，并在可能时验证修复。在当前工作目录中操作，假设代码位于本地，并确保根因直接关联到作者自己的编辑。

## 工作流

### 1) 确定最近更改的范围

使用 Git 识别过去一周内的作者和变更文件。

- 通过 `git config user.name`/`user.email` 确定作者。如果不可用，则使用环境中的当前用户名，或询问一次。
- 使用 `git log --since=1.week --author=<author>` 列出最近的提交和文件。重点关注这些提交触及的文件。
- 如果用户的提示为空，直接按这个默认范围继续。

### 2) 找出与最近更改相关的具体故障

优先处理可直接归因于作者编辑的缺陷。

- 如果本地有日志或 CI 输出，查找最近的失败（测试、lint、运行时错误）。
- 如果没有提供失败信息，运行与已编辑文件相关的最小验证（单个测试、文件级 lint，或定向复现）。
- 确认根因与作者的更改直接相关，而不是无关的遗留问题。如果只发现无关失败，则停止并报告未检测到符合条件的 bug。

### 3) 实施修复

进行符合项目约定的最小修复。

- 仅更新解决该问题所需的文件。
- 避免添加额外的防御性检查或无关重构。
- 保持更改与本地风格和测试一致。

### 4) 验证

在可能的情况下尝试验证。

- 优先选择最小验证步骤（定向测试、聚焦的 lint，或直接复现命令）。
- 如果无法运行验证，说明本应运行什么以及为何未执行。

### 5) 报告

总结根因、修复方式以及执行过的验证。明确说明根因如何与作者最近的更改相关联。

随后，创建一个新的 automation：

检查我过去 24 小时内的提交并提交一个 $recent-code-bugfix。