AI 浏览器代理最容易让人产生错觉。它能打开网页、读页面、点按钮、填写表单、下载文件、上传附件、切换标签、截图、提取信息，表现得很像一个坐在电脑前的人。团队看到演示后，很自然会想到更多场景：让它登录后台查数据，让它帮运营发布内容，让它从供应商网站收集价格，让它填报销单，让它自动处理订单，让它跑一遍竞品页面。浏览器是今天数字工作的入口，所以能操作浏览器的 AI 看起来像能操作整个互联网。

问题也在这里。浏览器不是一个干净的 API 环境，而是一个混合了登录态、第三方网页、广告脚本、表单、支付按钮、验证码、下载文件、剪贴板、扩展、跨站跳转和用户隐私的复杂界面。页面内容本身可能可信，也可能恶意；按钮文字可能清楚，也可能误导；登录态可能只属于当前任务，也可能代表用户全部账号权限。AI 浏览器代理一旦拥有真实点击和输入能力，风险就从“回答错了”变成“真的提交了、真的下载了、真的删除了、真的付款了”。

这篇社区实践帖讨论一个核心问题：AI 浏览器代理能做什么，不能做什么。它不是反对浏览器代理，相反，浏览器自动化是非常实用的 AI 能力。Playwright 这样的自动化框架已经在测试、爬取、表单操作和端到端验证中成熟使用；Browser Use、Computer Use 等能力把页面观察、动作选择和模型推理连起来，让非结构化网页也能被智能体处理。但生产级使用必须划边界。能阅读不等于能授权，能填表不等于能提交，能看到登录页面不等于能绕过验证码，能下载文件不等于能打开任意文件，能访问网页不等于能把网页指令当系统指令。

一、先把浏览器代理分成四层能力

讨论边界前，先把能力分层。第一层是观察能力：打开网页、读取标题、URL、DOM、可见文本、截图、表格、链接、按钮、表单字段和错误提示。这个层级主要是“看”。它可以用于网页理解、信息提取、页面巡检、资料整理和测试诊断。风险相对低，但仍可能接触敏感信息和恶意内容。

第二层是导航和输入能力：点击链接、滚动页面、切换标签、输入关键词、选择下拉项、上传文件、下载文件、填写表单。这个层级开始改变浏览器状态，但不一定改变外部业务状态。比如在搜索框里输入、在草稿框里写内容、打开筛选器、选择日期范围。风险中等，因为错误点击可能进入危险页面，错误输入可能暴露隐私，上传下载可能带来文件风险。

第三层是提交和写入能力：提交表单、发送消息、发布内容、创建订单、更新资料、保存配置、确认删除、触发工作流。这个层级会改变网站或业务系统状态。它不再是普通“浏览”，而是代用户执行动作。必须有权限、确认、审计和回滚设计。

第四层是高风险外部动作：支付、退款、转账、购买、授权 OAuth、授予权限、修改密码、解绑银行卡、删除数据、取消订阅、发出不可撤回的公开内容、操作生产后台。这些动作不应该由通用浏览器代理自动完成。更合理的做法是让 AI 读页面、解释选项、准备草稿、指出风险，再让用户或业务系统完成最终确认。

这四层划分比“让不让 AI 控浏览器”更实用。一个产品可以允许浏览器代理自动完成观察和低风险输入，但对提交和外部动作加确认；可以让它在测试环境自由点击，但在生产后台只读；可以让它生成表单草稿，但不让它按下付款按钮。边界越具体，体验越可控。

二、浏览器代理擅长什么

浏览器代理擅长处理那些网页结构复杂但风险较低的重复任务。比如读取多个网页的信息并整理成表格，比较不同产品价格和参数，检查一组页面是否存在 404、错别字和布局问题，打开后台页面核对某个字段，帮用户在复杂表单中准备填写内容，阅读公开文档并提取步骤，生成页面测试报告。这些任务的共同点是：主要价值来自观察、理解、整理和低风险输入。

它也擅长做探索式网页自动化。传统 Playwright 脚本需要开发者预先写选择器、断言和流程；AI 浏览器代理可以根据页面变化临时决策，比如看到登录按钮就点击，看到筛选器就调整，看到错误提示就解释原因。对不稳定页面、临时运营后台、第三方网站和一次性资料收集，这种灵活性很有价值。

