Agent 突然“装死”?openclaw agent不回消息排查实战总结

本文源自一次 OpenClaw 生产问题排查。我们复盘了全过程，系统梳理出 Agent 不回消息的排查方法与常见原因。如果你也有类似烦恼，这篇文章会帮你快速找到突破口。

好不容易调教好的 Agent，关键时刻突然“装死”不回消息了？

当你费尽周折，终于让 Agent 理清了需求逻辑、敲定了设计文档，眼看就要生成终稿时，它突然——不回消息了。

是的，大多数 Agent 罢工都发生在这种时刻。我这次也不例外。

花了将近三个小时反复沟通，全部达成一致，即将产出终稿。然后，下面这个画面出现了：

⚠️ Agent couldn’t generate a response. Please try again.

无论怎么重试，都是同样的错误提示。查看后端，只有前端发来的消息记录，说明飞书通讯链路没有问题，但 Agent 没有任何反应，等到了超时时间，就返回这条冷冰冰的错误信息。

排查开始了。

第一步：openclaw doctor 健康检查——一切正常。

第二步：openclaw gateway restart 重启网关——依然没有回复。

第三步：对比 openclaw.json 配置文件——未被改动。（这里插一句：日常修改一定要严格遵守备份纪律，这点非常关键。）

第四步：从 WebChat 发消息测试——同样没有回复。

第五步：查看系统日志，相关组件加载正常，没有异常报错。

到这里，常规排查手段基本用尽。问题到底出在哪？

突破口出现在 Session 日志里。

Session 日志内容格式复杂，我让巧鸦（主 Agent）帮忙分析。巧鸦可以正常工作，很快在日志中发现了端倪：内容太长，被截断了。巧鸦给出的建议是“告知龙虾 1 号不要在回复消息里回复长内容，使用 exec+write 直接写文件”。

但这里要提醒大家一个关键原则：对 Agent 给出的结论一定要保持怀疑态度。虽然大约 60% 的情况下它是正确的，但那 40% 的错误会带来巨大的排查麻烦。

巧鸦提到的“length”实际指的是 token 长度。而消耗 token 的元凶不是回复消息本身，而是与大模型交互的整个过程。我的第一反应是——超了设置的最大单次消耗 token 量。

当前配置如下：

"maxTokens": 8192

为了进一步证实，我让巧鸦继续查证报错出现的具体环节。结果很明确：报错出现在 thinking 环节，明确标识超出了 maxTokens 设置的 8192。

这也解释了为什么“不回消息”这类问题总是出现在反复沟通的最后阶段：

积累的连续上下文不断增多，token 本身已经膨胀；

最后阶段需要汇总整理所有内容、加工、再次验证、然后生成终稿，token 消耗直线上升。

尤其是 Coding 类项目，生成最终版设计文档和终版程序，都是最消耗 token 的环节。

解决方案也清楚了。

不能简单地修改全局 openclaw.json 配置，而要根据不同 Agent 负责的工作内容分别设置。在这个项目中，我只把负责 Coding 的龙虾 1 号的配置文件（.openclaw/agents/lobster01/agent/models.json）中主模型的 maxTokens 值改为 30000。其他 Agent 不受影响，也避免了不必要的 token 浪费。

修改完成后即刻生效，Agent 恢复正常工作。

经验总结

一、Agent 不回消息排查步骤（建议收藏）

健康检查：执行 openclaw doctor，确认服务状态正常；
重启服务：执行 openclaw gateway restart，排除临时性故障；
配置核查：检查 openclaw.json 及各 Agent 配置文件是否被误改；
多端测试：从 WebChat 等其他入口发消息，判断是否为渠道特有问题；
系统日志排查：查看 ~/.openclaw/logs/ 或 journalctl -u openclaw，排查系统级异常；
会话记录深挖：查看对应 Agent 的 Session 日志（~/.openclaw/agents//sessions/.jsonl），重点关注 stopReason、token 消耗和 thinking 环节报错。

二、保持独立思考，不能 100% 依赖 AI

本次排查中，巧鸦给出的初步建议并不准确——它把“token 超限”误判为“回复消息过长”。如果不加验证直接采纳，排查方向就会跑偏。AI 是强大的辅助工具，但最终的判断和决策权必须掌握在人手里。

三、会话记录和日志文件，什么时候该查哪个？

这个问题很实用，我做一个清晰的区分：

📂 会话记录（Session 日志）

位置：~/.openclaw/agents//sessions/.jsonl

存的是什么：Agent 与用户的完整对话内容

什么时候查：

✅ 排查 Agent 说了什么、做了什么
✅ 查看 toolCall / toolResult 调用情况
✅ 查看 stopReason（是 length 截断还是正常 stop）
✅ 验证某条消息的内容是否符合预期
✅ 分析 token 消耗、usage 统计

一句话：想看 Agent 的“对话内容”和“行为轨迹” → 查会话记录

📂 系统日志

位置：~/.openclaw/logs/ 或 journalctl -u openclaw

存的是什么：系统级别的事件记录

什么时候查：

✅ Gateway 启动/停止/崩溃
✅ 插件加载失败、连接错误
✅ 外部 API（飞书/MiniMax）调用异常
✅ 权限错误、认证失败
✅ 性能问题、超时排查

一句话：想看“系统有没有出 Bug” → 查系统日志

希望这篇实战记录能帮到你。下次 Agent 再“装死”，你就不用慌了。

——

感谢阅读

真实经历，真诚分享

关注我，一个只分享 AI 实战记录的人类