在过去的数年里，主流 AI Agent 的使用方式本质上是一种同步的请求 - 响应模式：用户在聊天窗口中输入提示词，大语言模型通过 SSE 流式返回生成的令牌。这种模式构成了 ChatGPT、Claude Code 以及各类 AI SDK 演示应用的基础架构。然而，当 Agent 开始从后台任务、定时调度、跨设备继续等场景中运行时，这套基于 HTTP 的同步传输机制正在成为瓶颈。本文将深入分析这一范式转移背后的技术动因，并给出面向异步 Agent 的工程化架构建议。
同步交互范式的局限性
传统的 Chatbot 架构围绕单个 HTTP 请求构建：客户端发送包含提示词的请求，服务端调用 LLM 进行推理，通过 SSE 将生成的令牌流式返回至同一 HTTP 连接的响应体中。这种设计的核心假设是人类用户始终在线并保持连接。当页面刷新、网络中断或用户切换设备时，传输链路断裂，Agent 的工作随之终止。
现代 Agent 的使用场景正在突破这一假设。Anthropic 推出的 Remote Control 允许用户从手机继续桌面端的 Claude Code 会话；ChatGPT 的 Scheduled Tasks 支持定时触发 Agent 并在完成后主动通知用户；Claude Code 的 Routines 功能让 Agent 能够在后台执行预定义的工作流。这些能力的共同特征是 ** Agent 工作生命周期与单个 HTTP 连接的生命周期解耦 **。
具体而言，同步传输模式在以下四个场景中失效：第一，Agent 生存时间超过调用方 —— 定时任务触发后五十分钟返回结果，但调用方已离线；第二，Agent 需要主动推送 —— 后台任务完成后需要向用户发送 PR 审核请求，而非等待轮询；第三，调用方身份变化 —— 用户在桌面端启动任务后在手机端继续；第四，多人协作场景 —— 团队成员共同参与一个任务，Agent 需要向所有人推送更新并接收任意一方的输入。这些场景在传统 HTTP 请求 - 响应模型中缺乏原生支持。
异步架构的两层挑战
解决上述问题的核心在于将 Agent 架构分解为两个独立维度：持久化状态（Durable State）与持久化传输（Durable Transport）。前者涉及 Agent 的会话上下文、工作进度和输出结果如何在断开连接后仍然可访问；后者涉及响应数据如何在 Agent 与人类或其他 Agent 之间可靠传递，如何在设备切换、网络中断后自动恢复，以及如何支持服务器主动推送。
当前行业解决方案普遍侧重于解决第一个维度。Anthropic 通过 Routines 和 Remote Control 将更多会话状态迁移至托管平台，使 Agent 能够在不同设备间恢复上下文。Cloudflare 的 Sessions API 提供了会话与对话存储的持久化能力，支持客户端通过 HTTP GET 后续获取数据。然而，这些方案在传输层面的改进仍然有限：查询结果仍依赖轮询或 HTTP 请求，缺乏真正意义上的双向实时通信。
OpenClaw 模型提供了另一种思路 —— 将交互完全迁移至外部聊天平台（WhatsApp、iMessage、Telegram、Discord），利用这些平台已有的消息传递机制实现异步通知与上下文持久化。这种设计的优势在于利用现成的消息队列基础设施，但其局限在于定制化程度有限，难以满足企业级 Agent 的精细控制需求。
面向生产环境的工程实践
构建异步 Agent 系统需要在架构层面进行系统性升级。在持久化状态方面，建议采用独立的会话存储层，将对话历史、工作进度、中间结果与 LLM 推理引擎解耦。会话标识符应设计为可在不同连接间传递的持久化句柄，而非绑定到特定 HTTP 会话。状态存储可选用 Redis 集群（低延迟场景）或 PostgreSQL（需要强一致性场景），关键是要支持按会话标识符的快速恢复与跨设备同步。
在持久化传输方面，推荐引入支持双向通信且具备断线重连能力的实时消息中间件。WebSocket 是最基础的选项，但需注意其无法自动处理长时间断连后的消息可靠传递。更高层的方案包括采用 Ably 等实时消息平台提供的 Session 抽象，或自建基于发布 - 订阅模式的消息总线。核心设计原则是将 “会话” 提升为第一等公民：人类和 Agent 均可随时接入或断开会话，会话本身在后台持续运行并累积状态。
在工程参数层面，以下阈值可作为初始参考：连接心跳间隔建议设置为 15 至 30 秒，超时阈值可设定为 3 至 5 倍心跳周期；消息队列的分区或通道划分应按会话粒度设计，避免单点瓶颈；状态持久化的写入策略建议采用写透模式（Write-Through），确保 Agent 产生的每个关键状态变更立即落盘。
监控与可观测性要点
异步 Agent 系统的可观测性建设需要关注三个关键指标链。第一，传输层面监控包括连接建立成功率、消息投递延迟（端到端推送时间目标建议控制在 500 毫秒以内）、断线重连频率和消息丢失率。第二，状态层面监控涵盖会话恢复时延（会话中断后重新获取状态的 P99 目标应低于 2 秒）、状态一致性校验失败频率和存储层读写延迟。第三，业务层面指标包括 Agent 任务完成率、人类响应等待时间和任务超时放弃率。
建议在架构层面埋点时统一采用分布式追踪上下文，将一次完整的异步任务从触发到完成的完整链路串联起来，便于在跨服务调用中定位延迟热点与失败根因。
小结
Agent 正在从同步交互工具演变为后台持续运行的异步工作者。这一转变要求基础设施从面向单次 HTTP 请求的设计转向支持持久化状态与持久化传输的架构。会话不再是请求的附属物，而是需要被独立管理、跨设备共享、能够容纳多参与方的第一等抽象。对于计划在生产环境中大规模部署 Agent 的团队而言，投资构建这套异步基础设施的回报将在可靠性、可扩展性和用户体验维度上得到持续体现。
资料来源：本文技术细节主要参考 Zak Knill 在 zknill.io 发布的《All your agents are going async》一文，该文系统阐述了异步 Agent 的技术动因与行业解决方案。