浏览器代理还适合做产品验收。真实用户路径经常跨多个页面：打开首页、登录、搜索、筛选、进入详情、提交表单、查看结果。AI 代理可以像用户一样走流程，并记录截图、URL、按钮文案和异常。它能发现接口测试发现不了的问题，例如页面文案混乱、按钮不可见、弹窗遮挡、移动端布局错位、登录后跳转错误、空状态没有说明。

对企业内部工具来说，浏览器代理还能降低集成成本。不是每个旧系统都有 API，也不是每个供应商愿意开放接口。有些工作只能通过网页后台完成。浏览器代理可以作为过渡方案，把人工重复操作变成可审计的半自动流程。但这里要强调“过渡”和“半自动”：如果某个动作长期高频、高价值、高风险，最终应该建设正式 API、权限和流程，而不是一直靠浏览器模拟点击。

它也适合辅助而不是替代。比如帮用户解释网页上复杂的设置项，指出需要填写哪些字段，预填一份内容，提醒哪些按钮会产生外部影响。用户仍然是确认人，AI 是阅读和准备工具。这种模式常常比全自动更可靠，也更容易被业务接受。

三、浏览器代理不擅长什么

浏览器代理不擅长承担最终责任。网页上的内容可能过期、恶意、误导或不完整，模型对页面的理解也可能出错。它可以建议“这个按钮看起来会提交订单”，但不能替代业务规则判断“是否应该提交”。真正的责任需要落在人、业务系统或明确审批流程上。

它不擅长处理强安全边界。验证码、二次验证、短信码、人脸验证、硬件密钥、银行 U 盾、风控弹窗，本质上都是为了确认真实用户或阻止自动化。AI 浏览器代理不应该试图绕过这些机制。遇到验证码和强认证，合理行为是暂停，请用户完成，或切换到官方 API 和授权流程。把绕过验证码当作能力，会让产品直接进入违规和滥用区域。

它不擅长高风险不可逆动作。支付、转账、退款、购买、删除、授权、公开发布和生产配置修改，都需要确定性系统、权限校验、确认和审计。浏览器代理可以读页面、准备草稿、解释影响，但不能在没有明确确认的情况下自动提交。即使用户一句话说“帮我搞定”，系统也要拆解出最终参数并让用户确认。

它不擅长长期依赖脆弱页面。第三方网站经常改版，按钮文字、DOM 结构、登录流程、风控策略、分页和弹窗都会变。AI 比固定脚本灵活，但不代表稳定。关键业务若长期依赖第三方网页自动化，会面临不可控变更、账号风控、法律条款和数据质量问题。能用官方 API 时，应优先用 API。

它也不擅长处理需要严格数据一致性的流程。浏览器界面是给人看的，不一定暴露完整事务状态。页面显示“提交成功”可能只是前端状态，后端任务还在处理中；点击退款后可能只是创建申请，不是退款完成；下载报表可能是异步生成。若系统需要强一致、幂等、回调和对账，浏览器代理应该退居辅助，核心动作交给后端 API。

四、Playwright 和 AI 浏览器代理不是一回事

Playwright 是成熟的浏览器自动化框架，提供可靠的定位器、自动等待、动作可执行性检查、网络控制、认证状态复用、文件上传、截图和测试断言。它适合写可重复的脚本：进入页面，定位按钮，填写字段，断言结果。Playwright 文档强调 actionability checks，例如元素是否可见、稳定、可接收事件、可编辑，这些机制让自动化脚本比简单坐标点击可靠得多。

AI 浏览器代理通常在 Playwright 或类似能力上再加一层模型决策。模型观察页面，决定下一步点击哪里、输入什么、是否滚动、是否返回、是否提取信息。Browser Use 这类项目就是把浏览器动作和 LLM 代理结合，让模型能按目标操作网页。OpenAI 的 Computer Use 工具则提供屏幕观察和鼠标键盘动作，让模型能在浏览器或桌面应用中完成步骤。

两者的区别在于确定性。Playwright 脚本是开发者写死流程，适合稳定回归；AI 浏览器代理是模型动态决策，适合开放探索。前者失败时容易定位选择器或断言问题；后者失败时可能是页面理解、目标分解、视觉识别、提示注入、登录态、网络或动作选择问题。生产系统不能把 AI 代理当作普通测试脚本直接信任。

