性能优化不是只看响应速度，还要看稳定性、可恢复性和成本。你的目标是“高峰时不乱，低峰时不浪费”。
本章完成标准
你能完成一套可观测、可限流、可恢复的部署基线，并知道何时从单实例升级到多实例。
先记住官方第一原则
大多数场景只需要一个 Gateway。单实例稳定后，再考虑扩展。
步骤一：先做观测，再做优化
openclaw status
openclaw gateway status
openclaw logs --follow- 记录高峰时 CPU、内存、消息积压和响应时间。
- 先定位瓶颈是模型调用、工具执行还是消息队列。
- 每次只改一个变量，避免“改完不知道哪项生效”。
步骤二：优先使用队列治理
比起盲目加并发，先让队列行为可控，通常更稳定。
{
messages: {
queue: {
mode: "collect",
debounceMs: 1000,
cap: 20,
drop: "summarize"
}
}
}步骤三：并发与重任务拆分
- 常规对话保持低并发，保障用户体验。
- 重任务交给 sub-agent 或独立实例。
- 模型调用设置 fallback，防止单模型故障拖垮链路。
步骤四：部署与容灾基线
- 固定端口、固定目录、固定启动方式。
- 定期备份状态目录和关键配置。
- 做一次“服务重启 + 会话恢复”演练。
何时升级到多实例
- 渠道与会话量持续超出单实例承载。
- 需要故障隔离（某渠道异常不影响全局）。
- 有明确容灾目标（主备切换或救援网关）。