一行配置,我排查了整整5天!OpenClaw＂罢工＂真相曝光

4月30号刚把“龙虾”从笔记本搬上服务器，五一小长假它就给我上演了一出“我只聊天，不干活”的大戏。面板失联、安全审计暴击、模型装死……踩遍所有坑后，凶手竟是一行不起眼的配置。

没错，这就是我这个五一假期的真实遭遇。

我的 OpenClaw 智能助手其实早就跑在本地笔记本上了，我管它叫“龙虾”。4月30号那天，我寻思着放假也要时时刻刻”养龙虾”，干脆把它正式搬家到服务器上，用 Docker 容器来跑。本以为是换个更稳的池子，结果好了，从5月1号开始，那个在本地还算听话的“实干家”，直接变成了一个“嘴炮王者”。

飞书叫不动，网页控制台同样叫不动。你让它干啥，它都用 <invoke name="exec"> 这样的标签“演”给你看，仿佛在说：

“你看，我已经知道该怎么做了，但我就是不动手。”

更气人的是，搬到服务器后连 Dashboard 面板都打不开了——明明网关显示运行正常，浏览器访问 http://127.0.0.1:18789 就是连不上，系统还贴心提示”URL拼写可能存在错误”。回头看本地笔记本上随开随用的面板，简直恍如隔世。

第一阶段：服务器环境+安全机制，双重暴击

🔒 面板失联：服务器自带的”隔离buff”

一开始以为是 SSH 隧道没配好，反复改端口转发命令，折腾一小时还是不行。直到跑了 openclaw gateway status 才发现真相：

合着 OpenClaw 默认只监听服务器本地回环地址，相当于把面板锁在服务器里，外部根本进不去！这和本地笔记本”全网可访问”的默认配置完全不一样，服务器部署天生自带“隔离buff”。

更坑的是，想拿登录 Token 都难——命令行输入 openclaw config get gateway.auth.token，结果输出 __OPENCLAW_REDACTED__（安全脱敏），新手直接懵圈。最后还是暴力破解：直接打开 ~/.openclaw/openclaw.json 配置文件，才在里面找到明文 Token。

🌀 一头扎进”安全迷宫”

面板终于登上了，但”龙虾”依然只聊天不干活。我立刻把矛头指向了另一个方向：安全机制。

毕竟 OpenClaw 在 2026 年 3 月刚引入了一整套多层安全策略，什么 Agent 侧、Host 侧的双层审批，各种权限、白名单……怎么看都像是“安全太紧了，把干活儿的路给堵死了”。尤其我是直接用最新镜像起的容器，这些新特性一个没落下。

一跑 openclaw status --deep，更是被安全审计结果吓住：3 个 CRITICAL 严重漏洞、6 个 WARN 警告，红得刺眼！核心问题全出在飞书通道配置上——本地用的时候图方便开了 groupPolicy="open"（开放模式），搬到服务器后没改，直接导致任意飞书群成员都能 @ 机器人触发调用，系统命令、文件读写等高危工具直接暴露，沙箱也没启用。

一边是想让机器人干活必须放开权限，一边是高危漏洞不敢不管，卡在中间进退两难。

于是，从 5 月 1 日到 5 月 5 日，我开始了漫长的“安全迷宫”之旅：

一通操作下来，权限全放开了，安全锁解开了，面板也正常了，可“龙虾”呢？依然只会聊天，绝不干活。更糟的是，某些改动还导致容器不断重启，报错信息一遍遍弹出 Unrecognized key，像一个无声的嘲讽。

第二阶段：一条日志，彻底推翻所有假设

5 月 6 日，我终于冷静下来，决定抛弃所有的“想当然”，从最基础的日志入手。

一条命令，改写了整个故事的走向：

docker logs ...

一条关键线索浮出水面：

这说明，Agent 其实收到了任务，但它根本没有生成任何回复。

这个信息彻底推翻我之前所有的”权限被拦截”假设。问题根本不在于安全策略，而是：Agent 内部，连执行计划都没生成。

就像一个员工，不是你批不批准他出差的问题，而是他压根儿就没提出差申请。他在脑子里就把这件事否了。

第三阶段：真相大白，一行配置藏得有多深？

5 月 6 日晚上，我开始逐行死磕配置文件 /home/node/.openclaw/openclaw.json。

在 models.providers.custom 的深处，我为 MiniMax-M2.5 模型定义了一段 compat（兼容性配置）。起初我几乎要跳过这段了，因为眼前全是 API 地址、密钥、模型名这些”大件”。

可就是在这段不起眼的配置里，藏着一行致命代码：

"compat": {    "requiresStringContent": true,    "supportsTools": false// <--- 罪魁祸首！}

看到 "supportsTools": false 的那一瞬间，我血液都凝固了。

这行配置，用最直白的方式告诉 OpenClaw：“此模型不支持工具调用。”

难怪！Agent 从一开始就被设定成“这个人不会用工具”，自然连生成调用指令的尝试都不会做。它只能跟你聊天，做一个勤勤恳恳的”嘴替”，把命令”念”出来，但永远不会执行。

我几乎是颤抖着手，把 false 改成 true，然后重启了容器。

结局：一句命令，我的”龙虾”又活了 🎉

再次向”龙虾”发送指令——

它没有再”演”给我看。直接执行，直接返回结果。

那个熟悉的“行动派”又回来了。五天的困扰，最终被一行配置画上句号。

复盘：为什么你我都容易忽略这个配置？

这次故障，根源在于 OpenClaw 在 3 月底更新中引入的 compat（兼容性）配置。对于我这种 4 月 30 号才用 Docker 把”龙虾”从笔记本搬到服务器的用户来说，这个更新是直接“附赠”进容器的。

它的初衷是好的：因为市面上部分非标准模型对工具调用的支持不稳定，官方提供了手动调整兼容性的选项，让用户自由选择。

但问题就出在：当你在自定义接入一个模型时，所有人的注意力都集中在 API 地址、密钥、模型名称上，很少会去留意一个叫 supportsTools 的细分字段。

更坑的是，很多模型 provider 在生成配置模板时，为了确保兼容不出错，会倾向于采用保守方案——也就是直接禁用工具调用。

这是一种典型的“暗坑”：由版本快速迭代、安全策略收紧、模型适配细节三者叠加产生，隐蔽性极强，误导性更强。特别是像我这样，从本地环境升级到服务器、卡在版本更新后第一时间上生产环境的人，简直是精准踩雷。

而安全机制的“烟雾弹”让这个坑更深了——当我被面板失联和安全审计吓住时，"supportsTools": false 就安安静静地躺在配置文件深处，完美地躲过了我所有的注意力。

容器部署特别提醒：这些细节别漏

除了核心的 supportsTools 坑和安全配置，服务器容器部署还有几个容易忽略的细节：

写在最后：给所有遇到类似问题的人

如果你也遇到了 OpenClaw（或者其他 AI 智能体框架）“只聊天不干活”的情况，尤其是刚刚从本地迁移到服务器或升级过版本，请先从下面这三件事查起，别像我一样在”安全迷宫”里浪费五天：

希望这五天的迷踪，能帮你避开同样的弯路。也希望你的“龙虾”永远活蹦乱跳。🦞