OpenClaw Agent 回复慢、卡住或 Thinking 不结束：如何从日志和会话状态定位
OpenClaw Agent 回复慢、一直 Thinking、工具调用卡住或偶尔无响应时，先区分模型延迟、网络问题、工具调用阻塞、会话状态异常和 Channel 回写失败。本文给一套实战排障方法。
需要继续找相关内容？
如果你想继续查工具名、术语、对比页或相关问题，可以直接搜全站，不用回到博客列表页重找。
核心结论
OpenClaw Agent 卡住时，不要只说“模型慢”。先把问题拆成输入进入、Agent 路由、模型调用、工具调用、会话状态、Channel 回写六层，再用日志和最小复测定位。
适合谁看
适合遇到 OpenClaw Agent 回复慢、一直 Thinking、工具调用无返回、同一问题偶尔成功偶尔失败的小团队和开发者。
关键判断
重点观察 openclaw logs --follow、会话状态、provider 错误、tool timeout、rate limit、Channel send failed 等信号。
下一步建议
先用一个最小消息复现，再逐层记录耗时，不要直接把所有问题归因到模型。
你将学到
- + 如何区分模型慢、网络慢、工具慢和 Channel 回写失败
- + 如何设计最小复现消息
- + 日志里哪些关键词值得优先看
- + 为什么工具调用必须设置 timeout 和失败边界
- + 如何把卡住问题转成可观测的工作流问题
OpenClaw 用起来像聊天入口，但它背后不是一条简单的“用户问、模型答”链路。
真实链路更像这样：
用户消息
-> Channel
-> Gateway
-> Session
-> Agent route
-> Model provider
-> Tool calls
-> Agent response
-> Channel send
-> 用户看到回复所以当你看到：
- 一直 Thinking
- 回复很慢
- 偶尔没有反应
- 工具调用卡住
- 日志里没有明显报错
- 用户那边看不到最终回复
不要直接说“模型慢”。
更实战的排查方式是先找链路停在哪一层。
先做最小复现
不要一上来就用复杂任务复测。
先发三条消息：
ping用一句话回复当前时间不要调用工具，只回复 ok然后观察：
- 三条都慢
- 只有需要模型理解的慢
- 只有触发工具调用时慢
- 生成了但平台没有收到
同时盯日志：
openclaw logs --follow如果最小消息都慢，优先看 Gateway、provider 和网络。
如果只有复杂任务慢，重点看工具调用、上下文长度和 Agent route。
第一层：确认消息是否已经进入 OpenClaw
如果日志里完全看不到用户消息，那不是 Agent 慢，是消息没有进来。
先回到消息链路排查：
openclaw gateway status
openclaw channels status --probe
openclaw logs --follow这类问题应该看：
- Channel 是否 connected
- Gateway probe 是否正常
- 是否有 mention required
- 是否被 allowlist / pairing 阻挡
- 平台侧 Webhook 是否有事件进来
如果消息没进入 OpenClaw，模型层不用查。
第二层：确认 Agent route 是否正确
如果日志里能看到消息进入，但没有进入预期 Agent，就查 route。
常见信号：
- 当前 channel 绑定的 Agent 不是你以为的那个
- 默认 Agent route 仍然指向旧配置
- 某个 sender 或 channel 有单独 override
- 新配置只对新会话生效，旧会话仍用旧 route
建议做一个记录：
| 测试消息 | Channel | Sender | Session | Agent route | 是否符合预期 |
| --- | --- | --- | --- | --- | --- |
| ping | | | | | |如果 route 错了，就不要继续看 provider。
第三层：区分 provider 慢和 provider 失败
如果 Agent 已经开始调用模型，就看 provider 日志。
重点搜这些关键词：
timeout
rate limit
429
provider error
upstream
connection reset
invalid api key
context length
model not found你可以用一个简单表记录：
| 消息 | provider | model | 首 token 时间 | 总耗时 | 错误 |
| --- | --- | --- | --- | --- | --- |如果是 provider 慢，表现通常是：
- 日志里能看到请求发出
- 等很久才返回
- 没有工具调用
- 切换更快模型后明显改善
如果是 provider 失败，表现通常是：
- 429
- 401 / 403
- model not found
- context length
- upstream timeout
这两类处理方式不同。
慢要考虑模型、区域、上下文和任务复杂度；失败要修 key、模型名、限流或 provider 配置。
第四层：工具调用最容易伪装成 Thinking
很多 Agent 一直 Thinking，其实是工具调用没返回。
典型原因：
- 工具访问外部 API 超时
- 本地命令没有退出
- 浏览器自动化卡在页面加载
- 文件锁或数据库锁
- 工具没有设置 timeout
- 工具失败后没有把错误返回给 Agent
工具调用必须有边界。
一个最小的工具调用包装可以这样设计：
type ToolResult<T> =
| { ok: true; value: T; elapsedMs: number }
| { ok: false; error: string; elapsedMs: number; retryable: boolean };
async function runWithTimeout<T>(
name: string,
task: () => Promise<T>,
timeoutMs = 15000
): Promise<ToolResult<T>> {
const started = Date.now();
try {
const value = await Promise.race([
task(),
new Promise<T>((_, reject) =>
setTimeout(() => reject(new Error(`${name} timed out`)), timeoutMs)
),
]);
return { ok: true, value, elapsedMs: Date.now() - started };
} catch (error) {
return {
ok: false,
error: error instanceof Error ? error.message : String(error),
elapsedMs: Date.now() - started,
retryable: true,
};
}
}OpenClaw 的外层排障和具体工具实现不是一回事，但原则一样：
任何工具调用都不能无限等。
第五层：生成成功，不代表发送成功
还有一种很迷惑的情况：
- 模型已经生成回复
- 日志里看起来 Agent 完成了
- 用户平台上却没看到消息
这时要查 Channel send。
常见关键词：
send failed
Forbidden
missing_scope
rate limit
message too long
file upload failed
channel not found有些平台对消息长度、Markdown 格式、文件上传、群权限都有额外限制。
所以“模型生成成功”和“用户看到回复”之间还隔着最后一层：Channel 回写。
复测时要区分：
| 状态 | 是否完成 |
| --- | --- |
| 消息进入 Channel | |
| Gateway 接收 | |
| Agent route 命中 | |
| Provider 返回 | |
| Tool calls 完成 | |
| Channel send 成功 | |
| 用户看到回复 | |这张表能把“卡住”拆成可定位的问题。
第六层：给慢请求做最小监控
如果你已经把 OpenClaw 放进真实工作流，就不要只靠肉眼看慢不慢。
至少记录：
- messageId
- channel
- sender
- sessionId
- agent route
- provider
- model
- tool count
- startedAt
- firstTokenAt
- completedAt
- sendCompletedAt
- errorName
- errorMessage
可以用这样的字段：
{
"messageId": "msg_123",
"channel": "telegram",
"agent": "support-agent",
"provider": "openai",
"model": "gpt-4.1",
"toolCalls": 2,
"receivedAt": "2026-04-23T08:00:00Z",
"modelStartedAt": "2026-04-23T08:00:02Z",
"modelCompletedAt": "2026-04-23T08:00:12Z",
"sentAt": "2026-04-23T08:00:13Z",
"status": "completed"
}有了这类记录，慢在哪里会很清楚。
为什么这体现 OpenClaw 的实战派定位
概念型 Agent 平台经常只展示“能回答”。
实战型 Agent Gateway 必须能解释：
- 为什么没回答
- 为什么慢
- 为什么卡住
- 为什么生成了但没发出去
- 为什么同一条消息有时成功有时失败
OpenClaw 适合实战派开发者，是因为它的价值不只在模型调用，而在整条链路的可运行、可排查、可维护。
相关阅读
继续延伸
要点总结
- - Agent 卡住不是一个原因，而是一条链路上的某一层没有结束
- - 先用最小消息复现，再看复杂任务
- - 工具调用没有 timeout，会把一次失败伪装成一直 Thinking
- - 模型调用成功不代表 Channel 一定成功回写
- - 实战派 OpenClaw 工作流必须记录耗时、状态和失败边界
常见问题
OpenClaw 一直 Thinking，是模型太慢吗？
可能是模型慢，也可能是工具调用没有返回、provider rate limit、网络阻塞、会话状态异常，或者回复生成完但 Channel 回写失败。要用日志分层判断。
为什么简单问题能回复，复杂问题会卡住？
复杂问题可能触发更长上下文、更多工具调用、更慢的 provider，或者更容易触发超时。先用最小消息和关闭工具调用的测试分离变量。
工具调用卡住怎么处理？
给每个工具调用设置 timeout、错误分类和 fallback。不要让工具调用无限等待，否则用户看到的就是 Agent 一直 Thinking。
