OpenClaw 卡住这件事,暴露了 AI Agent 最真实的短板

不知道大家使用Openclaw的时候有没有一种感觉，大部分你想要执行的任务，到了一定阶段就会卡柱，停滞不前，往往要经过很多轮的对话才能搞定；又或者很多人就直接放弃了；最近看到一篇帖子颇有启发：

标题很简单："How to fix a Lazy Claw"（如何修复懒惰的小龙虾），发帖人也遇到了同样的问题：

"大约 40% 的时间，它会停滞不前，不完成任务。当我检查时，它声称正在工作，但没有任何进展。"

他尝试了各种方法：

看门狗机制（watchdogs）/ 频繁 ping/ 手动推动

都没用。

他现在只能每隔几分钟 ping 一次，强行推动任务继续，"但这太让人沮丧了"。

他用的是 ChatGPT Codex 5.4 模型，"感觉比 Claude Sonnet 差，虽然更便宜"。

社区的智慧：两个关键解法

我整理了最有价值的两个解决方案：

解法一：检查 Think Level

其中一位用户给出了广泛被采纳的答案：

"检查你的默认 think level 是否设置为 low 而不是 off。"

操作步骤：

为什么有效？

Think Level 控制 AI 的"思考深度"。设置为 off 时，AI 会跳过深度思考环节，直接输出结果。这看似更快，但实际上：

复杂任务容易出错

错误后不会自我纠正

陷入死循环时无法自拔

设置为 low 后，AI 会进行基础的推理和验证，虽然稍微慢一点，但稳定性大幅提升。

用户 Sutanreyu 分享了一个容易被忽视的细节：

"你必须告诉它：永远不要在没有行动的情况下以承诺结束。"

规则：

1. 每次回复必须包含具体行动或已完成的结果

2. 不允许只说"我将会..."而不执行

3. 如果卡住，主动报告问题并请求帮助

基于社区讨论和我的实践经验，我总结了一个三层防御体系：

thinking:enabled: truelevel: low

model:default: claude-sonnet-4

# 超时设置timeout:per_step: 300# 每步最多5分钟total: 3600

logging:enabled: truefile: memory/task_log.mdfrequency: per_step

heartbeat:enabled: trueinterval: 300

第三层：恢复（异常处理）

自动恢复

recovery:max_retries: 3retry_delay: 60fallback_model: gpt-4o

主模型失败时切换：人工介入

human_in_loop:trigger: after_3_failuresnotification: feishu

Lazy Claw 问题，本质上是AI Agent 可靠性的问题。

OpenClaw 很强大，但它不是银弹。

你需要：