三代技术路线：从选择器到像素
「自动操作网页」不是新需求（RPA 行业做了二十年），新的是实现范式。三代技术路线的更替，就是浏览器智能体与经典 RPA 的分水岭。第一代：选择器脚本（经典 RPA）。按 CSS 选择器/XPath 精确定位元素、按录制或编写的脚本执行——快、便宜、确定性 100%；死穴是脆弱（页面改版即失效）与「不会变通」（脚本处理不了没见过的情况）。每一处自动化都要人工「教」，维护成本随页面数量线性涨。第二代：DOM + LLM（API 派智能体）。把页面的 DOM 结构（或可访问性树）喂给模型，让模型理解页面并决定操作——智能体获得了「读」页面语义的能力，页面小改版不再失效；局限是对非 DOM 呈现的内容（canvas、复杂可视化、桌面应用）无能为力，且长页面的 DOM 会撑爆上下文。第三代：像素 + Computer Use（视觉派智能体）。模型直接看屏幕截图、移动光标点击输入——与人类操作界面完全同构，任何「人能操作的界面」理论上都能操作（包括桌面应用与不开放 DOM 的环境）。代价是慢（每步都要截图推理）、贵（视觉 token 的消耗）与可靠性波动（点击坐标的精度、动态界面的时序）。
三代不是替换关系而是覆盖关系：结构稳定的页面用第一代（性价比之王）、有 DOM 的场景用第二代（当前主流）、无 DOM 的环境才动用第三代——成熟的产品都是三代混合调度（Computer Use 作为兜底而非默认）。
flowchart LR
R1["一代：选择器脚本<br>（经典 RPA）<br>快·稳·脆弱"] --> R2["二代：DOM + LLM<br>（API 派）<br>读语义·抗改版"]
R2 --> R3["三代：像素 + Computer Use<br>（视觉派）<br>通用·慢·贵"]
R3 -.->|"兜底而非默认"| R1
对 RPA 格局的重构：从「实施商生意」到「自服务能力」
经典 RPA 的商业模式有个结构性软肋：实施是重活——每个自动化流程都要实施商或企业 IT 人工编写与维护，销售的是「人天」；市场规模大（企业自动化的刚需真实存在）但增长受人力瓶颈约束，客户常抱怨「买了平台还要养一批实施」。浏览器智能体重构了这个结构：自动化的「编写」环节被模型接管——描述目标（「把这个系统的订单逐个导出」）即可获得自动化流程，维护也由智能体自己适应页面变化（看到改版就重新理解）。RPA 的「实施商生意」因此被挤压，行业正在向「自动化平台 + 智能体能力」转型（经典 RPA 厂商纷纷接入 LLM）。
重构的另一半是需求面的扩容：经典 RPA 服务的是企业确定性流程（财务、供应链的高频操作），浏览器智能体把自动化带给了长尾与个人场景——帮助文档里没有的内部系统、临时性的数据搬运、个人的网页操作 chores。RPA 从「企业重流程」扩展为「一切网页操作的自动化」，市场边界扩大了一个量级。这也是为什么「浏览器智能体」的产品井喷（各家助手、编码智能体、垂直产品纷纷加网页操作能力）——它是智能体接触「互联网上未被 API 化的世界」的主要通道。
真实边界：为什么「操作网页」比想象中难
浏览器智能体的演示总是惊艳，日常使用的翻车也真实——边界由四个结构性难点划出。难点一：登录与凭证。大多数有价值的网页操作需要登录——凭证的托管（智能体替你输密码）是安全敏感问题（本库凭据安全篇的战场），不托管则每次要人接管（自动化断链）。难点二：反自动化。目标网站未必欢迎被自动化：验证码、行为检测、风控——法律与合规的灰色地带（绕过反自动化条款可能违反服务协议甚至法律），这条边界让「爬取与自动化」的商业产品始终戴着手铐。难点三：不可逆操作。浏览页面安全、下单付款危险——智能体在「 irreversible 的世界」里操作的权限设计（确认流、额度限制、操作白名单）是产品成熟度的分水岭，也是翻车的高发区。难点四：长流程的累积误差。十步操作的流程，每步 95% 可靠性，全程可靠性只剩 60%——「流程越长越不可信」的规律决定了浏览器智能体先吃「短流程高频操作」（填表、导出、比价），长流程（多系统的端到端业务）仍是人机协作（智能体做人验收）。
生态判断：通道价值大于独立产品价值
浏览器智能体的生态位判断可以压缩成一句话：它是智能体的「手」，不是「脑」——独立产品（一个专门替你操作网页的助手）的天花板有限，作为能力嵌入各类智能体（编码智能体帮你查文档、运维智能体帮你点控制台、个人助手帮你比价下单）的价值大得多。这个判断的产品含义：独立浏览器智能体产品的出路是双向的——要么做深垂直场景（把某个行业的网页操作流做透，含凭证、合规、验收的完整方案），要么做底（成为其他智能体调用的能力层/工具层）。观察信号有两个：反自动化的演化（网站的反爬与「为智能体开 API」的进程——哪个快，决定这条通道的宽窄）与权限产品的成熟（凭证托管与不可逆操作确认的标准化方案）——这两件事的进展，比任何 demo 视频都更能预示浏览器智能体的天花板高度。
浏览器智能体的合规暗线：协议、法律与「API 化」的博弈
浏览器智能体与网站之间的紧张关系有一条合规暗线，值得单独拆解。现状的三方博弈：网站（想控制自己的内容与流量被谁、怎么消费）、智能体产品（想获得操作通道）、用户（想自动化自己的操作——用自己账号操作自己的数据）。法律层面：多数网站的服务条款禁止自动化访问与操作——用户用智能体操作自己的账号，条款上可能已经违约（即使操作本身合法）；对公共信息的抓取与操作的边界（ robots 协议、反爬条款的效力）在各法域的判例不一。行业的两个演化方向正在赛跑。方向一：网站的反自动化军备（更强的行为检测、更普遍的验证码与人机验证）——短期提高智能体的成本，长期把「操作通道」推向地下（更隐蔽的自动化，合规更糟）。方向二：「为智能体开 API」的进程——网站主动提供机器可读的接口（从「只给人看的页面」到「也给智能体用的门」），把自动化纳入自己的条款与计费——这是健康终局，但网站的动力需要商业理由（智能体带来的增量价值 vs 失控风险）。两个方向的赛跑结果决定浏览器智能体的天花板：「API 化」赢，浏览器智能体成为「 legacy 通道」（兼容旧世界）；反自动化赢，它困在灰区做不大。给从业者的合规底线：商用产品不做「绕过反自动化」的卖点（法律风险直接传导给用户），把「遵守站点条款的自动化」作为产品设计约束——短期能做的场景少一些，长期活下来的资格多一些。
浏览器智能体的「可给可不给」清单：产品经理视角
浏览器智能体产品决定「让智能体操作什么」时的清单，按可给度分级。可以给的（低风险）：只读操作（浏览、搜索、截图、提取公开信息）、表单的草稿填充（填好让人确认提交）、已登录会话内的查询类操作（查订单、查余额的只读页面）。要确认后给的（中风险）：表单的实际提交、邮件的发送（草稿可给、发送需确认）、内容的修改（编辑已发布的内容）。默认不给的（高风险）：支付与转账、删除操作、权限变更（改设置、授权第三方）、批量操作（批量删除/群发——一次误操作的爆炸半径太大）。绝对不给的：绕过身份验证（代解验证码、共享登录态给第三方智能体）、超授权范围的数据导出。这份清单的产品学意义：「可给度」的分级不是安全团队的单方面规定，是产品信任的渐进解锁路径——新产品从「可以给的」起步，用运行记录（零事故）换取用户对「要确认后给的」的授权，逐级放开；信任的扩张速度由事故率决定，这是产品与安全团队唯一的共同 KPI。
浏览器智能体的企业版机会：内网的无 API 世界
浏览器智能体（正文）讨论的多是公网场景，它的企业版机会其实更大且无合规灰区：内网系统的自动化。企业内部充斥着「没有 API 的系统」——老牌 ERP 的客户端、内部自建的管理后台、供应商部署的本地化系统——这些系统的共同点是：业务天天要用、接口没开放、改造成本高到不值得。经典 RPA 在这个市场深耕多年（实施重、维护贵），浏览器智能体（尤其 DOM+LLM 混合路线）给出了轻得多的方案：内网环境可控（无反自动化博弈、凭证治理在企业安全体系内）、页面稳定（内部系统改版少——智能体的维护成本低）、合规清晰（操作自家系统自家数据，无第三方条款问题）。这个机会的产品形态：面向企业 IT 的「内网操作智能体平台」——IT 部门用自然语言定义操作流程（替代 RPA 的实施）、业务部门自助使用。它是浏览器智能体赛道里「合规无争议、需求真实、付费能力强」的最佳细分——公网场景的热闹属于消费者叙事，内网场景的订单属于企业叙事，而企业叙事的钱，向来比消费者叙事到得早。
小结
浏览器智能体是 RPA 的范式重生：三代技术路线（选择器脚本、DOM+LLM、像素+Computer Use）是覆盖关系而非替换，成熟产品三代混用、视觉派兜底。它重构了 RPA 的实施商生意（编写与维护被模型接管）、扩容了需求面（从企业重流程到长尾个人场景）。真实边界由四难点划出：凭证托管、反自动化的法律灰区、不可逆操作的权限设计、长流程的累积误差。生态位判断：它是智能体的手不是脑——通道价值大于独立产品价值，出路是做深垂直或做底能力层。两个先行指标：网站侧「反自动化 vs 开放 API」的演化、权限产品的标准化进程。
读者留言
COMMENTS 暂无还没有留言，来说第一句？