生产环境中的计算机操作与浏览器智能体

这些演示令人目不转睛：AI可以完成复杂的预订流程、在多个应用之间切换、填写政府表格，还能自主执行长达数小时的任务。2024至2025年间，Anthropic的Computer Use、OpenAI的Operator、Google的Project Mariner，以及一大批初创公司，纷纷展示了像人一样操作计算机的智能体。

到了2026年，这些工具已经真正投入使用，而且确实有效。一些公司已经成功将其部署到生产环境，但这些部署与演示并不相同：任务范围更窄、限制更多，外围还有严密的约束措施。本文关注的正是生产系统与演示之间的这些关键差异。

我们在一篇中级文章中介绍过基础知识。本文将进一步深入生产模式、反复出现的故障、成本效益，以及如何交付一套真正能大规模创造价值的计算机操作系统。

生产环境的真实情况

从实际生产部署中可以观察到以下规律：

模式1：以范围有限的任务为主。 生产部署在具体且定义明确的任务上更容易成功。它们不是“什么都做”，也不是“操作任何网站”，而是在指定网站上执行指定工作流。

模式2：严格限定范围。 任务边界非常明确，智能体只能在特定网站执行特定操作。一旦超出范围，系统就会停止，而不是临场发挥。

模式3：录制好的工作流优于自主探索。 许多生产部署采用预先录制的工作流——只定义一次步骤，执行时按情况微调并重放——而不是完全自主的智能体。这种方式更可靠，也更容易维护。

模式4：有重大影响的操作由人参与决策。 任何可能产生重大财务、法律或客户影响的操作，都要经过人工审核。

模式5：严密监控。 记录每项操作，检测异常，设置紧急停止开关，并由运营团队持续查看监控面板。

模式6：严格控制成本。 成本效益至关重要。许多设想中“AI包办一切”的部署，与人工或RPA替代方案相比并不划算。

模式7：专用优于通用。 生产部署往往针对具体任务使用专用模型或专门配置，而不是让通用计算机操作模型处理一切。

这些规律也符合生产级AI的一般特征：任务范围比营销宣传更窄，约束措施则更严格。

计算机操作智能体适合哪些生产任务

以下几类任务特别适合使用计算机操作智能体：

1. 从没有API的网站提取数据

许多企业工具、政府门户和小型B2B服务没有API，或者API功能缺失严重。计算机操作智能体可以通过界面交互来提取数据。

生产环境中的例子：

• 从50多个供应商门户下载发票。
• 从法院系统网站提取案件数据。
• 抓取竞争对手的定价页面。
• 汇总合规申报门户中的数据。

如果替代方案是由人反复进行繁琐的点击操作，计算机操作智能体显然更有优势。

2. 大规模填写表单

向许多不同网站提交同一类表单。各网站略有差异，最好能使用API，但现实中并不存在。

例如：

• 政府事务申请，每个机构都有自己的门户。
• 合规申报。
• 在供应商系统中为客户办理入驻。
• 为SaaS工具开设账户。

3. UI测试和质量保证

计算机操作智能体很适合充当QA测试人员，可以浏览应用、尝试用户流程并报告问题。

例如：

• Web应用的端到端测试。
• 视觉回归测试。
• 无障碍审查。
• 在多种设备上验证用户流程。

这类能力与RPA相近，但AI更灵活，能应对UI变化。

4. 跨应用工作流

有些任务横跨多个应用，却没有统一的集成入口。

例如：

• 从CRM读取数据，完成格式化后上传至分析工具。
• 读取客服工单，在项目管理工具中创建任务，并在CRM中更新状态。
• 汇总多个内部工具生成的报告。

如果无法或不愿直接集成这些应用，智能体就能充当灵活的桥梁。

5. 重复的多步骤流程

也就是由同一个人反复执行的任务。

例如：

• 通过包含30个步骤的流程为新客户办理入驻。
• 每周核对两个系统之间的数据。
• 从多个来源提取数据并生成定期报告。

如果一个流程定义明确、频繁重复，而且目前靠人手点击完成，就值得考虑自动化。

哪些任务仍然不适合

另一方面，计算机操作智能体尚不足以在生产环境中可靠处理以下任务：

1. 需要主观判断的任务

例如“帮我找一家好的供应商”。智能体可以浏览供应商网站，却无法判断哪一家真正符合你的具体需求。

2. 采用陌生UI模式的任务

面对从未见过的新网站，智能体不善于摸索反常的交互惯例。常见模式（表单、列表和导航菜单）比定制化设计更容易处理。

3. 反自动化措施严密的任务

许多网站会主动检测并拦截自动化操作。智能体有时可以设法规避，但这是一场没完没了的攻防博弈，往往得不偿失。

