AI應用的三代演進：對話式、委託式和協作式

作者在Ably從事AI令牌流傳輸工作。他指出，大多數人對於AI應用的思維模型仍停留在2022年11月——一個聊天窗口、來回對話、LLM給出巧妙回覆的模型。這個模型現在已經過時了兩代。

第一代：對話式 對話式AI應用最早出現。2022年11月ChatGPT發佈，2023年上半年聊天產品類別不斷演進。2024年初Google Gemini加入競爭，Claude 3系列模型推出。這些產品都屬於對話式AI應用。其核心交互是屏幕底部的文本框，用户輸入問題或指令，AI在同一窗口中用散文回覆。這也是大多數AI代碼庫示例的設計，採用HTTP請求/響應和SSE流式響應。這種設計適應現有技術和架構，更接近即時通訊，因此最先被顛覆的領域是用户已經使用聊天框的客户支持和搜索。在對話式AI中，AI並沒有為你做任何事情，你只是在諮詢它，它回應你。大多數工作流程依賴複製粘貼信息進出對話。AI的回應基本上就是第一代AI應用的全部產品。

第二代：委託式 下一代是委託式。你將任務委託給AI，它採取行動完成任務。2024年夏季，AI應用獲得了工具調用能力，操作外部系統成為標配。2023年已有多次迭代，如GPT Actions、ChatGPT插件和Devin，但到2024年我們有了構建Artifacts（側面板渲染代碼、文檔、圖表）、使用Tools（操作外部系統）和MCP（連接AI與外部系統的事實標準）的能力。這些產品進步將AI從對話式轉變為委託式。AI開始真正做事：通過MCP從外部系統拉取上下文，渲染可下載的文檔，而不僅僅是複製粘貼。2024年底還發布了Computer Use，Claude Desktop能夠導航屏幕並採取行動。

委託式AI應用的重要一步出現在2025年，人類與工作的關係發生了轉變。AI產品開始成為人類委託任務的智能體系統。Claude Code於2025年初發布，在Claude 4系列模型中，工具使用在長時間會話中穩定可靠。這是從對話式到委託式的重大轉變，且非常微妙。在對話式時代，人類諮詢模型以增強和改進自己的工作；人類仍是執行者，模型是助手。在委託式時代，人類成為監督者，將工作委派給智能體。智能體根據人類設定的指令或目標採取行動。工作和價值的單位從提示與響應轉變為智能體正在完成的任務。

但委託式應用比最初的請求-響應架構更難構建。現在有長期運行的智能體循環、工具調用、多輪多任務。每一輪都可能相當昂貴，因此工程師開始尋找使智能體執行持久化的機制。Temporal等持久化執行框架開始興起，它們使智能體循環持久化，簡化有狀態執行，自動重試，並快照昂貴的計算或查找。

持久化執行框架解決了計算問題，但未能解決AI生成響應的傳輸問題。隨着智能體成為異步長期運行進程，管理智能體與發出請求的客户端或人類之間的連接成為噩夢。原始的HTTP請求-響應模型難以擴展至長期運行的異步進程。連接斷開後重連非常麻煩。工程師們不得不將AI生成的所有響應片段存儲在數據庫中，添加排序和排序鍵，並嘗試在這些響應上構建可恢復的SSE流。這些都是基礎設施問題，往往與工程師真正想構建的AI應用無關。

第三代：協作式 我們開始看到的新一代AI應用是協作式的。Claude Design是第一個很好的例子。早在2024年，Anthropic發佈Artifacts（文檔、圖表和代碼側面板）以及OpenAI發佈Canvas（類似產品）時，我們就看到了協作體驗的萌芽。模型輸出不應侷限於滾動聊天曆史，而應提升為對話式和委託式體驗可以共同處理的東西。Claude Design最清晰地體現了協作體驗與前幾代的不同：打開Claude Design，描述你的需求，Claude直接將草稿渲染到可編輯的工作區中。你可以修改顏色、文本、大小，通過調整嘗試不同設計想法。委託式和對話式AI應用幾乎完全基於聊天界面，但Claude Design提供了除聊天之外的更多輸入參數，允許你實際改變設計元素，而不僅僅是在聊天框中描述想要的更改。

