你的所有智能体都将走向异步

# 你的所有 agent 都在异步化 — /dev/knill 来源：https://zknill.io/posts/all-your-agents-are-going-async/ **过去，agent 是你同步对话的对象；现在，它们在你工作时于后台默默运行。一旦改成这样，传输层就崩了。** 自 LLM 诞生以来，最常见的用法就是打开一个聊天窗口，输入提示词，然后看模型逐字流式返回。ChatGPT、claude.ai、Claude Code 以及几乎所有 AI SDK 的演示都是这么干的。于是大家误以为“聊天机器人”就是 AI 能力的上限。事实并非如此。 传统设计围绕单次 HTTP 请求 **现实是：你的所有 agent 都在异步化**。它们开始支持定时任务（cron）、Webhook、WhatsApp 集成、手机“遥控”、定时任务与例行程序。agent 变成后台长驻进程，在你敲代码、开会、睡觉时默默干活，做完再异步汇报。Temporal、Vercel WDK、Relay.app 等工作流引擎都在帮它们实现这一点。人类坐在终端前“一问一答”只是其中一种交互，而且越来越不是最有趣的那种。真正有趣的是无人值守时 agent 能做什么。 问题在于，聊天机器人基于 HTTP：一次请求附提示词，SSE 流式把 token 返回来。一旦 agent 异步运行，这条 HTTP 连接早断了，回应往哪儿发？ ## OpenClaw 的异步一步 OpenClaw 把 agent 搬进 WhatsApp，让大家意识到：agent 可以随身跑，后台处理任务。你无需钉在浏览器或终端前，它就能替你干活。 OpenClaw channels 模型 Anthropic 的对标方案是 [Channels](https://code.claude.com/docs/en/channels)（基于 MCP），可把外部聊天消息异步推进 Claude Code 会话；再加上 `/loop`、`/schedule` 斜杠命令与 [Routines](https://code.claude.com/docs/en/routines)，以及 [Remote Control](https://code.claude.com/docs/en/remote-control) 手机续会话功能，都是让 agent 在后台跑。 ChatGPT 的 [scheduled tasks](https://help.openai.com/en/articles/10291617-tasks-in-chatgpt) 也能定时唤醒 agent，必要时再联系你。 Cursor 的 [background agents](https://cursor.com/docs/cloud-agent) 直接在云端后台运行。 这些功能都在做同一件事：把“人必须坐在聊天窗口前”这一假设拆掉，让交互变成连续、远程、长时、异步。 ## 传输层错位 这些异步能力都有一个共同点：agent 的生命周期与单次 HTTP 连接的生命周期**脱钩**。在演示应用里，HTTP 一断，agent 就“死”。LLM 推理靠 HTTP 请求触发，token 靠 SSE 流回来。我早说过[聊天机器人最大的敌人是 F5 刷新](https://zknill.io/posts/chatbots-worst-enemy-is-page-refresh/)，根因就是传输层错位：HTTP 扛不住刷新，更扛不住异步场景。 旧传输搞不定的四种情况： 1. **agent 比调用方活得长**：定时任务触发，或任务跑太久。五分钟后出结果，却没人监听。结果只能先落库，再给个会话 URL 让你轮询——烂体验。 2. **agent 要主动推送**：夜间扫档生成三条 PR 等你审；或工作流卡在人审环节，需要你先点“确认”。此时没有回连通道，只能发邮件或 Slack 消息。 3. **调用方换了设备**：桌前发起，吃完饭想用手机看一眼。Anthropic Remote Control 靠自建会话存储才能续上，HTTP 本身并不支持。 4. **多人同会话**：五人小组协作，agent 要能把更新推给所有人，也能接收任意人的输入。 大家之所以觉得 OpenClaw 爽，是因为它把这些全包圆了：把“agent 干活的生命周期”与“人连不连得上”彻底分离。agent 异步执行，做完用 WhatsApp、iMessage、Telegram、Discord 等异步通道把结果推给你——HTTP 请求-响应根本做不到。 ## 行业怎么补锅？ 目前各家解法不一。OpenClaw 模式算一种：所有交互走外部聊天平台，平台自带聊天记录，agent 重启也能续上下文。但这只是聊天模型的延伸，并非最有趣的路线。 更多厂商把会话状态往自家中心托管。Anthropic 的 Routines、Remote Control 就把会话历史、推理状态全搬进自家云；不再只做纯 LLM API，而是接管整个 agent 生命周期。Cloudflare 也入局，基于 Workers 做 [Agents 平台](https://developers.cloudflare.com/agents/)，其 [Sessions API](https://developers.cloudflare.com/agents/api-reference/sessions/) 提供会话存储，并通过 HTTP 暴露；异步通知靠新推出的 [Email for Agents](https://blog.cloudflare.com/email-for-agents/)。 ## 只解决了一半 问题其实拆成两半： - **耐久状态**：agent 状态存哪儿？重启或异步任务时怎么读取？输出放哪儿？ - **耐久传输**：结果字节怎么送到人或其他 agent？连接断了、换设备、服务端要推送、一对多广播时怎么办？ Anthropic、Cloudflare 目前主攻前半——帮 agent 存状态。至于“怎么把字节送到你手里”，还是靠轮询或额外 HTTP GET。Cloudflare 虽有 WebSocket，但断线后也无法续流式 LLM 响应。他们的思路是：数据我都存好了，客户端自己轮询来取——能用，但谈不上“优雅”。 ## 耐久传输 + 耐久状态 如今会话和传输被捆在一个 HTTP 请求-响应里。Cloudflare 和 Anthropic 让会话状态耐久，却没解决传输层：你仍得轮询才能知道有没有新消息。OpenClaw 把聊天记录放聊天通道，agent 进程与 LLM 提供方都解耦，可这套“企业级自托管”版本在 Cloudflare 或 Anthropic 上根本搭不出来——缺的就是耐久传输 + 耐久状态的方案。 我在 [Ably](https://ably.com/ai-transport) 工作，我们正在给 AI agent 造这样一条“耐久传输”，核心概念就是“会话”。我们基于已有的实时消息平台做扩展。看着大家一次次重复踩坑，就因为最初选错传输层——HTTP 请求-响应，实在憋屈。 Ably 的传输 AI“会话”应该让人和 agent 随时连、随时断；Wi-Fi 掉线、手机进隧道都不影响，人类和 agent 都无需关心重连。OpenClaw 和现代异步 agent 应用能做到这一点，靠的是会话本身耐久：聊天记录存在会话里，双方通过会话互相通知。会话应成为构建异步 agent 的一等原语。 正因我们已有双向、耐久、实时的消息传输，且原生支持多设备、多用户，现在只需在之上叠加会话状态与聊天记录，就能一次性解决“耐久传输 + 耐久状态”两半难题。