SaaS並未消亡

隨著AI代理的興起，許多人宣稱軟體即服務（SaaS）的時代已經終結。他們認為，只需幾行自然語言提示和幾美元的花費，任何人都能建立自己的軟體，而無需訂閱任何服務。這些自建的軟體（通常是執行在代理中的技能）將完全符合個人需求，不多不少。

然而，每當有人談論SaaS的死亡時，總有一些關鍵點被忽略。工作本質上是團隊和群體的活動，而目前用AI代理程式設計仍然是個人行為。此外，SaaS公司擅長為人類構建儀表盤和報告，但代理需要的是原始資料，而非資料呈現。

想象一個優秀銷售團隊的協作場景。某位銷售人員可能需要一個資料庫來管理客戶資訊。使用Claude、Gemini或GPT，可以輕鬆構建一個基於SQLite後端的CRM系統，並配上合理的Web前端。但隔壁的銷售同事也需要類似的CRM，她同樣可以用AI工具建立，但結果會反映她自己的需求和偏好。很快，團隊中的每個人都擁有了自己的個人CRM，它們相似但又略有不同：可能使用不同的後端（Filemaker、SQLite、MySQL或企業級Oracle例項），資料模式也不一致（有人用一個欄位儲存地址，另一些人則分為街道、城市、州和國家）。這些系統無法互通。

如果是這樣，如何生成公司級別的報告？如果每個團隊成員都有自己的指標版本，又怎能知道業務是成功還是失敗？每個人都成了自己的孤島。

公司不再向Salesforce這樣的供應商支付訂閱費，但這真的是進步嗎？恰恰相反，我們需要讓資料共享和指標比較變得更容易，而不是更難。此外，像Salesforce這樣的產品擁有數百項功能。大多數人不需要其中的大部分，但幾乎每個人都會需要某個別人不需要的功能。而且總有一些你未曾想到的功能，能讓你從資料中獲得額外價值。購買一個超過當前需求的捆綁包是有價值的。

毫無疑問，賦予人們自行開發工具的能力有很多好處。我敢保證，如果三十年前就有Claude Code，我一定會用“意譯程式設計”來管理作者。但現在有了代理程式設計，我可能再也不會自己寫工具了。不過，SaaS場景揭示了代理程式設計中缺失的東西：缺乏共享和協作的工具。沒有人會為自己單獨購買Salesforce訂閱，它是部門或公司資源，供多人共享。而易於共享正是代理程式設計所欠缺的。我為自己構建了一些Claude工具和技能，但很難與O'Reilly的其他同事共享。ChatGPT的“業務與企業技能”功能暗示了在團隊內共享技能以及協作生成的能力，但很難找到證據表明它真的實現了。我認為這是技術過度自信的症狀：人們容易假設某些事情“很簡單”，而實際上並非如此。

為了使技能在公司內真正有用，我們需要：

• 共享：可以是一個註冊為私有市場的Git伺服器，透過公司管理儀表盤配置。但將技能釋出到市場仍然是熟悉Git的使用者的事，這本身就是一個問題。
• 需求：我們不希望每個人都構建個人工具集，這正是需要解決的問題。如何解決使用者之間的需求差異？技能的產品需求文件應該是什麼樣的？
• 協作：除了Google Docs，當今廣泛使用的協作工具狀況堪憂。在Git倉庫的不同分支上工作併合並更改可能適合專業程式設計師，但對其他人來說並不適用。
• 測試：代理的測試和評估（相關但不相同）是我們尚不充分理解的課題。如果允許使用者使用和建立代理工具來生成預測和報告，必須確保它們不會產生反效果。技能也像其他AI應用一樣，會隨時間漂移。即使釋出後，也需要定期評估其效能。
• 版本控制：與任何軟體一樣——我們需要認識到代理工具和技能也是軟體，即使是用英語編寫的——隨著需求變化和LLM行為漂移，更新它們很重要。使用者需要能輕鬆將技能更新到最新版本。這再次涉及為非技術使用者封裝Git。
• 安全：智慧代理的安全問題仍未被很好理解。我們瞭解提示注入，但也知道這個問題目前無法解決。攻擊者仍在尋找新的注入方式。如果代理技能能夠訪問公司資料，它們可能存在哪些漏洞？

雖然程式設計民主化並不威脅SaaS公司，但智慧代理帶來了更深層次的挑戰。正如Jesus Rodriguez在《Salesforce的代理不會是Salesforce，Google的代理不會是Google》一文中指出的，Salesforce和Google這類服務的未來不是Web UI和儀表盤，而是專為代理設計的API。這些API需要不同型別的資料：不是供人類快速瀏覽的摘要，而是“結構化狀態、任務目標、關係圖、許可權化記憶、機器可讀的銷售手冊和可靠的意圖更新API”。人類需要儀表盤的資料壓縮，而代理需要資料本身，它們會自行處理壓縮。SaaS公司可以成為記錄系統，負責提供準確的資料。它們需要認識到，真正的客戶可能不再是人類使用者，而是代理。這將影響從營銷策略到產品設計再到定價的一切。

我不認為Salesforce或Google無法或不會構建API來幫助公司訪問自己的資料。SaaS仍然相關，但將是一種不同於現在的SaaS。像Salesforce這樣的公司知道哪些資料可用以及如何處理它們。設計和構建提供下一代SaaS所需的資料基礎設施並非易事，用英語而非C++程式設計並不會使其更容易。Salesforce和Google知道需要構建什麼。他們可能會提供自己的代理技能集合作為起點，同時提供API。但大型成熟公司如果行動遲緩，很容易被打個措手不及——而大型機構很難快速行動。

SaaS公司擁有動量——或者說慣性，從物理學家角度看是一回事。它們必須改變，但並不受AI、代理和使用者定義技能的威脅。提供專為機器可用格式設計的資料API應該是顯而易見的下一步。如果它們消亡，那將是因為未能適應。但這並非新鮮事。