4. 单次操作风险很高的任务

例如付款、签署法律文件，或代表他人公开发帖。一旦操作错误，影响范围很大，因此必须由人审核。

5. 需要现实背景信息的任务

智能体只能看到屏幕上的内容，并不了解你与客户的关系、团队近期情况或政治环境。缺少背景信息的任务很容易失败。

6. 开放式探索

例如“找到最划算的方案”或“彻底调查这个人”，这类任务没有明确的完成标准。智能体不是陷入无休止的尝试，就是过早停止。

架构

生产级计算机操作系统包含以下层次：

┌─────────────────────────────────────┐
│ 编排                                │ 调度、重试、升级处理
├─────────────────────────────────────┤
│ 任务定义与范围                      │ 智能体能做什么、不能做什么
├─────────────────────────────────────┤
│ 智能体运行时（Computer Use SDK）    │ Anthropic / OpenAI / Browserbase
├─────────────────────────────────────┤
│ 浏览器／桌面环境                    │ 隔离、沙箱化
├─────────────────────────────────────┤
│ 身份验证与会话                      │ 凭据、Cookie、MFA处理
├─────────────────────────────────────┤
│ 结果处理                            │ 捕获、验证、存储
├─────────────────────────────────────┤
│ 监控与告警                          │ 实时可观测性
└─────────────────────────────────────┘

下面逐层说明。

任务定义

这是最重要的一步：严格限定智能体要做什么。

一份好的任务定义包括：

触发条件。 什么会启动任务？例如定时、事件或手动触发。

输入。 智能体可以获得哪些数据？例如具体记录或结构化表单数据。

范围。 可以访问哪些网站、执行哪些操作，以及采用哪些UI路径。

成功标准。 怎样才算完成？

停止条件。 哪些情况会让任务提前结束？

输出。 智能体返回哪些数据？

错误语义。 如何分类和报告故障？

定义不佳的任务是：“提交我们的每周合规报告。”

定义良好的任务则是：

任务：向门户X提交每周合规报告。

触发条件：Cron，每周一上午9点。

输入：
- `/reports/weekly.csv` 中的报告数据文件（CSV）。
- 环境变量中的提交人信息（姓名、ID）。
- 密钥管理器中的凭据。

范围：
- 网站：https://portal.example.gov/submit （及其子路径）。
- 允许的操作：导航、点击、输入、上传、提交、截图。
- 禁止的操作：访问外部网站、更改账户设置、离开提交流程。

成功标准：
- 收到包含提交ID的确认页面。
- 捕获提交ID。

停止条件：
- 收到确认：成功。
- 遇到CAPTCHA：转交人工处理。
- 登录失败：转交人工处理。
- 表单验证错误：报告错误并停止。
- 5分钟超时：报告超时并停止。

输出：
- 提交ID。
- 确认页面截图。
- 时间戳。

错误：
- 验证错误：记录日志、通知负责人，不重试。
- 身份验证错误：记录日志、通知运维，不重试。
- 网络错误：重试一次，然后升级处理。

生产任务需要具体到这种程度。“提交报告”只是演示级的描述。

强制执行范围

范围不应只停留在描述中，还必须在运行时强制执行。

URL白名单。 智能体只能访问匹配指定模式的URL。任何不在白名单内的导航都会被阻止。

操作过滤。 只允许执行特定类型的操作，不再笼统授予“操作计算机”的完整权限。

元素过滤。 有些页面元素是智能体绝不能操作的，例如设置、退出登录和危险按钮。可以在感知层将其过滤掉。

时间限制。 为任务设定不可突破的最长时间。N分钟内未完成就中止。

步骤限制。 限制任务的最大步骤数，原理与限制智能体循环次数相同。

各平台的实现方式不同——Anthropic Computer Use、OpenAI Operator和Browserbase都有各自的机制——但原则相同：在运行时强制限定范围，而不能只在提示词中描述。

身份验证

这是生产部署始终要面对的难题：智能体的会话必须通过身份验证。

预先登录的会话。 由人登录一次，捕获会话Cookie或令牌，智能体随后在该会话中操作，并在需要时刷新会话。

服务账户。 如果网站支持，可以为智能体创建专用账户，并设置有限权限和审计日志。

注入凭据。 智能体在运行时取得凭据，用于登录后立即丢弃。必须安全地存储和处理凭据。

MFA处理。 这确实很棘手，可选方案包括：

• 使用智能体能够计算的一次性密码（TOTP）密钥。
• 将MFA请求交由人工批准。
• 使用支持API令牌而非MFA的账户或网站。

OAuth。 对于现代网站，OAuth流程通常效果很好：人工只需批准一次，智能体即可通过该流程获得令牌。