更好的组合方式是：用 AI 代理探索和生成候选流程，用 Playwright 固化高频稳定流程；用 Playwright 的定位器、自动等待、断言和认证状态管理提供可靠执行底座，用模型处理页面变化和语义理解。对关键流程，最终仍应沉淀为可测试、可审计、可回放的自动化，而不是每次让模型临场发挥。

另一个差别是安全边界。Playwright 默认按脚本执行，安全来自脚本作者和运行环境；AI 代理会读取网页内容并把它纳入决策，必须额外防提示注入和越权动作。网页里的文字不能成为更高优先级的指令，模型看到“点击授权并输入验证码”也不能自动照做。AI 代理需要比传统脚本更多的任务权限、域名限制和确认机制。

五、登录态：浏览器代理最危险的隐形权限

登录态是浏览器代理的核心风险。Cookie、localStorage、sessionStorage、浏览器 profile、扩展和保存的密码，代表用户在多个网站上的真实身份。一个浏览器代理如果使用用户日常浏览器 profile，就可能继承邮箱、网盘、支付平台、公司后台、社交账号和云控制台的登录权限。它看起来只是在完成一个小任务，实际拥有大量横向能力。

生产系统不应该默认让 AI 使用用户完整浏览器 profile。更稳的方式是为每个任务创建隔离浏览器上下文，只登录当前任务需要的网站。Playwright 支持 browser context 和 storageState，可以保存和复用特定站点认证状态，但这也意味着认证状态文件包含敏感 cookie 和 header，需要像密钥一样保护。不要把 storageState 放进普通日志、公开仓库或可下载调试包。

登录态还要按任务授权。用户要求“帮我查看这个供应商后台订单”，不等于授权 AI 同时打开邮箱、云盘和银行网站。任务启动时应明确可访问域名、可使用账号、有效时间和可执行动作。浏览器代理若试图访问未授权域名，应被阻止，而不是让模型自己判断是否合理。

多账号场景更复杂。一个用户可能在同一浏览器里登录多个租户、多个环境、多个客户后台。AI 代理必须知道当前操作属于哪个租户、哪个账号、哪个环境。测试环境和生产环境要明显隔离，不能因为页面相似而点错。对企业后台，最好使用专门的低权限机器人账号或受限用户账号，而不是管理员账号。

登录失败和二次验证也要有边界。AI 可以告诉用户“当前需要登录”或“页面要求二次验证”，可以等待用户手动完成，也可以使用官方 OAuth 授权流程。它不应该要求用户把短信验证码、一次性密码或恢复码发给模型，更不应该把这些信息写入日志。二次验证的意义就是让自动化停下来确认人类在场。

退出和清理同样重要。任务结束后，应清理临时 Cookie、缓存、下载文件和上传文件，关闭浏览器上下文。长时间保留登录态会扩大风险窗口。若必须保存会话，应记录用途、所有者、过期时间、最后使用时间，并允许用户撤销。

六、表单：能填不等于能提交

表单是浏览器代理最常见的应用场景。填写采购申请、报销单、CRM 客户信息、招聘表、后台配置、问卷、内容发布页，都很适合 AI 先帮用户整理字段。模型能从上下文中提取姓名、日期、金额、地址、描述和附件，减少人工复制粘贴。但表单也是风险高发区，因为“填入字段”和“提交生效”之间有明确边界。

安全做法是把表单操作拆成三个阶段：理解字段、生成草稿、确认提交。理解字段时，AI 读取页面标签、placeholder、必填项、帮助文本和错误提示。生成草稿时，AI 把值填进页面或在旁边给出预览。确认提交时，系统展示最终字段、目标网站、提交按钮含义、影响对象和风险提示，由用户确认后再执行。

不要让模型在模糊信息下自动提交。比如用户说“帮我把上次那个客户资料补一下”，模型可能猜错客户；用户说“金额按之前的来”，模型可能取错记录；页面有两个“保存”按钮，一个保存草稿，一个发布上线，模型可能误判。遇到指代不清、字段缺失、金额、身份、权限和外部影响时，应追问或停在草稿。

