- 为什么现在是浏览器·计算机使用代理的时刻
- 计算机使用代理究竟是什么
- 为什么现在实务价值变大了
- 推荐的架构模式
- 最适合的使用场景
- 防护机制与运营护栏
- 常见的失败模式
- 面向产品团队和开发团队的落地路线图
- 现实的落地检查清单
- 各团队的一句话建议
- 结语
- References
为什么现在是浏览器·计算机使用代理的时刻
2025 年 7 月 17 日，OpenAI 在 ChatGPT agent 的发布页面上说明，代理是连接调研与执行的系统，会在自己专属的虚拟计算机上同时使用网站交互、深度调研、终端、文本浏览器、可视化浏览器和直接 API 访问。同一页面也明确指出，用户在重要操作之前应获得确认权，并且能随时中断或直接接管。
这个时间点之所以重要，是因为代理不再只是在聊天窗口里生成答案的工具，而是转变为把实际工作流程一路执行到底的运营层。2026 年的产品团队和开发团队,现在更常问的问题不是"能生成什么",而是"能放心交给它做到哪一步"。
浏览器·计算机使用代理尤其在改变以下工作。
| 变化点 | 原有方式 | 代理方式 |
|---|---|---|
| 基于网页的运营工作 | 人工点击屏幕反复执行 | 代理读取浏览器状态并逐步执行 |
| 调研与执行的衔接 | 调研之后由人重新录入 | 基于调研结果直接衔接到下一步操作 |
| 运营工具整合 | 浏览器、文档、控制台彼此分离 | 在虚拟计算机内连成一条工作流 |
| 自动化范围 | 以拥有 API 的系统为主 | 只要有浏览器，相当一部分工作都可自动化 |
核心不在于"能不能用浏览器"。核心在于，在非结构化的屏幕环境中也能持续推进工作的运营自动化层已经变成了现实。
计算机使用代理究竟是什么
计算机使用代理不是只解析文本指令的模型，而是观察屏幕状态、组合工具、选择下一步行动的执行系统。通常同时具备以下要素。
| 构成要素 | 角色 | 实务要点 |
|---|---|---|
| 规划器（Planner） | 把目标拆解为子步骤 | 步骤数越短，失败后越容易恢复 |
| 浏览器或 VM 运行时 | 实际操作 UI 与系统 | 隔离环境应作为默认设置 |
| 观察器（Observer） | 读取 DOM、截图、日志、文件状态 | 只依赖一种信号会很脆弱 |
| 行动层 | 点击、输入、滚动、执行命令、调用 API | 需要审批策略和速率限制 |
| 记忆 | 保存当前作业状态与约束条件 | 应把短期执行记忆与长期策略记忆分开 |
| 护栏（Guardrails） | 阻断敏感操作、请求审批、留存审计日志 | 需要安全团队和运营团队共同设计 |
在实务中，如果把"代理"当作单一模型来看，设计往往会出问题。从运营的角度看，把它理解为规划、观察、执行、审批、记录捆绑在一起的软件系统更为准确。
为什么现在实务价值变大了
这个话题现在之所以受到关注，有三个原因。
- 就算是没有 API 的老旧业务系统，也已经可以通过浏览器实现自动化。
- 在人工重复运营成本高的团队，能立刻看到降本效果。
- 调研代理与执行代理正在合并，使得可以衡量的不再是"答案"，而是"完成度"。
尤其是运营、销售运营（Sales Ops）、QA、内部工具团队反应最快。原本就在浏览器标签页、电子表格、管理后台之间来回切换工作的组织，效果会更明显。
推荐的架构模式
在实际落地时，与其一上来就打造宏大的通用代理，不如从范围有限的模式开始。
模式 1：审批型单一任务代理
只接收一个工单或请求，只在有限的站点集合中作业。在重要操作之前始终请求用户审批。
| 适合的团队 | 优点 | 注意事项 |
|---|---|---|
| 初期引入团队 | 运营风险较低 | 一旦加入过多例外处理，很快就会变复杂 |
| 内部运营团队 | 容易衡量 ROI | 等待人工审批的时间可能会变长 |
模式 2：先调研、后执行的流水线
先收集并汇总信息，只把已核实的事实传递到执行阶段。这是对 OpenAI 所说的"research and action"组合最保守的一种实现方式。
Request intake
-> Research pass
-> Structured plan
-> Human approval gate
-> Browser execution
-> Verification
-> Audit log
这种模式有助于减少虚假推理，也能提升执行前那一刻审批的质量。
模式 3：基于策略的任务队列代理
只把已结构化的任务放入队列，由策略引擎为每个任务确定允许范围后再执行。
示例如下。
| 任务类型 | 允许范围 | 阻断条件 |
|---|---|---|
| 潜在客户信息收集 | 仅限只读访问指定域名 | 要求登录、进入支付页面 |
| 内部 QA 检查 | 仅允许预发布（staging）环境 | 访问生产环境管理页面 |
| 客服辅助处理 | 仅允许起草到草案为止 | 确认退款、删除账户、变更条款 |
运营规模越大，这种模式越是最容易管理的一种。
最适合的使用场景
并不是所有工作都适合交给代理。以下这类以屏幕为基础、但规则相当明确的工作最为适合。
| 使用场景 | 适配度 | 原因 |
|---|---|---|
| 竞品价格与功能调研 | 高 | 调研、整理、收集证据链接都很自然 |
| QA 回归检查 | 高 | 重复流程和成功标准容易定义 |
| 管理后台运营辅助 | 中等 | 值的核对很好，但写入操作需要强管控 |
| 销售运营数据录入 | 中等 | ROI 高，但录入错误的代价也大 |
| 客户退款、删除账户 | 低 | 误操作的代价太大 |
| 财务审批、权限授予 | 低 | 法律与安全风险高 |
一个好的起点是"人工在 5 分钟内就能反复处理，但手动做起来很麻烦的工作"。
防护机制与运营护栏
Anthropic 的 computer use 文档建议使用专用虚拟机或容器、施加最小权限、排除敏感数据，并以允许域名清单为核心限制互联网访问。这些原则几乎已经是与具体模型供应商无关的标准做法。
实务中可以立即套用的护栏如下。
| 护栏 | 推荐基准 | 原因 |
|---|---|---|
| 执行环境 | 专用 VM 或隔离容器 | 防止污染主机、防止凭证泄露 |
| 账户策略 | 业务专用的低权限账户 | 禁止使用个人账户 |
| 网络 | 仅允许访问已列入名单的域名 | 减少外泄和意外的探索行为 |
| 数据策略 | 默认阻断敏感信息 | 截图和页面文本中可能混入秘密信息 |
| 审批体系 | 涉及金钱、删除、权限变更前必须审批 | 保护难以撤销的操作 |
| 审计日志 | 保存屏幕依据、操作日志、结果 | 用于事后分析和合规应对 |
最小权限检查清单
- 使用专用浏览器配置文件。
- 保持会话过期时间较短。
- 不共享密码管理器、个人书签、个人 Cookie。
- 隔离文件下载目录。
- 限制可上传的文件类型。
- 组织内部域名也只在必要处才开放。
常见的失败模式
Anthropic 的文档提到了来自截图和网页的提示注入（prompt injection）风险，并建议采用分步指令与受限的行动范围。文档同时说明，延迟和计算机视觉的可靠性目前仍是现实中的制约。
这些提示在实际运营中几乎原样得到印证。
| 失败模式 | 现象 | 应对方法 |
|---|---|---|
| 基于屏幕的提示注入 | 把页面中的指令误当作作业指示 | 将系统策略固定为最高优先级，把外部文本视为不可信输入 |
| 选择器不稳定 | UI 变更后丢失点击目标 | 同时使用 DOM 信号和视觉信号，并设计重试路径 |
| 执行缓慢 | 页面加载与推理叠加导致明显延迟 | 长时间任务转入异步队列，向用户暴露中间状态 |
| 未经验证就宣告完成 | 实际未生效却报告为成功 | 强制在执行后加入重新查询验证的步骤 |
| 会话过期 | 登录失效后仍在错误的画面上继续 | 检测认证状态，失败时立即中止 |
| 过度自主 | 未经审批就推进到危险操作 | 应用基于风险评分的审批门槛 |
提示注入防御原则
- 网页中的文本是参考资料，不是指令文本。
- 作业目标、禁止行为、终止条件应单独保存在系统策略中。
- 高风险作业应把提示设计得每一步都需确认。
- 让代理在每一步都记录"为什么要执行这个行动"。
面向产品团队和开发团队的落地路线图
大多数失败并非源于模型质量，而是运营范围设定不当。按以下顺序引入，能在不勉强的情况下确认成效。
| 阶段 | 目标 | 产出物 |
|---|---|---|
| 第 1 阶段 | 选定 3 项重复性工作 | 候选工作清单、禁止工作清单 |
| 第 2 阶段 | 部署只读代理 | 调研结果与依据链接 |
| 第 3 阶段 | 加入审批型写入操作 | 审批日志、执行成功率仪表盘 |
| 第 4 阶段 | 接入策略引擎 | 按任务类型划分的权限策略 |
| 第 5 阶段 | 优化运营指标 | 成功率、重试率、平均处理时间 |
不建议从一开始就以完全自主代理为目标。从只读开始、逐步扩展到审批型写入操作是最现实的方式。
现实的落地检查清单
只有当以下所有项目都能回答"是"时，才建议扩大到生产环境。
| 问题 | 是 / 否 |
|---|---|
| 作业范围是否被定义为一两个明确目标 | |
| 允许访问的站点和禁止访问的站点是否已区分 | |
| 是否已准备好专用 VM 或容器 | |
| 是否可以在没有敏感数据的情况下完成作业 | |
| 删除、转账、购买、权限变更前是否有审批流程 | |
| 是否有对执行结果进行再验证的步骤 | |
| 失败时是否有安全移交给人工的路径 | |
| 是否有追踪成功率和错误类型的指标 | |
| 是否保存审计日志并有专人负责审阅 | |
| UI 变更时是否有更新提示词和策略的运营流程 |
各团队的一句话建议
| 团队 | 推荐起点 |
|---|---|
| 产品团队 | 与其替用户执行操作，不如先从内部运营自动化开始 |
| 开发团队 | 先搭建隔离运行时、审批门槛、验证步骤，再设计成可替换模型 |
| 安全团队 | 先定义允许域名、敏感数据策略、审计日志架构 |
| 运营团队 | 比起成功案例，更应尽快收集并分类失败案例 |
结语
浏览器·计算机使用代理不是 2026 年一个被夸大的演示话题，而是在有限范围内已经创造出较高实务价值的自动化方式。不过，成功与否与其说取决于模型有多"聪明"，不如说更大程度上取决于隔离环境、审批设计、验证回路、失败移交路径。
最好的团队不是最大胆的团队，而是从最窄的范围开始、学习速度最快的团队。
References
현재 단락 (1/120)
2025 年 7 月 17 日，OpenAI 在 ChatGPT agent 的发布页面上说明，代理是**连接调研与执行的系统**，会在自己专属的虚拟计算机上同时使用网站交互、深度调研、终端、文本浏览...