浏览器 Agent 进入下半场：会点鼠标不稀奇，能被安全接管才是真本事

Agent 已经帮你找到了机票、填好了乘客信息，甚至选好了座位。

下一秒，它把鼠标移向“确认支付”——问题来了：你真的授权它花这笔钱了吗？

更麻烦的是，页面突然弹出会员优惠，验证码迟迟收不到，航班行李额度也与预期不符。此时 Agent 是应该继续猜，还是停下来问你？如果你接管浏览器完成验证，它能否从当前位置继续执行，还是必须把整项任务推倒重来？

这正是 AI Agent 从演示走向交付时，必须面对的现实。

过去，人们惊叹于模型会操作浏览器：打开网页、搜索商品、点击按钮、填写表单。现在，企业和用户真正关心的已经变成了四个更具体的问题：

• 任务最终有没有完成？
• Agent 可以操作到什么程度？
• 高风险动作由谁确认？
• 失败以后能不能恢复？

浏览器控制只是 Agent 的“手”，权限系统、审计机制和人工接管，才是它的刹车、仪表盘与方向盘。

炫技阶段结束，Agent 开始面对真实世界的“脏活”

浏览器演示往往非常丝滑。

输入一句“帮我寻找下周去上海的机票”，Agent 自动打开网站、设置日期、比较价格，然后停在订单页面。整个过程像是拥有了一位不会抱怨的数字助理。

但真实任务很少沿着预设路线前进。

网站可能出现 Cookie 弹窗、登录过期、验证码、广告遮挡、库存变化；表单可能要求身份证号、手机号、银行卡信息；同一个“提交”按钮，也可能意味着保存草稿、发送邮件或产生实际扣款。

真正困难的，不是找到按钮，而是回答三个问题：

1. 它如何看懂并操作网页？

2. 它可以操作到什么程度？

3. 出错时，谁来阻止或接管？

这三个问题共同构成了 Agent 商业化的分水岭。

一次成功录屏只能证明“它有可能做到”。企业需要的却是：任务反复执行时仍然稳定，页面发生变化后能够恢复，敏感操作不会误执行，整个过程还能被追踪和复盘。

浏览器正在成为 Agent 的通用执行层

企业软件可能有 API，内部系统可能提供标准接口，但普通用户每天接触的大量服务，仍然存在于网页中。

只要 Agent 能够稳定使用浏览器，它就能在不等待每个网站单独适配的情况下，处理搜索、填表、查询、上传、下载和信息汇总等任务。

目前，浏览器 Agent 主要采用三条技术路线。

真正成熟的系统通常不会只选一种。

它可能先通过 DOM 查找“出发城市”输入框，再用视觉模型判断弹窗是否遮挡页面；搜索结果通过浏览器操作获取，最终数据则通过接口读取和验证。

Agent 如果只说“我看见这里像一个按钮，所以点了”，风险很难控制。更理想的状态是，它能够记录：识别了什么元素、调用了什么工具、为什么执行该动作，以及执行后页面发生了什么变化。

从 Operator 到 Manus：差距不只在“会不会点”

几家代表性产品已经展示了不同的浏览器执行路线，但它们不能简单放在同一条模型榜单上比较。

这里有一个很容易被忽略的区别：Anthropic computer use 更像能力层，而 Operator、ChatGPT agent 和 Manus 更接近完整产品。

能力层负责让模型控制鼠标和键盘，产品层则必须继续处理账号、权限、确认、日志、异常和用户接管。前者解决“能不能做”，后者解决“出了问题怎么办”。

截至相关官方材料发布时，多数厂商并未完整披露以下商业交付指标：

• 长任务的端到端成功率
• 平均人工介入次数
• 页面发生变化后的恢复率
• 同一任务重复执行的稳定性
• 单任务完整调用成本
• 误发送、误提交或误购买率

因此，我们不能用一次顺利的官方演示，推导出产品在所有网站和账号环境下都能稳定工作。

