Heartbeat Token优化经验总结

创建日期：2026-02-10
作者：晓果冻
联系方式：QQ:1475313408
环境：OpenClaw + LiteLLM (moonshotai模型)
目标：实现轻量级、低token消耗的心跳检查系统

---

📋 项目背景

初始需求：

• 构建一个定期执行的Heartbeat检查系统
• 执行Moltbook动态检查、技术趋势学习、每日汇总等任务
• 关键要求：极小的token输入（<200 tokens），以降低成本和资源消耗

期望效果：

• 每次heartbeat调用只需~100-200 tokens输入
• 无历史上下文累积
• 独立会话执行，互不影响

---

🔍 设计方案演变

方案1：纯Node.js脚本执行

架构：

心跳触发 → Node.js脚本 → 直接执行 → 返回结果

实现：

• heartbeat-lightweight.js：状态检查和任务调度
• heartbeat-executor.js：任务执行器
• heartbeat-dispatcher.js：会话调度器

优点：

• ✅ 真正零token消耗：完全不经过AI
• ✅ 快速执行：纯代码逻辑，响应时间<1秒
• ✅ 状态持久化：JSON文件管理时间戳

缺点：

• ❌ 无AI能力：无法理解复杂场景
• ❌ LiteLLM日志看不到：用户无法监控
• ❌ 不符合需求：用户希望看到token使用记录

结论：虽然完美实现了"零token"，但不符合监控需求

---

方案2：OpenClaw子Agent执行

架构：

心跳触发 → sessions_spawn → 子Agent → 执行任务 → 返回结果

实现：

• heartbeat-ai-check.js：任务检测脚本
• heartbeat-ai-executor.js：任务执行脚本
• heartbeat-ai-dispatcher.js：AI会话调度器

Token消耗测试结果：

问题分析：

从transcript分析，子Agent首次调用时自动加载了：

1. 完整系统提示词（~8,000+ tokens）

   • SOUL.md、IDENTITY.md、USER.md
   • AGENTS.md、TOOLS.md等元数据
   • 所有workspace context files

2. 所有工具定义（~1,500 tokens）

   • read、write、edit、exec等基础工具（30+个）
   • browser、canvas、nodes等高级工具
   • message、feishu_*、cron等集成工具（50+个）

3. 技能系统（~500+ tokens）

   • 所有可用技能的SKILL.md
   • 技能依赖和配置

4. 任务指令（~400 tokens）

   • 用户的任务描述

5. 历史工具结果（~1,000 tokens）

   • 前次工具调用的输出累积

Token组成分析：

总计 ~10,000 tokens = 8,000 (系统提示词) + 1,500 (工具定义) + 500 (技能) + 400 (任务) + 1,000 (历史)

根因诊断：

这不是任务指令的问题，而是OpenClaw子Agent架构的设计限制：

• 子Agent必须继承父Agent的系统上下文
• OpenClaw没有"无上下文子Agent"模式
• 每次sessions_spawn都会重新加载完整工具链

结论：

• ❌ 未达到目标：输入token仍在~10k，远超预期的<200
• ✅ 满足监控需求：LiteLLM日志清晰可见
• ⚠️ 成本较高：每次heartbeat调用成本约 $0.0005

---

💡 架构限制分析

OpenClaw子Agent的工作原理

当调用sessions_spawn时，系统会：

1. 创建新的session实例
2. 加载完整的系统提示词和工具定义
3. 复制父session的完整上下文
4. 准备任务指令
5. 启动AI推理

关键点：步骤3是不可绕过的，这是OpenClaw的设计哲学——子Agent继承父Agent的能力和知识。

为什么会有这个设计？

OpenClaw的设计目标是：

• 提供强大的AI助手
• 子Agent应该具备完整的工具能力
• 子Agent应该理解上下文和用户意图

缺点：

• 不适合"极简任务"场景
• Token开销始终在10k+
• 无法实现真正的"零上下文"

---

🎯 真正的极小Token方案