基本原则是：智能体绝不能拥有与人类用户同等的账户访问权限。它应该使用权限受限、可审计且可随时撤销的凭据。

结果验证

智能体声称成功时，必须加以验证。

捕获证据。 保存截图、下载文件和输出数据。不要只相信智能体的报告，要核查证据。

核实成功条件。 表单是否真的提交了？是否出现确认信息？数据是否正确？

交叉核验。 如果可以通过其他渠道验证结果，例如API、确认邮件或数据库查询，就应该这样做。

异常检测。 本次运行是否异常地长、短或昂贵？应调查离群情况。

原则是：默认智能体可能出错，验证必须独立于它的自我报告。

错误处理

计算机操作任务有许多失败方式，需要分类处理：

网络错误。 网站宕机或请求超时。采用退避策略重试。

身份验证失败。 登录失败或会话过期。刷新凭据或升级处理。

UI变更。 网站已改版，找不到预期元素。停止任务并通知维护人员。

验证错误。 表单输入被拒绝。记录并通知，不要盲目重试。

反自动化检测。 出现CAPTCHA或被拦截。升级处理，必要时将该网站加入禁用列表。

智能体不知所措。 智能体卡住、循环或偏离既定流程。终止运行、记录日志并调查。

配额或速率限制。 网站限制了智能体的请求速率。退避后重试，或安排稍后执行。

每类错误都需要不同的处理语义。错误做法是“智能体失败了，再试一次”；正确做法是“智能体发生X类故障，执行X类处理流程”。

监控

记录每项操作、跟踪每次运行，并让每个异常都能及时暴露。

单次运行日志：

• 开始和结束时间戳。
• 执行的全部操作。
• 所有截图。
• 结果（成功、失败或升级处理）。
• 成本。
• 性能指标。

运行监控面板： 运营团队可以查看正在执行的任务、近期故障和队列深度。

汇总指标：

• 各任务类型的成功率。
• 延迟分布。
• 单次运行成本。
• 异常率。

告警：

• 成功率低于阈值。
• 单次运行成本激增。
• 某类故障明显增多。
• 网站UI可能发生变化，例如最近多次在同一步骤失败。

这套监控能在问题演变成事故之前将其发现。

成本效益

最直接的问题是：计算机操作智能体是否比替代方案便宜？

成本：

• 单次运行成本：通常为€0.50–€5，具体取决于任务复杂度；视觉模型调用价格较高。
• 基础设施：Browserbase等托管运行时，或自托管环境。
• 维护：网站一旦改版，任务就可能失效，因此需要持续投入一定维护工作。

替代方案：

• 人工成本为€30/小时：10分钟任务成本€5，1分钟任务成本€0.50。
• RPA工具：单次运行成本更低，但要求自动化流程结构明确。
• 直接集成API：单次调用便宜得多，但前提是API确实存在。
• 离岸外包：€5–€10/小时，计算方式与内部人工类似。

以下情况更适合采用计算机操作智能体：

• 网站没有API。
• 任务耗时足够长，自动化收益可以覆盖固定成本。
• 任务量足够大，累计人工时间可观。
• 网站相对稳定，维护负担较低。

以下情况采用计算机操作智能体并不划算：

• 已有API，直接使用即可。
• 任务很短，而且不常发生。
• 网站频繁变化。
• 任务的边界情况太多，维护成本很高。

一个实用的评估方法是：分别估算智能体和人工完成单项任务的成本，再乘以任务量进行比较。

行之有效的生产模式

成功部署中常见以下模式：

模式1：“录制操作流程”

对于高频且范围有限的任务，可以先用明确步骤录制一次工作流，再让智能体针对每组输入稍作调整并重放。

这种方法更接近传统RPA，但又具备AI应对小幅变化的灵活性，例如按钮位置略有移动或多出一个确认对话框。

它远比完全自主操作可靠。

模式2：拆分“提取”和“提交”

许多工作流分为两个阶段：

• 从某处提取数据。
• 向某处提交数据。

将两者拆成不同的智能体运行或操作流程会更清晰。每个阶段的成功标准更加明确，其中一个阶段失败也不会给另一个阶段叠加问题。

模式3：“人工检查点”

智能体自主完成准备工作，然后进入“可以执行”的待确认状态。人工审核并批准后，再由智能体执行操作。

这种模式适用于付款、公开发帖和敏感材料提交。智能体节省准备时间，人工则负责发现错误。

模式4：“专用智能体”

不要使用一个通用智能体处理一切，而应为具体任务配备专用智能体。每个智能体都针对特定工作流进行调优、测试和维护。

“操作任意网站”的通用智能体很难维护，而“提交每周合规报告”的专用智能体则简单直接。

模式5：“回退到RPA”