判断一个 Agent 是否成熟，至少还要观察三件事：页面改版后能不能继续、任务中断后能不能恢复、每一步有没有可审计记录。

配图建议一：Agent 打开网页、执行搜索并填写表单的界面。

配图建议二：发送、提交或付款前的确认窗口。

配图建议三：用户接管时的暂停提示与控制权切换界面。

配图建议四：任务完成后的步骤记录、日志或结果总结。

发布时应优先使用官方演示截图或编辑部实测截图，并遮挡账号、Cookie、订单编号、地址及支付信息，避免使用无法验证来源的二手图片。

权限边界，决定 Agent 是助手还是安全风险

很多产品默认了一个危险前提：既然用户已经登录，Agent 就可以代表用户完成所有操作。

但账户访问权不等于任务授权，更不等于无限授权。

你可能允许 Agent 查看机票价格，却没有允许它购买；允许它填写报销单，却没有允许它提交审批；允许它起草邮件，也不代表它可以直接发送。

一个实用的权限体系，至少应将操作分成五级。

权限也不应是一张静态清单，而应该随任务风险动态升级。

以订机票为例，搜索航班属于只读操作，填写乘客信息涉及敏感数据，提交订单会对外产生动作，付款则进入财务权限。Agent 每前进一步，权限要求都应随之提高。

企业报销更复杂：读取发票、提取金额可以自动完成；填写报销草稿风险较低；提交审批会影响企业流程；修改收款账户或确认付款，则必须进入更严格的验证与审计环节。

成熟的 Agent 至少应具备以下机制：

• 最小权限：只开放完成当前任务所必需的能力
• 域名或工具白名单：限制 Agent 可访问的网站和工具
• 敏感字段隔离：密码、身份证号、银行卡信息不直接暴露给模型
• 凭证托管：使用临时令牌或安全凭证服务，而非明文保存密码
• 高风险操作确认：发送、支付、删除前必须再次确认
• 金额与次数上限：防止重复提交或超额执行
• 完整审计日志：记录动作、原因、结果和接管人
• 临时权限回收：任务结束后自动撤销访问权

从工程角度看，这套机制可以被理解为一个“权限闸门”：

def execute_action(action, context):
risk = evaluate_risk(action, context)

if risk == "forbidden":
return stop_task("该操作超出授权范围")

if risk == "high":
approved = request_human_approval(
action=action,
reason="涉及付款、发送或不可逆修改"
)
if not approved:
return pause_task("等待用户处理")

result = browser.execute(action)
audit_log.record(action, result)

if result.failed:
return request_human_takeover(result.error)

return result

这段伪代码揭示了一个关键事实：人工确认不是弹出一个对话框那么简单，而是执行架构的一部分。

权限判断必须发生在动作执行之前，结果必须在执行之后进入日志，异常则需要进入暂停或接管流程。

人工接管不是失败，而是产品能力

很多人仍然把“全自动”当作 Agent 的最高目标，仿佛只要用户中途动了一次鼠标，就说明产品不够先进。

真实情况恰恰相反。

当 Agent 遇到验证码、账号登录、付款确认、法律条款、信息歧义或连续操作失败时，主动停下来比继续猜更成熟。

不成熟的 Agent 会反复点击、擅自选择，甚至在错误页面继续填写信息；成熟的 Agent 应明确告诉用户：

• 已经完成了哪些步骤
• 当前卡在什么位置
• 为什么需要用户介入
• 下一步会产生什么后果
• 用户完成操作后，它能否继续执行

人工接管大致可以分成三类。

操作前审批

Agent 已经准备好动作，但尚未执行。

例如：“即将向客户发送这封邮件，是否确认？”这是最适合处理发送、发布、提交和付款等高影响操作的方式。

执行中接管

Agent 遇到验证码、登录或无法可靠识别的页面，将浏览器控制权交给用户。

用户完成验证后，Agent 应从当前位置重新读取页面状态并继续，而不是重新搜索、重新填表。

异常后恢复

Agent 已经遇到错误，例如弹窗遮挡、页面超时或表单校验失败。

