傳統 SaaS 公司面對Agentic AI 來勢洶洶的挑戰，傳統以人為操作主體、按人頭收費（Seat-based）、訂閱制的 SaaS 模式正面臨被AI內建功能稀釋的風險，一堆傳統SaaS 公司的未來令人擔憂，面臨生存危機的文章紛紛提出，連帶使得包含美國軟體大廠的估值都大幅下修。當然既有的軟體公司都會受到衝擊，但影響的大小也會跟公司所提供的服務內容，價值鏈所在的位置而不同。更重要的是這些傳統的SaaS 公司該如何利用既有的競爭優勢，整合Agentic AI 的好處，為公司建立新的利基。
面對 Agentic AI ，傳統的 SaaS正從人機互動的介面轉型成為 AI 時代的基礎設施元件與服務。過去 SaaS 的使用流程是，使用者登入系統 、 點選功能 、 填表 、 簽核 、 查詢 、 匯出報表。但 Agentic AI 之後，流程會變成使用者用自然語言下指令 、 然後AI Agent 自動查資料、判斷、填表、送簽、產出結果。Agentic AI 的核心破壞力在於 AI 不再像LLM 只回答問題，而是能自主規劃、使用工具並完成複雜任務。 這樣的轉變會造成SaaS軟體使用本質上的衝擊，例如使用者可能不進系統，直接透過 Copilot、Chatbot、Agent 操作，使的UI 價值下降，這樣一來既有軟體功能被抽象化了，AI Agent 直接呼叫 API，使用者不在乎後面是哪套 SaaS。若UI 使用頻率下降，企業可能將會思考每人每月收費模式的必要性，對訂閱服務的存續產生壓力。
SaaS 廠商對此趨勢的因應將可分為以下幾個方面：
1.產品的無介面化
未來的使用者可能根本不進入 SaaS 的後台，而是直接在 Slack、Teams 或自家的 Agent 介面操作。SaaS 提供各個流程中需要功能物件，讓Agent 需要時取用個別的功能物件。在這種使用模式下，計費模式將發生轉變，當 Agent 效率大幅提升，SaaS原本按帳號數（Seat-based）的計費模式可能會失效，轉向按價值或按任務執行次數計費。
2.導入人為檢查 / 監督的流程管理架構
當 Agent 開始自主執行任務（如自動發信給客戶、自動調整預算）時，風險控管變得至關重要。所以一方面在必要節點都需要加入人為審核機制， SaaS 系統必須提供暫停流程，並請求人工確認之後才可以往後進行。另一方面加入可追溯性（Audit Log），詳細記錄 Agent 的每一項操作路徑，以便在出錯時進行回溯與糾正。
3.提供垂直領域的知識庫 (RAG)
SaaS 的核心價值在於其擁有的企業內部的專有數據 (Proprietary Data)，這是與通用型AI的重要差異。RAG 是 Retrieval-Augmented Generation，檢索增強生成，AI 不是只靠自己的記憶回答，而是先去企業資料庫、文件庫、知識庫裡找相關資料，再根據找到的資料回答。RAG 存在兩大限制 ，Embedding 準確率與Chunking 資訊破碎。Embedding 就是把文字轉成一組數字向量，讓電腦判斷這段文字跟問題有多相關。例如你問這個客戶有沒有付款風險?如果 Embedding 模型不夠好，它可能只找含有付款風險四個字的文件，卻漏掉應收帳款逾期 90 天、財務異常 等等這種其他重要的內容 。Chunking 是把一份長文件切成一小段一小段，方便 AI 檢索。例如一份合約有 100 頁，系統可能切成很多小段，但文件被切碎後，AI 可能只看到局部片段，看不到完整脈絡。於是Reranker、GraphRAG、Multi-Turn RAG 等進階版 RAG 提出，目的是讓 AI 查資料更準、更完整。
4. 從 UI 優先轉向 API/工具優先 (UI-First to API-First)
傳統 SaaS 是為了讓人閱讀、人手操作而設計的（GUI）。Agentic AI 則需要機器可讀的介面，將軟體封裝為 Tool/Action，將原本複雜的點選流程，封裝成 AI Agent 可以直接呼叫的 API。例如原本需要點選 多個步驟才能產出的財務報表，現在應簡化為一個類似程式語言中的物件導向的取用概念。
提供高品質、符合 OpenAPI 標準的文檔，是讓 Agent 正確調用 SaaS 功能的前提，所以軟體廠商需要提供完整的 Metadata 與 Documentation 讓 Agent 理解 API 的用途，資料內容以及資料存取的方法。
5. Agentic AI 下SaaS 運作方式 : 原生 API、Webhook 和 MCP
API 讓不同系統可以互相溝通 ，讓功能元件在需要的時候被呼叫使用。Webhook則是某件事發生時，功能元件在事件觸發時，自動通知其他系統的方式，跟API 是相反方向的動作。API 比較像是我主動去問你資料；Webhook 則是事情一發生，元件立刻通知我。
MCP（Model Context Protocol，模型上下文協定） 是一種由 Anthropic 於 2024 年 11 月推出的開放標準，作為 AI 模型與外部資料來源/工具之間建立一套標準化的溝通方式。
MCP 定義了模型如何安全地存取本地與遠端資源 :
1.標準化介面：它將不同數據源的 API 轉換為模型可理解的標準化請求，支援結構化（如資料庫）與非結構化（如文件、影像）數據。
2.本地控制：它允許 AI 在不將敏感數據上傳至雲端的前提下，直接與本地環境（如電腦檔案系統、開發環境）互動。
經由此方式，MCP 提供了一個安全且規範的通道，讓 AI 能夠理解有哪些工具可用以及如何使用。這使 AI 能從單純的對話機器人轉變為能主動執行任務（如查詢會議記錄、發送郵件、操作 GitHub）的 AI Agent。
從科技新報中叡揚的AI Solution Day 報導也可以增加對此的理解，https://technews.tw/2025/12/01/from-genai-to-agentic-ai-gss-ai-solution-day/
SaaS 廠商導入Agentic AI 應有循序漸進的機制：
1.加入人工審查 ：企業導入 Agentic AI 時，不能一開始就讓 AI 完全自動決策，尤其是涉及金錢、合約、人事、法遵、客戶風險時，也就是要 Human-in-the-loop。 此方法產生的價值為避免AI缺失以及保留責任歸屬。也就是 Agentic AI 初期要當助理，不能直接當主管。
2.確保 LLM 易切換 ：企業不要把系統綁死在單一 AI 模型供應商上，而是要能彈性切換，這對SaaS 廠商很重要，因為如果能做到模型可切換，就比較像是企業 AI 平台，而不是某個模型的代理商，才可以做為長期演進的平台，而不是被某一家 LLM 綁死的系統。
可能的需求情境舉例如下,需要有不同的模式使用：
3.先求完善工具價值，再談 AI 自主
很多企業一開始會期待AI 能自己完成所有事情，但實務上，在這之前應該先把企業系統功能工具化讓 AI 可以安全查詢資料、可以產生草稿、送人工確認、在低風險任務逐步自動執行之後才能慢慢加深其自主性。若工具沒先完備，一味的追求Agentic AI導入 ，將會產生如下的災難。
4.選擇彈性且能加速工具開發的平台
在Agentic AI 時代的關鍵不是做一個 Chatbot，而是快速開發一批可被 AI 調用的工具。 而如果每個工具元件都需要從零開發，會導致成本很高、開發速度很慢。因此，SaaS 公司若能提供低API 管理、MCP、Webhook、權限與稽核，就有機會成為企業 Agentic AI 的開發平台。
Agentic AI 對 SaaS 公司的機會
1. 提高產品黏著度 ：當 SaaS 被接入企業 AI 工作流後，客戶更不容易更換系統。因為系統不只是儲存資料，而是已經變成工作流程核心的一部分，這會提高客戶轉換成本。
2. 提高 ARPU 與加值收費 ：如果 AI 功能能幫企業節省人力、降低錯誤、加速流程，SaaS 公司就有機會收取額外費用 。
3. 擴大企業客戶場景 ：Agentic AI 可以讓 SaaS 從單一部門擴展到更多部門，比如申請文件原本可能只是行政或資訊部使用，Agentic AI 使 SaaS 產品從單點工具，變成跨部門平台。
Agentic AI 對 SaaS 公司的風險
1. AI 平台可能吃掉前台入口 ：未來使用者可能更多透過 ChatGPT、Claude、Gemini、Copilot 等 AI 入口操作企業系統。這代表 SaaS 公司的前台介面重要性可能下降。如果 SaaS 公司無法成為 AI 背後的重要工具，就可能被邊緣化。
2. 低價值功能可能被 AI 原生工具取代 ：如果某些 SaaS 只提供簡單功能，例如簡單表單、簡單記事、簡單查詢，未來可能被 AI 平台或通用自動化工具取代。 比較有防禦力的是具備掌握企業核心流程 、有權限與稽核 、有深度行業知識 、有複雜系統整合 、有長期資料累積 或是有法規與合規要求的工具。
3.AI 成本可能侵蝕毛利 ：AI 功能會增加成本，如果 SaaS 公司無法把 AI 成本轉嫁給客戶，毛利率可能受壓 。
