从"等半天没响应"到恢复秒回,一篇实战教程带你定位问题、优化配置。
GitHub Issue 参考:#55103[1]、#53330[2]、#49272[3]
发一条消息给 OpenClaw Agent,等了 10 秒、20 秒甚至更久才收到回复?
这不是错觉,也不是模型"变笨了"。我在实际使用中多次遇到这个问题,排查后发现背后有明确的技术原因,而且——完全可以解决。
这篇文章会带你一步步排查,从原因分析到配置优化,最终让你的 OpenClaw 恢复高效响应。
问题现象:你是否遇到了这些"慢"?
先对照一下,看看你是否踩中了这些"雷点":
| 现象 | 具体表现 |
|---|---|
| 响应超长等待 | 发消息后等待超过 10 秒甚至更久 |
| 对话越长越慢 | 刚开始很快,聊了十几轮后明显变慢 |
| 重启后短暂恢复 | openclaw gateway restart 后变快,过会儿又慢了 |
| 日志出现警告 | Summary unavailable due to context limits |
| Agent 速度差异大 | 某些 agent 快,某些 agent 特别慢 |
如果你中了 2 条以上,这篇文章就是为你准备的。
原因一:模型选型——最容易被忽略的"元凶"
不同模型的响应速度差异极大,这是最常见的原因,也是最容易被忽略的。
模型速度对比
| 模型类型 | 代表模型 | 速度 | 适用场景 |
|---|---|---|---|
| 快速模型 | claude-haiku-4-5、qwen3.5-plus | ⚡ 最快 | 日常问答、运维任务、快速查询 |
| 中速模型 | claude-sonnet-4-6、qwen3-max | 🚗 中等 | 写作、内容生成、技术文章 |
| 重模型 | claude-opus-4-6、kimi-k2.5 | 🐢 最慢 | 复杂推理、多工具调用、战略规划 |
验证方法:快速模型测试
怀疑是模型问题时,最简单的验证方法是临时切换快速模型:
/model bailian/qwen3.5-plus如果切换后响应明显变快,那就确认了:问题根源是模型选型。
选型原则
根据 agent 的职责选择合适的模型:
| Agent 类型 | 推荐模型 | 为什么 |
|---|---|---|
| 运维/工具类 | Haiku / qwen3.5-plus | 速度优先,减少等待 |
| 写作类 | Sonnet / qwen3-max | 速度与质量平衡 |
| 复杂规划类 | Opus / kimi-k2.5 | 准确性优先,可接受慢 |
原因二:Skills 泛滥——看不见的 token 膨胀
每个 skill 都会向 system prompt 注入一段描述,skill 越多,每次请求的 token 就越多。
技术细节
- • 每个 skill 约占用 97 字符 + 描述长度
- • 如果你装了 33 个 skill,system prompt 开销可达数千 token
- • 更严重的问题:所有 agent 共享同一批 skill,wechat agent 加载了飞书相关 skill,pm agent 加载了公众号写作 skill,互相污染
验证方法
openclaw skills list --eligible看看你的 agent 实际加载了多少 skill。如果超过 15 个,就该精简了。
原因三:上下文膨胀——对话历史的隐形负担
对话轮次越多,携带的历史 token 越多,API 请求体积越大,响应越慢。
safeguard 模式的陷阱
OpenClaw 默认的 compaction 模式是 safeguard,当上下文超过约 18 万 token 时会静默失败,输出 Summary unavailable due to context limits。
这是 GitHub issue #55103[1] 报告的问题:
"When a session grows past the context window limit before compaction triggers, the compaction summarization itself can fail, resulting in the fallback message..."
结果:上下文持续膨胀,越来越慢。
Tool Result 也会膨胀
飞书操作、文件读写等工具调用产生的 tool result 体积很大,会加速上下文膨胀。
验证方法
开一个全新的 session 测试:
/new如果新 session 明显更快,说明是上下文膨胀问题。
原因四:Compaction 黑盒——30-60 秒的无响应
这是 GitHub issue #53330[2] 描述的问题:
"When a session approaches the model context window limit, compaction + memory flush can take 30-60 seconds, during which the user sees silence."
当 context window 快满时,OpenClaw 会触发 compaction(压缩),这是一个同步阻塞操作:
- • Agent 停止响应
- • 整个上下文被发送给 LLM 进行摘要
- • 用户看到的是"黑屏等待"
解决方案:提前配置好 compaction 参数,让压缩在更早的阶段触发,避免临到 context limit 才紧急处理。
原因五:网络延迟——跨境 API 的天然瓶颈
如果你的服务器在国内,访问 Anthropic、OpenAI 等境外 API 天然存在网络延迟。
验证方法
curl -o /dev/null -s -w "连接时间: %{time_connect}s\n总时间: %{time_total}s\n" \
https://api.anthropic.com如果连接时间超过 1 秒,网络就是瓶颈。
解决方案
- • 使用国内中转 API(如百炼 bailian)
- • 或配置代理服务器
四步解决方案
找到原因后,按以下方案逐一优化。
方案一:按 Agent 分配合适的模型
在 openclaw.json 中为每个 agent 单独设置模型:
"agents": {
"defaults": {
"model": {
"primary": "bailian/qwen3.5-plus"
}
},
"list": [
{
"id": "wechat",
"model": {
"primary": "bailian/qwen3-max-2026-01-23",
"fallbacks": ["bailian/qwen3.5-plus"]
}
},
{
"id": "pm",
"model": {
"primary": "bailian/kimi-k2.5",
"fallbacks": ["bailian/qwen3-max-2026-01-23"]
}
}
]
}核心原则:
- • 默认用快速模型(qwen3.5-plus)
- • 写作类 agent 用中速模型(qwen3-max)
- • 复杂规划类 agent 用重模型(kimi-k2.5)
方案二:精简 Skills,按 Agent 隔离
第一步:把通用 skill 移到全局共享目录
# 所有 agent 都用到的 skill 放这里
mv /root/.openclaw/workspace-wechat/skills/agent-tools ~/.openclaw/skills/
mv /root/.openclaw/workspace-pm/skills/clawhub ~/.openclaw/skills/第二步:用 skills.entries 限制可见范围
"skills": {
"allowBundled": ["clawhub", "skill-creator", "weather", "session-logs"],
"entries": {
"feishu-doc": { "agents": ["pm", "main"] },
"feishu-bitable": { "agents": ["pm", "main"] },
"wechat-article-writer": { "agents": ["wechat"] },
"wechat-tech-article": { "agents": ["wechat"] },
"baoyu-post-to-wechat": { "agents": ["wechat"] }
}
}效果:每个 agent 只加载自己需要的 skill,token 消耗减少 30-50%。
方案三:配置上下文自动压缩
这是最关键的优化。将 safeguard 模式替换为更可靠的配置:
"agents": {
"defaults": {
"compaction": {
"mode": "default",
"model": "bailian/qwen3.5-plus",
"reserveTokensFloor": 40000,
"memoryFlush": {
"enabled": true,
"softThresholdTokens": 60000,
"prompt": "将本次会话的关键信息整理到 memory/YYYY-MM-DD.md。重点保留:决策结论、任务进展、重要数据、待办事项。无重要内容则输出 NO_FLUSH"
}
},
"contextPruning": {
"mode": "cache-ttl",
"ttl": "6h",
"keepLastAssistants": 3
}
}
}关键参数解释:
| 参数 | 作用 |
|---|---|
mode: "default" | 用 AI 真正摘要,比 safeguard 可靠 |
model | 用便宜快速模型做压缩,主对话模型做正式回复 |
reserveTokensFloor: 40000 | 提前触发压缩,给摘要 API 留足空间 |
memoryFlush.enabled: true | 压缩前先把重要内容写到每日记忆文件 |
contextPruning.mode: "cache-ttl" | 按时间剪枝旧上下文,减少重复计算 |
方案四:日常维护操作
除了配置优化,日常维护也很重要:
# 手动触发压缩
/compact
# 带指令压缩(保留特定内容)
/compact 保留所有任务清单和决策记录
# 开启新 session
/new
# 重置当前 session
/reset建议:每聊 20-30 轮后,主动 /compact 一次;每天开始工作时 /new 开新 session。
快速排查流程
遇到慢问题时,按这个流程排查:
发现响应慢
↓
切换 Haiku/qwen3.5-plus 测速
├─ 明显变快 → 模型问题 → 调整 agent 模型配置
└─ 还慢
↓
查 skills 数量(openclaw skills list --eligible)
├─ 超过 15 个 → 精简 skills,用 skills.entries 隔离
└─ 还慢
↓
开新 session 测试
├─ 明显变快 → 上下文膨胀 → 配置 compaction
└─ 还慢
↓
测 API 网络延迟(curl 测试)
├─ 连接 > 1s → 换国内中转 API 或配代理
└─ 还慢
↓
查服务器资源(top / free -h)完整配置示例
将以下内容合并到 ~/.openclaw/openclaw.json:
{
"agents": {
"defaults": {
"model": {
"primary": "bailian/qwen3.5-plus"
},
"compaction": {
"mode": "default",
"model": "bailian/qwen3.5-plus",
"reserveTokensFloor": 40000,
"memoryFlush": {
"enabled": true,
"softThresholdTokens": 60000,
"prompt": "将本次会话的关键信息整理到 memory/YYYY-MM-DD.md。重点保留:决策结论、任务进展、重要数据、待办事项。无重要内容则输出 NO_FLUSH"
}
},
"contextPruning": {
"mode": "cache-ttl",
"ttl": "6h",
"keepLastAssistants": 3
}
},
"list": [
{ "id": "main" },
{
"id": "wechat",
"model": {
"primary": "bailian/qwen3-max-2026-01-23"
},
"skills": ["wechat-article-writer", "wechat-tech-article"]
},
{
"id": "pm",
"model": {
"primary": "bailian/kimi-k2.5"
},
"skills": ["feishu-doc", "feishu-bitable", "feishu-task"]
}
]
},
"skills": {
"allowBundled": ["clawhub", "skill-creator"],
"entries": {
"feishu-doc": { "agents": ["pm", "main"] },
"wechat-article-writer": { "agents": ["wechat"] }
}
}
}修改完成后重启 gateway:
openclaw gateway restart写在最后
OpenClaw 对话变慢,本质上是资源管理和配置优化的问题。
核心要点:
- 1. 模型是第一因素——先用快速模型验证,排除后再查其他
- 2. Skills 要隔离——每个 agent 只加载自己需要的
- 3. Compaction 要配置好——
mode: "default"+ memoryFlush 防止上下文膨胀 - 4. 日常维护很重要——定期
/compact和开新 session
优化是一个持续过程。建议每两周检查一次:
- •
openclaw skills list --eligible—— skill 数量是否超标 - •
openclaw status—— gateway 运行状态 - •
/status—— 当前 session 的 token 使用量
保持这些习惯,你的 OpenClaw 就能长期保持高效响应。
参考资料:
- • OpenClaw Session Management Deep Dive[4]
- • GitHub Issue #55103[1]
- • GitHub Issue #53330[2]
- • GitHub Issue #49272[3]
本文基于 OpenClaw 官方文档和 GitHub issues 排查经验整理,版本:2026-03-30
引用链接
[1] #55103: https://github.com/openclaw/openclaw/issues/55103
[2] #53330: https://github.com/openclaw/openclaw/issues/53330
[3] #49272: https://github.com/openclaw/openclaw/issues/49272
[4] OpenClaw Session Management Deep Dive: https://docs.openclaw.ai/reference/session-management-compaction
夜雨聆风