OpenClaw 连接失败？先排查 prompt 和 context 预算

最近，我遇到了一种比人们愿意承认的情况更常见的失败模式：

拉取一个还不错的本地模型

直接测试模型，一切正常

运行第一个真正的 Agent 回合，然后一切都崩了

遇到这种情况，大多数人的第一反应都很自然：怪模型。

把 Qwen 换成 Llama。试试更大的模型。试试更小的模型。重新拉取权重。调整量化配置。如此反复。

我认为，这通常不是正确的第一步。

真正的问题往往出在 prompt 负担、上下文预算或后端兼容性上，而不是模型本身。

直接向 Ollama 发送 prompt，只是一次非常轻量的测试。OpenClaw 的 Agent 回合则完全不是一回事。

明显信号：直接调用 Ollama 正常，OpenClaw 却失败

我在 r/openclaw 上看到一个讨论帖，其中一位使用 Ubuntu Server 的用户表示，即使是一个全新的 session，仅仅输入 hello，也会触发反复出现的错误。奇怪的是，同一个模型通过 Ollama 直接使用、上下文设为 4096 时，却感觉“快如闪电，表现也很棒”。

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen2.5-coder:14b",
    "messages": [
      {"role": "user", "content": "hello"}
    ]
  }'

但如果 OpenClaw 在一个普通回合中就崩溃，那么模型很可能不是你首先需要排查的问题。

你面对的通常是以下某个问题：

系统指令过于庞大

加载了太多 skills

每个回合都会注入 memory payload

输出预留设置过于激进

后端存在 OpenAI-compatible 兼容性问题

这种模式并不只会出现在 OpenClaw 中。我在 n8n、Make、Zapier 以及自定义 OpenAI-compatible Agent 技术栈中都见过同样的情况：hello-world prompt 可以通过，但真正的自动化任务却失败了，因为生产环境中的请求远比所有人想象的更重。

“全新”安装的 OpenClaw 并不是真的空

这是人们最容易忽略的部分。

当你的本地模型真正收到一个 OpenClaw 回合时，它可能已经携带了：

预留的输出预算

所以，没错，你的模型可能会标明它拥有 42,967 token 的上下文窗口。

但这并不意味着下一个响应可以使用全部 42,967 个 token。

很多“模型坏了”的调试过程，正是在这个差距上彻底跑偏的。

直接 prompt 与 Agent 回合

直接聊天测试只能证明模型能够回答问题。

它不能证明你的后端可以可靠地支持 Agent 行为。

从诊断开始，不要凭感觉

在更换模型之前，我会先运行那些乏味但必要的命令。

OpenClaw 的文档在这方面其实写得相当不错，因为它把后端健康状态与 Agent/runtime 问题区分开了。

我会先按以下顺序执行：

openclaw status
openclaw status --all
openclaw gateway probe
openclaw gateway status
openclaw doctor
openclaw channels status --probe
openclaw logs --follow

如果我要调试一个全新的本地环境，这些操作一定会发生在更换任何模型之前。

openclaw status
openclaw status --all
openclaw gateway status
openclaw doctor
openclaw logs --follow

如果原始 HTTP 请求正常，但 openclaw infer model run 失败，问题就指向兼容性或 runtime

如果日志显示存在上下文压力，就别再假装这是模型智商的问题

如果 tool call 格式错误，可能是后端契约不匹配

相比在 Qwen 和 Llama 之间随机来回切换，这样利用时间要有效得多。

我会尽早检查的两个 compat 标志

很多本地 OpenAI-compatible 后端只能做到“大致兼容”。

这已经足以浪费你一整个下午。

OpenClaw 特别指出了两个标志，它们能解决多得出人意料的故障：

models:
  providers:
    local:
      models:
        - name: your-model
          compat:
            requiresStringContent: true
            supportsTools: false

它们在实际使用中的含义是：

requiresStringContent: true：当后端拒绝结构化的 messages[].content 时会有所帮助

supportsTools: false：当后端声称支持 tools，但在真正进行 tool calling 时表现糟糕，它会有所帮助

这并不是“权重有问题”。

如果管道本身就有问题，那么从 Qwen 换到 Llama，不过是在漏水的房子里重新装修。

reserve_tokens_floor 可能让故障更加频繁

这一点让我很意外，因为它看起来像是一项安全设置。

在那个 Reddit 讨论帖中，有位评论者提到，应该检查 reserve_tokens_floor；如果之前提高过它，就将其设置为 20,000，因为更高的值会让错误更加频繁地发生。

一旦算一下账，这就说得通了。

如果 OpenClaw 为响应预留了很大一部分上下文，那么留给其他所有内容的可用预算就会迅速缩小。

然后，这个回合突然就装不下了，尽管模型标明的上下文窗口看起来还很充裕。

所以，如果你一直在提高 reserve 设置，因为感觉模型不稳定，那么这种不稳定可能正是你亲手制造的。

