OpenClaw出问题了？我用 Claude Code 修复它

我的本地 OpenClaw 智能体负责运行这个网站、聊天应用以及诸多小型自动化任务。它们以固定的月费模式全天候处理这些常规工作，直到运行的系统出现故障为止。此时我不会指望已经不堪重负的系统自行恢复，而是会在同一台机器上打开 Claude Code，让能力更强的模型来修复问题。

两级处理机制

本地模型足以完成很多任务：撰写文章、监控服务状态、发送聊天消息、执行定时任务等。不过它们也有局限——上下文处理能力有限、调试能力较弱，还常常贸然重启那些其实需要深入诊断的系统组件。

基本原则是：如果修复方案属于已知流程，就由 OpenClaw 来处理；若需“摸索”出解决方案，则交由 Claude Code 负责。OpenClaw 模型管理器的图形界面正是基于这种协作机制诞生的——它能在保存配置前验证模型编号的有效性，从而防止各类错误配置流入系统。

实际案例：陷入死循环的网关

某天早晨，OpenClaw 的网关陷入了死循环，日志里只有这样一条信息：

agents.list.5: Invalid input

错误信息中并未提及具体是哪个智能体。反复重启也无效——配置刚修复好就又被破坏。若是本地模型，恐怕会陷入无休止的重启循环。

我在同一台机器上运行 Claude Code 后，它很快查明了原因：OpenClaw 的身份识别模块在启动时重新读取了一个此前清理操作留下的“过时工作区文件”，从而把无效的智能体定义不断注入到实时配置中。最终的修复方案包含三步：

1. 修正那个导致问题的过时源文件；
2. 恢复干净的网关配置；
3. 完整执行启动与重启流程，确保所有组件都能正常运行。

这就是典型的处理模式：表面上看是配置错误，实际上根源在于几周无人问津的文件。重点在于诊断而非简单重启。

“修复后要让 OpenClaw 今后也能自行应对”

每次使用 Claude Code 时，最常被忽略的环节就是修复后的收尾工作：我会让它把相关知识整合进本地系统，这样同类问题以后就无需调用昂贵的模型了。具体做法包括：

• 为本地智能体编写可执行的流程指南。 针对能力较弱的模型设计逐步指令——明确可验证的步骤、精确的命令与硬性规则。我之前每周执行的网站更新任务正是依据此类文档完成的。
• 以自动防护替代人工监控。 某次事故后，Claude Code 为该网站的构建流程新增了发布前检查机制（包含敏感信息扫描与内容合规校验），确保无论本地还是云端的智能体都无法推送不当内容。
• 针对已知故障模式设置防护机制。 为运行较慢的本地模型调整超时阈值；为已派发任务配置自动清除定时器；设计健康检查程序，使其将异常状态反馈至我的聊天应用而非默默失败。

今后若再出现类似问题，OpenClaw 只需利用固定费用内的资源即可自行解决，唯有真正全新的问题才需调用 Claude Code。

为何要在 OpenClaw 机器上运行 Claude Code？

在同一台机器上运行的话，Claude Code 能直接读取真实日志、配置与服务状态信息，从而进行端到端的验证——而不必仅凭我的描述去推测。经过我转述的信息往往会导致看似合理实则错误的修复方案。

注意事项

• 切勿让本地智能体在故障期间自行修复。 自身网关已损坏的智能体只会让情况更糟。必须由外部系统（如 Claude Code）完成修复后再将控制权交还。
• 务必确保修复具有持久性。 “重启一下”只是治标之策。需明确要求找出根本原因，并验证该方案能否经受住多次重启测试。
• 趁记忆尚新时编写相关文档。 最佳的记录内容应由刚刚完成修复的模型即时生成。
• 绝对不能将敏感信息混入流程文档。 供智能体阅读的指南中不可出现密钥等敏感内容；密钥应存储于环境变量中，而非明文写入文本。

相关链接：OpenClaw 智能体体系——本修复策略所保护的对象；将 DeepSeek 接入 Claude Code 与 OpenClaw 体系的方法；OpenClaw 模型管理器；若您初次接触 Claude Code，可参阅如何配置 LLM 助手指南。