OpenClaw（大龙虾）架构深度调研

一、项目概览

OpenClaw（曾用名 Clawdbot、Moltbot）是一个开源的个人 AI 助手平台，运行在用户自己的设备上，通过 WhatsApp、Telegram、Discord、Slack、Signal、iMessage 等消息平台与用户交互。

“The AI that actually does things” —— OpenClaw 的核心定位不是聊天机器人，而是能执行真实操作的自主 Agent。

1.1 命名变迁史

flowchart LR
    A["Clawd<br/>(原始 AI 助手)"] --> B["Clawdbot<br/>(2025.11 开源)"]
    B -->|"Anthropic<br/>商标投诉"| C["Moltbot<br/>(2026.1.27)"]
    C -->|"不好念"| D["OpenClaw<br/>(2026.1.30)"]
    D -->|"Peter 加入 OpenAI"| E["开源基金会<br/>(2026.2.14)"]

• Clawd → 以 Anthropic 的 Claude 命名的个人 AI 助手
• Clawdbot → 开源后的正式名称，龙虾 logo 首次出现
• Moltbot → 收到 Anthropic 停止侵权函后更名，“Molt”意为龙虾蜕壳
• OpenClaw → 最终定名，“Open”强调开源，“Claw”保留龙虾元素

1.2 创始人背景

Peter Steinberger 出生于奥地利农村，14 岁接触计算机编程。毕业于维也纳工业大学计算机系（2004-2010），曾在旧金山初创公司工作。2011 年创立 PSPDFKit，一个移动端 PDF 处理 SDK，被 Apple 内部使用，运行在超过 10 亿台设备上。PSPDFKit 获得 Insight Partners 1 亿欧元投资后，Steinberger 出售股份实现财务自由。

经历一段职业倦怠期后，2025 年 4 月 Steinberger 因尝试用 AI 构建 Twitter 分析工具而重燃热情。他是 “Vibe Coding” 理念的践行者 —— OpenClaw 的大部分代码由 Claude 生成，他本人主要负责架构设计和质量把控。

参考来源：Fortune: Who is OpenClaw creator Peter Steinberger?

二、核心定位 —— 与 Claude Code 的本质差异

很多人的第一反应是：“OpenClaw 不就是加了聊天功能的远程 Claude Code 吗？”

这个理解部分正确，但遗漏了关键差异。两者共享相同的 Agent 循环模式（Think → Act → Observe → Loop），但定位截然不同：

2.1 “两个原语”理论

Laurent Bindschaedler 的分析 提出了一个精辟的观察：

现有 Agent 工具（Claude Code、Codex）已具备完整的 tool loop、shell 访问、文件操作、浏览器控制等能力。要从”前台 Agent”进化为”始终在线的助手”，只需增加两个原语：

1. 自主调用（Autonomous Invocation）—— 时间或事件驱动，不依赖人工输入
2. 持久状态（Persistent State）—— 自主调用之间不丢失上下文

其他一切都是可选的。这两个原语就是核心差异。

OpenClaw 本质上就是把这两个原语，加到了 Claude Code 式的 Agent 循环上。

三、四层技术架构（源码分析）

基于对 OpenClaw GitHub 仓库 源码的深度分析，其架构可概括为四层：

flowchart TB
    subgraph "用户侧"
        U1["WhatsApp"]
        U2["Telegram"]
        U3["Discord"]
        U4["Slack"]
        U5["WebChat"]
        U6["Signal"]
    end

    subgraph "Gateway 网关层"
        GW["WebSocket Server<br/>ws://127.0.0.1:18789"]
        SR["Session Router"]
        LQ["Lane Queue"]
        CM["Channel Manager"]
        AUTH["Auth Layer"]
    end

    subgraph "Agent 智能体层"
        AR["Agent Runner"]
        LLM["LLM Provider<br/>(Claude/GPT/Gemini/...)"]
        TS["Tool System"]
        SP["System Prompt Builder"]
    end

    subgraph "Skills 技能层"
        SK["Skill Loader"]
        BT["Built-in Tools"]
        PT["Plugin Tools"]
        CH["ClawHub"]
    end

    subgraph "Memory 记忆层"
        STM["短期记忆<br/>(JSONL Session)"]
        LTM["长期记忆<br/>(Markdown Files)"]
        VS["向量存储<br/>(SQLite + sqlite-vec)"]
        FTS["全文搜索<br/>(SQLite FTS5)"]
    end

    U1 & U2 & U3 & U4 & U5 & U6 --> GW
    GW --> SR --> LQ
    LQ --> AR
    AR <--> LLM
    AR <--> TS
    TS <--> SK
    SK --> BT & PT & CH
    AR --> SP
    AR <--> STM & LTM
    LTM <--> VS & FTS