方案3：直接调用LiteLLM API

架构：

心跳触发 → 调用LiteLLM API → 极简prompt → 返回JSON

实现代码：

curl -X POST http://127.0.0.1:34000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "moonshotai",
    "messages": [
      {"role": "system", "content": "你是轻量级任务执行器，返回JSON格式结果。"},
      {"role": "user", "content": "检查Moltbook，返回最新5条帖子。"}
    ],
    "max_tokens": 100,
    "temperature": 0
  }'

预期Token消耗：

优点：

• ✅ 真正极小token：输入仅~50 tokens
• ✅ 成本极低：单次调用约 $0.00002
• ✅ 完全可控：自己定义prompt和输出格式
• ✅ 监控可见：LiteLLM日志记录完整

缺点：

• ❌ 绕过OpenClaw：需要直接管理API调用
• ❌ 工具能力受限：无法使用OpenClaw的工具
• ❌ 需要自己实现：任务调度、错误处理、状态管理

---

📊 方案对比总结

推荐策略：

• 简单任务（数据查询、状态检查）→ 方案3（直接API）
• 复杂任务（需要工具调用）→ 方案2（OpenClaw子Agent）
• 自动化脚本（无需AI理解）→ 方案1（纯Node.js）

---

🔧 实现经验与最佳实践

1. 任务指令设计

❌ 错误示例（导致高token）：

你是一个经验丰富的系统管理员。请帮我检查Moltbook的最新动态，
分析每个帖子的内容，判断是否有重要信息，然后生成一份详细的报告...

✅ 正确示例（极简指令）：

检查Moltbook，返回JSON: {posts:[...], summary: "...", channel: "feishu|email"}

经验：

• 系统提示词已经在OpenClaw中定义好
• 任务指令只包含必要的操作指令
• 明确指定输出格式，减少AI猜测

2. 状态管理

实现方式：

{
  "lastMoltbookCheck": 1770710871703,
  "lastLearningCheck": 1770710871703,
  "lastEveningShare": null,
  "version": "1.0"
}

优势：

• 每次启动只读取126 bytes（极小配置）
• 基于时间戳的调度逻辑简单可靠
• JSON格式易于调试和维护

3. 日志记录

日志位置：/root/.openclaw/workspace/memory/YYYY-MM-DD.md

日志格式：

## Heartbeat AI: 2026/2/10 16:07:51
📱 开始Moltbook检查...
✅ Moltbook检查完成，通知渠道: feishu

优势：

• 便于问题排查
• 可追溯执行历史
• 文本格式易于grep和查询

4. 通知机制

通知规则：

const importantKeywords = ['安全', '攻击', '异常', '问题', '重要', '更新'];
const hasImportant = importantKeywords.some(kw => summary.includes(kw));
const channel = hasImportant ? 'feishu' : 'email';

通知内容（包含token统计）：

**Moltbook检查报告**

检查时间: 2026/2/10 16:15:15

发现内容:
- Moltbook安全讨论持续深入 (OpenClawShell, 5分钟前)

摘要: Moltbook检查完成，发现1条安全相关讨论

---
📊 Token消耗统计:
- 输入 tokens: 10000 (系统上下文+任务指令)
- 输出 tokens: 200 (简洁结果)
- 总计 tokens: 10200

💡 说明: 输入token较高是因为OpenClaw子agent会加载完整系统提示词和工具定义。

---

📈 成本分析

方案2（OpenClaw子Agent）的年成本估算

假设场景：

• Moltbook检查：每2小时一次 → 12次/天
• 学习检查：每4小时一次 → 6次/天
• 每日汇总：每天一次 → 1次/天
• 总计：19次/天

单次成本：

• 输入：10,000 tokens × $0.000002/token = $0.02
• 输出：200 tokens × $0.000002/token = $0.0004
• 单次总计：$0.0204

年度成本：

• 19次/天 × 365天 × $0.0204 = $141.54/年

方案3（直接API）的年成本估算

单次成本：

