openclaw - 💡(How to fix) Fix [Bug]: 多 Agent 部署下性能严重瓶颈：Gateway 内部上下文加载缓慢及事件循环饥饿

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

我在 OpenClaw 环境中部署了 5 个 Agent（1 个主 Agent，4 个子 Agent），每个 Agent 都有独立的 Telegram Bot 连接和独立 API Key。经过详细排查，发现系统在高负载（多 agent 并发请求）下存在严重的性能瓶颈，主要表现为 Gateway 内部的会话上下文加载时间过长 (session-resource-loader, bootstrap-context) 和 任务分派阶段的显著排队 (attempt-dispatch)，导致请求响应时间高达几十秒甚至上百秒。怀疑是 Gateway 的单进程/单线程事件循环在多 Agent 场景下无法高效处理导致的资源争抢。

Steps to reproduce

问题详细描述：

在部署多个 Agent 后，系统响应速度显著下降，尤其是在 Agent 首次响应或有其他 Agent 正在活跃时。这与 Agent 使用的模型、API 速度、Ollama Embedding 模型选择无关。我们的诊断日志显示了以下关键性能瓶颈：

1. 巨大的 session-resource-loader 和 bootstrap-context 耗时：

• 在一次请求处理的 prep stages 中，session-resource-loader 耗时高达 66 秒至 85 秒。 • bootstrap-context 耗时也达到 31 秒至 38 秒。 • 分析：这两个阶段负责加载 Agent 的会话历史、上下文、依赖配置、及构建运行环境。当会话历史（.trajectory.jsonl 文件）积累到几十兆字节（例如 28MB / 28000K tokens，且单个会话轨迹文件可达 10MB，约 2.6M tokens），每次全量加载这些“冷”会话的资源都成为巨大的 I/O 和 CPU 密集型操作，严重阻塞了 Gateway 的处理流程。 2. attempt-dispatch 阶段的长时间排队：

• 日志显示 attempt-dispatch 阶段耗时高达 63 秒。 • 分析：这直接表明 Gateway 在分派任务给 Agent 执行前，由于内部资源争抢或事件循环阻塞，导致请求长时间处于等待状态。这与 5 个 Telegram bot 同时进行的**长轮询（polling）**对 Gateway 的单进程事件循环造成冲击高度相关。日志中 timer delayed 48164ms, likely event-loop starvation 也印证了主事件循环被长时间阻塞。

Expected behavior

核心问题归因： OpenClaw Gateway 在当前部署模式（单 Gateway 进程处理多个 Agent，多个 Agent 使用各自的 Telegram bot 进行长轮询）下，其内部的会话上下文管理和事件循环处理机制在面对多 Agent 并发访问时，无法保持高性能。

我们的环境信息：

• CPU: 4 cores (Gateway 进程平稳占用约 27%) • 内存: 7.6GB (充足，Gateway 进程 RSS ~1GB) • GPU: 无 (纯 CPU 运行) • Ollama Embedding Model: 已切换为 nomic-embed-text (比 mxbai-embed-large 更快)，autoRecall/autoCapture 已关闭。 • 活跃 Agents: 5 个 Agent，每个都有独立的 Telegram bot。

Actual behavior

寻求的解决方案： 我们希望了解到：

1. OpenClaw 是否支持为每个 Agent 启动独立的 Gateway 进程或子进程？ 如果是，具体的配置或部署方法是什么？这将有效地隔离 Agent 间的资源竞争和事件循环阻塞。
2. 如果不支持独立的进程，是否有其他推荐的部署架构或优化策略，以提高单个 Gateway 进程在多 Agent 环境下的性能表现？例如，是否存在对大规模会话上下文进行惰性加载、增量更新或更高效内存管理的方法？
3. 是否有计划在未来的版本中优化 Gateway 在多 Agent 并发场景下的性能，特别是针对 session-resource-loader 和 bootstrap-context 的耗时以及 event-loop starvation 问题？

我们目前的缓解措施（和你的建议相反）：

• Embedding 模型已切换为 nomic-embed-text (为了加速本地向量化计算)。 • 已关闭 autoRecall 和 autoCapture 功能，以减少每次对话的额外 Ollama embedding 负载。

但这些并没有根本解决 session-resource-loader 和 attempt-dispatch 的主要瓶颈。

我们期待您的指导和帮助，以便我们能更好地利用 OpenClaw 平台。

致谢，

OpenClaw version

2026.5.12

Operating system

Ubuntu 24.04

Install method

docker

Model

deepseek/deepseek-v4-flash

Provider / routing chain

deepseek/deepseek-v4-flash

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response