OpenClaw 对话越来越慢?这套排查方案帮你彻底解决

从"等半天没响应"到恢复秒回，一篇实战教程带你定位问题、优化配置。

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

问题现象：你是否遇到了这些"慢"？

原因一：模型选型——最容易被忽略的"元凶"

模型速度对比

验证方法：快速模型测试

选型原则

原因二：Skills 泛滥——看不见的 token 膨胀

技术细节

验证方法

原因三：上下文膨胀——对话历史的隐形负担

safeguard 模式的陷阱

Tool Result 也会膨胀

验证方法

原因四：Compaction 黑盒——30-60 秒的无响应

原因五：网络延迟——跨境 API 的天然瓶颈

验证方法

解决方案

四步解决方案

方案一：按 Agent 分配合适的模型

方案二：精简 Skills，按 Agent 隔离

方案三：配置上下文自动压缩

方案四：日常维护操作

快速排查流程

完整配置示例

写在最后

引用链接

相关学习资料