当大量用户同时使用 Agent 时需要处理并发访问。同时很多任务不能阻塞等着——需要异步执行。这两个问题在生产环境中几乎一定会遇到。但比负载更棘手的问题是多端同步——用户在 Web 端和 APP 端来回切换Agent 正在执行的任务怎么做到实时同步、不丢失、不乱序一、并发银行窗口模型理解并发就用银行窗口模型单个任务处理时间 10 秒 → 客户在窗口办业务并发数 → 同时开几个窗口吞吐量 → 银行一天能服务多少客户。并发挑战LLM API 有速率限制每秒只能调用有限次数单个 Agent 实例扛不住大量请求LLM 推理本身耗时1-5 秒串行处理效率极低解决方案Agent Runtime Gate 负载均衡用户请求 → Gate入口网关 ├─ Agent Runtime 实例 1 ├─ Agent Runtime 实例 2 └─ Agent Runtime 实例 NAgent Runtime并行运行每个实例独立处理请求Gate 负载均衡轮询、最少连接、权重分配等策略分散压力健康检查自动剔除故障实例水平扩展Docker 容器化 Kubernetes 自动扩缩容HPA Redis 做会话共享和状态同步。核心指标每秒请求数QPS。单实例 QPS × 实例数 总 QPS。二、异步任务架构同步模式要等上一个回答完再问下一个。异步模式让多个任务并行后台运行随时查看状态。架构流程创建 Task → 队列执行 → 监听状态变化 → 推送到前端核心组件TaskService接收请求将信息抽象为 Task 实例存入数据库和队列。Queue多任务排队Worker 逐个取出执行防止资源抢占。可以用 Redis Queue 或 RabbitMQ。Agent Runtime执行引擎本质是 ReAct 循环的异步版本。Step每个 Task 拆分为多个 Step记录每一步状态变化方便调试。状态机Pending → Queued → Running → Completed / Failed / Cancelled / Retrying每一步状态变化通过 SSEServer-Sent Events流式推送给前端。SSE 是轻量级 HTTP 协议服务器通过单一长连接向客户端推送更新。相比 WebSocketSSE 更简单纯 HTTP、浏览器原生支持、自动重连。定时任务TaskService 可以用 LLM 语义分析判断用户输入是否为定时任务需求如每天 9 点发报告生成 cron 表达式放入队列定时执行。三、多端状态同步五层架构当 Agent 需要支持多端Web / APP / API时单纯的负载均衡架构不够用了。用户可能在手机上开始一个任务到电脑上查看进度又切回手机继续。这需要五层架构来解决。第一层通信层端协议理由Web 端WebSocket全双工长连接延迟最低APP 端长连接 / SSEHTTP 标准兼容可做降级服务间内部gRPCProtocol Buffer 编码性能高性能后端维护连接注册表记录用户当前哪些端在线。Agent 状态一变 → 通过注册表广播给所有在线端。第二层状态存储层Event Sourcing核心思路——不存当前状态把所有发生过的事件一条条记录下来每步操作都是带版本号的不可变事件。组件作用PostgreSQL事件日志持久化Redis状态快照缓存 Pub/Sub 实时广播重连/离线上线追状态逻辑和 Git 一样客户端带上最后同步的版本号如 v32服务端返回 v33 到最新的增量事件客户端本地重放。不需要每次 clone 完整仓库只需要拉之后的 diff 合并。第三层增量同步 乐观更新增量同步基于版本号只传增量补丁不全量传输。乐观更新用户点暂停→不等服务器响应先立刻更新本地 UI→后台悄悄同步确认→一致则万事大吉不一致则回滚修正。用户感受零延迟。离线补偿离线期间所有本地操作存进待同步队列重新上线后拉服务端增量事件 → 与本地队列做三方合并 → 原子性一次提交幂等性设计所有写操作带唯一 request_id服务端对同一 ID 只处理一次网络重试安全。第四层三方合并进阶APP 端和 Web 端同时修改同一任务状态时找到两端操作的共同祖线版本作为基准分别看两边各自改了什么能自动合并的直接合并真正有冲突的才提示用户手动选择逻辑与 Git 的三方合并完全一致。第五层向量时钟进阶用于解决分布式环境下的因果排序问题——不依赖物理时钟通过逻辑时钟确定操作间的因果关系保证最终一致性。四、实践要点单实例 QPS 优先优化缓存 LLM 响应、减少不必要的工具调用比加实例更省钱异步是默认选择生产环境中所有耗时操作都应该异步同步模式只有调试时用状态机要有兜底所有状态都要有超时处理没有永远 pending的状态幂等性设计不能省网络重试是常态不是异常多端同步先用 Event Sourcing比手动维护状态表干净得多
