Codex Record & Replay：把桌面操作录成可复用 Skill

Codex 的 Record & Replay 是一种“录制并复现”能力：你先在电脑上完整演示一遍任务，Codex 观察你的操作过程，把流程整理成一个 skill（技能）；下一次遇到类似任务时，你只需要给出本次不同的输入，Codex 就可以调用这个 skill，尝试自己完成后续步骤。

它适合处理一类很常见、但过去很难自动化的工作：流程本身不复杂，却很依赖图形界面、账号状态、个人习惯和隐性规则。例如：

这类任务用脚本写并不一定划算，因为很多系统没有稳定的 Application Programming Interface（API，应用程序编程接口），或者接口没有覆盖完整流程。Record & Replay 的思路不是要求软件先暴露接口，而是让 Codex 学会人类怎么使用软件界面。

flowchart LR
    A[人类演示一次任务] --> B[Codex 观察界面和操作]
    B --> C[整理成 skill]
    C --> D[新任务提供不同输入]
    D --> E[Codex 调用 skill]
    E --> F[通过电脑操作完成任务]

Record & Replay 解决的核心问题

传统自动化通常依赖三件事：

Record & Replay 介于人工操作和自动化脚本之间。它不是把鼠标坐标硬录下来，也不是生成一段完全固定的宏，而是把一次演示转化为可复用的上下文说明。这个 skill 会记录任务适用条件、需要的输入、执行步骤、关键判断点和完成后的验证方式。

换句话说，它更像一份“给 AI 用的操作手册”，而不是一段只能按固定路径运行的脚本。

一个 skill 里面通常有什么

录制结束后，Codex 会复盘刚才观察到的操作，并起草一个 skill。一个可用的 skill 至少要回答四个问题：

skill 的价值在于“保留规则”。很多工作流真正难写清楚的不是点击顺序，而是隐藏在操作中的偏好，例如：

• 文件名要按什么格式组织；
• 某个字段没有特殊说明时默认填什么；
• 遇到多个选项时优先选哪一个；
• 什么时候发布，什么时候保存草稿；
• 哪些步骤必须人工确认后才能继续。

这些规则如果全部用文字一次性描述，成本很高。先演示一遍，再补充关键偏好，通常更接近真实工作方式。

录制和复现的工作流

Record & Replay 的完整过程可以拆成两个阶段：录制阶段负责“学习”，复现阶段负责“执行”。

sequenceDiagram
    participant U as 用户
    participant C as Codex
    participant CU as Computer Use
    participant App as 桌面应用或网页

    U->>C: 启动录制并说明任务目标
    U->>App: 正常完成一次操作
    C->>CU: 观察窗口、点击、输入和页面状态
    CU-->>C: 返回操作轨迹和界面信息
    C->>C: 生成 skill 草稿
    U->>C: 补充隐性规则和可变输入
    C->>C: 完善 skill

    U->>C: 新任务调用该 skill
    C->>CU: 按当前输入执行操作
    CU->>App: 点击、输入、切换页面、上传文件
    App-->>CU: 返回界面状态
    CU-->>C: 确认结果
    C-->>U: 汇报完成情况或请求确认

录制时要专注于一个任务，不要把无关操作混进去。因为 Codex 会把观察到的流程用于生成 skill，如果中途切去处理邮件、聊天或其它窗口，skill 里可能混入噪声，后续复现时就更容易跑偏。

怎么启用 Record & Replay

Record & Replay 目前依赖 Computer Use，也就是 Codex 操作电脑图形界面的能力。启用时一般需要完成三件事：

1. 在 Codex 应用里打开 Plugins（插件）。
2. 搜索并添加 Record & Replay 插件。
3. 授予录制和 Computer Use 相关权限。

插件入口通常会出现在 Codex 的插件管理界面。确认添加的是 Record & Replay 后，再进入权限授权流程。

插件安装完成后，系统会要求你确认录制权限。这个权限很关键，因为 Codex 需要观察窗口内容、鼠标点击、键盘输入和应用状态，才能把一次人工演示整理成 skill。

