★ FEATURED ARTICLE AI浏览器会取代App吗这个问题我最近被问了很多次。不是客套式的好奇而是实打实的决策焦虑RPA项目做着做着老板说“AI都这样了直接上Agent吧”App团队刚做完三年规划转头看到Computer Use在浏览器里握住鼠标开始怀疑自己到底在给谁修护城河。我理解这种焦虑。过去几年我一直在带RPA落地从UiPath到影刀流程跑通上百条。到了2024年下半年局面已经有了明显分岔Computer Use让模型能够直接操作界面WebMCP这类协议又在把网页交互语义结构化地暴露给Agent。从RPA到Computer Use再到WebMCP不是三条孤立的新词而是同一根“流程自动化”主轴上的三段式演化。这篇文章我打算把这条线完整串起来结合自己的落地踩坑拆清楚每一层到底解决了什么问题、带来了什么新麻烦、又该如何组合使用。权当给还在纠结“要不要转型”“要不要砍App”的同行一份工程视角的参考。1. 为什么“AI浏览器会取代App”成了一个真问题1.1 从“人操作”到“模型直接操作”的执行路径转移传统App之所以“无法替代”关键问题不在于交互体验而在于入口和数据的封闭。账号体系、支付通道、业务数据全锁在App里外部系统想接入只能走API。可现实里真正麻烦的流程往往恰恰是没有API、只能在界面上一步步点的那些。RPA解决的就是“没有API但界面能跑”的缝隙。它通过选择器锁定界面元素用录制器生成指令序列再靠调度器定时执行。本质上RPA把人的操作路径固化成脚本。这个特点带来两个相反的结果好处是稳定、可复现、审计清晰坏处是脚本一旦固化就失去了感知环境的能力。页面布局改一点选择器失效整条流程就断。我见过太多团队的维护工时最后全消耗在“等某个按钮什么时候出现”这种毫无语义的纠缠上。从RPA向Agent进化核心就是补上“感知和决策”这一层。Computer Use把大模型放在操作者的位置模型看屏幕、输出下一步动作、再循环。它不再走预先录好的固定路径每一步都在“看情况办事”。听起来很理想但真正工程化之后你会发现问题全转移到了“边界控制”“成本控制”“错误恢复”上。好比把一个只走轨道的老实工人换成一个很有想法但会走神的天才——你要优先解决的是怎么管住他而不是他能不能干。1.2 App的壁垒正在被两层机制击穿很多不接触自动化底层的朋友会问App是我做的AI怎么碰得到这两年格局其实已经变了。第一层击穿发生在“浏览器里的App”。现在大量业务系统本身就跑在浏览器中表单、表格、审批流、外部控制台全是网页结构。Computer Use操作的根本不是原生App而是Chromium内核的界面。只要业务形态还在Web上AI就有进入路径。第二层击穿发生在“数据语义层”。光靠截图模拟点击效率和准确率都不稳因为截图是像素不是信息。后来业内开始用MCP协议把网页能力抽象成“工具函数”又发展出更偏Web语义的封装思路。简单说就是让网页主动把自己的“可操作能力”描述给AI看这是一个表单、这是校验规则、这是提交入口。AI不需要猜可以直接按描述调用。这意味着App的信息孤岛正在被边缘化。你不需要去打破App你只是在它外面搭了一个新的操作层把App默默退化成后台能力把浏览器或Agent界面变成新的前台入口。App本身不会消失但“以App为中心设计流程”这件事确实开始松动了。2. 从RPA到Computer Use的关键跳跃2.1 RPA是“流程固化”Computer Use是“模型驱动”工程视角下这两者的差异绝对是第一位的。RPA的每个步骤都是确定性指令点击某个坐标、输入某段文本、断言某处内容中间没有任何概率。这种确定性带来一个巨大红利——出了问题容易定位也带来一个同等巨大的代价——凡是脚本里没有预设的情况它必定卡死。Computer Use则完全反过来。模型每次决策都是概率性的它基于当前截图、DOM结构、历史步骤来生成下一个动作。同一个页面这次走A路径下次可能走B路径。很多人把这当成“不稳定”其实这是它的价值本身它能应对变化。我接手的真实场景里对比非常典型RPA处理异常弹窗脚本未预设直接抛错流程中断Computer Use处理同样弹窗模型判断这可能是异常分支尝试寻找关闭按钮或切换处理逻辑哪怕偶尔判断失误也比彻底中断强得多。所以我跟团队讲架构时常常强调RPA解决的是“能不能执行”Computer Use解决的是“能不能自适应执行”。两者不是替代关系是递进关系。2.2 Computer Use的工程化改造点先泼冷水直接用原生Computer Use跑生产流程目前依然很疼。我遇到三个绕不开的工程坑。第一Token消耗没有上限。一个中长流程几十步每步都要回传截图和DOM片段模型还要输出思考链和动作参数一次完整跑下来token量会大到怀疑人生。我试过一种很土但有效的策略用便宜的小模型先做意图分类把每轮动作限制在几个候选命令里只在真正规划分叉时才调大模型。相当于给模型装了一个节流阀明显把成本压下来了。第二时延不可控。截图合成、OCR、模型推理一个动作周期常常要几秒到十几秒。如果流程拆出100个动作全串行等待接近十分钟。这在RPA时代几乎不存在因为它毫秒级就能完成点击。缓解的办法是分层执行把大流程拆成多个小Agent每个Agent只专注一个阶段按阶段并行运行。第三坐标点击的脆弱性。很多项目还是“截图输出坐标点击”页面一滚动坐标全错可靠性极差。现在更稳的做法是加载可访问性树用元素ID显式定位只有实在找不到定位锚点时才回退到截图坐标。如果你在用浏览器工具库做探索请特意确认它的默认模式是坐标模式还是语义定位模式。这一步检查能帮你少走很多弯路。2.3 WebMCP让Agent真正读懂网页操作WebMCP目前还没有像MCP那样绝对统一的正式标准但它背后的思路我非常认可把网页里的可交互控件以协议方式暴露给Agent而不是让Agent拿着截图去逐像素猜测。用一个生活化类比你去餐厅吃饭。Computer Use模式等于只能对着菜单图片猜菜名、比划手点菜、偶尔还點錯WebMCP模式等于服务员直接把菜谱数据结构给你你可以程序化地告诉后厨“宫保鸡丁不要花生”。效率完全不是一个量级。在工程实现上WebMCP通常包含四部分能力声明网页告诉Agent自己哪些操作可以自动化输入参数Schema每个控件需要什么字段、什么格式动作返回结果操作结束后返回的状态信息和错误码上下文元数据当前路由、登录态、环境变量等让Agent能够判断重试、切换分支或退出。实际改造不需要把整个网站全部WebMCP化。我建议只挑流程里的关键交互页比如登录页、下单页、查询页每页声明两三个核心操作即可其余继续靠截图兜底。这样的改动量最小稳定性提升却最显著。3. Agent工作流的实操架构与落地清单3.1 一个能跑的Agent工作流长什么样我经常纠正一个误区Agent工作流不是ChatGPT多轮对话也不是RPA项目加一个对话框入口。一套完整的Agent工作流至少包含五个环节意图解析层把用户的模糊目标拆解成结构化任务规划层决定任务用什么工具、什么顺序执行执行层实际调用RPA脚本、API、浏览器自动化等能力感知层读回执行结果、页面反馈、异常状态驱动下一步判断记忆与审计层记录每一步推理和执行证据支撑回溯和责任认定。举个实际的例子——“自动查询物流异常并通知客户”客户消息进来意图解析层识别出“异常查询”和“通知”两个子任务规划层决定先登录物流平台再遍历订单列表最后筛选状态字段执行层调用一个RPA脚本完成登录再用一个Computer Use模块处理动态渲染的表格感知层识别到异常订单将订单号和页面截图一并存入记忆层最后通过企业微信或邮件发送通知并生成完整流程报告。你会发现RPA在这个工作流里没有消失它只是变成了执行层的一个稳定工具。大模型只负责“判断”不负责“手抖”。这也是我一贯推荐的混合架构LLM决策 RPA稳定执行 协议层约束。如果想在代码层面快速搭起一个最小骨架可以用类似下面的伪代码结构来组织class SimpleAgent: def __init__(self, planner, executor, perceiver, memory): self.planner planner # 大模型规划 self.executor executor # RPA/浏览器工具 self.perceiver perceiver # 结果解析与验证 self.memory memory # 步骤存档与审计日志 def run(self, user_goal): task self.planner.parse(user_goal) for step in task.steps: result self.executor.execute(step.action, step.params) verified self.perceiver.verify(result) self.memory.append(step, result, verified) if not verified: recover_plan self.planner.decide_recovery(step, result) result self.executor.execute(recover_plan.action, recover_plan.params) return self.memory.build_report()这段代码不复杂但它把职责边界切得很清楚规划层不碰具体点击执行层不碰业务决策。后面的扩展、调试、审计都会舒服很多。3.2 工具选型对比与参数计算直接给出我这边用下来比较顺手的一套组合RPA执行器影刀或UiPath负责高稳定节点操作浏览器自动化层Playwright或直接操作CDPChrome DevTools ProtocolComputer Use本质上是在CDP之上叠加模型决策Agent编排层根据团队语言选型我用过LangChain也用过Spring AI不同规模各有取舍WebMCP语义层把登录、查询、提交这几个关键节点封装成独立协议工具模型侧规划用大模型动作提取用中小模型OCR用专用小模型各干各的不浪费。不同方案的对比可以看这张表维度传统RPAComputer UseWebMCP Agent混合执行稳定性很高脚本即逻辑中低易受页面变化影响高关键节点协议化自适应能力无只能按脚本走强能应对未预知分支中高关键节点稳定 非关键节点自适应成本低纯部署和运维高按token计费中可针对高频节点做降本优化可审计性强步骤日志明确中需要额外快照和日志机制强协议层天然带状态记录改造门槛低中模型功底要求高偏高但一次改造长期受益再说参数计算。给一个可以直接套的经验公式假设流程有N个动作每个动作的input约包含截图编码加DOM描述约8000到15000 tokenoutput约1000到3000 token决策和动作指令。我做过一个中等复杂度的电商对接流程N64个动作单次跑完约消耗1.5万到2万token。如果用的是主流强模型API一次完整流程的成本大概几块钱。相比RPA跑一次的成本这高了一个量级但未必不可接受关键在于“值不值得”。人工处理同样流程要10分钟Agent换算下来只相当于半分钟人工成本长期看仍然是划算的。但如果是高频小任务比如每天几千次重复点击就不能这么蛮干。我的做法是把高频路径直接抽成确定性脚本或内部接口Agent只负责异常和策略引导。这是成本与稳定性的平衡点建议在做技术方案时提前算清楚别等上线了再被账单教育。3.3 用WebMCP把工作流串起来的具体做法拿“登录态保持”这个场景实际讲讲怎么落地。常见痛点是Agent跑长流程中途会话过期弹出登录框如果没有预案整个流程直接报废。传统RPA的解法是写死“每20分钟心跳点击一次”既消耗资源又很脆弱。用WebMCP的思路登录页可以暴露这样几个能力{ capabilities: { check_login_status: {}, refresh_qrcode: {}, submit_credential: { params: { account: string, password: string } } } }Agent每次执行前先调用check_login_status发现过期就调用submit_credential成功后再继续原流程。这样流程就具备了中途恢复能力而不是死板地定时心跳。这个改造量不大但收益极其明显。我建议起步阶段先做三个点的WebMCP化登录态检测、表单提交前校验、分页列表切换。这三处正是Agent最容易失手、RPA脚本又最需要维护的地方投入产出比最高。4. 真实环境踩过的坑与解决方案4.1 流程飘移Agent“做错步骤”的根因Agent再聪明也会做错事。我做过上百次测试后总结出所谓“做错步骤”大多数情况下不是模型变笨而是上下文被污染。典型场景有三类弹窗把表单标题挡住模型误以为页面切换了任务网页里埋着大段推荐文案或广告模型把广告内容当作业务数据提取上一步操作的残留文本留在输入框里模型当作本次输入直接提交。这些问题的共同点是Agent的“感知材料”不够干净。解决方式不是反复调prompt而是在执行层回传数据前加一个清洗层。具体动作包括只保留表单区和主内容区的DOM过滤广告与推荐节点每次开始执行前重置页面状态清空所有输入框对提取结果做schema校验不符合预期就自动重试。我把这个环节称为“感知端降噪”。在实际项目里它比任何提示词工程都管用。4.2 并发与成本用实例说明正确的测试方式关于“Agent怎么扛并发”我收到过很多咨询。我的答案可能让一部分人失望别指望单个Agent天然扛并发真正能扛的是多实例隔离。我们做过一个并发电商价格采集场景。最初我开20个线程每个线程各启动一个Agent实例共用同一个浏览器上下文。结果20个实例疯狂抢DOM页面状态全部错乱采出来的价格数据一片狼藉。改成独立浏览器上下文、独立会话、独立缓存目录之后20个实例稳定运行。我们还按站点拆分Agent实例每个站点独立负责自己的采集任务避免互相干扰。还有一个省钱的小建议并发测试时先别用强模型用一个便宜的小模型把链路跑通测并发稳定性等逻辑验证完再把模型换成强模型跑正式任务。这样能在开发阶段省下大量成本同时也能暴露架构层面的死锁或竞态问题。4.3 安全、审计与权限Agent越权的管控手段AI Agent能操作账号、能操作数据、能操作钱安全问题绝对不能事后弥补。我在生产环境设置了三条防线。第一道是权限隔离。Agent用单独的低权限账号运行不做管理员不绑个人手机不开放支付授权。所有涉及资金变动或对外发送的操作一律二次确认。第二道是工具白名单。Agent能调用的工具必须显式注册没有注册过的能力无论对话里怎么诱导都不允许执行。这里尤其要提防浏览器插件带来的“隐形工具”一些所谓“装了就送自动化能力”的插件经常会在你不注意的时候打开权限后门属于高危项。第三道是审计快照。每一步动作执行前都截屏连同页面状态、排队顺序、调用参数写入日志。养成这个习惯很重要没有证据链的Agent项目出事之后往往比不出事更麻烦因为你连问题出在哪一步都讲不清。三条防线缺一不可。忽略任何一条Agent的能力越大风险就越大我反复和客户讲这句话。这里附上一份实际执行时的安全检查清单可以直接复用Agent账号是否独立且低权限支付/发送类操作是否有二次确认钩子工具清单是否全部经过显式注册浏览器是否运行在独立隔离环境超时和失败重试是否有上限每一步行为是否留有截图和调用日志敏感数据是否脱敏后才传给模型。4.4 常见问题排查速查表把我在群里、工单里被问得最多的问题汇总成一张速查表方便直接对号入座。症状根因解法Agent频繁点击错误元素坐标模式依赖截图页面布局变化导致定位偏移改用可访问性树或元素ID语义定位长流程后半段开始乱执行上下文被弹窗、残留文本污染增加感知端清洗层重置页面状态并发一高数据就乱多实例共用浏览器上下文或会话目录隔离上下文、会话、缓存目录Token烧得飞快小动作也调大模型增加小模型意图路由压缩动作候选集流程总会卡在登录态过期缺少检测登录态的动作节点WebMCP化登录检测与恢复提交出了事故无法复盘缺乏执行快照每步截图并记录页面状态与调用参数页面数据提取不准模型直接解析整屏DOM只保留业务区域DOM用schema校验提取结果某些步骤不稳定不确定的路径用了确定性逻辑高频步骤脚本化异常分支交给模型规划这张表是我自己项目里的OCS操作故障记录演化来的每次遇到新问题就往里补充团队新人也更容易上手。5. 我的判断App不会消失但“以App为中心”的设计正在让位聊完这些技术细节回到最开始的问题。我不认为AI浏览器会“取代App”但它会彻底改变App的存在方式。App会从“用户的第一入口”降级为“能力提供方”。用户看到的交互层会逐步被AI驱动的浏览器或Agent工作流接管。短期内在手机端登录态、推送、支付的体验优势仍会保住原生App的地位但在企业流程自动化和效率场景里App作为数据孤岛的价值会被持续削弱。5.1 判断口径别问要不要做App问能力是否可被访问我在团队里的判断口径是与其争论“App到底做不做”不如问“你的业务数据和业务能力能不能被Agent以标准接口访问”。能访问App就能变成Agent能力的一部分不能访问App就迟早被另一个浏览器层绕过去。特别是对做企业服务的团队现在布局Agent接口越早未来被替代的风险就越低。就像早期做数据化没有赶上的人后面补的代价是几何级数增长的。5.2 给RPA团队的一条转型路径参考如果你现在正带着RPA团队不知道下一步往哪走我的建议是走一条渐进路线先把现有RPA脚本当作“稳定执行器”继续跑在它外面套一层Agent决策壳再用类WebMCP协议把登录、校验、提交这几个高危节点封住。这样做既有执行稳定性又有决策柔性还能在突发故障时快速回退到纯RPA模式。这条路我已经实际跑通过相对最不折腾。团队里原来写RPA的工程师不需要有特别深的模型功底只需要学会跟Agent框架接口对接几个月内就能完成技能升级。而且这类混合型架构在汇报里也特别好讲不是推翻重来而是模块演进老板和业务方都比较容易接受。最后我个人的体会是这个行业真正稀缺的不是既会RPA又懂Agent的人而是愿意把每种工具的边界当作第一原则的人。工具每几个月就迭代一轮但边界认知不会过时。什么时候该相信模型什么时候该把它锁在脚本里什么时候让协议层兜底——这些判断能力才是长期有效的竞争力。
阅读完成 · 觉得有帮助？
