Codex Record & Replay 的核心原理

原文：https://indieseek.co/zh/blogs/codex-record-and-replay-principles/

Codex Record & Replay 的核心原理

Codex Record & Replay 有意思的地方在于，它从一个很自然的人类习惯出发：一件事很难描述清楚时，就演示一次。

用户不需要写一大段 prompt，解释每一次点击、窗口切换、偏好和边界情况。用户只要在 macOS 上录制一个工作流，Codex 观察这段过程，读取事件 trace，然后草拟一个可复用 Skill。

核心思路很简单：

人类演示 -> 结构化事件 trace -> 可复用 Skill -> 语义回放 -> 结果验证

录制出来的 trace 不是最终自动化。它是证据。真正可复用的产物是 Skill。

这个区别很重要。

它不是坐标宏

传统宏录制器通常记低层动作：移动到这里，点击那里，输入这段文字，等一会。

这种方式很容易坏。按钮位置变了，页面改版了，窗口大小不同了，某次用户已经登录，另一次用户没登录。

Record & Replay 指向的是更好的模型。录制帮助 Codex 理解工作流，但回放时应该使用最稳定的工具。

有 API，就用 API。有浏览器目标，就用浏览器自动化。需要操作桌面 UI，就用 Computer Use。状态变了，就验证当前状态并调整。

所以它更像工作流学习，而不是鼠标回放。

公开形态

