--- layout: post.njk source: https://yage.ai/share/rpa-semantic-replay-codex-skills-20260628.html speaker: yage.ai title: |- Codex Record & Replay 与 reusable skills：RPA 正在从重放点击变成重放业务意图 date: '2026-06-28' summary: 文章探讨了自动化从单纯的重放点击转向重放业务意图的核心转变。OpenAI 的 Codex Record & Replay 正在将操作演示沉淀为可复用的 'skill' 资产，这种资产不再局限于固定的界面坐标和键鼠动作，而是抽象成了包含输入参数、决策点和验证规则的业务技能。这标志着自动化核心从‘人怎么操作界面’转向‘业务上怎样算完成’，强调了将人类隐性判断转化为机器可审阅和安全执行的资产。 area: tech-engineering category: ai-application tags: - record-replay - business-skill - workflow-automation - agentic-trajectory people: [] companies_orgs: - OpenAI products_models: - Codex Record & Replay media_books: [] draft: true status: evergreen --- OpenAI 最近给 Codex 推出了一组新能力，其中最容易被低估的是 Record & Replay：用户在 Mac 上演示一遍工作流程，Codex 捕获并分析这些步骤后，草拟一个可以复用的 skill。表面看，这是一个更聪明的录屏功能；往深一层看，它暴露了一个更大的变化：自动化正在从重放点击，转向重放业务意图。 这里的关键不在于 Codex 能不能帮用户少点几下鼠标，而在于它把一次操作演示沉淀成了什么资产。传统 RPA 录完以后得到的是流程图、selector、键鼠动作和异常分支。Codex 试图生成的是一份 skill：什么时候启用，需要哪些输入，执行时遵守哪些步骤，怎样验证结果正确。换句话说，软件自动化的核心资产正在从“人怎么操作界面”上移到“业务上怎样算完成”。 财务录入发票就是一个典型场景。真正消耗注意力的，通常是弄清楚每个操作背后的业务逻辑，而不是把字段填进系统。发票号跟采购订单（PO）匹配不上时，该直接退回还是先做异常标记？遇到不爱用系统、只发 PDF 文件的供应商，是先做字符识别，还是先发邮件催促？月初拉取经营月报、同步更新 CRM、往供应商平台录入三张报价表，在这三个小时里，真正用于点击按钮的时间其实还不到一半，其余精力全消耗在规则判断、数据核对和不同系统的频繁切换中。 常规的 RPA 录制工具能够精确记录鼠标点击位置、文本输入内容，以及页面之间的跳转逻辑，但它无法捕捉你在这个过程中停顿下来核对金额时的思考。结果就是，尽管自动化脚本在理想环境下能顺利通过演示，但真正落地运行的第一周，往往就会因为页面微小的变动而无法继续，比如金额字段在前端代码中更换了属性名称，或是网页突然跳出了一个从未见过的 Cookie 许可弹窗。 所以，Record & Replay 不是一个孤立的 Codex 小功能。它更像一个入口，让我们看到 RPA、computer use agent、工作流平台和企业自动化正在汇合到同一个问题上：如何把人类在界面里的隐性判断，变成机器可以审阅、复用和安全执行的业务技能。 ## 旧 RPA 重放动作，新 replay 重放任务语义 平心而论，现在的传统 RPA 早就超越了单纯记录屏幕坐标的阶段。例如，Microsoft Power Automate 的录制器 会捕捉鼠标和键盘针对特定用户界面元素的操作，并通过微软辅助技术标准（UIA 或 MSAA）定位。即便定位标识失效，系统也配有相应的修复工具与备用方案。而 UiPath 的 Task Mining 录制器 做法更进了一步，它会记录屏幕截图、点击动作和键盘事件，最后通过聚类算法绘制出任务路径图。此外，光学字符识别（OCR）与计算机视觉技术，也能在远程桌面或虚拟化环境等传统标识失效的场景下，准确识别各种图片按钮。流程挖掘技术甚至可以直接分析系统事件日志，自动找出业务流程中的变动分支与效率瓶颈。 然而，上述技术本质上都在解决同一个维度的问题，即如何稳定地记录界面操作，并原封不动地将其重现出来。录制完成后的产出通常是本地工作流、活动序列或操作路径图。到了实际运行阶段，自动化的成败主要依赖于定位标签的稳定性、对各种异常分支的穷举覆盖程度，以及整个工作流引擎的确定性。 语义化重放走的是另一条执行路径。它会先理解当前任务的目标和规则限制，在运行中实时观察屏幕画面、网页文档对象模型（DOM）、无障碍辅助树、工具返回结果以及运行日志。基于这些实时信息，系统会判断下一步该做什么，并在执行后对照成功标准进行验证。一旦遇到阻碍，它会尝试重新运行、更换工具，或者请求人工协助。这种运行机制和传统 RPA 那种必须遵循第一步找标签、第二步点击、第三步输入的固定模式，属于两种思路。 传统 RPA 是固定步骤链路，语义化重放是观察、行动、验证、恢复的闭环。 比起表面上的操作差异，这两者在如何保障可靠性这一底层逻辑上，有着更深的分歧。传统 RPA 依靠的是完全固定的步骤、一成不变的页面标签，以及对所有可能出现的异常情况进行人工预判。语义化重放则将赌注压在状态的实时感知、结果验证、人工审核、审计日志和回滚机制上。正因如此，前者在界面稍微发生改变时就会宣告失效；而后者虽然能够自如地应对页面改版，却也带来了大模型特有的非确定性。这就注定了各种关键的、高风险的业务操作，必须卡在人工审批的关口前。 ## Asset 从 flow 变成 skill 这两套技术路线之间真正的分野，在于录制之后沉淀下来的自动化资产，在形态上发生了根本性的改变。 在传统 RPA 巨头里，Microsoft Power Automate 的 Record with Copilot 已经接近这种通过演示生成工作流的体验。用户分享屏幕并配合口头讲解，AI 录制器会记录语音、鼠标和键盘操作，自动整理出一套 desktop flow。用户检查、修改并保存后，就可以运行。它强过传统录制器的地方在于，能够根据用户的语音旁白推断出分支条件和循环逻辑，而不像过去那样只能重放点击和输入。 不过，这样录出来的最终产物依然是桌面流。它运行在 Power Automate 的底层环境中，虽然在设计阶段有 AI 帮忙绘制流程图，但在运行阶段唱主角的依然是传统的 RPA 引擎。这种方式真正解决的，是如何加速从人工操作到流程图的转化过程，而不是将演示提炼成智能体在面对新环境时可以自主推理、灵活调用的可复用技能。 与之相比，Codex Record & Replay 将产出固化为一种全新的 技能。这是一种纯文本格式的工作流资产，里面清晰声明了所需的输入参数、具体步骤和校验规则，支持重新配置参数后再次执行。下一次，即使面对的是全新的文件名称、不同的任务工单或新的时间段，系统也能自主调配屏幕操作能力、浏览器动作和各种外部插件来完成任务，而不必强求网页前端标签和之前一模一样。在这里，技能成了核心的开发格式，插件则是具体的分发单位，这与传统 RPA 依靠组件和模板市场的商业逻辑完全不同。 UiPath 庞大的产品矩阵更能说明这场转型的难度。在这个生态里，Task Mining 负责录制步骤和发现流程，Autopilot 和 Studio 负责将文本指令转化为 flow，Maestro 用来统一调度 agents、robots、tools 和 people，还有 Healing Agent 来应对界面变化。它的功能覆盖面最完整，但捕获到的用户轨迹、开发工具里的工作流、编排器中的 agent 之间，依然缺少同一份语义资产。一次 GUI 操作演示如何变成通用的 agent skill，目前市场上还没有完整答案。 RPA 的 replay 对象从坐标和键盘逐步上移到 skill 中的目标、输入和验证。 ## 只录动作不够，还要捕捉动作背后的判断 Codex 选择在技能定义中加入结果核验机制，背后的原因并不神秘：录屏本身的技术含量不高，难的是把一次演示中的隐性判断提取出来。真正的智能体现在录制完成后的两个维度。第一，系统能否仅凭一次演示，剥离出输入变量、用户偏好、关键决策点和预期的成功状态。第二，在重放执行时，系统能否依靠观察、规划、执行、验证和恢复的闭环，来应对现实中出现的各种意外。 这个思路在 Anthropic 的 computer use 训练管线里看得更清楚。Anthropic 一项关于 “Generation of agentic trajectories” 的专利描述了如何把人类操作转成 agent 训练数据：系统在用户操作前后记录界面状态、动作和上下文，还允许用户附加思考标注，例如“我点这个按钮是因为它通常在右下角”或“这里选第三个选项，因为前两个是灰色的”。这样得到的数据不只是“看到界面后点击哪里”，而是“看到界面后为什么这样判断”。这和 Codex Record & Replay 面向的是不同阶段：Anthropic 这条线服务于训练 computer use 模型，Codex 这条线服务于复用具体 workflow。但两者共享同一个底层认识：只记录动作，只能学到模仿；记录动作背后的理由，才有机会形成可迁移的能力。 放到 workflow replay 里，动作背后的理由会落到更具体的东西上：哪些字段是每次运行都变化的输入，哪些分支代表业务规则，哪些停顿是用户在做风险判断，运行到什么状态才算完成。传统 RPA 的 selector 和坐标难以表达这些信息，而 skill 可以把它们写成输入参数、偏好、决策点和验证标准。这也是为什么 Record & Replay 真正有价值的部分不在“录”，而在“录完以后抽象成什么”。 我们可以看到，OpenAI 的 Computer Use 与 Anthropic 的 computer use tool 都为这种循环设定了明确的逻辑：智能体读取当前屏幕的状态，选择下一步操作，执行完毕后再获取新的屏幕状态，如此循环往复直至目标达成。这套模式的优势在于，它将最终任务目标与实时的页面观察牢牢绑定在一起，使系统能够自如地适应网页的微小变动。然而，其代价也十分明显：每走一步都需要调用大模型进行实时推理，这导致其确定性无法与预先设定好的固定脚本相比。 在开发者群体中，开源工具 Stagehand 已经提供了一个参考样本。它通过执行、提取、观察和智能体这四个基础操作，把自然语言指令与浏览器底层动作串联起来。在运行时，AI 会动态解析类似点击提交按钮这样的口头指示。在重放时，系统默认会优先采用 Playwright 框架进行精确匹配，只有在操作受阻时，才会激活 AI 自动修复机制。尽管这并非真正意义上的从演示直接生成技能，但它揭示了底层自动化的演进趋势：正在从遇到错误直接报错退出，转向优先确保高确定性执行、辅以 AI 兜底修复的混合模式。对工程师而言，这种做法显然比传统的 Selenium 或 Playwright 录制工具更契合业务语义。 单看执行成功率，其实是一个相对滞后的指标。真正决定自动化能否在业务中落地的，是当流程出现异常时，系统能否提供清晰且可用于修复的执行轨迹。微软在 Copilot Studio 中推出 computer-using agents 时，特别突出了会话回放、逐步动作日志、屏幕坐标、时间戳和上下文记录功能。这表明，可观测性已经从单纯的开发调试工具，上升为企业决定是否引入该系统的核心考量。企业客户不仅需要知道任务最终是否跑完，更需要掌握每一步的具体动作、确保没有发生越权行为，并能自证清白。 ## 市场还没把三件事合起来 客观来看，当前市场上的三条产品路线各有所长，但尚未融合出一款终极形态的产品。传统 RPA 厂家的优势在于成熟的录制机制、稳定的桌面运行环境以及严密的合规治理体系；新兴的智能体平台则在视觉感知和自然语言任务执行上独领风骚；而传统的集成式工作流平台则凭借海量的预置连接器、现成模板和完善的审计日志占据一席之地。 就打通录制与可复用技能而言，OpenAI Codex Record & Replay 迈出的步子最为直接，不过目前它仅限于苹果电脑系统，极度依赖电脑操作能力的成熟度，现阶段定位更偏向于办公室白领个人的技能捕获工具。如果微软能将现有的 AI 录制器与 Copilot Studio 的自动化智能体彻底整合，无疑最有可能从企业服务端率先实现这一理想状态。UiPath 虽然产品覆盖面最广，但不同模块间尚未建立起完全统一的语义资产。至于像 Zapier、Workato、Gumloop、Lindy 这样的新型自动化平台，虽然都在努力将工作流从简单的触发式执行升级为智能体自主运行，但它们的入口依然是提示词、画布或现成接口，不支持直接通过操作演示来创建任务。这就导致它们在处理标准应用接口（API）时游刃有余，而在面对需要跨多套桌面软件、富含隐性业务经验的实际图形界面操作时，依然缺乏有效的捕获手段。 行业缺的关键一环，可以这样概括：业务人员在真实的图形界面上操作演示一遍，系统自动分离出运行参数、准入条件、分支走向以及验证标准，并把它保存为一份可审阅、可版本控制、可跨团队共享的资产。之后 agent 可以在不同系统环境中按语义重放。在这条链路里，录制只是入口，价值在后面的抽象过程。录完以后，哪些字段是每次运行时都会变化的输入变量？哪些步骤差异代表用户偏好，而不是流程错误？运行到什么状态才算真正完成？这些问题，传统 RPA 的 selector 或操作轨迹回答不了，Codex 的 skill draft 开始回答了。Codex 已经跑通了最小闭环，但它还难以直接成为企业级治理资产；传统巨头握有成熟的合规体系与运行环境，却尚未完成从 desktop flow 到 agent skill 的资产转型。 ## 对 business skill 的真正启发 回到具体设计，一个业务 skill 不该只是一段 prompt，也不该只是一串录屏脚本。它应该像一份业务执行合同，写清楚启动触发条件、输入数据格式、执行前置要求、安全权限边界、核心操作步骤、结果核验机制、异常回滚预案以及人工介入通道。 以最常见的销售系统信息维护为例：销售代表在结束客户会议后，需要将谈话纪要、新联系人信息和后续跟进事项同步到 HubSpot 系统中。在全新模式下，开发这个技能无需录制诸如依次点击销售板块、选中对应账户、找到备注栏并粘贴等一连串琐碎动作。它需要界定的核心要素清晰具体：输入参数是谈话记录文本和账户 ID，前置条件是该账户已在系统中创立且用户已获得相应授权，核心动作是提炼关键业务实体、对比系统既有记录并形成更新草案，而核验标准则要求每次修改都有谈话记录中的原始文字作为支撑、期间严禁外发任何邮件，且改动的字段必须限定在许可名单内。至于图形界面的模拟重放，仅仅在目标系统不提供数据接口（API）时，才作为最后的兜底手段来使用。 这种契约化设计的模式，适用于一大批具有类似特质的业务流程。第一，财务发票的字段提取，信息整理完毕后仅录入草稿箱，默认绝不触发实际付款。第二，月初自动拉取 Stripe 交易记录与银行流水，仅用于生成初始对账单草稿。第三，客服工单分类与自动回复草稿生成，外发给客户前必须留给人工审核。第四，内容发布前进行死链检测与 SEO 元数据验证，而最终发布动作始终停在人工审批前。第五，员工入职时跨多套系统开立账号，针对敏感权限的操作必须进行二次确认。第六，合规审计证据的只读采集与归档，系统只做客观记录，不代替业务负责人下合规结论。这些流程的共同点在于，它们致力于减少员工在不同系统间搬运数据的摩擦与频繁的屏幕切换，绝不在付款、外发、电子签署或删除等不可逆的关键节点上自作主张，且每一步都配有可量化的验证标准。这正是语义化重放技术能够大施拳脚的黄金地带。 在实际落地时，一个行之有效的方法是根据动作风险进行分层管理，而不是生硬地按照业务部门或所用工具来划分。第一，基础的只读数据采集（如报表调取、合规取证）归入第一层。第二，仅写入草稿箱而不直接对外发布的操作（如生成发票草稿、CRM 字段填写建议）归入第二层。第三，针对许可名单内字段所做的、支持一键回滚的更新操作归入第三层。第四，涉及付款、邮件外发、合同签署等高风险的终结性动作归入第四层，且必须卡在审批关口之后。在同一个部门内部，既存在无伤大雅的客户资料补全，也包含影响重大的折扣承诺或合同签署，如果用一刀切的权限模型去管理，往往会导致效率与安全的双重失效。在这样一套架构中，图形界面重放纯粹退化为一种底层的执行手段，只有在数据接口、文件导出或数据库连接全都行不通时才会启动。一个技能的本质属性，取决于它自身声明的安全权限、成果验证机制以及异常回滚能力，不取决于它通过点击屏幕还是通过接口调用。 智能体并没有消灭传统 RPA，而是把后者的界面操作能力收进自己的工具箱。行业真正的变化，是自动化资产的定义变了：从一组点击操作，变成业务上怎样算完成。