AI瀏覽器會取代App嗎這個問題我最近被問了很多次。不是客套式的好奇而是實打?qū)嵉臎Q策焦慮RPA項目做著做著老板說“AI都這樣了直接上Agent吧”App團隊剛做完三年規(guī)劃轉(zhuǎn)頭看到Computer Use在瀏覽器里握住鼠標開始懷疑自己到底在給誰修護城河。我理解這種焦慮。過去幾年我一直在帶RPA落地從UiPath到影刀流程跑通上百條。到了2024年下半年局面已經(jīng)有了明顯分岔Computer Use讓模型能夠直接操作界面WebMCP這類協(xié)議又在把網(wǎng)頁交互語義結(jié)構(gòu)化地暴露給Agent。從RPA到Computer Use再到WebMCP不是三條孤立的新詞而是同一根“流程自動化”主軸上的三段式演化。這篇文章我打算把這條線完整串起來結(jié)合自己的落地踩坑拆清楚每一層到底解決了什么問題、帶來了什么新麻煩、又該如何組合使用。權(quán)當給還在糾結(jié)“要不要轉(zhuǎn)型”“要不要砍App”的同行一份工程視角的參考。1. 為什么“AI瀏覽器會取代App”成了一個真問題1.1 從“人操作”到“模型直接操作”的執(zhí)行路徑轉(zhuǎn)移傳統(tǒng)App之所以“無法替代”關(guān)鍵問題不在于交互體驗而在于入口和數(shù)據(jù)的封閉。賬號體系、支付通道、業(yè)務(wù)數(shù)據(jù)全鎖在App里外部系統(tǒng)想接入只能走API?？涩F(xiàn)實里真正麻煩的流程往往恰恰是沒有API、只能在界面上一步步點的那些。RPA解決的就是“沒有API但界面能跑”的縫隙。它通過選擇器鎖定界面元素用錄制器生成指令序列再靠調(diào)度器定時執(zhí)行。本質(zhì)上RPA把人的操作路徑固化成腳本。這個特點帶來兩個相反的結(jié)果好處是穩(wěn)定、可復現(xiàn)、審計清晰壞處是腳本一旦固化就失去了感知環(huán)境的能力。頁面布局改一點選擇器失效整條流程就斷。我見過太多團隊的維護工時最后全消耗在“等某個按鈕什么時候出現(xiàn)”這種毫無語義的糾纏上。從RPA向Agent進化核心就是補上“感知和決策”這一層。Computer Use把大模型放在操作者的位置模型看屏幕、輸出下一步動作、再循環(huán)。它不再走預先錄好的固定路徑每一步都在“看情況辦事”。聽起來很理想但真正工程化之后你會發(fā)現(xiàn)問題全轉(zhuǎn)移到了“邊界控制”“成本控制”“錯誤恢復”上。好比把一個只走軌道的老實工人換成一個很有想法但會走神的天才——你要優(yōu)先解決的是怎么管住他而不是他能不能干。1.2 App的壁壘正在被兩層機制擊穿很多不接觸自動化底層的朋友會問App是我做的AI怎么碰得到這兩年格局其實已經(jīng)變了。第一層擊穿發(fā)生在“瀏覽器里的App”?，F(xiàn)在大量業(yè)務(wù)系統(tǒng)本身就跑在瀏覽器中表單、表格、審批流、外部控制臺全是網(wǎng)頁結(jié)構(gòu)。Computer Use操作的根本不是原生App而是Chromium內(nèi)核的界面。只要業(yè)務(wù)形態(tài)還在Web上AI就有進入路徑。第二層擊穿發(fā)生在“數(shù)據(jù)語義層”。光靠截圖模擬點擊效率和準確率都不穩(wěn)因為截圖是像素不是信息。后來業(yè)內(nèi)開始用MCP協(xié)議把網(wǎng)頁能力抽象成“工具函數(shù)”又發(fā)展出更偏Web語義的封裝思路。簡單說就是讓網(wǎng)頁主動把自己的“可操作能力”描述給AI看這是一個表單、這是校驗規(guī)則、這是提交入口。AI不需要猜可以直接按描述調(diào)用。這意味著App的信息孤島正在被邊緣化。你不需要去打破App你只是在它外面搭了一個新的操作層把App默默退化成后臺能力把瀏覽器或Agent界面變成新的前臺入口。App本身不會消失但“以App為中心設(shè)計流程”這件事確實開始松動了。2. 從RPA到Computer Use的關(guān)鍵跳躍2.1 RPA是“流程固化”Computer Use是“模型驅(qū)動”工程視角下這兩者的差異絕對是第一位的。RPA的每個步驟都是確定性指令點擊某個坐標、輸入某段文本、斷言某處內(nèi)容中間沒有任何概率。這種確定性帶來一個巨大紅利——出了問題容易定位也帶來一個同等巨大的代價——凡是腳本里沒有預設(shè)的情況它必定卡死。Computer Use則完全反過來。模型每次決策都是概率性的它基于當前截圖、DOM結(jié)構(gòu)、歷史步驟來生成下一個動作。同一個頁面這次走A路徑下次可能走B路徑。很多人把這當成“不穩(wěn)定”其實這是它的價值本身它能應對變化。我接手的真實場景里對比非常典型RPA處理異常彈窗腳本未預設(shè)直接拋錯流程中斷Computer Use處理同樣彈窗模型判斷這可能是異常分支嘗試尋找關(guān)閉按鈕或切換處理邏輯哪怕偶爾判斷失誤也比徹底中斷強得多。所以我跟團隊講架構(gòu)時常常強調(diào)RPA解決的是“能不能執(zhí)行”Computer Use解決的是“能不能自適應執(zhí)行”。兩者不是替代關(guān)系是遞進關(guān)系。2.2 Computer Use的工程化改造點先潑冷水直接用原生Computer Use跑生產(chǎn)流程目前依然很疼。我遇到三個繞不開的工程坑。第一Token消耗沒有上限。一個中長流程幾十步每步都要回傳截圖和DOM片段模型還要輸出思考鏈和動作參數(shù)一次完整跑下來token量會大到懷疑人生。我試過一種很土但有效的策略用便宜的小模型先做意圖分類把每輪動作限制在幾個候選命令里只在真正規(guī)劃分叉時才調(diào)大模型。相當于給模型裝了一個節(jié)流閥明顯把成本壓下來了。第二時延不可控。截圖合成、OCR、模型推理一個動作周期常常要幾秒到十幾秒。如果流程拆出100個動作全串行等待接近十分鐘。這在RPA時代幾乎不存在因為它毫秒級就能完成點擊。緩解的辦法是分層執(zhí)行把大流程拆成多個小Agent每個Agent只專注一個階段按階段并行運行。第三坐標點擊的脆弱性。很多項目還是“截圖輸出坐標點擊”頁面一滾動坐標全錯可靠性極差。現(xiàn)在更穩(wěn)的做法是加載可訪問性樹用元素ID顯式定位只有實在找不到定位錨點時才回退到截圖坐標。如果你在用瀏覽器工具庫做探索請?zhí)匾獯_認它的默認模式是坐標模式還是語義定位模式。這一步檢查能幫你少走很多彎路。2.3 WebMCP讓Agent真正讀懂網(wǎng)頁操作WebMCP目前還沒有像MCP那樣絕對統(tǒng)一的正式標準但它背后的思路我非常認可把網(wǎng)頁里的可交互控件以協(xié)議方式暴露給Agent而不是讓Agent拿著截圖去逐像素猜測。用一個生活化類比你去餐廳吃飯。Computer Use模式等于只能對著菜單圖片猜菜名、比劃手點菜、偶爾還點錯WebMCP模式等于服務(wù)員直接把菜譜數(shù)據(jù)結(jié)構(gòu)給你你可以程序化地告訴后廚“宮保雞丁不要花生”。效率完全不是一個量級。在工程實現(xiàn)上WebMCP通常包含四部分能力聲明網(wǎng)頁告訴Agent自己哪些操作可以自動化輸入?yún)?shù)Schema每個控件需要什么字段、什么格式動作返回結(jié)果操作結(jié)束后返回的狀態(tài)信息和錯誤碼上下文元數(shù)據(jù)當前路由、登錄態(tài)、環(huán)境變量等讓Agent能夠判斷重試、切換分支或退出。實際改造不需要把整個網(wǎng)站全部WebMCP化。我建議只挑流程里的關(guān)鍵交互頁比如登錄頁、下單頁、查詢頁每頁聲明兩三個核心操作即可其余繼續(xù)靠截圖兜底。這樣的改動量最小穩(wěn)定性提升卻最顯著。3. Agent工作流的實操架構(gòu)與落地清單3.1 一個能跑的Agent工作流長什么樣我經(jīng)常糾正一個誤區(qū)Agent工作流不是ChatGPT多輪對話也不是RPA項目加一個對話框入口。一套完整的Agent工作流至少包含五個環(huán)節(jié)意圖解析層把用戶的模糊目標拆解成結(jié)構(gòu)化任務(wù)規(guī)劃層決定任務(wù)用什么工具、什么順序執(zhí)行執(zhí)行層實際調(diào)用RPA腳本、API、瀏覽器自動化等能力感知層讀回執(zhí)行結(jié)果、頁面反饋、異常狀態(tài)驅(qū)動下一步判斷記憶與審計層記錄每一步推理和執(zhí)行證據(jù)支撐回溯和責任認定。舉個實際的例子——“自動查詢物流異常并通知客戶”客戶消息進來意圖解析層識別出“異常查詢”和“通知”兩個子任務(wù)規(guī)劃層決定先登錄物流平臺再遍歷訂單列表最后篩選狀態(tài)字段執(zhí)行層調(diào)用一個RPA腳本完成登錄再用一個Computer Use模塊處理動態(tài)渲染的表格感知層識別到異常訂單將訂單號和頁面截圖一并存入記憶層最后通過企業(yè)微信或郵件發(fā)送通知并生成完整流程報告。你會發(fā)現(xiàn)RPA在這個工作流里沒有消失它只是變成了執(zhí)行層的一個穩(wěn)定工具。大模型只負責“判斷”不負責“手抖”。這也是我一貫推薦的混合架構(gòu)LLM決策 RPA穩(wěn)定執(zhí)行 協(xié)議層約束。如果想在代碼層面快速搭起一個最小骨架可以用類似下面的偽代碼結(jié)構(gòu)來組織class SimpleAgent: def __init__(self, planner, executor, perceiver, memory): self.planner planner # 大模型規(guī)劃 self.executor executor # RPA/瀏覽器工具 self.perceiver perceiver # 結(jié)果解析與驗證 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()這段代碼不復雜但它把職責邊界切得很清楚規(guī)劃層不碰具體點擊執(zhí)行層不碰業(yè)務(wù)決策。后面的擴展、調(diào)試、審計都會舒服很多。3.2 工具選型對比與參數(shù)計算直接給出我這邊用下來比較順手的一套組合RPA執(zhí)行器影刀或UiPath負責高穩(wěn)定節(jié)點操作瀏覽器自動化層Playwright或直接操作CDPChrome DevTools ProtocolComputer Use本質(zhì)上是在CDP之上疊加模型決策Agent編排層根據(jù)團隊語言選型我用過LangChain也用過Spring AI不同規(guī)模各有取舍WebMCP語義層把登錄、查詢、提交這幾個關(guān)鍵節(jié)點封裝成獨立協(xié)議工具模型側(cè)規(guī)劃用大模型動作提取用中小模型OCR用專用小模型各干各的不浪費。不同方案的對比可以看這張表維度傳統(tǒng)RPAComputer UseWebMCP Agent混合執(zhí)行穩(wěn)定性很高腳本即邏輯中低易受頁面變化影響高關(guān)鍵節(jié)點協(xié)議化自適應能力無只能按腳本走強能應對未預知分支中高關(guān)鍵節(jié)點穩(wěn)定 非關(guān)鍵節(jié)點自適應成本低純部署和運維高按token計費中可針對高頻節(jié)點做降本優(yōu)化可審計性強步驟日志明確中需要額外快照和日志機制強協(xié)議層天然帶狀態(tài)記錄改造門檻低中模型功底要求高偏高但一次改造長期受益再說參數(shù)計算。給一個可以直接套的經(jīng)驗公式假設(shè)流程有N個動作每個動作的input約包含截圖編碼加DOM描述約8000到15000 tokenoutput約1000到3000 token決策和動作指令。我做過一個中等復雜度的電商對接流程N64個動作單次跑完約消耗1.5萬到2萬token。如果用的是主流強模型API一次完整流程的成本大概幾塊錢。相比RPA跑一次的成本這高了一個量級但未必不可接受關(guān)鍵在于“值不值得”。人工處理同樣流程要10分鐘Agent換算下來只相當于半分鐘人工成本長期看仍然是劃算的。但如果是高頻小任務(wù)比如每天幾千次重復點擊就不能這么蠻干。我的做法是把高頻路徑直接抽成確定性腳本或內(nèi)部接口Agent只負責異常和策略引導。這是成本與穩(wěn)定性的平衡點建議在做技術(shù)方案時提前算清楚別等上線了再被賬單教育。3.3 用WebMCP把工作流串起來的具體做法拿“登錄態(tài)保持”這個場景實際講講怎么落地。常見痛點是Agent跑長流程中途會話過期彈出登錄框如果沒有預案整個流程直接報廢。傳統(tǒng)RPA的解法是寫死“每20分鐘心跳點擊一次”既消耗資源又很脆弱。用WebMCP的思路登錄頁可以暴露這樣幾個能力{ capabilities: { check_login_status: {}, refresh_qrcode: {}, submit_credential: { params: { account: string, password: string } } } }Agent每次執(zhí)行前先調(diào)用check_login_status發(fā)現(xiàn)過期就調(diào)用submit_credential成功后再繼續(xù)原流程。這樣流程就具備了中途恢復能力而不是死板地定時心跳。這個改造量不大但收益極其明顯。我建議起步階段先做三個點的WebMCP化登錄態(tài)檢測、表單提交前校驗、分頁列表切換。這三處正是Agent最容易失手、RPA腳本又最需要維護的地方投入產(chǎn)出比最高。4. 真實環(huán)境踩過的坑與解決方案4.1 流程飄移Agent“做錯步驟”的根因Agent再聰明也會做錯事。我做過上百次測試后總結(jié)出所謂“做錯步驟”大多數(shù)情況下不是模型變笨而是上下文被污染。典型場景有三類彈窗把表單標題擋住模型誤以為頁面切換了任務(wù)網(wǎng)頁里埋著大段推薦文案或廣告模型把廣告內(nèi)容當作業(yè)務(wù)數(shù)據(jù)提取上一步操作的殘留文本留在輸入框里模型當作本次輸入直接提交。這些問題的共同點是Agent的“感知材料”不夠干凈。解決方式不是反復調(diào)prompt而是在執(zhí)行層回傳數(shù)據(jù)前加一個清洗層。具體動作包括只保留表單區(qū)和主內(nèi)容區(qū)的DOM過濾廣告與推薦節(jié)點每次開始執(zhí)行前重置頁面狀態(tài)清空所有輸入框?qū)μ崛〗Y(jié)果做schema校驗不符合預期就自動重試。我把這個環(huán)節(jié)稱為“感知端降噪”。在實際項目里它比任何提示詞工程都管用。4.2 并發(fā)與成本用實例說明正確的測試方式關(guān)于“Agent怎么扛并發(fā)”我收到過很多咨詢。我的答案可能讓一部分人失望別指望單個Agent天然扛并發(fā)真正能扛的是多實例隔離。我們做過一個并發(fā)電商價格采集場景。最初我開20個線程每個線程各啟動一個Agent實例共用同一個瀏覽器上下文。結(jié)果20個實例瘋狂搶DOM頁面狀態(tài)全部錯亂采出來的價格數(shù)據(jù)一片狼藉。改成獨立瀏覽器上下文、獨立會話、獨立緩存目錄之后20個實例穩(wěn)定運行。我們還按站點拆分Agent實例每個站點獨立負責自己的采集任務(wù)避免互相干擾。還有一個省錢的小建議并發(fā)測試時先別用強模型用一個便宜的小模型把鏈路跑通測并發(fā)穩(wěn)定性等邏輯驗證完再把模型換成強模型跑正式任務(wù)。這樣能在開發(fā)階段省下大量成本同時也能暴露架構(gòu)層面的死鎖或競態(tài)問題。4.3 安全、審計與權(quán)限Agent越權(quán)的管控手段AI Agent能操作賬號、能操作數(shù)據(jù)、能操作錢安全問題絕對不能事后彌補。我在生產(chǎn)環(huán)境設(shè)置了三條防線。第一道是權(quán)限隔離。Agent用單獨的低權(quán)限賬號運行不做管理員不綁個人手機不開放支付授權(quán)。所有涉及資金變動或?qū)ν獍l(fā)送的操作一律二次確認。第二道是工具白名單。Agent能調(diào)用的工具必須顯式注冊沒有注冊過的能力無論對話里怎么誘導都不允許執(zhí)行。這里尤其要提防瀏覽器插件帶來的“隱形工具”一些所謂“裝了就送自動化能力”的插件經(jīng)常會在你不注意的時候打開權(quán)限后門屬于高危項。第三道是審計快照。每一步動作執(zhí)行前都截屏連同頁面狀態(tài)、排隊順序、調(diào)用參數(shù)寫入日志。養(yǎng)成這個習慣很重要沒有證據(jù)鏈的Agent項目出事之后往往比不出事更麻煩因為你連問題出在哪一步都講不清。三條防線缺一不可。忽略任何一條Agent的能力越大風險就越大我反復和客戶講這句話。這里附上一份實際執(zhí)行時的安全檢查清單可以直接復用Agent賬號是否獨立且低權(quán)限支付/發(fā)送類操作是否有二次確認鉤子工具清單是否全部經(jīng)過顯式注冊瀏覽器是否運行在獨立隔離環(huán)境超時和失敗重試是否有上限每一步行為是否留有截圖和調(diào)用日志敏感數(shù)據(jù)是否脫敏后才傳給模型。4.4 常見問題排查速查表把我在群里、工單里被問得最多的問題匯總成一張速查表方便直接對號入座。癥狀根因解法Agent頻繁點擊錯誤元素坐標模式依賴截圖頁面布局變化導致定位偏移改用可訪問性樹或元素ID語義定位長流程后半段開始亂執(zhí)行上下文被彈窗、殘留文本污染增加感知端清洗層重置頁面狀態(tài)并發(fā)一高數(shù)據(jù)就亂多實例共用瀏覽器上下文或會話目錄隔離上下文、會話、緩存目錄Token燒得飛快小動作也調(diào)大模型增加小模型意圖路由壓縮動作候選集流程總會卡在登錄態(tài)過期缺少檢測登錄態(tài)的動作節(jié)點WebMCP化登錄檢測與恢復提交出了事故無法復盤缺乏執(zhí)行快照每步截圖并記錄頁面狀態(tài)與調(diào)用參數(shù)頁面數(shù)據(jù)提取不準模型直接解析整屏DOM只保留業(yè)務(wù)區(qū)域DOM用schema校驗提取結(jié)果某些步驟不穩(wěn)定不確定的路徑用了確定性邏輯高頻步驟腳本化異常分支交給模型規(guī)劃這張表是我自己項目里的OCS操作故障記錄演化來的每次遇到新問題就往里補充團隊新人也更容易上手。5. 我的判斷App不會消失但“以App為中心”的設(shè)計正在讓位聊完這些技術(shù)細節(jié)回到最開始的問題。我不認為AI瀏覽器會“取代App”但它會徹底改變App的存在方式。App會從“用戶的第一入口”降級為“能力提供方”。用戶看到的交互層會逐步被AI驅(qū)動的瀏覽器或Agent工作流接管。短期內(nèi)在手機端登錄態(tài)、推送、支付的體驗優(yōu)勢仍會保住原生App的地位但在企業(yè)流程自動化和效率場景里App作為數(shù)據(jù)孤島的價值會被持續(xù)削弱。5.1 判斷口徑別問要不要做App問能力是否可被訪問我在團隊里的判斷口徑是與其爭論“App到底做不做”不如問“你的業(yè)務(wù)數(shù)據(jù)和業(yè)務(wù)能力能不能被Agent以標準接口訪問”。能訪問App就能變成Agent能力的一部分不能訪問App就遲早被另一個瀏覽器層繞過去。特別是對做企業(yè)服務(wù)的團隊現(xiàn)在布局Agent接口越早未來被替代的風險就越低。就像早期做數(shù)據(jù)化沒有趕上的人后面補的代價是幾何級數(shù)增長的。5.2 給RPA團隊的一條轉(zhuǎn)型路徑參考如果你現(xiàn)在正帶著RPA團隊不知道下一步往哪走我的建議是走一條漸進路線先把現(xiàn)有RPA腳本當作“穩(wěn)定執(zhí)行器”繼續(xù)跑在它外面套一層Agent決策殼再用類WebMCP協(xié)議把登錄、校驗、提交這幾個高危節(jié)點封住。這樣做既有執(zhí)行穩(wěn)定性又有決策柔性還能在突發(fā)故障時快速回退到純RPA模式。這條路我已經(jīng)實際跑通過相對最不折騰。團隊里原來寫RPA的工程師不需要有特別深的模型功底只需要學會跟Agent框架接口對接幾個月內(nèi)就能完成技能升級。而且這類混合型架構(gòu)在匯報里也特別好講不是推翻重來而是模塊演進老板和業(yè)務(wù)方都比較容易接受。最后我個人的體會是這個行業(yè)真正稀缺的不是既會RPA又懂Agent的人而是愿意把每種工具的邊界當作第一原則的人。工具每幾個月就迭代一輪但邊界認知不會過時。什么時候該相信模型什么時候該把它鎖在腳本里什么時候讓協(xié)議層兜底——這些判斷能力才是長期有效的競爭力。