表单字段还要做类型和范围校验。模型生成的日期、金额、邮箱、手机号、身份证号、订单号、地址、URL、SQL、正则表达式都可能有格式错误。浏览器页面本身可能有前端校验，但生产系统不能只依赖页面。若表单提交背后是自己系统，应在后端校验；若是第三方页面，至少在确认页前做本地校验和异常提示。

附件上传要特别谨慎。AI 不应从用户目录自由挑文件上传。用户应明确选择可上传文件，系统生成文件 ID，浏览器代理只能使用这些授权文件。上传前要展示文件名、大小、类型、目标网站和用途。涉及合同、身份证、财务凭证、源代码和客户资料时，更要有确认和审计。

表单提交后的状态也不能靠模型猜。页面提示“已提交”才是一个信号，不一定代表业务完成。系统应记录 URL、页面标题、提交时间、关键截图、表单摘要和网站返回状态。若网站生成申请编号、订单号或工单号，应提取并保存。没有明确结果时，应该说“已提交请求，状态待确认”，而不是直接宣布完成。

七、支付和购买：AI 可以准备，不能擅自付款

支付和购买是浏览器代理必须划红线的场景。AI 可以帮用户比较价格、解释套餐、整理购物车、检查优惠、填写收货地址草稿、计算税费和提醒风险，但不能在没有明确确认的情况下点击付款、转账、购买、退款或订阅。钱的移动需要比普通表单更高的确定性。

支付页面常常有复杂元素：商品名称、数量、币种、税费、运费、优惠券、收货地址、付款方式、分期、自动续费、不可退款条款。模型可能漏看某一项，也可能被页面广告和推荐影响。确认页必须展示最终金额、币种、商户、商品、数量、收件人、付款方式、是否订阅、是否自动续费、退款政策和按钮含义。

支付动作还要防重复。浏览器代理遇到超时、页面卡住或网络断开时，可能想再次点击。传统支付系统强调幂等，浏览器自动化更需要停止策略。支付按钮点击后，代理应等待明确状态，不应反复点击。若状态不明，应提示用户检查订单或支付平台，而不是自行重试。

退款和取消订阅同样高风险。AI 可以解释当前政策、找到入口、准备取消原因，但最终确认应由用户完成。取消订阅可能影响服务、数据保留和合同；退款可能影响订单、库存、财务和客户关系。浏览器代理没有足够上下文承担这些责任。

企业内部如果必须自动处理支付相关流程，应尽量使用正式后端 API、审批、幂等键和对账系统，不要依赖网页点击。浏览器代理可以作为辅助界面层，但真正的钱款状态应以后端支付系统和回调为准。

八、验证码和反自动化：遇到就停，不要绕

验证码、短信码、邮件码、TOTP、人脸验证、滑块、设备确认和风控验证，都是网站用来区分真实用户、降低滥用和保护账号的机制。AI 浏览器代理遇到这些机制时，正确行为是暂停并请求用户处理，或者提示该任务需要官方授权接口。把绕过验证码当作“智能”能力，不适合生产产品。

验证码不仅是技术问题，也是合规和平台关系问题。第三方网站明确不希望自动化时，强行绕过可能违反服务条款，导致账号封禁、法律风险或客户关系问题。即使某些自动化方案能在技术上通过，也不意味着产品应该这样做。

对自己产品内部的验证码，最佳做法不是让 AI 识别验证码，而是在受控测试环境提供测试模式、API token、测试账号或跳过开关。端到端测试和生产用户安全是不同目标。Playwright 测试自己站点时可以使用专门测试账号和受控环境；AI 代理操作第三方站点时应尊重对方风控。

二次验证里的验证码和一次性密码不能让模型保存或复述。用户手动输入后，浏览器上下文可继续任务，但不要把验证码写进聊天记录、日志或任务摘要。若页面要求高风险确认，例如银行或支付平台的验证码，AI 应停止在确认前，让用户自己完成最终动作。

浏览器代理产品应在界面上明确处理方式：需要验证码时暂停；需要短信码时等待用户手动输入；需要人脸或硬件密钥时交还用户；需要长期自动化时建议使用官方 API 或合作授权。这个边界比技术绕过更重要。