从 Codex 公开文档看，流程大致是：

  • 用户从 Codex 开始录制。
  • 用户在 macOS 上完成一个工作流。
  • Codex 通过 Computer Use 捕获动作和窗口上下文。
  • 用户停止录制。
  • Codex 读取录制 trace。
  • Codex 草拟一个可以检查、编辑和复用的 Skill。

    • 它适合那些“演示比描述更容易”的场景：

    • 重复性 UI 工作流；
    • 个人或团队偏好；
    • 没有好 API 的工具；
    • 跨浏览器页面、桌面 app、文件和弹窗的任务。

    它的承诺不是“Codex 记住每个像素”，而是“Codex 从演示里学到足够的信息，生成一份可复用的操作说明”。

    本机插件透露了什么

    本机 Codex app 里包含一个 bundled record-and-replay 插件。这个插件通过 Computer Use helper 暴露了一个 event-stream MCP server。

    内置 Skill 会让 Codex：

    • 用 event_stream_start 开始录制；
    • 用 event_stream_status 查询状态；
    • 用 event_stream_stop 停止录制；
    • 读取返回的 metadataPath 和 eventsPath；
    • 把 events.jsonl 当成主要证据；
    • 把 session.json 当成时间和路径元数据；
    • 把录制结果当成意图证据，而不是要求后续严格复现每一个 UI 动作。

    最后一点才是设计核心。

    对 helper 二进制做字符串扫描，也能看到 event_stream_start、event_stream_status、event_stream_stop、eventsPath、metadataPath、suppressedEventsPath、AXUIElement、screenRecordingGranted 这些名字。

    这不能揭示私有实现，但和公开形态是吻合的：macOS Accessibility、输入和窗口上下文、屏幕上下文、本地 trace 文件，以及 Skill 编译。

    一张图看架构

    flowchart LR U["用户演示工作流"] --> P["Record & Replay 插件"] P --> MCP["event-stream MCP server"] MCP --> OS["macOS Accessibility\n输入事件\n屏幕上下文"] OS --> E["session.json\nevents.jsonl"] E --> C["Codex 分析 trace\n意图、输入、步骤、验证"] C --> S["可复用 SKILL.md"] S --> R["新线程使用 Skill"] R --> T["Computer Use\nBrowser\nConnector\nCLI / API"] T --> V["验证结果"]

    重要的是这几层分工：

    • Record 记录发生了什么。
    • Trace 保存证据。
    • Compile 把嘈杂证据变成可读 Skill。
    • Replay 用最稳定的工具执行 Skill。
    • Verify 检查结果是否真的正确。

    没有 compile 和 verify，系统就会退化成脆弱的宏录制器。

    事件 trace 应该包含什么

    公开文档没有给完整 schema，但有用的 trace 一定不止点击。

    它应该保留：

    • 鼠标和键盘动作；
    • 前台 app 和窗口上下文；
    • 浏览器 URL 和页面状态；
    • 按钮、输入框、菜单、选中对象等 Accessibility 目标；
    • 文本输入和选区；
    • 结构信息不足时的截图或关键帧；
    • 开始、停止、取消、超时和脱敏边界。

    一个事件可以抽象成这样：

    { "timestamp": "2026-06-22T10:00:00.000Z", "surface": "desktop", "kind": "mouse.click", "app": { "name": "Google Chrome", "bundleIdentifier": "com.google.Chrome" }, "window": { "title": "Example Console", "url": "https://example.com/admin" }, "target": { "role": "AXButton", "name": "Save", "bounds": { "x": 1040, "y": 72, "width": 88, "height": 36 } } }

    目标不是低层回放完全保真，而是给 Codex 足够证据，让它理解工作流。

    Skill 编译才是难点

    原始 trace 通常很吵。里面会有等待、焦点变化、滚动、重复点击和误操作。

    Compiler 要把这些内容压缩成 Skill：

    flowchart TD A["events.jsonl"] --> B["清洗噪声"] B --> C["推断任务目标"] C --> D["抽取变量"] D --> E["生成语义步骤"] E --> F["定义验证方式"] F --> G["加入失败处理"] G --> H["SKILL.md"]

    一个好的 Skill 应该说明：

    • 什么时候使用它；
    • 每次运行哪些输入会变；
    • 需要什么登录、权限、页面、文件或 app 状态；
    • 哪些步骤真正重要；
    • 如何验证成功；
    • UI 变化时怎么办；
    • 哪些敏感数据不能保存。

    这就是它和传统 RPA 的区别。RPA 往往复现动作。Record & Replay 更像是在复现意图。

    Replay 应该选择最稳的路径

    Replay 不是读取 events.jsonl 后逐行执行。

    用户以后提出同类任务时，Codex 应该加载 Skill，解析输入和前置条件，然后为每一步选择最稳定的执行方式。

    flowchart TD A["用户提出同类任务"] --> B["Codex 读取匹配 Skill"] B --> C["解析输入和前置条件"] C --> D{"是否有稳定语义工具"} D -- "有" --> E["使用 connector、CLI、API 或浏览器自动化"] D -- "没有" --> F["使用 Computer Use 操作 UI"] E --> G["验证结果"] F --> G G --> H{"验证通过"} H -- "是" --> I["返回结果"] H -- "否" --> J["重试、调整或报告阻塞"] J --> G

    这样回放才更抗变化。按钮移动了，但 accessible name 没变，Codex 仍然可能找到它。如果有 connector 或 API，Codex 甚至可以绕过 UI。

    如果做一个类似 MVP

    我不会从只支持浏览器开始。Record & Replay 真正有意思的地方，是它能学习真实电脑工作流。

    最小可信 MVP 需要：

    • 浏览器录制：URL、DOM target、ARIA role/name、selector、输入、导航和截图；
    • 电脑录制：前台 app、窗口、Accessibility target、鼠标、键盘、选区和截图；
    • 一条带 surface 字段的统一 events.jsonl 时间线；
    • 把 trace 编译成 routine.md 或 SKILL.md 的 compiler；
    • 能按步骤选择浏览器、桌面、CLI、API 或 connector 的 runtime；
    • 能检查 DOM、Accessibility 状态、截图、文件输出或 API 返回的 verifier。

    模式可以概括为：

    Record -> Trace -> Compile -> Execute -> Verify -> Improve

    其他都是细节。

    安全不是可选项

    一个记录真实工作流的系统，会看到敏感信息。

    最低要求是：

    • 录制开始前说明采集范围；
    • 随时可以停止和取消；
    • 默认本地保存 trace；
    • 脱敏密码、token、key、付款信息和个人标识；
    • 把页面和窗口文字当成不可信输入；
    • 不可逆、付款、权限或破坏性动作需要确认；
    • 不要把真实凭据写进生成的 routine。

    Prompt injection 也要考虑。录制页面里可能出现试图指挥模型的文字。Compiler 必须把页面文本当作数据，而不是指令。

    最后的结论

    Codex Record & Replay 更适合理解成一个工作流学习系统：

    观察真实工作流 -> 保存结构化证据 -> 把证据编译成 Skill -> 按语义回放 Skill -> 验证结果

    真正的经验也很清楚：不要做鼠标录制器。要做 trace 系统、compiler、语义 runtime 和验证闭环。

    这才是 Record & Replay 和普通自动化工具真正不同的地方。

    来源和相关资源

    posted @ 2026-07-07 20:16  IndieSeek  阅读(0)  评论(0)    收藏  举报