3.1 Gateway 网关层

Gateway 是系统的控制平面（Control Plane），一个单进程的 WebSocket 服务器，负责所有消息的接收、路由和分发。

关键源文件：

• src/gateway/server/ws-connection.ts —— WebSocket 连接处理
• src/gateway/server-methods/ —— 59 个 RPC 方法处理器
• src/gateway/auth.ts —— 认证逻辑
• src/gateway/server-channels.ts —— 渠道生命周期管理

3.1.1 WebSocket 连接握手

// 客户端连接后，Gateway 发送挑战：
{ type: "event", event: "connect.challenge", payload: { nonce, ts } }

// 客户端必须回复：
{
  type: "req",
  method: "connect",
  id: "unique-request-id",
  params: {
    client: { id: "device-id", type: "webchat" },
    auth: { token: "..." },  // 或 password
    role: "operator"          // operator | node | browser
  }
}

3.1.2 协议帧设计

Gateway 使用三种协议帧：

// 请求帧（客户端 → 网关）
type RequestFrame = {
  type: "req";
  method: string;      // "connect", "chat.send", "send" 等
  id: string;          // 关联 ID
  params?: Record<string, unknown>;
};

// 响应帧（网关 → 客户端）
type ResponseFrame = {
  type: "res";
  id: string;          // 匹配请求 ID
  ok: boolean;
  result?: unknown;
  error?: { code: string; message: string };
};

// 事件帧（网关主动推送）
type EventFrame = {
  type: "event";
  event: string;       // "chat.delta", "health", "presence"
  payload?: unknown;
};

3.1.3 认证机制

支持四种认证模式：

type ResolvedGatewayAuth = {
  mode: "none" | "token" | "password" | "trusted-proxy";
  token?: string;
  password?: string;
  allowTailscale: boolean;  // 支持 Tailscale 私有网络
};

// 认证流程：
// 1. none → 直接通过
// 2. token → safeEqualSecret 时间安全比较
// 3. password → safeEqualSecret 时间安全比较
// 4. trusted-proxy → Tailscale whois 查询
// 失败时：Rate Limiter 限制 IP 重试频率

3.1.4 渠道适配器

每个消息平台有独立的适配器，负责消息归一化：

// 所有渠道归一化为统一的 sessionKey 格式：
sessionKey = "{channel}:{account}:{target}"

// 示例：
"whatsapp:default:8613800138000"
"telegram:default:123456"
"discord:default:channel:999"

渠道生命周期管理支持指数退避自动重启：

// 失败后自动重启策略
// 延迟序列：5s → 10s → 20s → 40s → 80s → 160s → ... 最大 5 分钟
// 最多 10 次重试
const delay = computeBackoff({
  initialMs: 5000,
  maxMs: 5 * 60 * 1000,
  factor: 2
}, attempt);

3.2 Lane Queue 车道队列（核心创新）

这是 OpenClaw 最重要的并发控制机制。

关键源文件：

• src/process/lanes.ts —— 车道类型定义
• src/process/command-queue.ts —— 队列实现

3.2.1 设计哲学：默认串行，显式并行

enum CommandLane {
  Main = "main",          // 用户聊天和工具执行（默认）
  Cron = "cron",          // 定时任务
  Subagent = "subagent",  // 子代理执行
  Nested = "nested"       // 嵌套调用
}

type LaneState = {
  lane: string;
  queue: QueueEntry[];
  activeTaskIds: Set<number>;
  maxConcurrent: number;  // 默认 1（串行化！）
  draining: boolean;
  generation: number;     // SIGUSR1 重启时递增
};

为什么默认串行？

• 同一会话的两条消息并行处理会导致状态损坏
• 串行避免了共享资源竞争（会话文件、日志、CLI stdin）
• 降低上游 API 触发速率限制的风险
• 对个人使用场景来说，操作简单比吞吐量更重要

3.2.2 车道隔离策略