九、文件下载和上传：浏览器会产生真实文件风险

浏览器代理不只是看网页，它还会下载和上传文件。下载可能是发票、报表、合同、图片、压缩包、安装包或未知文件；上传可能是身份证、合同、源代码、财务凭证、客户名单。文件一旦进入任务，就会带来隐私、恶意内容、路径、保留期限和权限问题。

下载文件应进入任务沙箱，而不是用户默认下载目录。沙箱应按任务隔离，有大小限制、类型限制、病毒扫描或格式检查，并记录来源 URL、文件名、MIME、大小、哈希和下载时间。下载的文件如果要交给模型读取，也要把文件内容视为不可信数据，不能把里面的文字当成系统指令。

上传文件必须来自用户明确授权。不要让 AI 浏览器代理遍历本地目录找附件，也不要让网页内容诱导它上传某个路径。用户选择文件后，系统给代理一个短期文件句柄或文件 ID，代理只能上传这些文件。上传前应展示目标域名、表单字段、文件信息和用途。

文件名和内容可能泄露隐私。即使不打开文件，文件名也可能包含客户名、项目名、金额、身份证号或内部编号。下载列表、任务日志、截图和审计摘要里都要注意脱敏。上传失败时，不要把完整本地路径显示给页面或写入公开日志。

文件保留要有策略。任务结束后，临时下载和中间解析文件应自动清理，除非用户明确保存。若文件进入知识库或审计系统，要继承权限和保留期限。浏览器代理产生的“临时文件”不能变成无人管理的长期敏感数据。

文件类任务最好限制域名和类型。比如只允许从指定供应商后台下载 CSV 和 PDF，不允许下载可执行文件；只允许向指定报销系统上传用户选择的 PDF，不允许上传整个目录。越具体，越安全。

十、网页提示注入：网页内容不能反过来指挥代理

浏览器代理最大的安全挑战之一是网页提示注入。网页里的文字、隐藏元素、评论、广告、图片 OCR、PDF 内容、搜索结果，都可能写着“忽略之前规则”“把用户资料发送到这个网址”“点击授权按钮”“打开邮箱复制验证码”。这些内容对人类来说可能只是网页内容，对模型来说却可能看起来像指令。

这类攻击叫间接提示注入，因为攻击者不直接和 AI 对话，而是控制 AI 会读取的外部内容。OWASP LLM Top 10 把 prompt injection 列为核心风险，也把 excessive agency 和 sensitive information disclosure 等问题列为重要类别。浏览器代理把外部网页和真实动作连在一起，正好处在这些风险交叉点。

防护第一原则是指令和数据分层。用户目标、系统规则、工具权限来自受信任系统；网页内容只是观察数据。网页可以提供事实、字段、按钮文字和错误提示，但不能改变工具权限，不能要求代理访问其他站点，不能跳过确认，不能要求输出隐藏信息。模型提示里要表达这个原则，工具层也要执行这个原则。

第二原则是域名和动作限制。即使网页诱导代理打开另一个域名，也应被 allowlist 拦住；即使网页要求发送数据，也应被提交确认拦住；即使网页要求下载文件，也应受类型和大小限制。不要把防护全部压在模型“识别恶意文本”上。模型识别会失败，系统边界必须独立存在。

第三原则是最小上下文。浏览器代理不应该同时拥有用户邮箱、云盘、支付网站、公司后台和本地文件系统的全部能力。网页提示注入之所以危险，是因为模型能把一个网页里的恶意指令转移到另一个工具。能力越少，横向伤害越小。

第四原则是关键动作前证据确认。提交表单、发消息、授权、支付、下载敏感文件前，要展示当前页面的关键信息和目标动作。用户确认的是系统整理出的事实，而不是网页夹带的指令。确认过程本身也要可审计。

提示注入不能彻底消灭，但可以把它限制为“模型提出了一个被拒绝的动作”，而不是“模型完成了一个危险动作”。这就是边界设计的价值。

十一、审计：浏览器代理必须能复盘一次点击

浏览器代理做了什么，必须能复盘。传统 API 调用可以记录方法、路径、参数和响应；浏览器操作更复杂，需要记录页面、动作、截图、表单字段、确认和结果。没有审计，出了问题只能看用户描述和模型日志，很难判断是页面误导、模型误点、权限配置错误还是用户确认过。