如果任务并不需要AI的灵活性——网站稳定、工作流固定——就回退到传统RPA，例如Playwright脚本或Selenium。在这些场景中，传统方案成本更低、速度更快，也更可靠。

只有在AI的灵活性确实能创造价值时，才使用计算机操作智能体。

模式6：“批量运行”

对于大批量任务，不要按需逐个启动智能体。应先汇总任务，再按计划并行运行。

例如，不采用“用户提交请求后智能体立即运行”，而是让请求进入队列，每15分钟批量运行一次。这样可以平滑负载并简化架构。

可能出现的问题

以下是常见故障模式：

网站发生变化。 智能体已经稳定运行6个月，网站一改版就全部失效。如果没有监控，可能要等到愤怒的用户投诉才会发现。

反自动化检测升级。 网站加入了自动化检测，智能体运行的失败率越来越高，最终账户被封禁。

卡死任务导致成本失控。 智能体在令人困惑的页面上反复循环，每一轮都会调用视觉模型，一小时便产生€100的费用。

执行了错误操作。 智能体点错按钮，例如本应确认订单却将其取消，或把消息发给了错误的人。

卡在MFA。 智能体无法通过MFA，生产任务不断积压，队列越来越长。

账户被封禁。 网站检测到异常活动并暂停账户，在恢复之前，所有类似任务都会中断。

凭据泄露。 智能体无意中把凭据暴露在日志或截图中，造成安全事故。

隐私问题。 智能体保存的日志截图无意中包含了PII。

上述大多数问题都可以通过前文的模式预防，但每一种都曾在真实部署中发生过。设计系统时必须设置相应防线。

成本效益：完整测算模型

这是一个模拟场景，并非客户案例。我们特意明确这一点：一套可以代入你自己的数字重新计算的ROI模型，比无法验证的“匿名案例”更有价值。

任务： 向12个不同的机构门户定期提交合规报告。在爱沙尼亚，可以参考那些仍要求逐份表单录入的门户，例如e-MTA申报、爱沙尼亚统计局问卷和欧盟层面的材料提交。

人工基准： 12个门户 × 90分钟 = 18小时/周。按包含各项成本在内的€30/小时计算，每周为€540。

自动化方案：

• 智能体运行：12 × 约€2（视觉模型加浏览器基础设施）= €24/周。
• 维护：每月约2个工程师工时，按€100/小时计算，约合€50/周。门户会发生变化；如果不为维护留出预算，自动化系统就会悄无声息地失效。
• 故障处理：自主成功率为92%时，大约每周有一次运行需要转交人工。预留30分钟审核时间，即€15/周。
• 合计：约€90/周，每周节省约€450，每年约节省€23,000。

接下来有两个数字决定这套方案是否真正可行。

第一是成功率。成功率低于约85%时，人工看护会吞噬节省的成本。应先让系统以影子模式运行两周并测量成功率，再决定是否信任它；不要采用供应商演示文稿中的数字。

第二是维护成本随时间的增长。门户每次改版都可能导致系统失效，而由12个门户组成的系统每年会遇到数次此类变化。如果你无法明确指定由谁在一个工作日内负责修复，那么人工流程反而更便宜。

部署清单

如果要把计算机操作系统部署到生产环境，请确认：

• 任务范围有限且定义明确。
• 在运行时强制执行范围，而不是只做文字描述。
• 已设置步骤、时间和成本上限。
• 身份验证方案能够安全处理凭据。
• 已考虑反自动化问题，使用合法账户并遵守速率限制。
• 已对错误分类并制定处理方式。
• 结果验证独立于智能体的自我报告。
• 已设置监控和告警。
• 已设置紧急停止开关。
• 有重大影响的操作由人参与决策。
• 已保留审计日志。
• 已妥善处理隐私和PII。
• 与替代方案相比，成本效益合理。
• 已制定网站改版后的维护计划。

每一项都并非轻而易举，跳过任何一项都会带来风险。

让技术与任务匹配

生产环境中的计算机操作与浏览器智能体，与广为传播的演示大不相同：任务范围有限、约束措施严格、监控严密、设有人工检查点，并且成本测算务实。

如果任务合适，它们确实很有用，例如从没有API的网站提取数据、大规模填写表单、执行跨应用工作流，以及处理重复的UI操作。真正的生产部署确实能节省时间和金钱。

如果任务不合适——需要开放式判断、面对陌生UI，或单次操作风险很高——它们还没有准备好。不要勉强使用。

关键在于让技术与任务相匹配。使用得当，计算机操作智能体是生产级AI技术栈中的实用工具；使用不当，它只会以高昂成本引入新的故障模式。

选择范围有限的任务，建立严格约束，持续监控，并坚持维护。只有这样，计算机操作智能体才能在生产系统中真正发挥价值。