> 环境：腾讯云 Lighthouse 轻量应用服务器（Ubuntu）+ OpenClaw 2026.4.21 + 飞书机器人通道 + opencode-go 模型网关（deepseek-v4-flash）
>
> 关键词：OpenClaw、Heartbeat、Token 消耗、LLM 排查、轻量应用服务器

## 一、背景

我在一台腾讯云 Lighthouse 轻量服务器上部署了 OpenClaw 作为 AI 网关，接入飞书机器人，平时通过飞书对话调用大模型。某天发现两个问题：

1. 飞书发消息报错：`LLM request failed: provider rejected the request schema or tool payload.`
2. 修复后查看模型后台用量，发现**每间隔半小时固定消耗一次 token**，且 input tokens 还在持续增长。

当前大模型 token 付费越来越贵，每一 M token 都值得省。本文记录完整的排查与修复过程。

## 二、问题一：飞书消息报错"schema or tool payload"

### 2.1 误导性报错

OpenClaw 把上游返回的 400 错误统一包装成了 `"provider rejected the request schema or tool payload"`，看起来像是工具调用 schema 的问题，实际和 schema 毫无关系。

从 gateway 日志里挖出原始错误：

```
error=LLM request failed: provider rejected the request schema or tool payload.
rawError=400 Error from provider (Console Go): Request is missing x-opencode-session
         and cannot be routed efficiently.
```

### 2.2 根因

模型端点 `https://opencode.ai/zen/go/v1` 是 opencode 官方 CLI 专用的模型网关，**上游在某个时间点新增了强制 `x-opencode-session` 请求头的路由校验**——我的配置此前一直正常运行，某周一开始突然全部 400，正是上游加校验的时间点。而 OpenClaw 作为第三方客户端不会自动携带这个头。

### 2.3 验证方法（最小成本复现）

用现有 Key 直接打端点，对比带/不带头的结果：

```bash
cat > /tmp/probe.js << 'EOF'
const fs = require('fs');
const c = JSON.parse(fs.readFileSync('/root/.openclaw/openclaw.json', 'utf8'));
const p = c.models.providers['opencode-go'];
const url = p.baseUrl + '/chat/completions';
const body = JSON.stringify({model: 'deepseek-v4-flash', messages: [{role: 'user', content: 'hi'}], max_tokens: 4});
async function t(name, extra) {
  const r = await fetch(url, {method: 'POST', headers: Object.assign({Authorization: 'Bearer ' + p.apiKey, 'Content-Type': 'application/json'}, extra), body});
  const txt = await r.text();
  console.log(name + ' -> ' + r.status + ' : ' + txt.slice(0, 220));
}
(async () => {
  await t('no-header', {});
  await t('with-session', {'x-opencode-session': 'openclaw-feishu-main'});
})();
EOF
node /tmp/probe.js
```

结果：不带头 → `400 MissingSessionID`；带 `x-opencode-session` → `200`。实锤。

### 2.4 修复：给 provider 注入自定义请求头

OpenClaw 的 provider 配置支持 `headers` 字段。先备份再修改：

```bash
# 备份（改坏了随时回滚）
cp -p /root/.openclaw/openclaw.json /root/.openclaw/openclaw.json.bak-session-header

# 注入 headers（注意 agent 级配置优先级高于主配置，三处都要改）
node -e '
const fs = require("fs");
const files = {
  "/root/.openclaw/openclaw.json": "openclaw-default",
  "/root/.openclaw/agents/main/agent/models.json": "openclaw-main",
  "/root/.openclaw/agents/life_assistant/agent/models.json": "openclaw-life"
};
for (const [f, sid] of Object.entries(files)) {
  const c = JSON.parse(fs.readFileSync(f, "utf8"));
  const provs = c.models ? c.models.providers : c.providers;
  if (provs && provs["opencode-go"]) {
    provs["opencode-go"].headers = {"x-opencode-session": sid};
    fs.writeFileSync(f, JSON.stringify(c, null, 2));
    console.log("OK " + f);
  }
}'

# 重启 gateway
export XDG_RUNTIME_DIR=/run/user/0
systemctl --user restart openclaw-gateway && sleep 6 && systemctl --user is-active openclaw-gateway
```

> 踩坑提示：OpenClaw 的配置有**三层优先级**（agent 级 `agents/<name>/agent/models.json` > 主配置 `openclaw.json`）。只改主配置可能被 agent 级文件覆盖，排查时务必三处都看。

修复后飞书消息恢复正常。

## 三、问题二：每半小时固定消耗 token

### 3.1 现象

模型后台用量记录（每半小时一条，固定节奏）：