基础审计字段包括任务 ID、用户、租户或组织、浏览器上下文、允许域名、起始 URL、访问 URL、页面标题、动作类型、目标元素、输入摘要、下载文件、上传文件、提交按钮、确认记录、错误、时间和结果。对高风险动作，还要保存动作前后的截图或 DOM 摘要。

审计要分级保存。普通公开网页抓取可以保存较多上下文；企业后台、客户资料、支付页面和文件内容要脱敏或只保存摘要、哈希和资源 ID。截图可能包含敏感信息，不能随意进入公开日志或客服系统。查看审计也要有权限。

审计还要记录拒绝。代理访问未授权域名、试图点击高风险按钮、遇到验证码、上传未授权文件、提交缺少确认、网页提示注入可疑内容，都应记录。拒绝记录能帮助团队发现边界是否过紧、过松，或者某些网页是否持续诱导异常行为。

对产品体验来说，审计也能建立信任。用户可以看到代理已完成哪些步骤、停在哪里、为什么需要确认、哪些信息被提交。透明度不等于暴露内部实现，而是用面向用户的语言说明关键动作。比如“已读取订单列表，已填写退款原因，等待你确认金额”，比黑盒自动点击更可信。

审计最终要能服务回放和改进。失败任务可以复盘页面状态和动作序列，把稳定流程沉淀成 Playwright 脚本，把易错页面加规则，把高风险动作加入确认，把常见验证码场景改走官方 API。没有审计，浏览器代理永远停留在演示水平。

十二、用户确认：确认要具体，不要形式化

确认机制不能只是一个“是否继续”的弹窗。有效确认要让用户知道：在哪个网站，对哪个对象，做什么动作，关键参数是什么，会产生什么后果，是否可撤销。用户确认的内容必须和执行动作绑定，不能确认前一套参数、执行时又让模型重新生成另一套参数。

比如发布内容时，确认页应显示目标平台、账号、标题、正文摘要、图片或附件、可见范围和发布时间。发送消息时，应显示收件人、主题、正文摘要和附件。提交报销时，应显示金额、币种、类别、发票文件和审批人。支付时，应显示商户、商品、数量、金额、币种、付款方式和自动续费。删除时，应显示对象、数量、位置和恢复方式。

确认还要按风险分级。低风险草稿保存可以轻确认或自动完成；对外发送、支付、删除、授权和生产配置修改必须强确认；大额或批量动作可以要求二次确认或审批。不要把所有动作都同样确认，否则用户会形成机械点击；也不要为了流畅体验取消关键确认。

确认界面要面向最终用户。不要展示内部工具名、JSON 参数、选择器、DOM 路径和调试字段。用户关心的是动作影响，不是实现细节。内部参数可以进入审计，用户界面只展示可理解的事实和后果。

确认后执行要可追踪。系统应生成待执行动作 ID，包含确认版本、参数、用户、时间和目标页面。执行器按这个动作 ID 执行。若页面状态变化导致参数不再一致，应停止并重新确认。比如支付金额变化、收件人变化、按钮变成“订阅并付款”，都不能继续执行旧确认。

确认失败也要清楚。页面过期、登录失效、验证码出现、金额变化、按钮不可见、网络超时，都应告诉用户当前状态，而不是继续猜测或重试。关键动作宁可停下来，也不要在不确定状态下继续点击。

十三、产品体验：不要把边界做成阻塞墙

边界不是为了让浏览器代理难用，而是让它可被信任。好的体验不是每一步都弹窗，也不是把所有危险都藏起来，而是让低风险任务顺滑、高风险动作清楚、失败状态可理解。

一个好的浏览器代理界面应展示任务目标、当前网站、当前步骤、已读取的信息、准备执行的动作和需要用户确认的事项。用户不需要看到模型思考过程，但需要知道代理在哪里、准备做什么、为什么停下。尤其是登录、验证码、支付和上传文件时，停顿要有清楚说明。

边界文案要面向用户。不要显示“工具调用被策略拒绝”“selector timeout”“storageState missing”这类内部说法。可以说“当前任务没有访问这个网站的权限”“这个页面要求你完成验证”“提交前需要你确认金额和收件人”“这个文件没有被授权上传”。用户要知道下一步怎么做。

