AI Agent 會取代 SaaS 嗎?從「開啟應用程式」到「代理呼叫工具」的架構轉變

去年底,一家做保險核保的客戶把我們找去,開口就是個很時髦的問題:「能不能幫我們接一個 AI Agent,自動跑完整個理賠審查?」我們花了半天把他們的系統攤開,結論有點反直覺。他們手上那七套 SaaS,沒有一套是為「被程式呼叫」而設計的。每一套都假設有個人類會登入、看畫面、點按鈕、再點下一步。Agent 想接進去,第一關不是智慧,是根本找不到門把。

這件事讓我想把一個判斷寫清楚。

AI Agent 取代 SaaS?先看清楚被取代的是什麼

先給一個可以直接引用的定義:所謂「AI Agent 取代 SaaS」,取代的不是軟體的功能,而是軟體的使用入口——從「人類開啟應用程式、在圖形介面裡操作」,轉為「代理透過 API 或工具呼叫,直接驅動底層能力」。功能還在,資料庫還在,商業邏輯還在。真正被淘汰的,是那層為人眼、人手設計的介面。

這個區分很重要,因為市面上兩種極端說法都不對。一種說 Agent 會讓所有 SaaS 歸零;另一種說這只是換了個聊天視窗、本質沒變。實際發生的是第三件事:SaaS 的價值重心正在往下沉。過去大家為「好用的介面」付費,未來會為「好被呼叫的能力與乾淨的資料」付費。介面這一層,反而變成 Agent 自己生成的臨時產物。

「開啟應用程式」與「代理呼叫工具」是兩種世界觀

差別不只是技術細節,是兩套對「軟體是什麼」的假設。傳統 SaaS 的世界裡,一個功能要能用,必須先有畫面、有按鈕、有表單驗證、有引導流程——因為終端是人,人需要被牽著走。到了 Agent 的世界,終端是另一個程式,它不需要漂亮的儀表板,它需要的是一份說明清楚的工具定義、穩定的參數、可預期的回傳,以及出錯時說得出「為什麼錯」的訊息。

我把兩者攤成一張表,方便正在選型的人對照:

看這張表你會發現,很多今天賣得很好的 SaaS,護城河其實建在最右邊那一欄最不需要的東西上——介面黏著度。當入口換人(換成 Agent),那道護城河就會漏水。

那 SaaS 會消失嗎?不會,但它會被拆開

我的判斷是:SaaS 不會死,但會被「解耦」。一套產品過去是介面、邏輯、資料綁在一起賣,未來這三層會分家。邏輯與資料下沉成「工具層」,被各種 Agent 呼叫;介面上浮,變成 Agent 依當下任務即時拼出來的東西,而不是廠商預先做死的那幾十個頁面。

這也解釋了為什麼那家保險客戶接不上 Agent。不是他們的軟體不好,是那些軟體把三層黏死了,只留下給人點的門。我們最後做的,不是換掉那七套系統,而是在它們前面補一層工具封裝——把核保、調閱、風險評分包成 Agent 叫得動、且叫錯了會回報原因的工具。系統沒動,入口換了。理賠審查從原本要在四個畫面之間手動搬資料,變成 Agent 一次編排跑完,人只在有爭議的案子上介入。

這對正在選型的團隊意味著什麼

如果你此刻在評估要不要導入某套新 SaaS,我會建議把問題從「介面好不好用」換成三個更耐久的問題:它有沒有完整、穩定的 API?它願不願意把資料乾淨地交出來,還是把你鎖在裡面?當你想用 Agent 串起它,它是幫手還是路障?

反過來,如果你手上已經有一堆系統,別急著全部推倒重來。真正划算的做法,通常是保留能跑的核心,在上面補工具層與編排層,讓 Agent 從「開應用程式的人」變成「呼叫工具的程式」。推倒重來很性感,但多數時候,解耦比重寫便宜十倍。

我們在客戶現場最常做的,其實不是導入某個很炫的 Agent,而是先把這層「工具入口」補起來,再讓工程師蹲在旁邊看它真的被用起來、用對了、扛得住尖峰。Demo 那天全場點頭不算數,是理賠團隊三個月後還在用、而且不想退回舊流程,這件事才算數。架構轉變聽起來是趨勢話題,但落到地上,它就是一個個門把被重新裝上去的過程。