| 时间 | 模型 | input | output | 成本 |
|---|---|---|---|---|
| 22:17 | deepseek-v4-flash | 54305 | 41 | $0.0082 |
| 21:47 | deepseek-v4-flash | 54142 | 41 | $0.0081 |
| 21:17 | deepseek-v4-flash | 53979 | 41 | $0.0081 |
| 20:47 | deepseek-v4-flash | 53816 | 41 | $0.0081 |
| 20:17 | deepseek-v4-flash | 53653 | 41 | $0.0081 |

三个可疑特征：**固定 30 分钟周期**、**每次 output 恒为 41**（说明是一次极短的 agent turn）、**input 每次递增 163**（说明上下文在滚雪球）。

### 3.2 排除法定位

依次排除所有"嫌疑人"，用一组只读命令一次跑完：

```bash
export PATH=/root/.nvm/versions/node/v22.22.2/bin:/root/.local/share/pnpm:$PATH
export XDG_RUNTIME_DIR=/run/user/0

# 1. heartbeat 显式配置（如果有就不是默认值）
grep -i heartbeat /root/.openclaw/openclaw.json

# 2. OpenClaw 注册的 cron/automation 任务
openclaw cron list --all

# 3. gateway 日志中的心跳/LLM 调用痕迹
journalctl --user -u openclaw-gateway --since '-3 hours' --no-pager | grep -iE 'heartbeat|llm request|model='

# 4. 最近半小时被写入的文件（实锤证据链）
find /root/.openclaw -type f -mmin -35 | grep -vE 'logs|\.log'

# 5. 其他桥接服务的定时任务 / 系统 crontab
crontab -l | grep -v '^#'
```

排查结果：

- 自定义 cron 任务（日报、备份等）：全部 disabled，120+ 天未跑 → **排除**
- 系统 crontab：只有腾讯云 stargate 守护 → **排除**
- 桥接服务定时任务：为空 → **排除**
- `openclaw.json` 中无任何 heartbeat 配置 → **走官方默认值：每 30 分钟一次**

### 3.3 实锤证据

`find -mmin -35` 发现 main agent 的会话文件在半小时内被写入。深入检查：

```bash
S=/root/.openclaw/agents/main/sessions/aaf30525-89fa-4487-aaaa-cd6753e8a2f7.jsonl
stat -c '最后写入: %y' $S
grep -o 'heartbeat monitor scratch\|HEARTBEAT_OK\|NO_REPLY' $S | sort | uniq -c
tail -2 $S | head -c 1500
```

输出（关键部分）：

```
最后写入: 2026-09-12 22:47:42 +0800
  17639 HEARTBEAT_OK        ← 累计 17639 次心跳！
```

会话文件最后一条记录：

```json
{
  "role": "user",
  "content": "Read HEARTBEAT.md if it exists (workspace context). ... If nothing needs attention, reply HEARTBEAT_OK. Current time: ... 10:47 PM ..."
}
```

```json
{
  "role": "assistant",
  "content": "HEARTBEAT_OK",
  "provider": "opencode-go",
  "model": "deepseek-v4-flash",
  "usage": {"input": 54468, "output": 41}
}
```

与模型后台的用量记录**逐字段吻合**。

### 3.4 根因：OpenClaw Heartbeat 机制 + 会话滚雪球

OpenClaw 的 Heartbeat（心跳）机制默认每 30 分钟唤醒一次 agent，读取 `HEARTBEAT.md` 检查是否有待办任务，无事则回复 `HEARTBEAT_OK`。问题在于：

1. **每次心跳是一次完整的 LLM 调用**，走默认模型，token 照扣；
2. 回复被 OpenClaw 抑制不外发（飞书上毫无感知），**悄悄扣费**；
3. 最致命的：**所有心跳历史堆在同一个会话文件里**，17639 条 `HEARTBEAT_OK` 意味着每次心跳都把累计 5.4 万 token 的上下文整个发给模型——所以 input 每 30 分钟 +163 持续膨胀，**消耗是滚雪球式增长的**。

### 3.5 修复：禁用心跳

```bash
# 备份
cp -p /root/.openclaw/openclaw.json /root/.openclaw/openclaw.json.bak-no-heartbeat

# heartbeat.every = "0m" 即禁用
node -e 'const fs=require("fs");const f="/root/.openclaw/openclaw.json";const c=JSON.parse(fs.readFileSync(f,"utf8"));c.agents=c.agents||{};c.agents.defaults=c.agents.defaults||{};c.agents.defaults.heartbeat=Object.assign({},c.agents.defaults.heartbeat,{every:"0m"});fs.writeFileSync(f,JSON.stringify(c,null,2));console.log("heartbeat ->",JSON.stringify(c.agents.defaults.heartbeat))'

# 重启生效
export XDG_RUNTIME_DIR=/run/user/0
systemctl --user restart openclaw-gateway && sleep 6 && systemctl --user is-active openclaw-gateway
```

