LLM 和 AI Agent 打破 20 年架构假设，pub/sub 频道或成破局关键

【导语：过去十年，“云原生”架构基于 20 年前的假设构建，但 LLM 和 AI Agent 正打破这一假设，让传统架构越来越难用。本文深入分析了其中的问题，并介绍了可能的解决方案。】

20 年架构假设被打破

过去十年，“云原生”架构建立在状态存储在数据库、计算无状态的假设上。扩展时，垂直扩展数据库，水平扩展应用服务器，负载均衡器无需关心请求发送到哪个服务器，数据库是唯一真相来源。然而，LLM 和 AI Agent 正悄悄打破这一假设，让传统架构面临挑战。

传统架构的三大难题

首先是长时间运行任务，执行 10 分钟任务的 Agent 是长时间运行的异步进程，传统 HTTP 请求 - 响应模式无法处理。其次是有状态计算，Agent 运行多轮对话、处理多个工具调用，依赖累积的上下文，这种状态是 Agent 的记忆，而非传统数据库状态。最后是双向交互，用户想观看 Agent 思考过程、中断并重定向它，这是对进程说话，而非查询无状态 API。

为了解决这些问题，人们采用轮询的方式，但轮询体验糟糕，存在延迟选择、数据库负载、无效请求、流媒体 UX 极差等问题。轮询本质上是用数据库当消息队列，是在没有真正消息队列之前的无奈之举。

缺失的路由原语

Knill 认为当前架构缺失一个根本的路由原语，即一个可路由的传输名称，而非服务器。我们需要能够将消息投递给正在产生工作流 X 输出的任何人，而无需知道具体的机器、服务器副本或进程。

pub/sub 频道解决方案

Pub/sub 频道反转了所有权，服务器进程和客户端都不是可寻址的，传输层才是可寻址的。客户端和服务器都通过名称连接到 pub/sub 频道，获得双向、有状态的通信。频道是持久的，即使连接断开也能重连并继续与同一进程通信。

编辑观点：LLM 和 AI Agent 的发展让传统架构的局限性愈发明显，pub/sub 频道为解决这些问题提供了新的思路，有望推动架构的升级和发展。