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應用即將到來，我為那些仍在試圖將此類應用硬塞進不適合它們的系統設計的工程團隊感到惋惜。