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

[xvrzhao]

目前的场景是这样：

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

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

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

[Rickkkkkkk]

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

[whoosy]

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

[jacketma]

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

[GeruzoniAnsasu]

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

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

[isbase]

研究一下 vercel ai sdk

[laikicka]

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

[night98]

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

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