★ FEATURED ARTICLE AI浏览器会不会取代App这个话题最近被问爆了。几乎每次聊到RPA、Computer Use、WebMCP和Agent这些关键词总有人抛出一句那以后App还要不要做了作为从RPA时代一路摸到Agent工作流的人我的看法是这不是一个App存亡的问题而是整个自动化范式正在换代的问题。这篇内容我把自己从影刀RPA实战、Codex Computer Use加Chrome的组合玩法到WebMCP协议层的理解再到Agent框架与编排的落地经验完整拆一遍。适合正在做RPA、想转Agent开发、或者单纯被AI浏览器概念搞到焦虑的工程师和产品经理读完可以自己对“取代”这件事下判断而不是被热搜带着走。1. 争议源头AI浏览器凭什么和App站在对立面1.1 所谓的AI浏览器不只是一个带对话框的浏览器先说清楚AI浏览器是什么。市面上的AI浏览器大体分成两类一类是把LLM对话能力直接嵌进浏览器帮你总结网页、翻译、问答另一类更激进它不只是“帮你读网页”而是能“替你操作网页”——模拟鼠标点击、填表、翻阅、提取数据甚至跨站点完成一条完整业务链路。真正引发“取代App”恐慌的是后者。这类浏览器的技术底座不复杂但工程细节非常难。它要实时理解页面的DOM结构或截图视觉信息把用户的目标拆解成一步步的浏览动作然后在无头浏览器或真实浏览器里执行。听起来像RPA确实像但它和传统RPA有个本质区别RPA靠录制好的规则驱动AI浏览器靠模型对页面理解和推理来驱动。规则只能处理写死的场景推理能应对突发状况。现在大家把这个能力叫Computer UseOpenAI也好、Anthropic也好给模型开放了“用电脑”的接口让它能看屏幕、点鼠标、敲键盘。各家Agent产品也把它当作杀手锏。而一个始终在剧情核心的配套方案是让网页主动向Agent暴露自己的“能力清单”这就要提到WebMCP。等于说AI浏览器想同时拥有两条腿一条模拟人的视觉和手一条让Web服务直接对Agent开口说话。1.2 App围墙花园与开放Web的路线之争为什么话题会上升到App的存亡因为App和Web代表了两种完全不同的服务分发模式。App是围墙花园数据封闭、交互固定、更新由厂商控制Web是开放场地链接直达、爬虫可读、页面随时可改。过去十几年移动互联网几乎把重心全部押在App上大量服务只能在应用商店下载后使用这给自动化带来了巨大阻碍——API不开放、页面不在浏览器里、自动化工具够不着数据。RPA为什么一度在企业里很火就是因为企业发现大量关键业务跑在老旧系统和桌面应用里拿不到API只有靠UI自动化去“装作人在操作”。AI浏览器想打一场翻身仗本质逻辑是既然模型已经能理解UI那我干脆把所有服务都当作能通过浏览器访问的页面来处理。你不需要给我App不需要给我API给我一个URL我就能干活。这个思路确实动人但绕过了一个现实很多重度服务的体验和计算发生在App本地浏览器根本加载不全。所以AI浏览器能不能取代App目前看不是技术问题而是服务和数据的可达性问题。这也是WebMCP这类协议能引起热议的真正原因——它想从源头改变Web服务的表达方式让Agent天生就可调用。1.3 争夺的是工作流入口不是流量入口过去浏览器争的是流量入口前缀要最大、导航要最快、搜索要最全。AI浏览器要争的却是工作流入口用户发起一个目标从哪个界面开始中间经过哪些工具和数据最后在哪里交付结果。谁抢到这个入口谁就定义了用户和数字世界的交互方式。从这个视角看App并没有输但它变成了整个工作流里的一个“资源节点”。工作流的编排跑在Agent层浏览器只是个承载工具集的外壳。我之前做RPA项目时经历过典型的局面客户的核心业务跑在微信小程序里外部自动化根本进不去最后只能用iOS的辅助功能来碰运气。类似问题在Agent工作流里一样存在。所以“取代”这个词太绝对了。更准确的说法是Agent工作流正在重新分配各端的角色App依然是数据和生产工具但“指挥权”正在向Agent和浏览器端迁移。判断是不是要押注这个方向核心看一点你的服务是否愿意向Agent暴露可编程的入口。愿意你就能接住这波红利不愿意你的App再好看也只会成为Agent绕开的那堵墙。2. 演进路线从RPA到Computer Use的范式跳跃2.1 RPA的黄金十年与影刀实践教训聊Agent工作流绕不开RPA。过去十年RPA在企业自动化里立下了汗马功劳。像影刀RPA、UIPath、按键精灵这类工具把“写脚本操作软件”的门槛拉到极低业务人员拖拽组件就能完成数据搬运、表单回填、网页采集。我做影刀RPA时最常被新人问的一个问题是怎么把列表中的[]去掉。这个看似基础的问题其实暴露了RPA开发的痛点。影刀取网页元素时返回的往往是一个列表对象直接填到Excel或文本框系统会原样输出[张三, 李四]而不是张三李四。解决办法通常是先用“文本处理”组件做一次连接操作把分隔符设成空字符串或者用正则去头尾。这类问题看着小却是RPA工程和Agent工程共同的核心议题数据在传递过程中格式和类型的丢失与重塑。RPA给我的最大教训是“规则脆”。录制好的流程页面一改版就崩元素一换选择器就失效。团队得不断地修脚本、补选择器、做异常兜底。维护成本高到客户怀疑人生。但这几年做下来我也积累了一套实战方法论能用结构化数据接口就不碰UI能走DOM定位就不走坐标关键步骤必须有截图留痕异常分支宁可多写几条也不放过。这套方法论用到现在做Agent工作流上依然完全成立。2.2 Computer Use为什么能打破RPA的天花板RPA解决的是“规则确定、步骤固定”的场景它没有能力处理没见过的情况。Computer Use则完全不同。它让模型直接看到屏幕截图根据用户的目标动态生成下一步操作。这个“动态”二字就是范式跳变的关键。我用过Codex Computer Use搭配Chrome做测试目标是让它从某个后台系统下载订单并在本地表格里汇总。传统RPA干这活需要我先录一遍流程、设定各种元素锚点Computer Use不用只要告诉它目标它会自己打开浏览器、找到页面元素、点击下载按钮、再把文件移动到目标目录。中间遇到弹窗它会自己关掉并继续。这种体验非常震撼但也非常烧钱。为什么烧钱因为模型每看一帧截图、每点击一次都在消耗token。一套复杂任务可能要几十上百次交互成本比RPA高出几个数量级。另一个硬伤是准确率模型偶尔点错位置、选错按钮尤其在深色模式、动态渲染、懒加载页面里错误率会显著上升。为了压成本需要缓存截图分析结果、合并连续动作、用CSS选择器优先替代纯视觉定位。2.3 从模拟操作到声明意图WebMCP的价值凸显Computer Use虽然聪明但它本质上还是在“模拟人”。模拟人意味着要和浏览器渲染结果死磕要处理各种JS动态加载、图片懒加载、弹窗遮挡。有没有可能让Agent不走视觉那条路直接拿到页面底层的“能力接口”这就是WebMCP想回答的问题。WebMCP可以理解成Web服务给Agent递交的一份“说明书”把页面上可执行的操作、可提取的数据、可触发的流程用结构化方式写出来Agent拿到这份说明直接调用能力不再需要逐像素地“看”页面。类比一下你到一家餐厅吃饭可以盯着菜单猜菜品样式也可以直接让服务员推荐并下单。Computer Use是前者参考菜单自己猜WebMCP是后者服务员直接把菜端上来。但WebMCP的普及有一个绕不开的挑战网站方是否愿意主动适配。主动暴露能力清单等于把自己的业务规则交给第三方Agent很多企业会紧张。所以短期来看Computer Use是Agent工作流的主要落地方式WebMCP是增量优化方案。我做Agent选型时基本策略是两条腿走路能走WebMCP就优先走页面不支持时才退回视觉点击。耗时和成本大约能差出40%很值得用脚投票。3. Agent工作流的核心架构拆解编排、工具、记忆与安全3.1 再聊“Agent是什么”以及两个常被混淆的词被问得最多的问题是“Agent到底是个啥”。我的理解Agent是一个能感知环境、做出决策、调用工具、执行行动、并从结果中学习的自动化实体。比起传统程序“输入→处理→输出”Agent多了一个循环观察→思考→行动→反思。这个循环让它可以处理开放性问题。还有个高频问题Harness和Agent有什么区别。简单说Harness是运行Agent的“骨架容器”提供生命周期管理、上下文注入、工具调用规范等基础设施Agent本身是业务实体负责决策。比如Spring AI Agent里Harness负责把用户请求包装成任务上下文驱动模型循环调用工具直到满足终止条件。很多所谓“Agent框架”核心就是一套Harness实现。理解了这个区别看代码时就不会乱。我用ADK的Kotlin快速上手版跑通过一个Agent体会特别深。它把Agent定义成一个带有工具列表的单元然后通过Runner来调度。开发者不需要关心模型循环细节只要配置好系统提示词、工具注册表、终止条件。这大幅降低了入门门槛但对生产级场景序列化、重试、状态恢复都要自己补。3.2 工具系统与Agent SkillAgent的双手和招数Agent再聪明没有工具也寸步难行。工具系统是Agent工作流里最贴近工程的部分。按照Claude Agent Skills的范式一个Skill就是一份指令加一组脚本告诉Agent“遇到这类任务时按这个方式处理”。例如我做过一个“将网页保存成Markdown的Skill”它会引导Agent识别页面主内容、过滤导航和广告、调用HTML转Markdown工具最后保存到本地仓库。这个设计思路很像我以前写RPA组件。RPA组件是预定义的动作单元Agent Skill则是带上下文的动作模板。区别在于Skill可以嵌入自然语言描述让模型决定何时调用而不是写死触发条件。这种灵活性让Agent可以处理未预见的输入。工具注册还有一个细节要给模型提供准确的函数描述和参数模式否则模型会反复生成错误的调用。Function Calling的失败往往不是模型笨而是描述信息写得太差。我做过一个统计在100次工具调用里参数描述里加上枚举值与边界说明后成功调用率从68%提升到91%。这个数据很说明问题工具系统看似简单49%的功劳藏在描述里。3.3 记忆是怎么影响Agent效果的Agent记忆可能是最被低估的模块。没有记忆Agent就是每轮对话都重新读剧本的演员永远记不住上一幕发生了什么。记忆按层级分为会话记忆、工作记忆、长期记忆。会话记忆是上下文窗口内的信息工作记忆是当前任务的关键中间量长期记忆则依赖外部存储。比如Hermes Agent配合Obsidian做知识库是我目前觉得最舒服的知识管理方案。让Agent把网页保存成Markdown写入Obsidian仓库再通过向量化把这批Markdown纳入长期记忆下次提问时就能检索到历史结论。整个链路解决了Agent“读过书但转身就忘”的问题。实现记忆有几个坑。第一是上下文膨胀把几百条历史一股脑塞给模型既费token又干扰注意力应该有取舍地压缩和筛选。第二是记忆污染错误信息一旦写入长期记忆会持续影响后续决策需要设计置信度或人工确认机制。第三是隐私敏感数据进记忆前要做好脱敏分级。3.4 高并发与Agent安全生产环境的生死线Agent跑通Demo容易上线扛并发是另一回事。AI Agent怎么扛并发核心思路是异步化和池化。把长耗时的工具调用异步化模型推理单独排队任务状态存Redis进程崩溃后可恢复。不能像写普通接口那样一个请求同步跑完整个Agent循环否则十个请求就能拖垮服务。框架层面可以借鉴Harness的调度策略把工具调用放到独立的Worker里用消息队列解耦。我用Rust写过高性能Agent进程Rust在内存安全和并发上优势明显但开发效率比不上Python。生产环境更常见的是Python主控加Rust工具服务两者混合。Agent安全更得重视。工具调用权限必须最小化Agent能执行的命令、能访问的数据都要有边界。常见手段是VPC隔离、容器化沙箱、命令白名单、敏感输出的拦截。我给Agent设计权限时有一条铁律Agent能做的事必须是人明确授权的事。它可以用浏览器插件“浏览”页面但不能悄悄上传文件它能读工作目录的数据但碰到用户目录就停。4. 实操环节从零搭建一条Agent工作流4.1 一个具体需求把网页资料自动归档进知识库为了把前面的原理串起来我设计了一个完整的实操让Agent根据用户输入的主题词主动去搜索网页提取主内容清洗成Markdown归档到Obsidian知识库。这是“网页保存成Markdown的Skill”的升级版涵盖了感知、决策、工具、记忆四大模块。技术选型上我用的是Chrome加Computer Use模式做页面操作用Hermes Agent做任务编排老牌RPA影刀负责那些需要稳定录制的环节比如登录、翻页、批量下载三者配合。选这套组合的原因很现实Comupter Use灵活但贵RPA稳定但僵人为编排把两者优势叠起来取长补短。4.2 核心流程分步拆解与参数设置第一步定义目标输入。用JSON Schema约束主题词、搜索页数、是否包含图片等参数。第二步编排Action序列Agent先发起搜索打开搜索结果前几页提取候选链接。第三步调用“网页转Markdown”Skill用HTML解析库去除script、style、nav等噪音节点提取article主体。第四步写入Obsidian库生成带frontmatter的Markdown文件frontmatter里写入来源URL、抓取时间、关键词。第五步触发记忆更新把这些新文档切块向量化入库。每一步都有参数讲究。比如提取主内容时不是简单取article标签因为很多站点的article不标准需要启发式规则统计文本密度、链接密度找到正文区域。我运行一次抓取任务大概消耗20个步骤这在纯Computer Use里算低消耗了因为网页转Markdown的Skill避开了大量逐字阅读页面的token开销。4.3 为什么保留RPA而不是全面转向AI这个架构里影刀RPA负责登录、翻页、批量下载这些操作高频、稳定、要求零失误。Computer Use负责处理异形页面、动态修改的DOM以及需要推理的环节。这个搭配很关键它解决了一个成本问题让RPA处理确定性动作让AI处理不确定性推理整体成本能砍掉一大半。RPA和AI这不是替代关系而是分工关系。以后Agent工作流的成熟形态大概率是“RPA做肌肉记忆Computer Use做临场反应WebMCP做直通对话”。三种技术栈各有擅长区间谁也别想完全吃掉谁。5. 问题排查与实战避坑那些文档没写明的事5.1 高频报错Agent Execution Terminated Due to Error这个错误翻译过来是“Agent执行因错误终止”新手看到就头皮发麻。我排查这类问题的顺序是固定的先看日志终止前的最后一条工具调用再确认错误类型。如果是工具返回异常大概率是参数模式没匹配回查工具描述如果是模型生成了非法JSON多数是上下文太长把模型绕晕了减少输入长度或重启一轮。还有一次我排查了一下午结果发现是工具函数抛出的异常信息没有被序列化Harness捕获不到具体错误只能返回终止信号。解决方式是在工具入口统一包一层异常拦截把错误转换成结构化输出。这个坑之所以隐蔽是因为问题不在调用逻辑在于序列化边界。5.2 表格速查Agent开发高频问题的归因与解法问题现象常见归因快速解法Agent重复调用同一个工具上下文没有记录已执行状态引入步骤状态追踪跳过已完成调用工具返回的数据带了[]或引号列表转字符串未处理显式指定分隔符空字符串直接join同一个任务有时成有时败页面元素动态加载增加等待策略优先DOM选择器定位高并发下任务互相污染共享变量/共享会话状态任务级隔离用Redis按task_id分KeyAgent产生“幻觉式操作”上下文不足或提示词模糊补充系统级约束和边界规则输出内容突然截断超过输出token上限任务拆分、数据分批返回5.3 关于Token消耗的优化实战我实测过一个典型任务用Computer Use下载十张报表并归档。默认方式跑了约12万token成本感人。优化后缩到3万token核心手段有三招。第一招把连续滚动和点击动作合并成一条指令让模型一次决策、一次执行第二招禁用非必要截图只对关键页面做视觉分析第三招能用WebMCP或结构化API的页面绝不走视觉路径。Token优化的本质不是省钱是减少延迟。Agent跑一个流程每轮推理2到5秒几十轮下来就是几分钟用户根本等不了。把轮次压缩到5轮内体验才算勉强可用。所以现在的Agent产品拼的不是谁的模型更聪明而是谁的编排更克制。6. 我的判断与选择AI浏览器到底会不会取代App我不觉得AI浏览器会像大家想象的那样“取代”App。更靠谱的说法是它正在成为一种新的“前台”把各类服务重新编排一遍。App依然生产内容、保存数据、执行重型计算但用户发起意图的第一入口会越来越多地落到AI浏览器和Agent工作流。对开发者来说与其纠结“要不要做App”不如问一句我的服务准备好被Agent理解和调用了吗被Agent调用意味着需要更规范的页面结构、更开放的接口、甚至WebMCP式的能力声明。那些早期就把自己改造成“Agent友好型”的服务会在这波工作流变革里吃到巨大红利。那些继续做封闭围墙的也不会立刻死掉但会看着用户一步一步绕开它。最后分享一个我自己的体会RPA时代我靠的是录制和选择器的熟练Computer Use时代我靠的是提示词和工具编排的精细到了WebMCP时代拼的会是数据建模和对业务本质的理解。工具在变但自动化底层那套“把流程拆解成步骤、把步骤沉淀成资产”的方法论从来没有变过。想做Agent的人先把这套基本功练扎实比你追一千个热搜都强。
阅读完成 · 觉得有帮助？