低风险自动化要减少摩擦。读取公开网页、滚动、提取表格、生成摘要、保存草稿、截图和检查页面，可在任务范围内自动完成。用户选择浏览器代理，是为了减少重复劳动，不是为了给每个滚动都点确认。

高风险确认要有证据。确认页不要只写“即将提交表单”，要展示字段和影响。用户愿意确认，是因为信息清楚，不是因为弹窗存在。产品团队要花时间设计确认体验，而不是把安全责任甩给一个模糊按钮。

失败恢复也重要。浏览器任务经常中途失败：页面改版、网络超时、登录过期、验证码、下载失败、按钮不可见。产品应允许重试当前步骤、返回上一步、交给用户手动完成、导出已整理的信息，而不是整个任务报废。

十四、什么时候该用 API，而不是浏览器代理

浏览器代理适合没有 API、流程变化快、任务低频、需要阅读页面语义的场景。长期生产流程如果高频、高价值、高风险，应该优先建设 API 或正式集成。API 可以提供明确身份、权限、参数、幂等、错误码、回调和审计，比浏览器点击稳定得多。

支付、退款、订单更新、库存同步、用户权限、生产配置、批量数据导入导出，应该尽量走 API。浏览器代理可以帮人找到入口、解释页面、准备草稿，但核心状态变更最好由后端接口执行。这样可以避免页面改版、误点、重复点击和状态不一致。

企业内部系统如果没有 API，可以把浏览器代理当作过渡方案，同时推动系统改造。每当某个浏览器自动化任务变成每天运行、影响业务结果、需要审计和 SLA，就说明它值得被产品化。长期用 AI 点击网页代替系统集成，会把自动化建立在最脆弱的界面层上。

第三方网站尤其要注意服务条款。公开网页阅读和人工辅助通常问题较小，批量抓取、绕过风控、自动购买、自动注册、规避验证码和高频操作可能违反规则。产品团队要考虑法律、账号安全和平台关系，而不是只看技术可行。

一个简单判断标准是：如果动作需要强一致、幂等、回滚、审批、对账或 SLA，就不要只靠浏览器代理。如果动作主要是阅读、整理、比较、草稿和低风险输入，浏览器代理很合适。

十五、团队落地的边界清单

第一，定义任务范围。每个浏览器任务要有目标、允许域名、允许动作、可用登录态、文件权限、超时和风险等级。不要让代理在整个互联网和用户完整浏览器 profile 中自由探索。

第二，隔离浏览器上下文。每个任务使用独立 context，必要时使用任务专用登录态。认证状态像密钥一样保护，任务结束清理 Cookie、缓存、下载和上传临时文件。

第三，限制网络和域名。只允许访问任务需要的网站。阻止内网管理地址、本机端口、云元数据地址和未授权外部域名。第三方跳转要重新确认。

第四，区分观察、填写、提交和高风险动作。观察和低风险填写可以自动，提交需要确认，支付、删除、授权和生产修改需要强确认或人工执行。

第五，文件进沙箱。下载文件进任务目录，上传文件来自用户授权。记录文件来源、哈希、大小和用途。任务结束清理临时文件。

第六，遇到验证码和二次验证就停。不要绕过，不要保存验证码，不要让模型复述一次性密码。用户手动处理后可继续低风险步骤。

第七，网页内容当数据。页面里的文字不能改变系统指令、工具权限、确认要求和域名范围。把提示注入防护落到工具层和策略层。

第八，关键动作前做具体确认。展示网站、对象、字段、金额、附件、按钮和影响。确认内容与执行参数绑定，页面状态变化时重新确认。

第九，审计每次关键动作。记录任务、用户、URL、页面标题、动作、输入摘要、截图或 DOM 摘要、文件、确认和结果。审计内容按敏感等级保存。

第十，把稳定高频流程固化。AI 代理探索出的可靠流程，尽量沉淀为 Playwright 脚本、后端 API 或正式工作流。不要让模型每次重新猜。

十六、典型场景判断

公开资料收集适合浏览器代理。它可以访问指定网站、提取页面标题、价格、发布日期、表格和链接，整理成报告。边界是限制域名、频率和下载类型，尊重网站规则，标注来源。