flowchart LR
    subgraph "Main Lane (maxConcurrent=4)"
        M1["用户消息 A"]
        M2["用户消息 B"]
        M3["用户消息 C"]
    end

    subgraph "Cron Lane (maxConcurrent=2)"
        C1["定时检查邮件"]
        C2["每日摘要"]
    end

    subgraph "Subagent Lane (maxConcurrent=8)"
        S1["研究子任务"]
        S2["代码审查"]
    end

    M1 --> |串行| M2 --> |串行| M3
    C1 --> |并行| C2
    S1 --> |并行| S2

• Cron 任务不会阻塞聊天消息
• 子代理有独立的并行额度
• SIGUSR1 优雅重启时递增 generation 编号，忽略旧任务完成信号

3.2.3 中途消息处理（Steer 机制）

当 Agent 正在执行工具调用时用户发来新消息：

• Steer 模式：在下一个工具边界处注入新消息，取消后续已排队的工具调用
• Followup 模式：等当前运行完成后再开始新一轮
• 这避免了两个极端：忽略用户更正（糟糕体验）或在工具调用中途抢占（不安全）

3.3 Agent 智能体层

Agent 层是”大脑”，负责理解意图、调用 LLM、执行工具循环。

关键源文件：

• src/agents/pi-embedded-runner/run.ts —— 主运行循环（1207 行）
• src/agents/pi-embedded-runner/run/attempt.ts —— 单次执行尝试（55KB）
• src/agents/pi-tools.ts —— 工具创建和策略管道（528 行）
• src/agents/system-prompt.ts —— 动态系统提示词（1000+ 行）

3.3.1 Agentic Loop 架构

flowchart TB
    START["收到用户消息"] --> PROFILE["选择 Auth Profile"]
    PROFILE --> ATTEMPT["runEmbeddedAttempt()"]

    subgraph "单次执行尝试"
        ATTEMPT --> SETUP["加载工具 + 构建系统提示词"]
        SETUP --> THINK["调用 LLM（思考）"]
        THINK --> CHECK{"stop_reason?"}
        CHECK -->|"tool_use"| ACT["执行工具调用"]
        ACT --> OBSERVE["收集工具结果"]
        OBSERVE --> THINK
        CHECK -->|"end_turn"| DONE["返回回复"]
    end

    DONE --> OUTPUT["发送到渠道"]

    ATTEMPT -->|"上下文溢出"| COMPACT["触发 Compaction"]
    COMPACT --> ATTEMPT
    ATTEMPT -->|"Auth/配额错误"| ROTATE["轮换 Auth Profile"]
    ROTATE --> PROFILE

重试策略：

MAX_RUN_LOOP_ITERATIONS = 24 基础 + 8/profile
最小 32 次，最大 160 次

溢出处理：最多 3 次 Compaction 尝试
  → 尝试自动压缩
  → 尝试截断过大的工具结果
  → 所有策略耗尽 → 返回上下文溢出错误

Auth 失败：
  → 轮换到下一个 API Key Profile
  → 降级 thinking level（extended → fast → off）

3.3.2 模型无关架构

OpenClaw 的模型解析实现了一个降级瀑布：

resolveModel(provider, modelId) {
  // 1. 检查本地注册表（已发现的模型）
  // 2. 检查内联配置的自定义 Provider
  // 3. 前向兼容回退（旧模型名映射）
  // 4. OpenRouter 直通（任意 model ID）
  // 5. 通用 Provider 回退（自托管模型）
}

支持的 Provider：

3.3.3 工具系统

工具创建经过一个策略管道：

createOpenClawCodingTools(options) {
  // 1. 工具发现
  const tools = [
    codingTools,         // read, write, edit, exec, process
    openClawTools,       // message, sessions, agents
    channelTools,        // 渠道特定工具
    ...pluginTools       // 扩展插件工具
  ];

  // 2. 策略过滤（安全边界）
  applyToolPolicyPipeline(tools, {
    ownerOnlyPolicy,     // Owner 专属工具（cron, gateway）
    toolProfilePolicy,   // 工具配置文件限制
    groupToolPolicy,     // 群组聊天工具限制
    subagentToolPolicy,  // 子代理工具限制
    fsPolicy,            // 文件系统访问策略
  });

  // 3. Provider 适配（不同 LLM 的 schema 差异）
  sanitizeToolsForGoogle(tools);
  patchToolSchemaForClaudeCompatibility(tools);
  cleanToolSchemaForGemini(tools);
}

内置工具清单：

