AI瀏覽器會不會取代App這個話題最近被問爆了。幾乎每次聊到RPA、Computer Use、WebMCP和Agent這些關(guān)鍵詞總有人拋出一句那以后App還要不要做了作為從RPA時代一路摸到Agent工作流的人我的看法是這不是一個App存亡的問題而是整個自動化范式正在換代的問題。這篇內(nèi)容我把自己從影刀RPA實戰(zhàn)、Codex Computer Use加Chrome的組合玩法到WebMCP協(xié)議層的理解再到Agent框架與編排的落地經(jīng)驗完整拆一遍。適合正在做RPA、想轉(zhuǎn)Agent開發(fā)、或者單純被AI瀏覽器概念搞到焦慮的工程師和產(chǎn)品經(jīng)理讀完可以自己對“取代”這件事下判斷而不是被熱搜帶著走。1. 爭議源頭AI瀏覽器憑什么和App站在對立面1.1 所謂的AI瀏覽器不只是一個帶對話框的瀏覽器先說清楚AI瀏覽器是什么。市面上的AI瀏覽器大體分成兩類一類是把LLM對話能力直接嵌進瀏覽器幫你總結(jié)網(wǎng)頁、翻譯、問答另一類更激進它不只是“幫你讀網(wǎng)頁”而是能“替你操作網(wǎng)頁”——模擬鼠標點擊、填表、翻閱、提取數(shù)據(jù)甚至跨站點完成一條完整業(yè)務鏈路。真正引發(fā)“取代App”恐慌的是后者。這類瀏覽器的技術(shù)底座不復雜但工程細節(jié)非常難。它要實時理解頁面的DOM結(jié)構(gòu)或截圖視覺信息把用戶的目標拆解成一步步的瀏覽動作然后在無頭瀏覽器或真實瀏覽器里執(zhí)行。聽起來像RPA確實像但它和傳統(tǒng)RPA有個本質(zhì)區(qū)別RPA靠錄制好的規(guī)則驅(qū)動AI瀏覽器靠模型對頁面理解和推理來驅(qū)動。規(guī)則只能處理寫死的場景推理能應對突發(fā)狀況?，F(xiàn)在大家把這個能力叫Computer UseOpenAI也好、Anthropic也好給模型開放了“用電腦”的接口讓它能看屏幕、點鼠標、敲鍵盤。各家Agent產(chǎn)品也把它當作殺手锏。而一個始終在劇情核心的配套方案是讓網(wǎng)頁主動向Agent暴露自己的“能力清單”這就要提到WebMCP。等于說AI瀏覽器想同時擁有兩條腿一條模擬人的視覺和手一條讓Web服務直接對Agent開口說話。1.2 App圍墻花園與開放Web的路線之爭為什么話題會上升到App的存亡因為App和Web代表了兩種完全不同的服務分發(fā)模式。App是圍墻花園數(shù)據(jù)封閉、交互固定、更新由廠商控制Web是開放場地鏈接直達、爬蟲可讀、頁面隨時可改。過去十幾年移動互聯(lián)網(wǎng)幾乎把重心全部押在App上大量服務只能在應用商店下載后使用這給自動化帶來了巨大阻礙——API不開放、頁面不在瀏覽器里、自動化工具夠不著數(shù)據(jù)。RPA為什么一度在企業(yè)里很火就是因為企業(yè)發(fā)現(xiàn)大量關(guān)鍵業(yè)務跑在老舊系統(tǒng)和桌面應用里拿不到API只有靠UI自動化去“裝作人在操作”。AI瀏覽器想打一場翻身仗本質(zhì)邏輯是既然模型已經(jīng)能理解UI那我干脆把所有服務都當作能通過瀏覽器訪問的頁面來處理。你不需要給我App不需要給我API給我一個URL我就能干活。這個思路確實動人但繞過了一個現(xiàn)實很多重度服務的體驗和計算發(fā)生在App本地瀏覽器根本加載不全。所以AI瀏覽器能不能取代App目前看不是技術(shù)問題而是服務和數(shù)據(jù)的可達性問題。這也是WebMCP這類協(xié)議能引起熱議的真正原因——它想從源頭改變Web服務的表達方式讓Agent天生就可調(diào)用。1.3 爭奪的是工作流入口不是流量入口過去瀏覽器爭的是流量入口前綴要最大、導航要最快、搜索要最全。AI瀏覽器要爭的卻是工作流入口用戶發(fā)起一個目標從哪個界面開始中間經(jīng)過哪些工具和數(shù)據(jù)最后在哪里交付結(jié)果。誰搶到這個入口誰就定義了用戶和數(shù)字世界的交互方式。從這個視角看App并沒有輸?shù)兂闪苏麄€工作流里的一個“資源節(jié)點”。工作流的編排跑在Agent層瀏覽器只是個承載工具集的外殼。我之前做RPA項目時經(jīng)歷過典型的局面客戶的核心業(yè)務跑在微信小程序里外部自動化根本進不去最后只能用iOS的輔助功能來碰運氣。類似問題在Agent工作流里一樣存在。所以“取代”這個詞太絕對了。更準確的說法是Agent工作流正在重新分配各端的角色App依然是數(shù)據(jù)和生產(chǎn)工具但“指揮權(quán)”正在向Agent和瀏覽器端遷移。判斷是不是要押注這個方向核心看一點你的服務是否愿意向Agent暴露可編程的入口。愿意你就能接住這波紅利不愿意你的App再好看也只會成為Agent繞開的那堵墻。2. 演進路線從RPA到Computer Use的范式跳躍2.1 RPA的黃金十年與影刀實踐教訓聊Agent工作流繞不開RPA。過去十年RPA在企業(yè)自動化里立下了汗馬功勞。像影刀RPA、UIPath、按鍵精靈這類工具把“寫腳本操作軟件”的門檻拉到極低業(yè)務人員拖拽組件就能完成數(shù)據(jù)搬運、表單回填、網(wǎng)頁采集。我做影刀RPA時最常被新人問的一個問題是怎么把列表中的[]去掉。這個看似基礎的問題其實暴露了RPA開發(fā)的痛點。影刀取網(wǎng)頁元素時返回的往往是一個列表對象直接填到Excel或文本框系統(tǒng)會原樣輸出[張三, 李四]而不是張三李四。解決辦法通常是先用“文本處理”組件做一次連接操作把分隔符設成空字符串或者用正則去頭尾。這類問題看著小卻是RPA工程和Agent工程共同的核心議題數(shù)據(jù)在傳遞過程中格式和類型的丟失與重塑。RPA給我的最大教訓是“規(guī)則脆”。錄制好的流程頁面一改版就崩元素一換選擇器就失效。團隊得不斷地修腳本、補選擇器、做異常兜底。維護成本高到客戶懷疑人生。但這幾年做下來我也積累了一套實戰(zhàn)方法論能用結(jié)構(gòu)化數(shù)據(jù)接口就不碰UI能走DOM定位就不走坐標關(guān)鍵步驟必須有截圖留痕異常分支寧可多寫幾條也不放過。這套方法論用到現(xiàn)在做Agent工作流上依然完全成立。2.2 Computer Use為什么能打破RPA的天花板RPA解決的是“規(guī)則確定、步驟固定”的場景它沒有能力處理沒見過的情況。Computer Use則完全不同。它讓模型直接看到屏幕截圖根據(jù)用戶的目標動態(tài)生成下一步操作。這個“動態(tài)”二字就是范式跳變的關(guān)鍵。我用過Codex Computer Use搭配Chrome做測試目標是讓它從某個后臺系統(tǒng)下載訂單并在本地表格里匯總。傳統(tǒng)RPA干這活需要我先錄一遍流程、設定各種元素錨點Computer Use不用只要告訴它目標它會自己打開瀏覽器、找到頁面元素、點擊下載按鈕、再把文件移動到目標目錄。中間遇到彈窗它會自己關(guān)掉并繼續(xù)。這種體驗非常震撼但也非常燒錢。為什么燒錢因為模型每看一幀截圖、每點擊一次都在消耗token。一套復雜任務可能要幾十上百次交互成本比RPA高出幾個數(shù)量級。另一個硬傷是準確率模型偶爾點錯位置、選錯按鈕尤其在深色模式、動態(tài)渲染、懶加載頁面里錯誤率會顯著上升。為了壓成本需要緩存截圖分析結(jié)果、合并連續(xù)動作、用CSS選擇器優(yōu)先替代純視覺定位。2.3 從模擬操作到聲明意圖WebMCP的價值凸顯Computer Use雖然聰明但它本質(zhì)上還是在“模擬人”。模擬人意味著要和瀏覽器渲染結(jié)果死磕要處理各種JS動態(tài)加載、圖片懶加載、彈窗遮擋。有沒有可能讓Agent不走視覺那條路直接拿到頁面底層的“能力接口”這就是WebMCP想回答的問題。WebMCP可以理解成Web服務給Agent遞交的一份“說明書”把頁面上可執(zhí)行的操作、可提取的數(shù)據(jù)、可觸發(fā)的流程用結(jié)構(gòu)化方式寫出來Agent拿到這份說明直接調(diào)用能力不再需要逐像素地“看”頁面。類比一下你到一家餐廳吃飯可以盯著菜單猜菜品樣式也可以直接讓服務員推薦并下單。Computer Use是前者參考菜單自己猜WebMCP是后者服務員直接把菜端上來。但WebMCP的普及有一個繞不開的挑戰(zhàn)網(wǎng)站方是否愿意主動適配。主動暴露能力清單等于把自己的業(yè)務規(guī)則交給第三方Agent很多企業(yè)會緊張。所以短期來看Computer Use是Agent工作流的主要落地方式WebMCP是增量優(yōu)化方案。我做Agent選型時基本策略是兩條腿走路能走WebMCP就優(yōu)先走頁面不支持時才退回視覺點擊。耗時和成本大約能差出40%很值得用腳投票。3. Agent工作流的核心架構(gòu)拆解編排、工具、記憶與安全3.1 再聊“Agent是什么”以及兩個常被混淆的詞被問得最多的問題是“Agent到底是個啥”。我的理解Agent是一個能感知環(huán)境、做出決策、調(diào)用工具、執(zhí)行行動、并從結(jié)果中學習的自動化實體。比起傳統(tǒng)程序“輸入→處理→輸出”Agent多了一個循環(huán)觀察→思考→行動→反思。這個循環(huán)讓它可以處理開放性問題。還有個高頻問題Harness和Agent有什么區(qū)別。簡單說Harness是運行Agent的“骨架容器”提供生命周期管理、上下文注入、工具調(diào)用規(guī)范等基礎設施Agent本身是業(yè)務實體負責決策。比如Spring AI Agent里Harness負責把用戶請求包裝成任務上下文驅(qū)動模型循環(huán)調(diào)用工具直到滿足終止條件。很多所謂“Agent框架”核心就是一套Harness實現(xiàn)。理解了這個區(qū)別看代碼時就不會亂。我用ADK的Kotlin快速上手版跑通過一個Agent體會特別深。它把Agent定義成一個帶有工具列表的單元然后通過Runner來調(diào)度。開發(fā)者不需要關(guān)心模型循環(huán)細節(jié)只要配置好系統(tǒng)提示詞、工具注冊表、終止條件。這大幅降低了入門門檻但對生產(chǎn)級場景序列化、重試、狀態(tài)恢復都要自己補。3.2 工具系統(tǒng)與Agent SkillAgent的雙手和招數(shù)Agent再聰明沒有工具也寸步難行。工具系統(tǒng)是Agent工作流里最貼近工程的部分。按照Claude Agent Skills的范式一個Skill就是一份指令加一組腳本告訴Agent“遇到這類任務時按這個方式處理”。例如我做過一個“將網(wǎng)頁保存成Markdown的Skill”它會引導Agent識別頁面主內(nèi)容、過濾導航和廣告、調(diào)用HTML轉(zhuǎn)Markdown工具最后保存到本地倉庫。這個設計思路很像我以前寫RPA組件。RPA組件是預定義的動作單元Agent Skill則是帶上下文的動作模板。區(qū)別在于Skill可以嵌入自然語言描述讓模型決定何時調(diào)用而不是寫死觸發(fā)條件。這種靈活性讓Agent可以處理未預見的輸入。工具注冊還有一個細節(jié)要給模型提供準確的函數(shù)描述和參數(shù)模式否則模型會反復生成錯誤的調(diào)用。Function Calling的失敗往往不是模型笨而是描述信息寫得太差。我做過一個統(tǒng)計在100次工具調(diào)用里參數(shù)描述里加上枚舉值與邊界說明后成功調(diào)用率從68%提升到91%。這個數(shù)據(jù)很說明問題工具系統(tǒng)看似簡單49%的功勞藏在描述里。3.3 記憶是怎么影響Agent效果的Agent記憶可能是最被低估的模塊。沒有記憶Agent就是每輪對話都重新讀劇本的演員永遠記不住上一幕發(fā)生了什么。記憶按層級分為會話記憶、工作記憶、長期記憶。會話記憶是上下文窗口內(nèi)的信息工作記憶是當前任務的關(guān)鍵中間量長期記憶則依賴外部存儲。比如Hermes Agent配合Obsidian做知識庫是我目前覺得最舒服的知識管理方案。讓Agent把網(wǎng)頁保存成Markdown寫入Obsidian倉庫再通過向量化把這批Markdown納入長期記憶下次提問時就能檢索到歷史結(jié)論。整個鏈路解決了Agent“讀過書但轉(zhuǎn)身就忘”的問題。實現(xiàn)記憶有幾個坑。第一是上下文膨脹把幾百條歷史一股腦塞給模型既費token又干擾注意力應該有取舍地壓縮和篩選。第二是記憶污染錯誤信息一旦寫入長期記憶會持續(xù)影響后續(xù)決策需要設計置信度或人工確認機制。第三是隱私敏感數(shù)據(jù)進記憶前要做好脫敏分級。3.4 高并發(fā)與Agent安全生產(chǎn)環(huán)境的生死線Agent跑通Demo容易上線扛并發(fā)是另一回事。AI Agent怎么扛并發(fā)核心思路是異步化和池化。把長耗時的工具調(diào)用異步化模型推理單獨排隊任務狀態(tài)存Redis進程崩潰后可恢復。不能像寫普通接口那樣一個請求同步跑完整個Agent循環(huán)否則十個請求就能拖垮服務?？蚣軐用婵梢越梃bHarness的調(diào)度策略把工具調(diào)用放到獨立的Worker里用消息隊列解耦。我用Rust寫過高性能Agent進程Rust在內(nèi)存安全和并發(fā)上優(yōu)勢明顯但開發(fā)效率比不上Python。生產(chǎn)環(huán)境更常見的是Python主控加Rust工具服務兩者混合。Agent安全更得重視。工具調(diào)用權(quán)限必須最小化Agent能執(zhí)行的命令、能訪問的數(shù)據(jù)都要有邊界。常見手段是VPC隔離、容器化沙箱、命令白名單、敏感輸出的攔截。我給Agent設計權(quán)限時有一條鐵律Agent能做的事必須是人明確授權(quán)的事。它可以用瀏覽器插件“瀏覽”頁面但不能悄悄上傳文件它能讀工作目錄的數(shù)據(jù)但碰到用戶目錄就停。4. 實操環(huán)節(jié)從零搭建一條Agent工作流4.1 一個具體需求把網(wǎng)頁資料自動歸檔進知識庫為了把前面的原理串起來我設計了一個完整的實操讓Agent根據(jù)用戶輸入的主題詞主動去搜索網(wǎng)頁提取主內(nèi)容清洗成Markdown歸檔到Obsidian知識庫。這是“網(wǎng)頁保存成Markdown的Skill”的升級版涵蓋了感知、決策、工具、記憶四大模塊。技術(shù)選型上我用的是Chrome加Computer Use模式做頁面操作用Hermes Agent做任務編排老牌RPA影刀負責那些需要穩(wěn)定錄制的環(huán)節(jié)比如登錄、翻頁、批量下載三者配合。選這套組合的原因很現(xiàn)實Comupter Use靈活但貴RPA穩(wěn)定但僵人為編排把兩者優(yōu)勢疊起來取長補短。4.2 核心流程分步拆解與參數(shù)設置第一步定義目標輸入。用JSON Schema約束主題詞、搜索頁數(shù)、是否包含圖片等參數(shù)。第二步編排Action序列Agent先發(fā)起搜索打開搜索結(jié)果前幾頁提取候選鏈接。第三步調(diào)用“網(wǎng)頁轉(zhuǎn)Markdown”Skill用HTML解析庫去除script、style、nav等噪音節(jié)點提取article主體。第四步寫入Obsidian庫生成帶frontmatter的Markdown文件frontmatter里寫入來源URL、抓取時間、關(guān)鍵詞。第五步觸發(fā)記憶更新把這些新文檔切塊向量化入庫。每一步都有參數(shù)講究。比如提取主內(nèi)容時不是簡單取article標簽因為很多站點的article不標準需要啟發(fā)式規(guī)則統(tǒng)計文本密度、鏈接密度找到正文區(qū)域。我運行一次抓取任務大概消耗20個步驟這在純Computer Use里算低消耗了因為網(wǎng)頁轉(zhuǎn)Markdown的Skill避開了大量逐字閱讀頁面的token開銷。4.3 為什么保留RPA而不是全面轉(zhuǎn)向AI這個架構(gòu)里影刀RPA負責登錄、翻頁、批量下載這些操作高頻、穩(wěn)定、要求零失誤。Computer Use負責處理異形頁面、動態(tài)修改的DOM以及需要推理的環(huán)節(jié)。這個搭配很關(guān)鍵它解決了一個成本問題讓RPA處理確定性動作讓AI處理不確定性推理整體成本能砍掉一大半。RPA和AI這不是替代關(guān)系而是分工關(guān)系。以后Agent工作流的成熟形態(tài)大概率是“RPA做肌肉記憶Computer Use做臨場反應WebMCP做直通對話”。三種技術(shù)棧各有擅長區(qū)間誰也別想完全吃掉誰。5. 問題排查與實戰(zhàn)避坑那些文檔沒寫明的事5.1 高頻報錯Agent Execution Terminated Due to Error這個錯誤翻譯過來是“Agent執(zhí)行因錯誤終止”新手看到就頭皮發(fā)麻。我排查這類問題的順序是固定的先看日志終止前的最后一條工具調(diào)用再確認錯誤類型。如果是工具返回異常大概率是參數(shù)模式?jīng)]匹配回查工具描述如果是模型生成了非法JSON多數(shù)是上下文太長把模型繞暈了減少輸入長度或重啟一輪。還有一次我排查了一下午結(jié)果發(fā)現(xiàn)是工具函數(shù)拋出的異常信息沒有被序列化Harness捕獲不到具體錯誤只能返回終止信號。解決方式是在工具入口統(tǒng)一包一層異常攔截把錯誤轉(zhuǎn)換成結(jié)構(gòu)化輸出。這個坑之所以隱蔽是因為問題不在調(diào)用邏輯在于序列化邊界。5.2 表格速查Agent開發(fā)高頻問題的歸因與解法問題現(xiàn)象常見歸因快速解法Agent重復調(diào)用同一個工具上下文沒有記錄已執(zhí)行狀態(tài)引入步驟狀態(tài)追蹤跳過已完成調(diào)用工具返回的數(shù)據(jù)帶了[]或引號列表轉(zhuǎn)字符串未處理顯式指定分隔符空字符串直接join同一個任務有時成有時敗頁面元素動態(tài)加載增加等待策略優(yōu)先DOM選擇器定位高并發(fā)下任務互相污染共享變量/共享會話狀態(tài)任務級隔離用Redis按task_id分KeyAgent產(chǎn)生“幻覺式操作”上下文不足或提示詞模糊補充系統(tǒng)級約束和邊界規(guī)則輸出內(nèi)容突然截斷超過輸出token上限任務拆分、數(shù)據(jù)分批返回5.3 關(guān)于Token消耗的優(yōu)化實戰(zhàn)我實測過一個典型任務用Computer Use下載十張報表并歸檔。默認方式跑了約12萬token成本感人。優(yōu)化后縮到3萬token核心手段有三招。第一招把連續(xù)滾動和點擊動作合并成一條指令讓模型一次決策、一次執(zhí)行第二招禁用非必要截圖只對關(guān)鍵頁面做視覺分析第三招能用WebMCP或結(jié)構(gòu)化API的頁面絕不走視覺路徑。Token優(yōu)化的本質(zhì)不是省錢是減少延遲。Agent跑一個流程每輪推理2到5秒幾十輪下來就是幾分鐘用戶根本等不了。把輪次壓縮到5輪內(nèi)體驗才算勉強可用。所以現(xiàn)在的Agent產(chǎn)品拼的不是誰的模型更聰明而是誰的編排更克制。6. 我的判斷與選擇AI瀏覽器到底會不會取代App我不覺得AI瀏覽器會像大家想象的那樣“取代”App。更靠譜的說法是它正在成為一種新的“前臺”把各類服務重新編排一遍。App依然生產(chǎn)內(nèi)容、保存數(shù)據(jù)、執(zhí)行重型計算但用戶發(fā)起意圖的第一入口會越來越多地落到AI瀏覽器和Agent工作流。對開發(fā)者來說與其糾結(jié)“要不要做App”不如問一句我的服務準備好被Agent理解和調(diào)用了嗎被Agent調(diào)用意味著需要更規(guī)范的頁面結(jié)構(gòu)、更開放的接口、甚至WebMCP式的能力聲明。那些早期就把自己改造成“Agent友好型”的服務會在這波工作流變革里吃到巨大紅利。那些繼續(xù)做封閉圍墻的也不會立刻死掉但會看著用戶一步一步繞開它。最后分享一個我自己的體會RPA時代我靠的是錄制和選擇器的熟練Computer Use時代我靠的是提示詞和工具編排的精細到了WebMCP時代拼的會是數(shù)據(jù)建模和對業(yè)務本質(zhì)的理解。工具在變但自動化底層那套“把流程拆解成步驟、把步驟沉淀成資產(chǎn)”的方法論從來沒有變過。想做Agent的人先把這套基本功練扎實比你追一千個熱搜都強。