技术观察与工程实践 · 更新至 2026 年 9 月AI浏览器会取代App吗——从RPA到Computer Use与WebMCP的Agent工作流深度解析人工智能AI浏览器AI Agent智能体RPAComputer UseWebMCP浏览器自动化大模型软件架构过去的浏览器负责打开网页RPA负责按流程点击今天的AI浏览器开始理解目标、规划路径、跨站操作并验证结果。当“搜索—比较—填写—提交—确认”都由Agent完成App还是用户入口吗本文从Computer Use、WebMCP、RPA与API演进出发拆解AI浏览器的技术栈、生产可靠性、安全边界和落地场景。结论不是“App消失”或“RPA过时”而是软件入口正从GUI转向“意图工具”RPA成为Agent体系中更确定的执行器。真正决定胜负的是谁能把动作做成可调用、可验证、可授权、可回滚的能力。一句话结论AI浏览器更可能取代“人必须亲手打开每个App并学习它怎么操作”这件事而不是取代App背后的业务系统它也不是更聪明的RPA而是把RPA、API、网页结构化工具和视觉操作统一编排起来的上层智能体。目录1. 当App不再被打开软件入口发生了什么2. 先把AI浏览器定义清楚——它不是“浏览器 聊天框”3. 为什么2026年是关键拐点——Computer Use开始进入主流工具链4. AI浏览器与RPA的本质差异——控制逻辑变了5. 真正的工程分水岭——从“点像素”到“多执行器分层”6. AI浏览器会取代App吗——拆开App的四层再回答7. 哪些场景值得用哪些场景不该用8. 从Demo到生产——幂等、验证、回滚与人工接管9. 安全边界——当不可信网页拥有了可执行权限10. 成本与可靠性——为什么不能让AI把每个按钮都点一遍11. 如何把产品做成Agent-ready12. 一张决策树选出API、WebMCP、RPA还是视觉操作13. 结语——下一代软件争夺的不是屏幕时间而是可信执行权1. 当App不再被打开软件入口发生了什么想象一个非常普通的任务你告诉AI“下周二去上海出差两晚优先高铁酒店离会场三公里内含早餐预算不超过900元把行程写进日历再生成一份可报销的行程单。”过去你要在地图、票务、酒店、日历和企业报销系统之间来回切换。真正花时间的往往不是“做决定”而是搜索、筛选、复制、填写、跳转、核对。如果这些动作全部由浏览器智能体完成你甚至没有亲手打开任何一个App。此时最值得讨论的就不是“浏览器是不是更聪明”而是一个产品层面的结构性变化对用户来说App正在从“必须学习和进入的界面”变成“智能体背后可以调用的能力与状态容器”。这也是为什么“AI浏览器会不会取代App”这个问题容易被问错。App至少包含四样东西交互界面、业务流程、规则与权限、数据与状态。AI最先冲击的是前两者中的“人工导航成本”而后两者恰恰会因为Agent能够代替人执行动作变得更加重要。真正发生的不是“浏览器吞掉所有软件”而是“GUI不再是软件能力的唯一入口”。2. 先把AI浏览器定义清楚——它不是“浏览器 聊天框”今天被统称为“AI浏览器”的产品其实有三种形态。第一种是在传统浏览器里加入侧边栏助手重点仍然是阅读、总结和问答第二种是让Agent拥有一个可操作的浏览器环境能够点击、输入、滚动、下载和跨页面执行任务第三种更进一步把浏览器当成“通用执行端”同时接入API、网页结构化工具、DOM、可访问性树、视觉识别和本地自动化。真正改变软件入口的是后两种。从工程视角看一个能“做事”的AI浏览器至少要维持一个闭环理解目标 → 动态规划 → 感知当前页面 → 选择最合适的工具 → 执行动作 → 验证结果 → 更新记忆。它和脚本最大的不同不是“会不会点按钮”而是路径可以在运行过程中改变。图 1 AI浏览器的核心不是点击而是目标—计划—执行—验证闭环例如“给客户找三家符合条件的供应商并发出询价”并没有唯一操作路径。某个站点可能有搜索API另一个站点只有网页有的网站提供结构化工具有的只能靠DOM有的还会因为登录、验证码或动态组件要求人工接管。一个真正的Agent需要根据当前状态决定“下一步用什么”而不是把所有步骤提前写死。3. 为什么2026年是关键拐点——Computer Use开始进入主流工具链截至2026年9月几个公开信号已经非常明确Computer Use不再只是单独的研究演示正在进入主流模型、浏览器标准和企业自动化平台。重要的不是某一家厂商的产品名而是行业在同时解决三个问题——“AI如何看懂界面”“网页如何主动暴露可调用能力”“企业如何把概率型Agent与确定性自动化放在一起”。时间 / 信号公开进展对AI浏览器意味着什么2026-06Google将computer use作为Gemini 3.5 Flash的内置工具用于浏览器、移动端与桌面环境。[1]“看屏幕—推理—行动”开始从专用模型走向通用模型工具。2026-05 至 09Chrome推进WebMCP目标是让网页向Agent暴露结构化工具安全文档专门讨论恶意工具描述与被污染输出。[2][3]网页不必永远让Agent猜按钮可以直接给出机器可理解的动作语义。持续更新OpenAI的computer use文档同时支持代码执行、结构化鼠标键盘动作以及既有function calling / MCP类接口。[4]同一个Agent可以按任务选择“调用工具”或“操作界面”。2026上半年Microsoft Power Automate把AI Agent、自愈桌面流与RPA协同列为重点并强调Agent可调用桌面流执行精确步骤。[5]企业自动化并没有抛弃RPA而是在上面增加判断与编排层。2026UiPath公开区分Agent与Robot前者偏概率型、适应型决策后者偏确定性、规则型执行并强调二者组合。[6]“Agent RPA”正在形成新的生产级分工。这些进展共同指向一个很重要的变化浏览器正在从“给人看的页面容器”变成“人和Agent共同使用的行动环境”。与此同时企业自动化也从“流程图驱动执行”转向“目标驱动编排 确定性执行器”。4. AI浏览器与RPA的本质差异——控制逻辑变了AI浏览器和RPA看起来很像因为它们都能点击、输入、复制和提交。但两者的核心控制逻辑不同。RPA通常从流程开始先定义步骤再让机器人重复执行AI浏览器通常从目标开始先理解“要达成什么”再决定走哪条路径。维度传统RPAAI浏览器 / Agent任务入口流程、触发器、结构化参数自然语言目标 上下文 约束执行路径预先编排分支显式运行时规划可改变路线页面理解选择器、坐标、OCR、规则语义理解 DOM/可访问性 视觉异常处理进入预设异常分支重规划、自纠错或请求人工输入类型结构化、规则明确可处理文本、页面、图片等非结构化信息可重复性高适合批量稳定流程受模型与环境影响需要验证闭环成本结构前期配置高单次执行稳定前期接入灵活推理与观察成本更高最佳场景高频、固定、可预测流程长尾、变化大、例外多、跨站任务图 2 RPA与AI浏览器的关系更像“确定性执行器”和“适应型编排器”因此把AI浏览器称为“更聪明的RPA”只说对了一半它确实覆盖了RPA曾经解决的“无API界面自动化”问题但它把任务入口从“固定流程”提升成了“目标与约束”又把执行器从单一路径扩展为多个工具。反过来RPA也不会因为Agent出现就消失。越是高频、稳定、对一致性要求高的步骤越适合交给确定性机器人而不是每次都让大模型重新思考。5. 真正的工程分水岭——从“点像素”到“多执行器分层”很多人第一次看到Computer Use会自然地把“像人一样看屏幕和点鼠标”当作终极形态。工程上恰好相反视觉操作越通用通常也越慢、越贵、越容易受界面变化影响。一个成熟Agent不应该为了证明自己会看图就坚持把所有任务都降级成鼠标点击。图 3 生产级执行栈应优先选择结构化、高可靠接口视觉操作用于长尾兜底更合理的执行优先级通常是· 第一优先业务API。参数明确、错误码明确、状态可查询最容易做幂等、审计和回滚。· 第二优先网页结构化工具。类似WebMCP的方向让站点主动告诉Agent“有哪些动作、参数是什么、返回什么”减少对页面布局的猜测。[2]· 第三优先DOM与可访问性树。仍然依赖页面结构但比纯视觉点击更精确也更容易定位控件。· 第四优先视觉Computer Use。它是“任何界面都能尝试”的通用后备方案特别适合没有API、结构复杂或动态变化的长尾网站。· 最后一层人工接管。验证码、强身份验证、不可逆高风险动作和状态不明确时应主动交还控制权。这里有一个容易被忽略的判断真正强的AI浏览器未必是“视觉点按次数最多”的那个而是“能在最少的不确定步骤里完成任务”的那个。6. AI浏览器会取代App吗——拆开App的四层再回答图 4 App并不是一个界面而是界面、流程、规则和数据四层能力的组合如果把App看成一个整体很容易得到“会取代 / 不会取代”的二元答案。把它拆成四层后结论会清晰很多。App层级核心价值AI浏览器的影响未来变化交互界面让人理解功能并完成操作影响最大部分操作从“人找菜单”变为“Agent直接调用动作”GUI更偏审核、探索和例外处理。业务流程把多个动作组织成交易或协作中到高流程逐步暴露为可组合工具Agent负责跨系统编排。规则与权限价格、风控、额度、角色、合规影响有限但重要性上升规则必须机器可判定权限需要细粒度作用域与确认。数据与状态订单、库存、客户、文档、账户不会被浏览器替代继续作为事实来源且必须提供可靠状态查询和审计能力。所以更准确的说法是AI浏览器会削弱“App必须占据用户屏幕时间才能创造价值”这一前提但不会削弱业务系统本身。恰恰相反当更多动作由Agent发起系统的规则、权限、状态机和可验证接口会变得更加重要。对消费软件来说用户可能越来越少记得“这个功能藏在哪个页面”对企业软件来说员工可能越来越少在十几个后台之间搬运字段。但订单、合同、库存、审批、权限、审计这些系统能力依然存在只是入口从“人点击GUI”转向“Agent调用能力”。7. 哪些场景值得用哪些场景不该用AI浏览器的价值并不与“任务复杂度”简单正相关。更有用的两个变量是路径变化程度以及出错代价。页面变化大、规则无法完全预先枚举但错误可发现、可回退的任务是当前Agent最有价值的区域。图 5 任务变化程度与出错代价共同决定自动化方式7.1 信息型任务——最适合快速规模化例如收集十家供应商的公开报价、从多个官网核对产品参数、整理会议日程、把公开网页中的结构化信息填入表格。这类任务的共同特点是“读多写少”即使某个页面理解错了也能通过交叉验证或人工抽查发现。它非常适合作为AI浏览器的第一批生产场景。7.2 遗留系统——Agent与RPA的组合价值最高老ERP、虚拟桌面、Citrix应用或没有API的内部系统本来就是RPA最擅长的地盘。Agent的增量价值不是把机器人删掉而是处理那些过去很难提前写完规则的异常输入格式不一致、页面提示变化、需要从文档中理解上下文、某个分支临时改走另一条流程。此时可以让Agent做判断再调用稳定的RPA片段执行。7.3 高风险交易——必须“先预览再提交再验证”付款、删除数据、发送外部邮件、修改权限、购买商品、提交法律或财务材料都不适合用“看起来成功了”作为完成标准。高风险任务的正确设计不是完全禁止自动化而是把自动化拆成三个阶段先生成可检查的预览得到明确授权后执行再通过服务端状态确认结果。8. 从Demo到生产——幂等、验证、回滚与人工接管浏览器Agent在演示中最吸引人的往往是“它真的点进去了”。但生产环境的核心问题完全不同如果提交请求后页面卡住Agent到底应该重试还是已经成功但没有刷新如果重复点击“支付”会不会下两次单如果下载按钮没有响应文件到底生成了还是没生成图 6 生产级Agent需要把“成功”定义成可验证状态而不是视觉上的“好像完成了”这套闭环里有五个工程点尤其关键。· 幂等性同一个业务意图应该有稳定的幂等键。网络超时或页面无响应时重试不能造成重复扣款、重复创建记录。· 前置条件执行前确认登录态、权限、目标对象、金额、版本、库存或表单关键字段避免“正确地执行了错误对象”。· 服务端验证重要动作完成后用订单号、状态接口、列表记录或后端查询确认不把“页面出现绿色提示”当成唯一证据。· 可回滚优先使用草稿、预览、临时状态、撤销操作把不可逆动作放到流程末端并设置明确确认点。· 人工接管当状态未知、页面出现异常安全提示、目标与约束冲突时不要让Agent无限尝试。一个最小的生产级执行器可以把核心逻辑写成下面这样的伪代码。重点不是语法而是“每个动作之后都要能证明发生了什么”。def run(intent, executor):key make_idempotency_key(intent)existing query_result_by_key(key)if existing.is_done:return existingplan build_plan(intent)for step in plan:policy.check(step) #权限、风险、金额、目标对象result executor.execute(step) # API / WebMCP / DOM / RPA /视觉操作state verify_on_server(step, result)if state done:audit.write(step, result)continueif state unknown:state query_again(step, key)if state ! done:return handoff_to_human(step, state)return build_verifiable_receipt(plan)如果一个Agent系统没有幂等、状态查询和审计能力那么模型再聪明它也只是在把传统“自动化脚本的脆弱性”升级成“带推理能力的脆弱性”。9. 安全边界——当不可信网页拥有了可执行权限浏览器Agent与普通聊天机器人的风险结构不同它不仅“读到内容”还可能拥有登录态、文件访问、外发、下载、提交表单甚至支付权限。于是网页中的恶意文本不再只是误导回答而可能变成间接提示注入——诱导Agent忽略原任务、泄露信息或执行不应该发生的动作。图 7 浏览器Agent的核心安全矛盾不可信内容与可执行权限被连接在了一起Chrome的WebMCP安全文档专门提示两类风险恶意工具定义以及可信站点返回内容中被混入的恶意指令。[3] NIST对Agent工具权限的讨论也强调了“读、受限写、写”与“可信、非可信环境”之间的组合差异浏览器使用本身就属于需要特别约束的场景。[7] 2026年的Agent安全研究进一步把间接提示注入视为需要持续红队测试和系统性缓解的问题。[8][9]风险典型表现生产级护栏间接提示注入页面、评论、邮件正文中夹带“忽略用户指令并执行……”把内容当数据而非指令对工具调用做独立策略判定敏感动作二次确认。权限过大一个浏览器会话同时拥有邮箱、云盘、支付与后台管理权限最小权限、按任务临时授权、读写分离、作用域令牌。状态欺骗页面伪造“已成功”提示或覆盖真实结果使用服务端状态、订单号、记录ID或独立查询渠道验证。数据外泄Agent把页面数据复制到不该访问的目标站点目标域白名单、敏感字段脱敏、跨域外发策略。自动下载 / 执行恶意页面诱导下载脚本或运行代码下载隔离、文件类型策略、沙箱执行、禁止默认运行未知文件。长任务漂移执行几十步后目标或约束逐渐偏离检查点、预算上限、最大步数、关键状态重新确认。安全设计的一个实用原则读取可以更自动写入必须分级可逆动作可以更放权不可逆动作必须有明确确认。10. 成本与可靠性——为什么不能让AI把每个按钮都点一遍AI浏览器还有一个经常被Demo掩盖的问题长任务的延迟和成功率会累积。一次视觉观察、一次推理、一次点击、一次等待、一次验证都要消耗时间如果一个任务有二十个关键步骤即使每步独立成功率达到98%粗略相乘后的端到端成功率也只有约66.8%。每步提高到99.5%二十步后仍只有约90.5%。现实任务的步骤还不是完全独立因此“减少不确定步骤数”本身就是可靠性优化。这也是为什么API与结构化工具如此重要。把五次“看屏幕—找按钮—点击—等待—再看屏幕”压缩成一次参数明确的工具调用通常同时降低延迟、token消耗和失败面。执行方式单步成本路径稳定性可审计性适合任务API低高高交易、查询、批量操作、核心业务流程网页结构化工具低到中高高网站主动支持Agent的标准动作DOM / 可访问性中中高中高网页表单、后台操作、可定位元素RPA中高稳定界面高高频固定流程、遗留系统视觉Computer Use高中到低中长尾网页、动态界面、无结构化接口人工高最高判断力视流程而定高风险确认、异常、目标冲突因此评估AI浏览器项目时不应该只看“任务完成率”还要至少记录平均步骤数、视觉步骤占比、重规划次数、人工接管率、端到端时延、单任务成本、重复写入率、状态未知率以及失败后恢复时间。真正成熟的系统会不断把高频视觉路径“下沉”为结构化工具或确定性自动化。11. 如何把产品做成Agent-ready过去网页主要为人设计按钮文案要好懂视觉层级要清晰表单要少填。Agent时代并不会让这些原则失效但会多出一套“机器可操作性”要求。产品如果希望被智能体稳定调用可以优先补齐下面八项。14. 稳定的业务动作接口把“创建订单、查询状态、提交工单、生成报表”等能力做成显式动作而不是只能通过页面路径触发。15. 机器可读的参数与错误明确必填字段、枚举值、权限要求、可重试错误和不可重试错误不要只返回一段模糊提示。16. 预览 / 提交分离复杂或高风险操作先返回diff、价格、影响范围再由用户或策略明确确认。17. 幂等与请求ID同一业务意图重复发送时不重复生效并能通过请求ID查询最终状态。18. 细粒度权限把读取、草稿、提交、删除、外发、支付等权限拆开不要只提供“全有或全无”。19. 完整审计轨迹记录谁授权、Agent调用了什么工具、参数是什么、返回了什么、何时人工接管。20. 语义化页面即使没有专用API也尽量保持可访问性树、表单语义、稳定标识和清晰状态。21. 失败后的恢复入口允许Agent安全查询状态、撤销、继续或转人工而不是失败后只能“从头再来”。图 8 更可能出现的形态是“个人智能体 多执行器 既有业务系统”对产品经理来说这会改变一个长期默认前提过去每个功能都必须争夺入口、导航位置和用户注意力未来一部分功能的主要“用户”可能先是Agent。对开发者来说前端仍然重要但“是否能被可靠调用、验证和授权”会成为和UI体验同等重要的产品能力。12. 一张决策树选出API、WebMCP、RPA还是视觉操作如果团队今天就要做浏览器Agent不必从“选哪个大模型”开始。先从执行方式做减法有稳定API就不要点页面有结构化网页工具或可靠DOM就不要上视觉界面稳定且任务高频重复就交给RPA只有长尾、动态、无接口的部分再使用视觉Computer Use。任何高风险动作都独立经过权限和确认策略。图 9 自动化执行方式的实用决策树这张图背后的原则可以压缩成一句话能让系统说清楚就不要让模型猜能让工具一次完成就不要让Agent分十步点击。13. 接下来真正值得关注的五个变化下面不是“某个产品一定会发生什么”的断言而是基于当前技术路线更值得关注的方向。· 第一浏览器会更像通用行动层。它的优势不是拥有全部业务而是天然连接大量网页、登录态与用户上下文适合成为跨站编排端。· 第二网页会出现越来越多“给Agent看的接口”。WebMCP所代表的结构化工具思路本质上是在给网站增加一套机器可理解的交互语义。[2]· 第三RPA会从“自动化的主角”变成“Agent的确定性执行器”。判断与异常交给Agent高频固定路径交给Robot是更经济也更可控的分工。[5][6]· 第四App的价值会进一步向可信交易、领域规则、数据质量和权限治理集中。界面可以被绕过事实来源和责任边界不能被绕过。· 第五评价Agent的核心指标会从“它能不能操作”转向“它能不能稳定完成并证明完成”。验证、恢复、审计和成本会比单次惊艳演示更重要。结语——下一代软件争夺的不是屏幕时间而是可信执行权AI浏览器不会让App突然消失。它更可能先让“打开App、找入口、学操作、搬数据”这些步骤逐渐消失。用户仍然需要应用背后的商品、账户、文档、规则、流程与服务只是不一定还要亲自穿过每一层GUI。它也不会简单淘汰RPA。相反RPA会在Agent体系里找到更清晰的位置把那些已经确定、重复、需要强一致性的执行段稳定跑完Agent则负责理解目标、处理上下文、选择工具、解决例外并决定何时请求人。所以真正的分水岭并不是“浏览器能不能像人一样点鼠标”而是软件能否把能力交付成四个词可调用、可授权、可验证、可恢复。谁先把这四件事做好谁就更可能成为Agent时代真正的基础设施。上一代软件竞争的是“谁拥有用户的屏幕时间”下一代软件竞争的可能是“谁能成为智能体最可信的执行目标”。参考资料[1] Google, Introducing computer use in Gemini 3.5 Flash, 2026-06-24[2] Chrome for Developers, WebMCP, published 2026-05-18, updated 2026-08-07[3] Chrome for Developers, WebMCP tool security, updated 2026-09-01[4] OpenAI Developers, Computer use[5] Microsoft Learn, Overview of Power Automate 2026 release wave 1[6] UiPath Docs, About agents; UiPath RPA product documentation[7] NIST, Lessons Learned from the Consortium: Tool Use in Agent Systems, 2025-08-05[8] NIST CAISI, Insights into AI Agent Security from a Large-Scale Red-Teaming Competition, 2026-03-23[9] NIST, Summary Analysis of Responses to the RFI Regarding Security Considerations for AI Agents, 2026-05-18注本文讨论的是“Agent化浏览器 / Computer Use / 浏览器自动化”这一技术范式不特指某一个品牌或单一产品。产品能力与标准仍在快速演进涉及权限、支付、企业数据等高风险场景时应以实际产品文档和组织安全策略为准。
AI浏览器会取代App吗——从RPA到Computer Use与WebMCP的Agent工作流深度解析
技术观察与工程实践 · 更新至 2026 年 9 月AI浏览器会取代App吗——从RPA到Computer Use与WebMCP的Agent工作流深度解析人工智能AI浏览器AI Agent智能体RPAComputer UseWebMCP浏览器自动化大模型软件架构过去的浏览器负责打开网页RPA负责按流程点击今天的AI浏览器开始理解目标、规划路径、跨站操作并验证结果。当“搜索—比较—填写—提交—确认”都由Agent完成App还是用户入口吗本文从Computer Use、WebMCP、RPA与API演进出发拆解AI浏览器的技术栈、生产可靠性、安全边界和落地场景。结论不是“App消失”或“RPA过时”而是软件入口正从GUI转向“意图工具”RPA成为Agent体系中更确定的执行器。真正决定胜负的是谁能把动作做成可调用、可验证、可授权、可回滚的能力。一句话结论AI浏览器更可能取代“人必须亲手打开每个App并学习它怎么操作”这件事而不是取代App背后的业务系统它也不是更聪明的RPA而是把RPA、API、网页结构化工具和视觉操作统一编排起来的上层智能体。目录1. 当App不再被打开软件入口发生了什么2. 先把AI浏览器定义清楚——它不是“浏览器 聊天框”3. 为什么2026年是关键拐点——Computer Use开始进入主流工具链4. AI浏览器与RPA的本质差异——控制逻辑变了5. 真正的工程分水岭——从“点像素”到“多执行器分层”6. AI浏览器会取代App吗——拆开App的四层再回答7. 哪些场景值得用哪些场景不该用8. 从Demo到生产——幂等、验证、回滚与人工接管9. 安全边界——当不可信网页拥有了可执行权限10. 成本与可靠性——为什么不能让AI把每个按钮都点一遍11. 如何把产品做成Agent-ready12. 一张决策树选出API、WebMCP、RPA还是视觉操作13. 结语——下一代软件争夺的不是屏幕时间而是可信执行权1. 当App不再被打开软件入口发生了什么想象一个非常普通的任务你告诉AI“下周二去上海出差两晚优先高铁酒店离会场三公里内含早餐预算不超过900元把行程写进日历再生成一份可报销的行程单。”过去你要在地图、票务、酒店、日历和企业报销系统之间来回切换。真正花时间的往往不是“做决定”而是搜索、筛选、复制、填写、跳转、核对。如果这些动作全部由浏览器智能体完成你甚至没有亲手打开任何一个App。此时最值得讨论的就不是“浏览器是不是更聪明”而是一个产品层面的结构性变化对用户来说App正在从“必须学习和进入的界面”变成“智能体背后可以调用的能力与状态容器”。这也是为什么“AI浏览器会不会取代App”这个问题容易被问错。App至少包含四样东西交互界面、业务流程、规则与权限、数据与状态。AI最先冲击的是前两者中的“人工导航成本”而后两者恰恰会因为Agent能够代替人执行动作变得更加重要。真正发生的不是“浏览器吞掉所有软件”而是“GUI不再是软件能力的唯一入口”。2. 先把AI浏览器定义清楚——它不是“浏览器 聊天框”今天被统称为“AI浏览器”的产品其实有三种形态。第一种是在传统浏览器里加入侧边栏助手重点仍然是阅读、总结和问答第二种是让Agent拥有一个可操作的浏览器环境能够点击、输入、滚动、下载和跨页面执行任务第三种更进一步把浏览器当成“通用执行端”同时接入API、网页结构化工具、DOM、可访问性树、视觉识别和本地自动化。真正改变软件入口的是后两种。从工程视角看一个能“做事”的AI浏览器至少要维持一个闭环理解目标 → 动态规划 → 感知当前页面 → 选择最合适的工具 → 执行动作 → 验证结果 → 更新记忆。它和脚本最大的不同不是“会不会点按钮”而是路径可以在运行过程中改变。图 1 AI浏览器的核心不是点击而是目标—计划—执行—验证闭环例如“给客户找三家符合条件的供应商并发出询价”并没有唯一操作路径。某个站点可能有搜索API另一个站点只有网页有的网站提供结构化工具有的只能靠DOM有的还会因为登录、验证码或动态组件要求人工接管。一个真正的Agent需要根据当前状态决定“下一步用什么”而不是把所有步骤提前写死。3. 为什么2026年是关键拐点——Computer Use开始进入主流工具链截至2026年9月几个公开信号已经非常明确Computer Use不再只是单独的研究演示正在进入主流模型、浏览器标准和企业自动化平台。重要的不是某一家厂商的产品名而是行业在同时解决三个问题——“AI如何看懂界面”“网页如何主动暴露可调用能力”“企业如何把概率型Agent与确定性自动化放在一起”。时间 / 信号公开进展对AI浏览器意味着什么2026-06Google将computer use作为Gemini 3.5 Flash的内置工具用于浏览器、移动端与桌面环境。[1]“看屏幕—推理—行动”开始从专用模型走向通用模型工具。2026-05 至 09Chrome推进WebMCP目标是让网页向Agent暴露结构化工具安全文档专门讨论恶意工具描述与被污染输出。[2][3]网页不必永远让Agent猜按钮可以直接给出机器可理解的动作语义。持续更新OpenAI的computer use文档同时支持代码执行、结构化鼠标键盘动作以及既有function calling / MCP类接口。[4]同一个Agent可以按任务选择“调用工具”或“操作界面”。2026上半年Microsoft Power Automate把AI Agent、自愈桌面流与RPA协同列为重点并强调Agent可调用桌面流执行精确步骤。[5]企业自动化并没有抛弃RPA而是在上面增加判断与编排层。2026UiPath公开区分Agent与Robot前者偏概率型、适应型决策后者偏确定性、规则型执行并强调二者组合。[6]“Agent RPA”正在形成新的生产级分工。这些进展共同指向一个很重要的变化浏览器正在从“给人看的页面容器”变成“人和Agent共同使用的行动环境”。与此同时企业自动化也从“流程图驱动执行”转向“目标驱动编排 确定性执行器”。4. AI浏览器与RPA的本质差异——控制逻辑变了AI浏览器和RPA看起来很像因为它们都能点击、输入、复制和提交。但两者的核心控制逻辑不同。RPA通常从流程开始先定义步骤再让机器人重复执行AI浏览器通常从目标开始先理解“要达成什么”再决定走哪条路径。维度传统RPAAI浏览器 / Agent任务入口流程、触发器、结构化参数自然语言目标 上下文 约束执行路径预先编排分支显式运行时规划可改变路线页面理解选择器、坐标、OCR、规则语义理解 DOM/可访问性 视觉异常处理进入预设异常分支重规划、自纠错或请求人工输入类型结构化、规则明确可处理文本、页面、图片等非结构化信息可重复性高适合批量稳定流程受模型与环境影响需要验证闭环成本结构前期配置高单次执行稳定前期接入灵活推理与观察成本更高最佳场景高频、固定、可预测流程长尾、变化大、例外多、跨站任务图 2 RPA与AI浏览器的关系更像“确定性执行器”和“适应型编排器”因此把AI浏览器称为“更聪明的RPA”只说对了一半它确实覆盖了RPA曾经解决的“无API界面自动化”问题但它把任务入口从“固定流程”提升成了“目标与约束”又把执行器从单一路径扩展为多个工具。反过来RPA也不会因为Agent出现就消失。越是高频、稳定、对一致性要求高的步骤越适合交给确定性机器人而不是每次都让大模型重新思考。5. 真正的工程分水岭——从“点像素”到“多执行器分层”很多人第一次看到Computer Use会自然地把“像人一样看屏幕和点鼠标”当作终极形态。工程上恰好相反视觉操作越通用通常也越慢、越贵、越容易受界面变化影响。一个成熟Agent不应该为了证明自己会看图就坚持把所有任务都降级成鼠标点击。图 3 生产级执行栈应优先选择结构化、高可靠接口视觉操作用于长尾兜底更合理的执行优先级通常是· 第一优先业务API。参数明确、错误码明确、状态可查询最容易做幂等、审计和回滚。· 第二优先网页结构化工具。类似WebMCP的方向让站点主动告诉Agent“有哪些动作、参数是什么、返回什么”减少对页面布局的猜测。[2]· 第三优先DOM与可访问性树。仍然依赖页面结构但比纯视觉点击更精确也更容易定位控件。· 第四优先视觉Computer Use。它是“任何界面都能尝试”的通用后备方案特别适合没有API、结构复杂或动态变化的长尾网站。· 最后一层人工接管。验证码、强身份验证、不可逆高风险动作和状态不明确时应主动交还控制权。这里有一个容易被忽略的判断真正强的AI浏览器未必是“视觉点按次数最多”的那个而是“能在最少的不确定步骤里完成任务”的那个。6. AI浏览器会取代App吗——拆开App的四层再回答图 4 App并不是一个界面而是界面、流程、规则和数据四层能力的组合如果把App看成一个整体很容易得到“会取代 / 不会取代”的二元答案。把它拆成四层后结论会清晰很多。App层级核心价值AI浏览器的影响未来变化交互界面让人理解功能并完成操作影响最大部分操作从“人找菜单”变为“Agent直接调用动作”GUI更偏审核、探索和例外处理。业务流程把多个动作组织成交易或协作中到高流程逐步暴露为可组合工具Agent负责跨系统编排。规则与权限价格、风控、额度、角色、合规影响有限但重要性上升规则必须机器可判定权限需要细粒度作用域与确认。数据与状态订单、库存、客户、文档、账户不会被浏览器替代继续作为事实来源且必须提供可靠状态查询和审计能力。所以更准确的说法是AI浏览器会削弱“App必须占据用户屏幕时间才能创造价值”这一前提但不会削弱业务系统本身。恰恰相反当更多动作由Agent发起系统的规则、权限、状态机和可验证接口会变得更加重要。对消费软件来说用户可能越来越少记得“这个功能藏在哪个页面”对企业软件来说员工可能越来越少在十几个后台之间搬运字段。但订单、合同、库存、审批、权限、审计这些系统能力依然存在只是入口从“人点击GUI”转向“Agent调用能力”。7. 哪些场景值得用哪些场景不该用AI浏览器的价值并不与“任务复杂度”简单正相关。更有用的两个变量是路径变化程度以及出错代价。页面变化大、规则无法完全预先枚举但错误可发现、可回退的任务是当前Agent最有价值的区域。图 5 任务变化程度与出错代价共同决定自动化方式7.1 信息型任务——最适合快速规模化例如收集十家供应商的公开报价、从多个官网核对产品参数、整理会议日程、把公开网页中的结构化信息填入表格。这类任务的共同特点是“读多写少”即使某个页面理解错了也能通过交叉验证或人工抽查发现。它非常适合作为AI浏览器的第一批生产场景。7.2 遗留系统——Agent与RPA的组合价值最高老ERP、虚拟桌面、Citrix应用或没有API的内部系统本来就是RPA最擅长的地盘。Agent的增量价值不是把机器人删掉而是处理那些过去很难提前写完规则的异常输入格式不一致、页面提示变化、需要从文档中理解上下文、某个分支临时改走另一条流程。此时可以让Agent做判断再调用稳定的RPA片段执行。7.3 高风险交易——必须“先预览再提交再验证”付款、删除数据、发送外部邮件、修改权限、购买商品、提交法律或财务材料都不适合用“看起来成功了”作为完成标准。高风险任务的正确设计不是完全禁止自动化而是把自动化拆成三个阶段先生成可检查的预览得到明确授权后执行再通过服务端状态确认结果。8. 从Demo到生产——幂等、验证、回滚与人工接管浏览器Agent在演示中最吸引人的往往是“它真的点进去了”。但生产环境的核心问题完全不同如果提交请求后页面卡住Agent到底应该重试还是已经成功但没有刷新如果重复点击“支付”会不会下两次单如果下载按钮没有响应文件到底生成了还是没生成图 6 生产级Agent需要把“成功”定义成可验证状态而不是视觉上的“好像完成了”这套闭环里有五个工程点尤其关键。· 幂等性同一个业务意图应该有稳定的幂等键。网络超时或页面无响应时重试不能造成重复扣款、重复创建记录。· 前置条件执行前确认登录态、权限、目标对象、金额、版本、库存或表单关键字段避免“正确地执行了错误对象”。· 服务端验证重要动作完成后用订单号、状态接口、列表记录或后端查询确认不把“页面出现绿色提示”当成唯一证据。· 可回滚优先使用草稿、预览、临时状态、撤销操作把不可逆动作放到流程末端并设置明确确认点。· 人工接管当状态未知、页面出现异常安全提示、目标与约束冲突时不要让Agent无限尝试。一个最小的生产级执行器可以把核心逻辑写成下面这样的伪代码。重点不是语法而是“每个动作之后都要能证明发生了什么”。def run(intent, executor):key make_idempotency_key(intent)existing query_result_by_key(key)if existing.is_done:return existingplan build_plan(intent)for step in plan:policy.check(step) #权限、风险、金额、目标对象result executor.execute(step) # API / WebMCP / DOM / RPA /视觉操作state verify_on_server(step, result)if state done:audit.write(step, result)continueif state unknown:state query_again(step, key)if state ! done:return handoff_to_human(step, state)return build_verifiable_receipt(plan)如果一个Agent系统没有幂等、状态查询和审计能力那么模型再聪明它也只是在把传统“自动化脚本的脆弱性”升级成“带推理能力的脆弱性”。9. 安全边界——当不可信网页拥有了可执行权限浏览器Agent与普通聊天机器人的风险结构不同它不仅“读到内容”还可能拥有登录态、文件访问、外发、下载、提交表单甚至支付权限。于是网页中的恶意文本不再只是误导回答而可能变成间接提示注入——诱导Agent忽略原任务、泄露信息或执行不应该发生的动作。图 7 浏览器Agent的核心安全矛盾不可信内容与可执行权限被连接在了一起Chrome的WebMCP安全文档专门提示两类风险恶意工具定义以及可信站点返回内容中被混入的恶意指令。[3] NIST对Agent工具权限的讨论也强调了“读、受限写、写”与“可信、非可信环境”之间的组合差异浏览器使用本身就属于需要特别约束的场景。[7] 2026年的Agent安全研究进一步把间接提示注入视为需要持续红队测试和系统性缓解的问题。[8][9]风险典型表现生产级护栏间接提示注入页面、评论、邮件正文中夹带“忽略用户指令并执行……”把内容当数据而非指令对工具调用做独立策略判定敏感动作二次确认。权限过大一个浏览器会话同时拥有邮箱、云盘、支付与后台管理权限最小权限、按任务临时授权、读写分离、作用域令牌。状态欺骗页面伪造“已成功”提示或覆盖真实结果使用服务端状态、订单号、记录ID或独立查询渠道验证。数据外泄Agent把页面数据复制到不该访问的目标站点目标域白名单、敏感字段脱敏、跨域外发策略。自动下载 / 执行恶意页面诱导下载脚本或运行代码下载隔离、文件类型策略、沙箱执行、禁止默认运行未知文件。长任务漂移执行几十步后目标或约束逐渐偏离检查点、预算上限、最大步数、关键状态重新确认。安全设计的一个实用原则读取可以更自动写入必须分级可逆动作可以更放权不可逆动作必须有明确确认。10. 成本与可靠性——为什么不能让AI把每个按钮都点一遍AI浏览器还有一个经常被Demo掩盖的问题长任务的延迟和成功率会累积。一次视觉观察、一次推理、一次点击、一次等待、一次验证都要消耗时间如果一个任务有二十个关键步骤即使每步独立成功率达到98%粗略相乘后的端到端成功率也只有约66.8%。每步提高到99.5%二十步后仍只有约90.5%。现实任务的步骤还不是完全独立因此“减少不确定步骤数”本身就是可靠性优化。这也是为什么API与结构化工具如此重要。把五次“看屏幕—找按钮—点击—等待—再看屏幕”压缩成一次参数明确的工具调用通常同时降低延迟、token消耗和失败面。执行方式单步成本路径稳定性可审计性适合任务API低高高交易、查询、批量操作、核心业务流程网页结构化工具低到中高高网站主动支持Agent的标准动作DOM / 可访问性中中高中高网页表单、后台操作、可定位元素RPA中高稳定界面高高频固定流程、遗留系统视觉Computer Use高中到低中长尾网页、动态界面、无结构化接口人工高最高判断力视流程而定高风险确认、异常、目标冲突因此评估AI浏览器项目时不应该只看“任务完成率”还要至少记录平均步骤数、视觉步骤占比、重规划次数、人工接管率、端到端时延、单任务成本、重复写入率、状态未知率以及失败后恢复时间。真正成熟的系统会不断把高频视觉路径“下沉”为结构化工具或确定性自动化。11. 如何把产品做成Agent-ready过去网页主要为人设计按钮文案要好懂视觉层级要清晰表单要少填。Agent时代并不会让这些原则失效但会多出一套“机器可操作性”要求。产品如果希望被智能体稳定调用可以优先补齐下面八项。14. 稳定的业务动作接口把“创建订单、查询状态、提交工单、生成报表”等能力做成显式动作而不是只能通过页面路径触发。15. 机器可读的参数与错误明确必填字段、枚举值、权限要求、可重试错误和不可重试错误不要只返回一段模糊提示。16. 预览 / 提交分离复杂或高风险操作先返回diff、价格、影响范围再由用户或策略明确确认。17. 幂等与请求ID同一业务意图重复发送时不重复生效并能通过请求ID查询最终状态。18. 细粒度权限把读取、草稿、提交、删除、外发、支付等权限拆开不要只提供“全有或全无”。19. 完整审计轨迹记录谁授权、Agent调用了什么工具、参数是什么、返回了什么、何时人工接管。20. 语义化页面即使没有专用API也尽量保持可访问性树、表单语义、稳定标识和清晰状态。21. 失败后的恢复入口允许Agent安全查询状态、撤销、继续或转人工而不是失败后只能“从头再来”。图 8 更可能出现的形态是“个人智能体 多执行器 既有业务系统”对产品经理来说这会改变一个长期默认前提过去每个功能都必须争夺入口、导航位置和用户注意力未来一部分功能的主要“用户”可能先是Agent。对开发者来说前端仍然重要但“是否能被可靠调用、验证和授权”会成为和UI体验同等重要的产品能力。12. 一张决策树选出API、WebMCP、RPA还是视觉操作如果团队今天就要做浏览器Agent不必从“选哪个大模型”开始。先从执行方式做减法有稳定API就不要点页面有结构化网页工具或可靠DOM就不要上视觉界面稳定且任务高频重复就交给RPA只有长尾、动态、无接口的部分再使用视觉Computer Use。任何高风险动作都独立经过权限和确认策略。图 9 自动化执行方式的实用决策树这张图背后的原则可以压缩成一句话能让系统说清楚就不要让模型猜能让工具一次完成就不要让Agent分十步点击。13. 接下来真正值得关注的五个变化下面不是“某个产品一定会发生什么”的断言而是基于当前技术路线更值得关注的方向。· 第一浏览器会更像通用行动层。它的优势不是拥有全部业务而是天然连接大量网页、登录态与用户上下文适合成为跨站编排端。· 第二网页会出现越来越多“给Agent看的接口”。WebMCP所代表的结构化工具思路本质上是在给网站增加一套机器可理解的交互语义。[2]· 第三RPA会从“自动化的主角”变成“Agent的确定性执行器”。判断与异常交给Agent高频固定路径交给Robot是更经济也更可控的分工。[5][6]· 第四App的价值会进一步向可信交易、领域规则、数据质量和权限治理集中。界面可以被绕过事实来源和责任边界不能被绕过。· 第五评价Agent的核心指标会从“它能不能操作”转向“它能不能稳定完成并证明完成”。验证、恢复、审计和成本会比单次惊艳演示更重要。结语——下一代软件争夺的不是屏幕时间而是可信执行权AI浏览器不会让App突然消失。它更可能先让“打开App、找入口、学操作、搬数据”这些步骤逐渐消失。用户仍然需要应用背后的商品、账户、文档、规则、流程与服务只是不一定还要亲自穿过每一层GUI。它也不会简单淘汰RPA。相反RPA会在Agent体系里找到更清晰的位置把那些已经确定、重复、需要强一致性的执行段稳定跑完Agent则负责理解目标、处理上下文、选择工具、解决例外并决定何时请求人。所以真正的分水岭并不是“浏览器能不能像人一样点鼠标”而是软件能否把能力交付成四个词可调用、可授权、可验证、可恢复。谁先把这四件事做好谁就更可能成为Agent时代真正的基础设施。上一代软件竞争的是“谁拥有用户的屏幕时间”下一代软件竞争的可能是“谁能成为智能体最可信的执行目标”。参考资料[1] Google, Introducing computer use in Gemini 3.5 Flash, 2026-06-24[2] Chrome for Developers, WebMCP, published 2026-05-18, updated 2026-08-07[3] Chrome for Developers, WebMCP tool security, updated 2026-09-01[4] OpenAI Developers, Computer use[5] Microsoft Learn, Overview of Power Automate 2026 release wave 1[6] UiPath Docs, About agents; UiPath RPA product documentation[7] NIST, Lessons Learned from the Consortium: Tool Use in Agent Systems, 2025-08-05[8] NIST CAISI, Insights into AI Agent Security from a Large-Scale Red-Teaming Competition, 2026-03-23[9] NIST, Summary Analysis of Responses to the RFI Regarding Security Considerations for AI Agents, 2026-05-18注本文讨论的是“Agent化浏览器 / Computer Use / 浏览器自动化”这一技术范式不特指某一个品牌或单一产品。产品能力与标准仍在快速演进涉及权限、支付、企业数据等高风险场景时应以实际产品文档和组织安全策略为准。