OpenClaw 坏了?交给 Claude Code 来修
- 发布日期
- 2026年7月11日
- 作者
- Jacob Lloyd —— 项目完成后，在 AI 协助下撰写
- 阅读时长
- 约 3 分钟阅读
简单来说： 我在家里跑一台服务器,上面有本地 AI 助手(OpenClaw)处理日常任务。一旦真的出了故障,或者问题复杂到它们应付不来,我就在同一台机器上叫来更强的云端助手(Claude Code)修好它——并且让它写下操作说明,这样本地助手以后就能自己处理同类情况。
我本地的 OpenClaw 智能体在跑这个网站、我的聊天应用,还有一堆零零碎碎的自动化任务。它们全天候免费处理这些日常工作——直到它们运行所依赖的这台机器本身出了故障。这时候我不会指望一个正在下沉的系统自己把自己救回来:我会在同一台机器上打开 Claude Code,让一个更强的模型来修。
tl;dr
- 简单、可重复的工作:交给本地的 OpenClaw 智能体。token 免费,常年在线。
- 真正复杂或彻底故障:Claude Code,直接在跑 OpenClaw 的那台机器上运行。
- 最关键的一点:Claude Code 不只是把问题修好——它还会顺手把系统改造好,好让 OpenClaw 下次能自己处理(或者至少扛得住)。
两级策略的思路
本地模型能干的事其实不少:写文章草稿、盯着服务状态、往聊天里推送消息、跑定时任务。但它们有天花板——上下文更小,排查问题的直觉更弱,还老是自信满满地把明明需要认真诊断的东西直接重启一遍了事。
经验法则很简单:如果修复方法已经写成了现成的运行手册,那是 OpenClaw 的活。如果需要真正搞清楚问题出在哪,那就交给 Claude Code。
一个真实案例:陷入崩溃循环的网关
有天早上,OpenClaw 的网关陷入了崩溃循环,留下的信息只有:
agents.list.5: Invalid input
错误里没提到具体是哪个智能体。重启也没用——配置被修复的速度还赶不上它被重新破坏的速度。要是换成本地模型,大概会陷入无限重启的死循环。
直接在这台机器上运行的 Claude Code 追查出了原因:OpenClaw 的身份校准(identity-reconcile)步骤,每次启动都会重新读取一份此前清理时遗留下来的陈旧工作区文件,再把里面无效的智能体定义重新注入到当前的运行配置里。彻底的修复分三步:
- 修正那份真正造成问题的陈旧源文件,
- 恢复干净的网关配置,
- 跑完整的启动-重启循环来验证,直到每个服务单元都能稳定保持运行。
这就是典型的模式:能看到的报错在配置里,但根源却是一份几周都没人碰过的文件。要的是诊断,不是重启。
"把它修好,让 OpenClaw 下次自己能处理"
每次 Claude Code 会话的后半段,是大多数人会跳过的部分:修好之后,我会让它把学到的知识回灌进本地系统,这样同一类问题以后就再也用不着请出这个更贵的模型了。具体做法是:
- 本地智能体能照着做的运行手册。 为更小的模型写的分步说明——每一步都能核对、命令写得明明白白、规则不留模糊地带。我这个网站的每周刷新任务,跑的正是这种文件。
- 用护栏代替时刻警惕。 出过一次事故之后,Claude Code 给这个网站的构建流程加了一道失败即拦截的发布前检查(密钥扫描+内容规则),这样不管是本地还是云端的智能体,都发不出什么让人尴尬的东西。
- 给已知故障模式配上看门狗。 为迟钝的本地模型调好的超时时间、给分派任务用的自删除跟进计时器、出问题时会推送到我聊天应用里而不是默默失败的健康检查。
下次同样的问题再冒头,OpenClaw 就能用免费的 token 自己搞定,Claude Code 只会在真正遇到新状况时才被叫来。
为什么要在 OpenClaw 所在的机器上运行 Claude Code?
在同一台机器上运行,它读到的是真实的日志、真实的配置、真实的服务状态——修复效果也是端到端验证过的,而不是靠猜我的描述。经过我转述加工过的描述,恰恰就是"听起来很对、实际上是错的"修复方案的温床。
踩过的坑
- 别让本地智能体在事故进行中自己修自己。 一个连自己网关都坏了的智能体,只会把事情弄得更糟。先从外部(Claude Code)修好,再把控制权交还回去。
- 坚持要彻底的修复。 "重启一下"只是缓解症状而已。要明确要求找到根本原因,并让助手证明修复能扛得住一轮重启周期。
- 趁上下文还热乎的时候让它写运行手册。 一次事故最好的文档,就是由刚修好它的那个"人",在修好之后几分钟内写出来的。
- 别让密钥掺和进这个流程。 智能体要读的运行手册和简报应该不含任何密钥;密钥应该活在环境变量里,而不是写进文字说明里。