权限确认后，就可以像平时一样在 Mac 上完成目标任务。录制期间要只做当前这一个流程，例如只上传一个视频、只创建一个 issue，或者只导出一份报表。

录制结束后，Codex 会根据捕捉到的操作生成 skill 草稿。这个草稿不一定一次就完美，最好立刻补充那些录制过程里看不出来的规则，例如“默认选择 Private”“标题用文件名去掉日期前缀”“字幕文件必须和视频文件同名”。

录制时应该怎么做

高质量的录制会直接影响 skill 的可复用性。可以按下面的清单准备：

不要录入密码、验证码、支付凭据、私钥、访问令牌等敏感信息。如果流程确实包含这些步骤，应该把它们设计成人工确认或人工输入点，而不是让 skill 自动处理。

Replay 不是简单“回放鼠标”

Record & Replay 的 replay（复现）并不是把第一次录制的鼠标轨迹按坐标重新跑一遍。如果只是坐标回放，窗口位置、页面布局、文件名、弹窗状态稍微一变，流程就会失效。

Codex 生成的 skill 更接近下面这种结构：

name: upload-video-to-platform
when_to_use:
  - 需要上传一个视频文件并配置元数据
inputs:
  - video_file
  - title
  - description
  - thumbnail_file
  - subtitle_file
  - visibility
steps:
  - 打开视频管理后台
  - 进入上传流程
  - 选择 video_file
  - 填写 title 和 description
  - 上传 thumbnail_file
  - 如果提供 subtitle_file，则进入字幕设置并上传
  - 根据 visibility 设置 Private 或 Unlisted
validation:
  - 确认视频状态变为已保存或已上传
  - 检查标题、缩略图、字幕和隐私选项是否正确

真实的 skill 不一定长成这个 YAML 格式，但核心思想类似：它记录的是任务结构、输入参数和验证逻辑，而不是死板的坐标序列。

这也是它能处理“这次上传 A 文件，下次上传 B 文件”的原因。skill 作为 reusable context（可复用上下文）参与每次任务执行，Codex 会结合当前页面状态、文件列表和用户给出的输入重新规划操作。

Codex 到底通过什么方式操作电脑

Record & Replay 能够复现流程，底层依赖 Codex 的多种操作能力。它们覆盖范围不同，适合的任务也不同。

flowchart TD
    A[Codex 任务执行] --> B[Computer Use]
    A --> C[Chrome 扩展]
    A --> D[应用内浏览器]
    A --> E[Appshot]

    B --> B1[操作 macOS / Windows 图形界面]
    B --> B2[窗口、菜单、键盘、剪贴板]
    B --> B3[适合没有 API 的桌面应用]

    C --> C1[使用已登录 Chrome]
    C --> C2[适合 Gmail、Salesforce、内部后台]
    C --> C3[可理解多标签工作流]

    D --> D1[运行在 Codex 对话内部]
    D --> D2[适合 Web 应用调试]
    D --> D3[隔离浏览器 cookie 和扩展]

    E --> E1[捕捉当前窗口]
    E --> E2[把截图和文字加入对话]
    E --> E3[用于指向问题，不负责操作]

Computer Use 覆盖面最广，因为它面向的是人类平时使用的图形界面。无论是菜单、按钮、输入框、文件选择器，还是桌面应用里的复杂面板，只要人能通过界面操作，Codex 理论上就可以通过视觉和控制能力尝试操作。

它的缺点也明显：比 API 慢。Codex 需要观察界面、判断下一步、执行点击或输入、等待页面响应，再确认状态是否正确。这个循环天然比直接调用接口耗时。

为什么 Record & Replay 必须依赖 Computer Use

Record & Replay 学到的是“人怎么操作电脑”。要复现这套流程，Codex 必须具备实际控制桌面或网页的能力，否则 skill 只能停留在说明书层面，无法真正执行。

可以把两者关系理解成：

如果 Computer Use 被组织策略关闭，Record & Replay 通常也无法出现或无法使用。对于团队环境，这一点尤其重要。

示例：上传视频工作流怎么被学会

上传视频是 Record & Replay 很典型的场景，因为它同时包含文件操作、表单填写、条件判断和结果验证。