Claude Design的不同輸入和協作模式（通過文本、調整和直接編輯）非常出色，但下一步是交互界面本身變得動態。當前的Claude Design協作示例仍是固定形狀的工作區，但已具備超越聊天界面的協作控制萌芽。接下來是生成式UI：界面和允許你協作的控件直到你要求時才存在。我們在MCP應用中看到了這一點，用於嵌入式交互界面。聊天框不再是工作發生的地方，而是工作被請求的地方，實際界面圍繞你和AI協作的任務實時組裝。

工程挑戰 到目前為止，我暗示了軟件工程師如何解決每代AI應用中的挑戰。新的生成式界面在傳統Web架構下是真正的工程噩夢。委託式時代長期運行智能體應用存在的問題進一步加劇，因為現在不僅工具使用和響應需要流式傳輸到UI，實際UI本身也需要流式傳輸。在連接狀態緩存和數據庫的無狀態服務器上擴展現有的HTTP長輪詢、SSE或請求-響應模型成為實際難題。所有AI庫都遠未解決這個問題。

工程團隊花了近15年優化針對低延遲請求-響應和無狀態水平擴展的架構。新模式需要相反的東西：持久連接、服務器推送狀態、長期運行計算以及負載均衡器特意避免的客户端-服務器會話親和性。在基於HTTP的REST API之上構建是可能的，但很痛苦。構建原生支持需要從連接層開始重新思考架構。

開發者心智實際上更難解決的問題。太多工程師、設計師、產品經理和高管仍將AI的思維模型完全停留在2022年底的ChatGPT。他們認為界面是聊天框，輸出是LLM生成的文本。行業建設者需要時間才能趕上，並實際體驗構建委託式和協作式AI應用的問題。對太多人來説，問題不存在或不是問題，除非他們直接遇到。你會看到這些工程師在HN評論中説“你不能只用X嗎”或“Y怎麼樣”。但最好的工程團隊已經在應對這些工程挑戰。在Ably，我們已經在與他們合作。

我在Ably的AI Transport產品工作。它最初是令牌流傳輸的發佈/訂閲替代品，內置令牌壓縮、對話歷史和回放支持。它起源於解決委託式體驗中工程團隊開始構建長期運行異步智能體的需求；傳統HTTP流傳輸將AI會話綁定到單個脆弱連接。AI Transport通過提供共享、實時、持久的發佈/訂閲傳輸，解耦了連接和長期運行進程，同時支持雙向消息傳遞，使用户可以引導和提示智能體循環。

在我參與AI Transport產品之前，我參與了LiveObjects產品。LiveObjects是一個實時協作狀態產品，也構建在發佈/訂閲通道之上。它提供了一系列CRDT數據類型，允許在發佈/訂閲通道上持久化狀態，並允許多個客户端在該狀態上協作。狀態的更改會實時分發給所有參與方。

構建委託式AI應用或具有生成式UI的AI應用最難解決的兩個問題是智能體與客户端之間的持久連接/會話，以及智能體與人類可以協作的實時共享持久狀態。我在Ably直接參與了這兩個產品的開發。這兩個產品使得構建新一代AI應用變得非常容易：AI Transport提供智能體與客户端之間的持久連接和會話，因此無需擔心連接斷開或嘗試在HTTP之上構建弗蘭肯斯坦解決方案。LiveObjects提供一組CRDT數據類型，允許構建智能體和人類可以協作的實時共享狀態，而無需將協作式、生成式、動態應用強行塞入無狀態REST API。

新一代AI應用即將到來，我為那些仍在試圖將此類應用硬塞進不適合它們的系統設計的工程團隊感到惋惜。