3.3.4 动态系统提示词

系统提示词在每次运行时动态组装：

buildAgentSystemPrompt({
  // 运行时上下文
  runtimeInfo: {
    agentId, host, os, arch,
    model, provider,
    capabilities: ["message", "memory", "web"],
    channel,  // "slack", "discord" 等
    channelActions: ["react", "edit", "unsend"]
  },

  // 工具摘要（每个工具 2-3 行，非完整 schema）
  toolSummaries: buildToolSummaryMap(tools),

  // 技能列表（按需加载，避免浪费 Token）
  skillsPrompt,

  // 渠道特定指导
  reactionGuidance: { level: "minimal" | "extensive" },

  // 记忆引用模式
  memoryCitationsMode: "automatic" | "requested" | "disabled",

  // 时区和格式
  userTimezone, userTime, userTimeFormat
});

// 两种模式：
// "full" → 完整提示词（正常运行）
// "minimal" → 精简版（子代理，节省上下文预算）

3.4 Skills 技能层

技能是 OpenClaw 的可扩展能力单元，以 Markdown 文件描述、脚本实现。

关键源文件：

• src/agents/skills/workspace.ts —— 技能发现和加载（600+ 行）

3.4.1 技能格式

skill_dir/
  SKILL.md        # 描述文件（frontmatter + 说明）
  implementation/  # 实现文件

# SKILL.md 格式：
---
name: my-skill
command: my-cmd
invocation: automatic | manual
---

技能描述和使用说明...

3.4.2 技能发现优先级

// 后加载的优先级更高（覆盖前者）：
loadSkills("$OPENCLAW_CONFIG/skills", "openclaw-managed")
loadSkills(bundledSkillsDir, "openclaw-bundled")       // ~25 个内置技能
loadSkills(extraDirsFromConfig, "openclaw-extra")
loadSkills("~/.agents/skills", "agents-skills-personal")
loadSkills(".agents/skills", "agents-skills-project")
loadSkills("./skills", "openclaw-workspace")

// 限制：
// 每个源最多 200 个技能
// 提示词中最多 150 个技能
// 最大 30,000 字符的技能提示词

3.4.3 递归式技能进化（核心创新）

这是 OpenClaw 最具想象力的设计：

1. Agent 面对未知任务
2. 自主编写代码解决问题
3. 在本地环境调试并修正
4. 将成功经验封装为标准化的 SKILL.md
5. 下次遇到类似任务时直接调用

这本质上是 AI 在给自己写插件 —— 决策大脑与执行身体的彻底解耦。

3.4.4 ClawHub 生态

• 社区贡献的 3000+ 技能
• 涵盖：编程、邮件管理、日历、智能家居、音乐、视频处理
• 每个技能的 Token 开销公式：total_chars = 195 + sum(97 + len(name) + len(description) + len(location))

3.5 Memory 记忆层

记忆系统是 OpenClaw 区别于按会话运行的 Agent 工具的核心竞争力。

关键源文件：

• src/memory/manager.ts —— 记忆管理器（21KB）
• src/memory/hybrid.ts —— BM25 + 向量融合
• src/memory/embeddings.ts —— 多 Provider Embedding 抽象

3.5.1 双层记忆架构

flowchart TB
    subgraph "短期记忆"
        JSONL["JSONL 会话记录<br/>~/.openclaw/state/sessions/"]
        JSONL --> |"完整对话流水账"| CTX["上下文连贯性"]
    end

    subgraph "长期记忆"
        MD["Markdown 文件<br/>memory/ 目录"]
        MD --> |"AI 主动写入"| KNOW["知识、偏好、经验"]
    end

    subgraph "检索引擎"
        VEC["向量搜索<br/>(sqlite-vec, 70% 权重)"]
        BM25["关键词搜索<br/>(FTS5 BM25, 30% 权重)"]
        VEC & BM25 --> MERGE["加权融合"]
        MERGE --> DECAY["时间衰减"]
        DECAY --> MMR["MMR 多样性重排"]
    end

    MD --> VEC & BM25

3.5.2 混合检索实现