一次完整的演示可能包含这些动作：

1. 打开视频管理后台；
2. 进入上传入口；
3. 选择 .mp4 视频文件；
4. 填写标题、描述和标签；
5. 上传缩略图；
6. 匹配 .srt 字幕文件；
7. 设置可见性，例如 Private 或 Unlisted；
8. 检查保存状态。

这里面真正需要学习的不是“点了哪个按钮”这么简单，而是背后的规则：

Record & Replay 把这些规则和操作路径沉淀下来后，下一次上传视频时只需要提供新的文件、标题、描述和可见性要求。Codex 可以根据 skill 执行同类流程，而不是重新从零理解后台怎么用。

什么时候适合用 Record & Replay

Record & Replay 不是万能自动化工具。它适合“重复、依赖界面、有隐性规则、但变化不太剧烈”的任务。

如果任务已经有稳定 API，用 API 自动化通常更可靠、更快，也更容易审计。Record & Replay 更适合作为“没有好接口时的自动化入口”，或者用来快速把个人工作流沉淀成可复用 skill。

什么时候应该做成独立插件

Record & Replay 适合快速从一次演示生成 skill，但如果要把流程提供给整个团队长期使用，就不应该只停留在录制层面。

可以把 Record & Replay 看作快速捕捉经验的方式，把插件看作正式交付和团队分发的方式。前者强调低成本生成，后者强调稳定、可维护和可管理。

Codex 不只绑定 OpenAI 模型

Codex 应用、Command-Line Interface（CLI，命令行界面）和 Software Development Kit（SDK，软件开发工具包）并不只能使用 OpenAI 自家的模型。通过 config.toml 配置 model_providers，可以接入 Ollama、LM Studio 这类本地模型，也可以接入 Mistral、Azure、Amazon Bedrock 等第三方服务。

本地开源模型模式通常通过 --oss 参数启动：

codex --oss

config.toml 的核心是声明 provider，再指定默认使用哪个 provider 和模型。不同服务的字段会有差异，结构可以理解成下面这样：

# config.toml：示意结构，具体字段按目标 provider 的配置要求填写

model_provider = "local-provider"
model = "local-model-name"

[model_providers.local-provider]
# base_url、鉴权方式、协议类型、模型列表等配置放在这里

这意味着 Record & Replay 所在的 Codex 客户端本身是开放的，它可以把“录制成 skill、复现工作流”的交互方式带到不同模型后端上。不过桌面控制、权限、安全策略和插件生态仍然取决于 Codex 客户端当前支持的能力。

管理员需要注意的开关

Record & Replay 当前有几个前提条件：

如果组织用 requirements.toml 统一管理 Codex 功能，要特别注意下面这个开关：

[features]
computer_use = true

当 computer_use 被设为 false 时，Computer Use 会被禁用，Record & Replay 也会一起不可用。用户看不到 Record & Replay 入口时，不一定是客户端版本问题，也可能是组织策略关闭了底层能力。

安全边界：哪些事必须人工确认

让 AI 操作电脑，本质上是在把一部分人的操作权限交给模型执行。越接近真实账号、真实资金和真实业务系统，越要设计确认点。

高风险步骤包括：

一个好的 skill 不应该追求“全程无人值守”，而应该把低风险、重复的步骤交给 Codex，把高风险、不可逆或对外可见的步骤留给人确认。

Record & Replay 代表的交互变化

过去，软件自动化的边界主要由 API 决定。软件开放了什么接口，自动化系统就能稳定调用什么能力；没有接口的部分，就只能靠人工或脆弱的脚本补齐。

Record & Replay 改变的是入口。它让 Codex 直接学习人类使用软件的方式，把按钮、菜单、窗口、文件选择器和网页表单都纳入可操作范围。Computer Use 负责实际操作电脑，Record & Replay 负责把人的操作经验沉淀成 skill。

这会带来一个很实际的变化：人不再只是软件的直接操作者，也开始成为 AI 的工作流训练者。以后处理重复任务时，重点可能不再是“每一步该怎么点”，而是“怎样演示一次清晰、可复用、风险可控的流程”。