请教大佬们一个问题： Agent 后端架构如何设计？

节点赞助商

目前的场景是这样：

前端负责用户会话交互，后端接收请求，调用 llm 和工具调用（涉及多轮循环）
不同用户会话复用同一个 llm client ，根据用户 sessionId 持久化 message history (postgres)
后端发送 sse 消息通知前端实时更新后端活动（推理过程、工具调用、执行结果等）

思考了一轮下来，现在还剩一个问题就是：用户一次请求，后端可能会执行多轮 ReAct 循环，可能会比较耗时，可能会堆积 http 服务的并发，这种情况大家是怎么处理的？如果用异步队列的话，可能就用不了 SSE 向前端发送动态了。

或者说，业界有没有比较比较标准化的架构设计方式？

Supplement 1 · 2 days ago

感谢大家回答，也请教了一下 Claude ，大致得出的结论是：

用户提交问题之后，前端向后端发送 http 请求，后端接口这边的这条线是：

1. 记录消息历史
2. 把任务丢进队列
3. 订阅对应的事件消息
4. 把事件消息通过 SSE 推给前端
5. 如果收到的事件是 finish ，则结束这次 http 请求

大前提是，http 服务应该采用异步 io ，nodejs/python asyncio ，这样的话，在订阅事件时，等待的过程不会占用线程（协程、事件循环）。

Supplement 2 · 2 days ago

task worker 这边的处理逻辑是：
1. 从任务队列取任务
2. 加载历史消息（ from pg ）
3. ReAct 循环，将过程中的事件 pushlish 到 redis Pub/Sub channel
4. 持久化最终消息历史（ to pg ）
5. 发送结束事件
6. 协程结束

work 需要注意的点是，exception 兜底机制，向 redis 发送 error 事件，以免前端一直等待

agent

后端

架构

7 replies • 2026-07-01 05:23:48 +08:00

Rickkkkkkk

Jun 30

机器上部署 codex 的 cil ，用 cc-connect 和外部交互。

whoosy

Jun 30

基本都是异步队列整的，异步队列推到 redis stream ，前端订阅 http sse

jacketma

Jun 30

参考 2 楼的方案用的多，官方 App 也是把多轮 react 的循环状态，在前端提示给用户嘛。要不用户干瞪眼看着，多无聊了

GeruzoniAnsasu

Jun 30 via iPhone

我最近就在尝试研究 agent ，其实你让 claude“调研自己的环境”它就会告诉你。有几个关键词你可以让 AI 教你：

1. 认知循环
2. prompt/消息 authority
3. 分层缓存
4. subagent 与上下文隔离
5. tools 的 approve 门控
6. 进程沙箱
7. memory 系统

isbase

PRO

Jun 30 via iPhone

研究一下 vercel ai sdk

laikicka

Jun 30

直接用 ws 不是更好吗? codex 都抛弃 sse 了.

night98

2 days ago

异步队列和用 sse 给前端推动态是两个东西，异步队列解决的是并发堆积的问题。sse 是解决实时推送给前端的问题。

之前美团还是啥来着有个技术文档，大致意思就是有一个高性能的集群专门做 websocket 连接和保活，优化一下的话基本上保活的成本很低，然后 sse 就是正常的后端发事件到队列，集群订阅这个队列然后推到用户实际连接的对应的机器上然后推给用户再销毁消息。