/compact 可以帮助压缩历史记录：

/compact

但它不会神奇地移除那些每个回合仍会注入的大型 system prompt、已加载的 skills、memory payload 或 tool definitions。

这就是那个没人愿意听到的恼人答案。

你安装 Agent framework，是因为想获得更多能力。

结果，这些能力本身成了问题。

在那些 OpenClaw 讨论中，我看到的一条非常有用的评论大意是：有东西正在吞噬你的上下文窗口；如果你下载了一大堆 skills，那么罪魁祸首很可能就是它们。

这话很直白，但很多时候可能也是对的。

有几类内容会迅速累积：

基于 LanceDB 的 memory

额外的 operator skills

长期运行的 session 历史记录

结果很简单：模型收到的回合已经无法干净地塞进上下文。

更换模型之前，先精简 Agent

如果我要调试本地 OpenClaw，我希望得到一个尽可能小的可复现环境。

简化或禁用 memory

使用范围最窄的 tool profile

让 prompt 保持简单乏味

OpenClaw 的 tool profile 默认值在这里很重要。新的本地配置通常默认为 coding，而：

minimal 只允许 session_status

messaging 的范围依然很窄

full 会取消 profile 限制

这意味着，在 Qwen、Llama 或其他任何模型生成一个 token 之前，tool profile 就已经改变了系统行为。

如果 minimal profile 可以正常工作，而范围更广的 profile 会失败，你就获得了一条非常重要的信息。

在 Ollama 模型之间反复切换之前，我的实用检查清单

我会按照下面的顺序排查。

1. 证明模型可以被直接调用

向 Ollama 发送一个普通请求。

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.1:8b",
    "messages": [
      {"role": "user", "content": "Write one sentence about Redis."}
    ]
  }'

如果失败，先修复 Ollama。

如果成功，继续排查。

2. 运行 OpenClaw 诊断

openclaw status
openclaw doctor
openclaw logs --follow

3. 检查上下文是否爆掉

如果日志指向上下文压力，就相信日志。

不要因为模型标明的上下文窗口看起来足够大，就一直和证据争辩。

暂时移除额外内容：

范围更窄的 tool profile

你需要确认故障是否由 Agent 开销引起。

5. 重新检查 reserve 设置

如果你提高过 reserve_tokens_floor，请调低它并重新测试。

一个看起来很“安全”的预留预算，可能反而让整个回合更难装入上下文。

6. 检查 compat 标志

如果后端在处理结构化内容或 tools 时不稳定，可以尝试：

compat:
  requiresStringContent: true
  supportsTools: false

7. 到这时再更换模型或后端

而且，更换时要有明确理由：

更好的上下文处理能力

更好的 OpenAI-compatible 兼容性

更稳定的 tool 支持

而不是因为你已经失去耐心。

什么时候更换技术栈才是理性选择

我喜欢使用本地技术栈做实验。

它们非常适合测试 prompt、尝试 Agent 创意，以及在投入更大的系统之前验证工作流。

但如果你打算每天运行 Agent，标准就不一样了。

稳定的 OpenAI-compatible 行为

可预测的 tool calling

更少的兼容性边缘情况

不用反复照看上下文和 token 预算

自动化任务全天候运行时，成本可预测

因此，很多团队最终不再继续对抗本地技术栈，而是迁移到更干净的 API 层。

如果你正在 n8n、Make、Zapier、OpenClaw 或自定义工作流中构建 Agent，问题通常不只是“这个模型能不能回答？”

真正的问题是：

这个 endpoint 能否在真实的 Agent 负载下始终保持一致的行为？

这是完全不同的标准。

这也解释了为什么按固定费率收费的 OpenAI-compatible 服务对生产环境自动化很有吸引力。当你的工作流涉及 tool call、重试、memory、长 prompt 以及持续不断的后台运行时，按 token 计费会让每一次调试都变成成本计算题。

Standard Compute 在这方面很有意思，因为它提供了一个 OpenAI-compatible endpoint，以固定月费提供不限量的 AI 算力。因此，你可以运行 Agent 和自动化任务，而不必盯着每个回合的 token 支出。如果你已经厌倦了绕着本地后端的各种问题进行调试，转到生产环境后又要承受按 token 计费的惩罚，那么这种模式就很合理。

如果模型在 Ollama 中可以正常运行，到了 OpenClaw 中却直接崩溃，先别急着给模型办葬礼。

先问问自己，还有哪些东西搭着 prompt 的便车一起进来了。

大多数全新安装环境的故障，并不是“这个模型太蠢”。

它们通常属于以下某一种：

隐藏的 prompt 开销

reserve 预算错误

后端兼容性不匹配

即使最后发现并非如此，至少你也能确定，自己真正需要的是更好的模型、更好的后端，还是更好的技术栈。

如需采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。