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