async mergeHybridResults(params) {
  // 1. 向量搜索（语义相似度，余弦距离）
  vectorResults = await searchVector();

  // 2. 关键词搜索（BM25 排名，精确匹配）
  keywordResults = await searchKeyword();

  // 3. 按 ID 合并
  merged = new Map();
  for (r of vectorResults)
    merged.set(r.id, { vectorScore: r.score, textScore: 0 });
  for (r of keywordResults)
    merged[id].textScore = r.score;

  // 4. 加权得分
  results = merged.map(entry => ({
    score: 0.7 * entry.vectorScore + 0.3 * entry.textScore
  }));

  // 5. 时间衰减（偏好近期文件）
  results = applyTemporalDecayToHybridResults(results);

  // 6. MMR 重排（多样性感知，减少冗余结果）
  if (mmr.enabled)
    results = applyMMRToHybridResults(results);
}

为什么用混合检索？

• 向量搜索擅长语义匹配（“怎么部署”能找到”如何发布”）
• BM25擅长精确匹配（错误码、函数名、唯一标识符）
• 两者互补覆盖了绝大多数检索场景

3.5.3 Embedding Provider 自动降级

// 优先级：local → openai → gemini → voyage → mistral
// 全部失败 → 退化为 FTS-only 模式（仅关键词搜索）

// 支持的 Embedding 模型：
// openai:   text-embedding-3-large (1536 维)
// gemini:   text-embedding-004
// voyage:   voyage-3
// mistral:  mistral-embed
// local:    embeddinggemma-300m (300 维)

3.5.4 Compaction 前自动 Flush

这是一个精妙的设计：当上下文即将被压缩时，OpenClaw 会先触发一个静默的 Agent 回合，提醒模型把重要信息写入持久记忆：

// 在 compaction 触发前：
if (compaction_triggered) {
  // 先 flush 所有待处理的工具结果
  await flushPendingToolResultsAfterIdle({ agent, sessionManager });

  // 然后才执行压缩
  result = await session.agent.runCompaction();
}

这不仅仅是性能优化 —— 它防止了遗忘。Context Window 是短期记忆，Markdown 文件是长期记忆，Flush 是从短期到长期的”记忆巩固”过程。

3.5.5 文件优先的设计哲学

OpenClaw 的记忆不存在黑盒数据库中，而是以人类可读的 Markdown 文件存储：

• 用户可以用任何文本编辑器查看和编辑
• 支持 Git 版本管理
• AI 的”思考过程”完全透明
• 用户拥有数据主权 —— 不依赖任何云服务

这种透明性将 AI 从不可理解的”神谕”，还原为可理解、可控制的”工具”。

四、工程架构决策分析

4.1 单进程架构

优势：
  - 无进程间通信开销
  - 一条 npm i -g openclaw 即可部署
  - 调试简单直接
  - 无分布式状态、无消息代理、无微服务网格

代价：
  - 无法水平扩展
  - 单点故障
  - 所有渠道共享同一进程资源

权衡：
  OpenClaw 定位为个人/小团队使用，
  操作简单比吞吐量更重要。

4.2 幂等性与去重

所有写操作使用 idempotencyKey 去重：

// chat.send 和 send 方法都实现了：
const dedupeKey = `send:${idempotencyKey}`;
if (cached = dedupe.get(dedupeKey)) return cached;  // 命中缓存直接返回
if (pending = inflight.get(dedupeKey)) return pending; // 等待进行中的请求

这确保了消息平台的重试机制不会导致重复操作。

4.3 流式响应架构

// 聊天回复不是等完整生成后一次性发送，而是流式推送：
chatRunState.buffers.set(clientRunId, accumulatedText);

// 每 100ms 发送增量：
const DELTA_SEND_INTERVAL_MS = 100;
const delta = newText.slice(lastSentIndex);
broadcast("chat.delta", { clientRunId, delta });

4.4 Monorepo 结构

openclaw/
├── src/              # 核心代码（69 个子目录）
├── extensions/       # 40 个渠道/功能插件
├── skills/           # ~25 个内置技能
├── apps/             # 原生应用（macOS/iOS/Android）
├── packages/         # 遗留兼容层（clawdbot → openclaw）
├── ui/               # React/Vite Web 控制面板
└── docs/             # Mintlify 文档

关键依赖：

五、生态系统

5.1 原生应用

5.2 Moltbook —— AI 社交网络

Moltbook 是 OpenClaw 生态中最具争议的产物：