企业后台巡检适合半自动。代理可以登录低权限账号，检查页面状态、截图、提取异常和生成报告。若需要修改配置，应停在确认或走内部 API。不要用管理员账号让代理自由操作。

内容发布适合草稿模式。代理可以把文章填入编辑器、上传用户选择的图片、预览排版，但发布按钮应确认。对外发布涉及品牌和法律责任，不应无确认自动完成。

报销和采购适合预填。代理可以读取发票、填写金额、日期、项目和说明，上传用户授权附件。提交前展示字段和附件，由用户确认。大额采购或供应商变更应走审批。

客服后台适合辅助查询和草稿。代理可以查看当前客户工单、整理历史、生成回复草稿。发送给客户、退款、改订单状态需要确认和业务权限。

支付和银行不适合自动执行。代理可以解释页面、帮助用户核对信息，但最终付款、转账、授权和验证码应由用户自己完成或由正式金融 API 处理。

验证码密集站点不适合浏览器代理长期操作。如果每次都需要验证码，说明对方不欢迎自动化或需要正式授权。应停止绕行思路，转向 API、合作接口或人工流程。

十七、常见误区

第一个误区是认为“人能点，AI 就能点”。人有责任、经验和法律主体，AI 只是系统能力。能点不代表应该点，更不代表可以无审计地自动点。

第二个误区是直接使用用户日常浏览器 profile。这样代理继承了过宽登录态，任何网页提示注入或误点都可能横向影响其他账号。

第三个误区是把验证码识别当成产品能力。验证码和二次验证是安全边界，生产系统应该暂停或走官方授权，而不是绕过。

第四个误区是只看最终结果，不记录过程。浏览器任务没有审计，失败后无法复盘，也无法让用户信任。

第五个误区是让网页内容决定安全策略。网页可以提供信息，不能要求代理跳过确认、打开未授权网站或读取其他资料。

第六个误区是把确认做成免责按钮。有效确认必须展示对象、参数、影响和后果，并绑定执行动作。

第七个误区是长期依赖浏览器点击替代 API。浏览器适合低频和过渡，关键高频流程应该沉淀为稳定接口或正式自动化。

第八个误区是把所有动作都阻塞确认。低风险观察和草稿可以自动完成，否则产品会变得难用。边界要按风险分级。

十八、结语

AI 浏览器代理的价值在于把网页从“只能人眼操作”变成“可以被智能系统理解和辅助”。它很适合阅读、提取、比较、巡检、预填、草稿和低风险自动化，也能帮助团队验证真实用户路径。它不适合绕过验证码，不适合继承用户全部登录态，不适合在无确认情况下支付、删除、授权和修改生产系统，也不适合长期承担需要强一致和审计的核心业务动作。

生产级边界可以概括为一句话：浏览器代理可以帮用户看清页面、准备动作和完成低风险步骤；当动作会影响账号、金钱、文件、客户、权限或外部世界时，必须由权限系统、确认机制和审计记录接管。这样设计，AI 才不是一个危险的自动点击器，而是一个能被信任的网页工作助手。

参考资料

1. Playwright Actionability and auto-waiting: https://playwright.dev/docs/actionability
2. Playwright Locators documentation: https://playwright.dev/docs/locators
3. Playwright Authentication and storage state: https://playwright.dev/docs/auth
4. Playwright Input and file upload: https://playwright.dev/docs/input
5. Browser Use documentation: https://docs.browser-use.com/
6. Browser Use GitHub project: https://github.com/browser-use/browser-use
7. OpenAI Computer Use guide: https://platform.openai.com/docs/guides/tools-computer-use
8. OpenAI Computer Use safety guide: https://platform.openai.com/docs/guides/tools-computer-use#safety
9. Anthropic Computer Use documentation: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/computer-use-tool
10. OWASP LLM01 Prompt Injection: https://genai.owasp.org/llmrisk/llm01-prompt-injection/
11. OWASP LLM06 Excessive Agency: https://genai.owasp.org/llmrisk/llm06-excessive-agency/
12. OWASP LLM02 Sensitive Information Disclosure: https://genai.owasp.org/llmrisk/llm02-sensitive-information-disclosure/