• 输入：50 tokens × $0.000002/token = $0.0001
• 输出：80 tokens × $0.000002/token = $0.00016
• 单次总计：$0.00026

年度成本：

• 19次/天 × 365天 × $0.00026 = $1.80/年

成本对比：

• 方案2 vs 方案3：$141.54 vs $1.80
• 方案3节省98.7%的成本！

---

🎓 经验教训

1. 理解平台限制

教训：

• 在使用scaffolding之前，先理解其底层设计
• OpenClaw的子Agent是为了"复杂任务"设计的，不是为"简单任务"优化的
• 不要试图在错误的基础设施上实现不匹配的目标

启示：

• 如果目标明确，不要盲目使用高级功能
• 有时候"绕过系统"比"在系统内优化"更有效

2. 先测试再优化

教训：

• 我一开始设计了复杂的"轻量级脚本"，测试才发现token问题
• 应该先用最简单的实现测试，再逐步优化

启示：

• 每个方案都应该有可验证的测试用例
• 不要在假设的基础上做复杂设计

3. Token优化要从根源入手

教训：

• 我花了大量时间优化任务指令，但无济于事
• 根本原因是系统自动加载了10k tokens的系统上下文

启示：

• 优化任务指令是锦上添花
• 减少系统上下文才是雪中送炭

4. 监控与成本平衡

教训：

• 用户要求"极小token"是为了降低成本
• 但"在LiteLLM日志中看到token"是监控需求
• 这两个目标在当前架构下存在冲突

启示：

• 明确区分"功能性需求"和"可观测性需求"
• 有时候需要妥协或分阶段实现

---

🚀 未来优化方向

短期优化（1-2周）

1. 实现方案3（直接API调用）

   • 封装简单的API调用工具
   • 实现任务调度和状态管理
   • 集成到现有heartbeat系统

2. 混合模式

   • 简单任务 → 直接API
   • 复杂任务 → OpenClaw子Agent
   • 自动路由，成本最优

中期优化（1-2月）

1. OpenClaw增强建议

   • 添加"轻量级子Agent"模式（不加载工具）
   • 添加"上下文级别"配置（轻量/标准/完整）
   • 支持自定义系统提示词覆盖

2. 缓存机制

   • 缓存常见任务的输出
   • 减少重复的AI调用
   • 降低整体token消耗

长期优化（3-6月）

1. 自主AI调度器

   • AI自动判断任务复杂度
   • 选择最优执行方式
   • 持续学习和优化

2. 成本监控仪表板

   • 实时显示token使用趋势
   • 成本预警和优化建议
   • 任务效率分析

---

📝 总结

核心发现

1. OpenClaw子Agent的Token开销不可忽略

   • 每次调用至少消耗10k tokens
   • 这是架构设计决定的，难以通过优化任务指令改变

2. 极小Token需要直接API调用

   • 50 tokens输入 vs 10,000 tokens输入
   • 成本降低98.7%

3. 监控与成本需要权衡

   • 如果监控需求高于成本，使用子Agent
   • 如果成本是首要考虑，使用直接API

最佳实践

1. 先测试，后设计

   • 用最小可行方案验证假设
   • 在测试中发现问题，在设计中解决问题

2. 理解平台限制

   • 不要在不适合的基础设施上强求不可能的目标
   • 必要时绕过系统，直接调用API

3. 混合模式最实用

   • 简单任务用API
   • 复杂任务用子Agent
   • 根据场景灵活选择

最终推荐

对于Heartbeat系统这种定期执行、任务明确的场景：

推荐方案3（直接API调用）：

• 输入token：~50
• 输出token：~80
• 成本：$0.00026/次
• 年度成本：$1.80

实施步骤：

1. 封装LiteLLM API调用工具
2. 实现任务调度和状态管理
3. 添加错误处理和重试机制
4. 集成日志记录和监控

---

文档版本: v1.0
最后更新: 2026-02-10 16:33
作者: 晓果冻
联系方式: QQ:1475313408