用 Operator 类 Agent API 构建稳定网页自动化
OpenAI 的 Operator 在2025年1月发布，立刻改变了关于网页自动化的讨论。不再需要脆弱的CSS选择器和XPath查询，你可以指着一个网站对AI说"帮我买菜"。它确实能用——有时候。挑战一直在于让它可靠到能用在生产系统中。
我花了六周时间为一个客户的内部工具构建 Operator 风格的自动化管道。我们处理了大约400个不同工作流中的12,000次页面交互。最终确定的架构不是炒作文章描述的那种。不是"AI搞定一切"，而是"AI处理困难的部分，代码处理其余的"。
核心架构：三层模型
我见过的每个生产级 Operator 系统都使用三层架构。跳过任何一层都是团队出问题的根源。
第一层：浏览器控制。 这是基础——agent可以命令的无头或有头浏览器实例。Playwright 已经成为这里的主流选择，尽管 Puppeteer 仍在广泛使用。OpenAI 的 Operator 使用带有无障碍树钩子的自定义 Chromium 构建。对大多数团队来说，Playwright v1.48+ 配合其无障碍快照 API 是实际的起点。关键能力不只是点击和输入——而是以结构化格式将页面状态读回给 agent。没有可靠的状态读取，agent 就是在盲飞。
第二层：Agent 推理。 这是解释页面状态、决定下一步操作并生成命令的 LLM。截至2026年初，GPT-4o 和 Claude 3.5 Sonnet 是最常见的选择。Agent 接收页面的结构化表示——通常是无障碍树或简化后的 DOM——然后输出离散操作：点击、输入、滚动、导航或提取。关键的设计决策是你给模型多少页面上下文。太少，它会猜错。太多，你会烧完上下文限制和 token 预算。
第三层：编排与恢复。 这是大多数教程跳过的粘合层。它处理重试逻辑、检查点管理、错误分类和人机协同升级。在生产中，这一层做了80%的重活。Agent 本身反而是相对简单的部分。
页面状态提取的实际工作原理
整个系统的可靠性取决于一件事：agent 能否准确感知页面的当前状态？这个搞错了，其他都白搭。
标准方法是提取无障碍树。每个现代浏览器都暴露一个无障碍 API，将页面表示为语义节点树——按钮、文本字段、标题、链接——附带标签、角色和当前值。Playwright 的 page.accessibility.snapshot() 方法以 JSON 格式返回这棵树，你可以序列化后传给 LLM。
但原始无障碍树很嘈杂。一个典型的电商产品页面生成300-800个无障碍节点。把所有这些喂给 LLM 既浪费 token 又经常迷惑模型。我们实现了过滤管道：移除不可交互节点、折叠深层嵌套结构、为可交互元素分配稳定数字 ID、将相关元素分组。
过滤后，一个典型页面从500个节点缩减到60-80个可操作元素。token消耗减少约70%，agent 在我们内部基准测试套件上的准确率从约72%提升到91%。
错误恢复：最重要的部分
这是大多数自动化项目失败的地方。Agent 会遇到错误——元素未加载、验证码、会话超时、意外弹窗、Cookie 同意横幅、A/B 测试变体。问题不在于错误会不会发生，而在于系统如何恢复。
我们构建了三级恢复系统：
一级：自动重试（处理约60%的错误）。 简单策略，如等待2秒后重试、滚动使元素可见、或关闭 Cookie 横幅。这些是基于规则的，不是 AI 驱动的，执行时间不到3秒。
二级：Agent 引导恢复（处理约30%的错误）。 错误状态附加上下文反馈给 LLM。Agent 提出替代方案。这是 LLM 推理能力真正闪光的地方——它能判断出需要关闭模态遮罩，或者页面已滚动、元素已移位。
三级：人工介入（处理约10%的错误）。 自动和 Agent 引导恢复都失败时，系统保存检查点，生成附截图的详细故障报告，通知人工操作员。
在生产中，我们的管道对复杂多步骤工作流实现了89%的自主完成率。剩下11%需要人工干预，但详细的故障报告意味着人工通常在2分钟内解决每个问题。
API 设计
如果你要将此作为 API 暴露给其他团队或客户，接口设计极其重要。
我们的 API 使用基于任务的模型。客户端用自然语言提交任务描述，附带配置选项（超时、重试限制、检查点频率）。API 返回任务 ID 并通过 Server-Sent Events 流式传输状态更新。
Token 成本的现实
说说钱的事。运行 Operator 风格的自动化并不便宜。在一个典型的多步骤工作流（8-12个操作）中，每个任务大约消耗8,000-15,000个输入 token 和500-1,000个输出 token。按 GPT-4o 的定价（2026年3月），仅 LLM 成本大约每个任务 $0.08-0.15。
加上浏览器基础设施成本（我们使用池化的 Playwright 实例，每次页面加载约$0.003），每个自动化任务大约 $0.09-0.16。对于高量级用例——抓取数千页面、处理批量表单提交——这会迅速累积。
我们通过两个策略将成本降低了40%。第一，对一级错误恢复和简单导航步骤使用更便宜的模型（GPT-4o-mini），保留完整模型用于复杂推理。第二，缓存页面状态快照——如果 agent 返回到之前看过的页面，我们重用已提取的状态而不是重新解析。
生产部署清单
在将 Operator 风格的系统推向生产前，确保已处理好这些。我见过团队跳过步骤然后后悔的。
- 浏览器池管理：不要每个任务启动新浏览器实例，使用可复用实例池
- 反检测措施：许多网站主动屏蔽无头浏览器，需要隐身插件、用户代理轮换和真实鼠标移动模式
- 检查点持久化：使用 Redis 等持久存储保存任务检查点
- 每域名速率限制：尊重目标网站的基础设施
- 成本监控：从第一天起就建立每任务成本跟踪
Operator 风格的自动化很强大，但不是万能药。89%的自主完成率听起来不错，直到你意识到在12步工作流中，11%的失败率意味着大约73%的任务完全无需人工干预（0.89^12）。这仍然很好——比传统自动化在非结构化页面上的表现好得多——但不是"设好就忘"。为人工介入开销做预算，精心设计错误恢复，并监控一切。做得好的团队会大幅领先于那些把这当作纯 AI 魔法的团队。