home / notes / AI 代理與 SaaS 介面：該問的不是 UI 會不會消失，而是代理入口由誰定義
Note
AI 代理與 SaaS 介面：該問的不是 UI 會不會消失，而是代理入口由誰定義
AI 代理會不會讓 SaaS 介面變得不重要，取決於代理從哪一條路接觸你的產品，UI 會不會消失反而不是重點。代理模擬點擊、操作人類介面時，UI 會變成一個沒有契約的機器介面，廠商失去權限、計量與稽核的控制點。如果是廠商主動開放 MCP server、API 或 llms.txt，這些控制點就能拿回來。所以對創辦人來說，真正的產品決策是由誰來定義代理入口。
為什麼「UI 會不會死」是問錯了問題
現在談代理與 SaaS 的文章，大致分成兩邊。取代派認為，代理和生成式軟體會繞過介面，甚至讓使用者自己做工具，取代原本訂閱的 SaaS。轉型派則認為，SaaS 的價值本來就包括安全、SLA、維護、客服與資料，代理改變的只是軟體被使用的方式，例如更多使用量會轉到 API。L.E.K. 在 2025 年 6 月的報告把未來分成共存、融合、取代三種情境，並強調影響會依產業與使用情境而不同。Nordic APIs 則主張 SaaS 應該往 API 加代理的方向走。
兩邊都把「介面」當成一整塊來討論，我認為漏掉的就是這一點。代理接觸一套 SaaS 至少有兩條路，而且兩條路對廠商控制權的影響方向相反。第一條是代理直接操作給人看的畫面：UI 不但沒死，還被迫多服務一種沒簽約、也看不見的使用者。第二條是代理經由廠商主動開放的入口進來：人類介面的角色會縮小，但權限、計量和稽核重新回到廠商手上。爭論 UI 會不會死，推不出可以執行的產品決策；能推出決策的問題是：代理入口由誰定義。
順帶排除一個常見的推論：代理普及，不代表 UI 從此不重要。在第一條路上，介面反而更脆弱、也更關鍵，因為人和代理同時依賴它，而廠商對其中一方幾乎一無所知。
代理接觸 SaaS 的兩條路：模擬點擊，或走廠商開放的入口
先講事實。根據 MIT Technology Review 2025 年 1 月的報導，OpenAI 的 Operator 是一個 web app，能在瀏覽器裡完成簡單的線上任務，例如訂演唱會門票、填寫線上雜貨訂單。它由名為 Computer-Using Agent（CUA）的模型驅動，CUA 建構在 GPT-4o 之上，發布時只開放給美國的 ChatGPT Pro 訂閱者。同一篇報導把 Anthropic 的 Computer Use 和 Google DeepMind 的 Mariner 列為同類工具。至於 Operator 表現優於這兩者，那是 OpenAI 自己的說法，沒有經過獨立驗證。有一點常被誤解：Operator 不是去呼叫各家軟體的專屬 API，它操作的是現有的網頁介面。
另一條路的代表是 Anthropic 開源的 Model Context Protocol（MCP）。官方的定位是一個開放標準，用來把 AI 助理連到資料所在的系統，包括內容庫、商業工具與開發環境。架構分成兩側：開發者用 MCP server 開放資料，或是建構連接這些 server 的 MCP client。Anthropic 指出，現在每接一個新資料來源都要各自客製實作，MCP 想用單一協定取代這些零散的整合。部分第三方整理把 MCP 描述成「應用程式與模型之間的整合層」，這跟官方的說法有出入：重點在資料與工具的存取，跟切換模型無關。
第三個訊號是 llms.txt。它明確自稱是一份提案，不是正式標準，目前是 v2。提案建議網站放一個 markdown 格式的 /llms.txt，可以放在根目錄，也可以放在任一路徑下，涵蓋該路徑底下的頁面。它的立論是：網頁是為人設計的，資訊被包在導覽、廣告和 JavaScript 裡，轉回乾淨文字既困難又不精確。提案頁也記下了時間上的變化："When this proposal was first written in 2024, this was largely a prediction." 提案頁還提到，Chrome 的 Lighthouse 在 agentic browsing 檢查中會稽核網站有沒有 llms.txt。不過採用規模的說法來自提案作者本人，不是第三方統計。
從目前公開資訊來看，這幾條路並沒有收斂成單一標準。Operator 這類產品押注的是不需要任何廠商配合；MCP 與 llms.txt 押注的是廠商願意為代理另外準備一個結構化的入口。對 SaaS 來說，這兩種押注各自代表一種權力結構。
五個控制點：控制權在兩條路上如何轉移
下表是我的分析框架，不是量測結果。我用五個廠商在意的控制點，比較代理模擬點擊與代理走廠商開放入口時，廠商各自還握有什麼。
| 控制點 | 模擬點擊人類介面（Operator 類） | 廠商開放的代理入口（MCP server、API） |
|---|---|---|
| 權限 | 代理沿用人類帳號的 session，能做的事等於那個人能做的事，無法單獨收窄 | 可以替代理另外設定範圍，例如只讀、限定物件、限定動作 |
| 計量 | 代理的操作混在人類流量裡，很難切出來計價 | 每次呼叫都是明確的事件，可以按次、按量或按結果計價 |
| 稽核 | 日誌只看得到「某帳號點了某按鈕」，看不出是人還是代理、受誰委託 | 可以記錄是哪個 client、代表誰、呼叫了哪個工具 |
| 改版風險 | 任何版面調整都可能悄悄弄壞客戶的代理流程，而且廠商事前不知道 | 有版本與契約可以管理，改動能公告、能設過渡期 |
| 身分辨識 | 廠商很難判斷操作者是人、哪一家代理，或是否違反服務條款 | 代理以可辨識的身分接入，可以設定配額、封鎖或分級 |
表裡最容易被低估的是改版風險。當代理靠模擬點擊完成工作，UI 實際上就變成一個非正式的 API：沒有版本、沒有文件、沒有棄用公告。產品團隊改個按鈕位置、拆一個表單步驟，對人類使用者可能是體驗改善，對代理卻可能讓整條委託流程默默失敗。更麻煩的是，客戶多半會把失敗算在 SaaS 頭上，而不是代理頭上。我認為這會讓廠商陷入一種很彆扭的處境：為了不弄壞看不見的代理，連改版都要變得保守。
走開放入口也有代價。MCP 這類協定要求廠商自己決定要開放哪些資料與工具，整合的主導權回到廠商手上，但權限模型、認證，以及代理可以寫入資料之後的安全設計，也都變成廠商的責任。這不是免費的控制權，而是用工程成本換回來的控制權。
當使用者改用代理，客戶關係歸誰
接下來是假說，目前沒有採用資料可以佐證。如果使用者在代理裡完成工作，SaaS 就失去了跟使用者直接接觸的那個畫面，而品牌曝光、新功能推廣、升級銷售，原本都發生在這個畫面上。在模擬點擊的路徑上，代理平台站在使用者和 SaaS 中間，SaaS 甚至不知道對面是代理。這可能代表客戶關係會被代理平台截走，SaaS 退到後端供應商的位置。
按席位計價會先感受到壓力。一個代理可能做完好幾個席位的工作，也可能根本不需要登入介面。L.E.K. 只建議廠商重新思考定價，沒有提出市場資料，所以「席位定價會失效」仍是推測。不過方向不難想像：沒辦法計量代理用量的廠商，很難設計出新的計價方式。這也是我把計量列成控制點的原因。
護城河的位置也會移動。如果護城河主要建立在「使用者習慣了我的介面」，代理繞過介面時最先被侵蝕的就是這一塊。建立在資料（system of record）、權限、合規、可靠度與客服上的護城河，受到的影響相對小。我在談輕量 SaaS 被拉進對話介面的筆記裡碰過類似的問題，在資料護城河那篇也討論過取得權限與整合的角色。
哪些功能先開放給代理，哪些留在人類 UI
我的判斷是，排順序時應該先看兩件事：錯誤可不可以逆轉，結果好不好驗收。高頻、規則清楚、做錯了可以撤回、結果容易核對的動作，最適合先開放成代理入口，例如查詢狀態、彙整報表、建立草稿。這些正好也是使用者最可能交給模擬點擊代理去做的工作。廠商不先開放，代理就會自己去點，而且是在廠商看不見的地方點。
反過來，涉及金流、權限變更、不可逆刪除，或需要人判斷的例外狀況，比較適合留在人類 UI，讓介面當審批與監督層。這屬於推測：人類介面可能從主要操作層，逐漸變成處理例外、審批與監督的層。這個方向和我在什麼時候不該用 agent裡用驗收成本與可逆性來判斷的邏輯一致。另外，讀取通常可以早於寫入。對文件量大的產品來說，llms.txt 這種只讀、成本低的入口可以先做，代價和適用範圍我在llms.txt 那篇拆過。
這個判斷在哪些情況下會錯
第一種情況：介面操作代理變得夠可靠又夠便宜，使用者寧可用一個能操作所有軟體的代理，也不在乎每家廠商有沒有開入口。那麼開放入口的優勢會縮小，控制權主要落在代理平台手上。目前沒有獨立資料說明這類代理完成多步驟商業流程的成功率，研究來源裡只有 OpenAI 自己的比較說法，所以我無法判斷離這一步有多遠。
第二種情況：即使走 MCP，客戶關係也不一定回到 SaaS。廠商拿回的是權限、計量與稽核，使用者面對的仍然可能是代理平台的對話框。開放入口能解決治理問題，解決不了品牌曝光的問題。這是這個論點最需要誠實面對的地方。
第三種情況是成本。小團隊同時維護人類介面、API、MCP server 與機器可讀的文件，代價不小；如果產品的使用者很少把工作交給代理，太早投入可能只是多養一層維護負擔。另外還有幾件事目前不確定：Operator 現在的形態與開放範圍是否還跟發布時一樣、MCP 現在的採用規模與治理方式，以及 SaaS 廠商會不會在服務條款中限制模擬點擊。Stratechery 在 2024 年 9 月 18 日評論 Salesforce 直接走向自主代理時寫道："the technology may not be the biggest problem." 我同意這個方向：真正難的是權責與商業安排，技術反而是其次。
接下來值得觀察的訊號
- SaaS 廠商的服務條款是否開始明文規範介面自動化與代理存取，這會決定模擬點擊路徑能走多遠
- MCP 在認證與權限上的治理如何演進，這會決定企業 IT 願不願意讓代理寫入系統
- 定價頁面是否出現以呼叫次數、任務量或結果計價的方案，取代或補充按席位計價
- Lighthouse 的 agentic browsing 檢查這類「可被代理使用程度」的指標，會不會變成代理替使用者挑工具時的依據
最後一項跟 AI 搜尋有直接關係。代理能不能讀懂你的文件、能不能透過協定呼叫你的功能、能不能穩定操作你的介面，都會影響代理替使用者選工具時會不會選到你。我認為這會變成一種跟 SEO 很像的新可見度問題，只是對象從搜尋引擎換成了代理。
結論：把代理入口當成產品來做，不要放任它成為副作用
代理不會讓 SaaS 介面自動失去價值，但會讓「不做選擇」付出代價。放任代理去點你的 UI，等於讓一個沒有契約、無法計量、無法稽核的通道承接越來越多實際使用量，同時綁住你的改版自由。主動開放入口要付工程與安全成本，換來的是重新定義這批流量的權利。我的判斷是，未來兩三年內，SaaS 之間真正的差距不在介面做得多漂亮，而在誰先把代理入口當成一條有權限、有版本、有價格的產品線來經營。這個判斷能不能成立，要看介面操作代理的可靠度能不能追上開放入口；在看到獨立的成功率資料之前，我會押在入口這一邊。
常見問題
Operator 這類代理是透過 API 操作 SaaS 嗎？
不是。依 MIT Technology Review 的報導，Operator 在瀏覽器裡操作現有的網頁介面，由建構在 GPT-4o 上的 Computer-Using Agent 模型驅動，不需要各家軟體另外開 API。
MCP 和 API 差在哪裡？SaaS 做了 API 還需要 MCP 嗎？
Anthropic 把 MCP 定位為連接 AI 助理與資料、工具所在系統的開放標準，目標是用單一協定取代各自客製的整合。API 是廠商自己的介面，MCP server 則是用共通協定把資料與工具開放給代理。要不要兩者都做，取決於你的使用者主要透過哪些代理工作，以及你能不能承擔維護成本。
llms.txt 已經是正式標準了嗎？
還不是。llms.txt 的原始頁面明確自稱是提案，目前為 v2。提案頁陳述 Chrome Lighthouse 的 agentic browsing 檢查會稽核 llms.txt，但採用規模的說法來自提案作者本人，不是第三方統計。
代理普及後，按席位計價會消失嗎？
目前只能算推測。一個代理可能做完好幾個席位的工作，所以席位定價承受壓力是合理推論；但 L.E.K. 只建議廠商重新思考定價，沒有提供市場資料。比較確定的是，無法計量代理用量的廠商很難設計出替代方案。