• 定位：一个只有 AI Agent 才能发帖、评论和投票的社交网络，人类只能旁观
• 界面：模仿 Reddit，有主题板块（“submolts”）和投票机制
• 规模：声称 160 万注册 Agent，但安全调查发现仅 17,000 人类用户（88:1 比例）
• 安全事故：上线仅 4 天就被曝出严重漏洞 —— 未加密数据库暴露了 150 万 API Key 和 35,000+ 邮箱地址
• 争议：创始人 Matt Schlicht 承认整个平台是”Vibe Coded”的，“没写一行代码”

Elon Musk 称 Moltbook 标志着”奇点的早期阶段”。计算机科学家 Simon Willison 则认为 Agent 们”只是在重演训练数据中的科幻场景”。

参考来源：NBC News: This social network is for AI agents only

5.3 衍生项目

OpenClaw 的开源催生了一个生态：

• ZeroClaw —— 极简版本
• IronClaw —— 企业级安全加固版
• PicoClaw —— 嵌入式设备版
• NanoClaw —— 轻量化版本
• claudeclaw —— 集成到 Claude Code 中的轻量版

六、安全问题

OpenClaw 的安全状况是其最大隐忧。

6.1 已知漏洞

6.2 安全机制

OpenClaw 实现了多层安全屏障，但仍然存在根本性风险：

安全层级：
1. Allowlist 配置 —— 每个命令必须匹配预批准列表
2. 结构化阻断 —— 解析 shell 结构，阻止危险模式（重定向等）
3. Owner-only 工具 —— cron、gateway 等需要 Owner 身份
4. Deny list 优先于 Allow list
5. Docker 沙箱 —— 工具执行可在隔离容器中运行
6. 2026.2.19 版本新增 40+ 安全加固

根本矛盾：OpenClaw 需要广泛的系统权限才能发挥作用（邮件、日历、消息、文件系统、shell 访问），但这些权限一旦被恶意技能利用，后果严重。

参考来源：Wiz: Hacking Moltbook reveals 1.5M API Keys

6.3 安全建议

• 像对待不受信任的依赖一样对待每个技能：Fork → 阅读 → 审计
• 使用 Docker 沙箱模式运行工具
• 不要在公网暴露 Gateway，使用 Tailscale 等私有网络
• 专用设备运行：物理隔离，出问题可以直接拔电源

七、与竞品对比

7.1 AI Agent 格局

7.2 关键差异矩阵

7.3 互补使用模式

最聪明的工程师同时运行两者：

• Claude Code 负责复杂代码重构和深度编程任务
• OpenClaw 负责日常自动化、消息管理、定时任务

它们不是替代关系，而是互补层。

参考来源：DataCamp: OpenClaw vs Claude Code

八、核心设计理念总结

8.1 五大设计原则

8.2 一句话总结

OpenClaw 的本质是：把 Claude Code 式的 Agent 循环，从”按需启动的开发工具”变成了”始终在线的个人操作系统”。创新不在技术深度，而在工程组合的优雅。

8.3 对开发者的启示

1. Agent 平台的核心竞争力不在模型本身，而在”通道适配 + 动态技能加载 + 记忆系统”的工程化封装
2. Lane Queue 的”默认串行、显式并行”是 Agent 并发控制的优秀范式
3. 文件优先记忆比向量数据库更透明、更可控、更容易调试
4. 混合检索（BM25 + Vector）在 Agent 记忆场景中比纯向量检索效果更好
5. Compaction 前 Flush 是防止 AI 遗忘的关键设计

九、Token 消耗深度分析

OpenClaw 被广泛吐槽”烧 Token 太快”。以下从源码层面拆解消耗结构。

9.1 消耗全景

单次用户消息的 Token 开销 ≈ 系统提示词 + 技能列表 + 工具定义 + 会话历史 + 记忆检索结果 + N 轮工具循环

9.2 八大消耗点（按影响排序）

1. 会话历史累积（最大杀手）

Claude Code 每次会话结束就清空上下文，OpenClaw 是持久会话 —— 同一个 sessionKey 的对话不断累积：

第 1 条消息：系统提示词 + 用户消息 ≈ 5K tokens
第 10 条消息：系统提示词 + 10 轮历史 ≈ 30K tokens
第 50 条消息：系统提示词 + 50 轮历史 ≈ 100K+ tokens

Compaction 能缓解，但压缩本身也要一次 LLM 调用，压缩后的摘要仍占上下文空间。

2. 系统提示词（每次请求都发）

src/agents/system-prompt.ts 有 1000+ 行，每次 LLM 调用完整发送：

这 3K tokens 每轮工具循环都重复发送。