顺手归档臃肿的心跳会话文件（17639 条 `HEARTBEAT_OK` 纯属噪音）：

```bash
mkdir -p /root/.openclaw/sessions-archive
mv /root/.openclaw/agents/main/sessions/aaf30525-89fa-4487-aaaa-cd6753e8a2f7.jsonl /root/.openclaw/sessions-archive/
systemctl --user restart openclaw-gateway
```

**验证**：等过下一个整半点约 10 分钟，`stat -c '%y'` 会话文件不再刷新、模型后台不再新增用量行，即确认停干净。

### 3.6 禁用心跳的影响评估

| 能力 | 有心跳 | 禁用后 |
|---|---|---|
| 飞书发消息 → 回复 | ✅ | ✅ 不变 |
| 主动巡检 HEARTBEAT.md 待办 | 每 30 分钟 | ❌ |
| 主动发消息（announce 任务） | 依赖心跳 | ❌ |
| Token 消耗 | ~$0.008/半小时且递增 | 零 |

如果确实需要主动巡检能力，可折中设为 `"6h"`（消耗降为 1/12）。我的场景里 HEARTBEAT.md 无待办、17639 次心跳全是无用功，禁用等于零损失止血。

## 四、成本账

| 项目 | 修复前 | 修复后 |
|---|---|---|
| 单次心跳消耗 | ~54k input + 41 output，且每半小时 +163 递增 | 0 |
| 日均消耗（心跳） | ~48 次 × 5.4万+ input ≈ **260万+ input token/天** | 0 |
| 月成本 | ≈ $11.6+ 且持续增长 | $0 |

按当前 token 价格，这一个问题每月白白烧掉超过 7800 万 input token——**每一 M token 都值得省**。

## 五、经验总结

1. **警惕框架包装的报错文案**。`"provider rejected the request schema or tool payload"` 跟实际根因（缺请求头）毫无关系，永远去日志里挖 `rawError` 原始错误。
2. **先复现，再修复**。用 `max_tokens: 4` 的最小探测请求直接打上游端点，比改配置重启猜结果快得多，也便宜得多。
3. **定时消耗类问题先看周期特征**。固定周期 + 固定 output 长度 = 某种心跳/巡检机制；output 恒定为 41 这种"无意义的短回复"是心跳的典型指纹。
4. **注意会话上下文滚雪球**。长期运行的心跳/定时任务若共享同一会话，历史会无限累积，每次调用的 input 越来越大。定期归档死会话文件。
5. **配置分层要理清**。OpenClaw 的 agent 级配置优先级高于全局配置，改了全局没生效时先查 agent 目录。
6. **排查外部依赖的"静默变更"**。一直正常的端点突然 400，且报错文案提到"cannot be routed efficiently"之类的路由提示，优先怀疑上游新增了校验策略，而不是自己的配置坏了。

---

*本文基于腾讯云 Lighthouse 轻量应用服务器上的真实排障过程整理，文中所有命令均可直接复用。*


环境：腾讯云 Lighthouse 轻量应用服务器（Ubuntu）+ OpenClaw 2026.4.21 + 飞书机器人通道 + opencode-go 模型网关（deepseek-v4-flash）

一次"神秘"的 Token 消耗排查：OpenClaw 心跳机制排查与修复实战

本文记录一次腾讯云 Lighthouse 上 OpenClaw + 飞书机器人的真实排障：飞书消息突发报错 "provider rejected the request schema or tool payload"，实为 opencode 上游新增 x-opencode-session 请求头校验导致 400，通过 provider 注入 headers 修复。随后发现模型用量每半小时固定消耗且

人工智能

OpenClaw部署于腾讯云Lighthouse轻量服务器，遭飞书报错与Token异常消耗。修复方案：为opencode-go注入x-opencode-session请求头解决400报错；禁用默认30分钟Heartbeat机制，阻止会话上下文滚雪球，月省7800万input token。附完整排查命令与配置示例，成本直降为零。

轻量应用服务器

代码解释

服务器

OpenClaw

路由

Ubuntu

JSON

pnpm

4核4G3M云服务器 新用户低至38元/年！

lighthouse

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

OpenClaw部署于腾讯云Lighthouse轻量服务器，遭飞书报错与Token异常消耗。修复方案：为opencode-go注入x-opencode-session请求头解决400报错；禁用默认30分钟Heartbeat机制，阻止会话上下文滚雪球，月省7800万input token。附完整排查命令与配置示例，成本直...

一次"神秘"的 Token 消耗排查：OpenClaw 心跳机制排查与修复实战-腾讯云开发者社区-腾讯云

一次"神秘"的 Token 消耗排查：OpenClaw 心跳机制排查与修复实战

一次"神秘"的 Token 消耗排查：OpenClaw 心跳机制排查与修复实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