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应用即将到来，我为那些仍在试图将此类应用硬塞进不适合它们的系统设计的工程团队感到惋惜。