此时系统除了允许人工处理，还应保留任务计划、已填写内容、页面状态和错误记录，避免整项任务从头开始。

真正优秀的 Human-in-the-loop，不是让人一直盯着 Agent，而是只在高风险、高不确定性的节点请人握一下方向盘。

一套理想的执行流程应当是：

用户下达任务 → Agent 制订计划 → 浏览器执行 → 权限检查 →

低风险操作自动继续 / 高风险操作请求确认 → 异常时人工接管 →

恢复执行 → 输出结果与审计记录

其中最关键的一步不是“接管”，而是接管之后能够继续。

如果用户每次处理验证码后，Agent 都要忘掉上下文、重新开始，那么所谓接管只是把失败包装得更好看，并没有真正降低交付成本。

衡量 Agent，不能再只看模型榜单

WebArena、WebVoyager、OSWorld 等基准能够帮助研究者观察模型的网页操作和计算机控制能力，但它们无法完全替代真实业务评估。

企业采购或开发 Agent 时，更应该建立一套面向交付的指标体系。

如果厂商没有披露这些指标，最可靠的方法不是凭观看演示下结论，而是自己设计一组小规模测试。

例如选择 5—10 个统一任务，每个任务重复执行多次，并固定：

• 账号登录状态
• 浏览器与系统版本
• 网络环境
• 网站和任务目标
• 是否允许人工介入
• 模型及工具配置

测试报告还应明确样本量。否则，一次成功和一次失败都没有足够的代表性。

某个 Agent 即使模型推理能力很强，如果每三步就要求用户确认，或者一次弹窗就必须重来，也很难产生稳定的商业价值。相反，一个能力没有那么“惊艳”，但能识别风险、保存进度、稳定恢复的产品，可能更适合进入真实业务。

Agent 产品最终卖的不是智能，而是可靠工作流

浏览器控制降低了 Agent 进入真实世界的门槛，也放大了错误执行的后果。

因此，未来的 Agent 产品不会只卖“模型有多聪明”，而是在售卖一套完整工作流：

这些工程细节看起来不如“自动订票”“自动购物”的录屏性感，却更可能成为真正的产品壁垒。

下次看到 Agent 演示时，别只看它能不能完成任务，还要看三个瞬间：

1. 它什么时候停？

2. 它为什么停？

3. 用户接过方向盘后，它能不能继续？

最值得关注的 Agent，不一定是最会演示的那一个，而可能是最懂边界、最容易接管、失败后仍能恢复的那一个。

如果你正在搭建自己的 Agent，可以先从“搜索网页—提取信息—生成结构化结果”这样的低风险任务开始，把工具调用、权限闸门和人工接管直接加入原型测试，而不是一开始就尝试自动付款或自动发布内容。

需要选择或测试底层模型 API 时，也可以前往 api.884819.xyz，对比不同模型在任务规划、结构化输出和工具调用场景中的实际表现。平台使用用户名和密码即可注册，不需要邮箱验证；内置 AI 对话功能，注册后可直接使用。国产模型如 Deepseek、千问等完全免费，没有月租和订阅，其他模型按量付费。

官方资料来源

• OpenAI：《Introducing Operator》，2025年1月23日
• OpenAI：《Introducing ChatGPT agent》，2025年7月17日
• Anthropic：《Developing a computer use model》，2024年10月22日
• Google：《Introducing Gemini 2.0: our new AI model for the agentic era》，2024年12月11日
• Manus 官方产品站及早期预览资料
• browser-use 官方 GitHub 仓库

浏览器 Agent 到底是怎么“看懂”网页的？DOM、可访问性树和视觉识别三条路线，哪一种更稳定、成本更低，又最容易被网页改版击穿？下一篇，我们将拆解浏览器控制的技术栈，并用一个最小代码示例搭建可人工接管的网页 Agent。

#AIAgent #浏览器Agent #人工智能 #AI安全 #工具调用 #人工接管 #8848AI #AI教程