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