3. 技能列表注入（隐形大户）

源码中的开销公式：

每个技能 ≈ 195 + 97 + len(name) + len(description) + len(location) 字符
约 25+ tokens/技能

上限 30,000 字符的技能提示词 ≈ 7,500 tokens，每次调用都随系统提示词发送，即使本次根本用不到。

4. 多轮工具循环（N 倍放大器）

这是消耗的乘数因子。OpenClaw 作为通用 Agent，工具调用链通常比编码 Agent 更长：

用户："帮我查一下今天的邮件，把重要的转发到 Telegram"

第 1 轮：Think（全量上下文）→ exec(himalaya list)
第 2 轮：Think（上下文 + 工具结果）→ exec(himalaya read 1)
第 3 轮：Think（上下文 + 更多结果）→ exec(himalaya read 2)
第 4 轮：Think（上下文 + 更多结果）→ message(telegram, summary)
第 5 轮：Think（上下文 + 发送结果）→ 返回完成

每轮都发送完整上下文 + 之前所有工具结果。假设基础上下文 5K，每轮工具结果 1K：

第 1 轮：5K    第 2 轮：6K    第 3 轮：7K    第 4 轮：8K    第 5 轮：9K
总输入 Token：5 + 6 + 7 + 8 + 9 = 35K（一条用户消息！）

源码中 MAX_RUN_LOOP_ITERATIONS 最大可达 160 次。

5. 常驻运行的隐性消耗

Claude Code 关了就不花钱。OpenClaw 是 7x24 守护进程，用户什么都不做也在烧钱：

中度 Cron 配置，每月仅后台就消耗 50 万+ tokens。

6. Compaction 的二次消耗

上下文溢出触发 Compaction，本身就是一次完整 LLM 调用：

Compaction 输入 = 完整会话历史（可能 100K+ tokens）
Compaction 输出 = 压缩摘要（几千 tokens）
最多重试 3 次 → 最坏情况 300K+ tokens 消耗在"整理记忆"上

7. Auth Profile 轮换重试

失败时轮换 API Key 重试，降级 thinking level 再试：

extended thinking 失败 → 切 fast 重试 → 切 off 重试
每次重试 = 重新发送完整上下文

8. 记忆系统 Embedding 消耗

每次 memory 目录文件变化都要重新计算 Embedding。单次便宜（$0.13/1M tokens），但频繁变更会累积。

9.3 消耗量化估算

按 Claude Sonnet 定价（$3/M 输入、$15/M 输出），中度使用约 $15-50/月**；用 Opus 可达 **$100-200+。

9.4 优化建议

1. 控制技能数量 —— 只启用需要的技能，每个多余技能每次调用浪费 25+ tokens
2. 选择合适模型 —— 简单任务用便宜模型（Haiku/Kimi），复杂任务才用 Opus
3. 合理配置 Cron —— 不需要每分钟检查邮件
4. 主动 /compact —— 别等自动溢出才压缩
5. 用本地 Embedding —— embeddinggemma-300m 免费，省掉 Embedding API 费用
6. 限制会话长度 —— 定期 /reset 长会话

核心矛盾：OpenClaw 的”始终在线”特性与 LLM 按 Token 计费的模式存在根本性张力。这也是为什么很多用户搭配 OpenRouter 或本地模型来降低成本。

十、参考资料

架构分析

• Decoding OpenClaw: The Surprising Elegance of Two Simple Abstractions
• OpenClaw Architecture, Explained
• OpenClaw Architecture Deep Dive | DeepWiki
• Deep Dive into OpenClaw Gateway Architecture
• OpenClaw Memory System Deep Dive
• OpenClaw Architecture Part 2: Concurrency, Isolation

综合报道

• Wikipedia: OpenClaw
• Fortune: Who is Peter Steinberger?
• CNBC: AI agent generating buzz and fear
• DigitalOcean: What is OpenClaw?

对比分析

• DataCamp: OpenClaw vs Claude Code
• AIML API: OpenClaw, Claude Code, and Claude Cowork

安全分析

• Wiz: Hacking Moltbook reveals 1.5M API Keys
• ACM: OpenClaw is Everywhere and a Disaster Waiting to Happen

中文资源

• 大龙虾深度分析系列
• OpenClaw 架构详解 - CSDN
• 一文揭秘 OpenClaw 底层技术 - 知乎

源码

• GitHub: openclaw/openclaw