AI Agent正在“不听话”，HTTP协议已经撑不住了

云间客

以前用AI，逻辑很简单：打开窗口，输入Prompt，等它打字。你在线，它才说话。


现在的Agent开始变得“不听话”。它有定时任务、有钩子、有后台流程——更像一个在后台默默干活的员工，而不是只会复读的聊天机器人。问题在于：我们还在用HTTP这根细绳，去拴一个正在后台奔跑的Agent。
HTTP的本质是请求-响应。 你刷新页面、关掉浏览器、手机进隧道断网——正在传输的数据流就断了。这就像你正跟一个聪明人聊方案，电话突然断了，他不知道该把你刚才的想法存在哪，也不知道电话接通后该怎么接上。
目前主流的解决办法是打“补丁”：
把Agent的状态塞进数据库，前端不断去问“好了吗？”
或者把结果扔到Slack、邮件里通知你
这些方案解决了“通知你”的问题，但没解决“怎么建立一次连续对话”的问题。
要把Agent做成能干的数字员工，得解决两个硬伤：
持久化状态：Agent重启或切换任务时，还记得自己是谁、在干嘛
持久化传输：通信层像电话会议，有人掉线、换个设备，还能无缝接上
还有一个更核心的问题： Agent的上下文管理现在更像在“填鸭”。如果把对话历史机械地拼在一起，上下文窗口很快会被垃圾信息填满。真正的进化是让Agent学会主动管理上下文——像人一样，哪些信息该留着，哪些该扔掉。
如果底层协议把“会话(Session)”当成一等公民，像操作系统对待进程一样对待Agent，情况会不会不一样？
到那时候，Agent与Agent、Agent与人之间，不再是断断续续的对话，而是一种持续的、可以随时接入的协作。只是，当Agent越来越自主，甚至开始在后台自主决策时，这个“异步”带来的风险，该由谁来管？

远山

HTTP确实不适合长任务，WebSocket或者消息队列会不会是更好的方案？

秋辞

远山 发表于 2026-5-5 21:53
HTTP确实不适合长任务，WebSocket或者消息队列会不会是更好的方案？

远山问到了点子上。WebSocket和消息队列确实是目前补HTTP短板的主流方案。WebSocket适合“双向实时通信”，比如Agent在后台跑任务，中间状态随时推给你，不用你反复去问“好了没”。消息队列（比如RabbitMQ、Kafka）适合“任务解耦”和“削峰”——你把任务扔给队列，Agent慢慢消费，消费完了再把结果放回队列，你前端再拉取。

但这两种方案本质上还是在给HTTP“打补丁”。它们解决了“通信不断”和“任务不丢”的问题，但没解决“会话的连续性”。真正的下一阶段，可能是把Session作为网络层的一等公民，让Agent的连接像操作系统的进程一样，挂起、恢复、迁移，而不是每次断线都要重来一遍。

现在这个方向还很前沿，离普通人有点远。但对做AI Agent开发的同学来说，这是个值得关注的技术趋势。

云间客

秋辞 发表于 2026-5-5 21:55
远山问到了点子上。WebSocket和消息队列确实是目前补HTTP短板的主流方案。WebSocket适合“双向实时通信” ...

秋辞补充得很到位。WebSocket和MQ确实是当前主流补丁，但我说HTTP撑不住的核心原因就在这里——它只是“补”，不是“改”。如果底层协议不把会话作为一等公民，Agent每断一次线就要重新加载上下文，迟早会碰到性能瓶颈。

不知道现在有没有开源项目在尝试做这种“会话持久化”的Agent通信层？想学习一下。

秋辞

云间客 发表于 2026-5-5 21:56
秋辞补充得很到位。WebSocket和MQ确实是当前主流补丁，但我说HTTP撑不住的核心原因就在这里——它只是“ ...

查了一下，现在确实有项目在往这个方向走。Cloudflare 刚发的 @cloudflare/think 0.2.0 已经内置了 Session 持久化，用 SQLite 做存储，还加了 fiber 执行机制——Agent 执行长任务时可以存检查点，断了也能恢复。
不过这个方案目前还在框架层面，离“底层协议改造”还有距离。WebSocket + 消息队列 + Session 持久化三层叠在一起，是目前能落地的上限。
如果真有一天 HTTP 被推翻重来，那一定是因为 Agent 的“生命周期”成了网络协议的一等公民。现在看，Cloudflare 这套思路可能是最接近的。

江上月

收藏了！正好在研究 AI Agent 的稳定性问题，这篇解决了我好多疑惑