OpenClaw 源码自检(二):定位与机制 8 问

这是"框架理解自检"系列的第 2 篇，共 5 篇。本篇覆盖 OpenClaw 的核心定位和机制，含 4 道基础题（ Q9-Q12 ）和 4 道进阶题（ Q22-Q25 ）。

上一篇我们用 8 道题自检了 Claude Code 的核心概念。你可能已经发现， Claude Code 的很多设计决策都围绕一个中心：prompt caching。

那 OpenClaw 呢？它的设计中心是什么？为什么它的默认模型不是 Claude 而是 GPT-5.5 ？它的 compaction 为什么走了一条完全不同的路？

这 8 道题帮你验证你对 OpenClaw 的理解深度。

Q9 ： OpenClaw 的默认模型说明了什么？

OpenClaw 的默认 Provider 是 OpenAI，默认模型是 GPT-5.5。

export const DEFAULT_PROVIDER = "openai";export const DEFAULT_MODEL = "gpt-5.5";

这个事实直接说明了 OpenClaw 的根本定位：提供者无关（ provider-agnostic ）。它不依赖任何特定 LLM 厂商， Claude 只是它支持的 20+ 个 Provider 之一。

这和 Claude Code 形成了鲜明对比——Claude Code 深度绑定 Anthropic API ，利用 prompt caching 等平台专属特性获得性能优势。 OpenClaw 则牺牲了这种深度绑定带来的好处，换取了跨 Provider 的灵活性。

Q10 ： OpenClaw 的人设文件体系

Claude Code 有一个 CLAUDE.md 作为项目级操作手册。 OpenClaw 对应的是一套分离的文件体系：

文件	职责
SOUL.md	核心人格/角色定义
IDENTITY.md	身份描述（名字、口吻、风格）
USER.md	用户画像
SKILL.md	技能定义
AGENTS.md	Agent 配置

这种分离设计反映了 OpenClaw "通用个人助手"的定位——它需要稳定的人格（你的 AI 助手不能每次重启就换一种性格）和独立的用户理解（记住你是谁、你喜欢什么）。

Claude Code 作为编程工具不需要"人格"，一个项目级操作手册就够了。

Q11 ：通道适配在哪一层？

OpenClaw 支持 20+ 消息通道（ WhatsApp 、 Telegram 、 Discord 、 Slack...）。这些通道的适配在 Gateway 层完成，不在 Agent Runtime 层。

用户 ─┬─ WhatsApp ─┐      ├─ Telegram  ├─ Gateway ─── Agent Runtime      ├─ Discord   │      └─ Slack     ┘

为什么不放在 Agent Runtime ？因为消息通道的协议差异巨大： HTTP webhook 、 WebSocket 、长轮询，认证机制各不相同，媒体格式也不同。如果放在 Agent Runtime ， Agent 的逻辑会被平台适配代码污染。

Gateway 做统一的协议转换和消息标准化， Agent Runtime 只接收标准化后的消息，保持逻辑纯粹。

Q12 ： Claude Code 在 OpenClaw 中的真实地位

一句话：Claude Code 是 OpenClaw 的一个可选编程外包 Skill ，地位等同于 Codex 和 OpenCode 。

当 OpenClaw 收到编程任务时，可以选择把任务外包给 Claude Code CLI 来执行。但 Claude Code 不是 OpenClaw 的核心组件，不在关键路径上。 OpenClaw 也可以用自己的 exec/write 通用工具来完成编程任务——只是效果不如 Claude Code 好。

很多人以为 OpenClaw 是"Claude Code 加了一层壳"。错了。它们从底盘开始就是不同的系统。

Q22 ： Compaction 质量保障的路线差异

Claude Code 偏重"减少损失"： microCompact 预清理 + partial 模式 + post-compact 文件恢复 + 转录文件自救路径。但它没有显式验证压缩质量——如果 LLM 生成了低质量摘要，系统不会检测到。

OpenClaw 偏重"验证质量"：压缩本身比较粗糙（全量、一次性、无预清理），但压缩后有 4 道校验：

1.必需章节验证 — 检查摘要是否包含所有结构化章节

2.标识符保留校验 — 提取 hex ID 、 URL 、文件路径，验证它们在摘要中存活

3.用户请求重叠验证 — 确认最新用户请求被反映

4.质量不合格则重试 — 最多 3 次

对于编程场景， Claude Code 更优（代码文件恢复至关重要）；对于通用对话， OpenClaw 的质量守卫能避免低质量摘要。

Q23 ：插件化架构 vs Tool 注册机制

Claude Code 的所有工具定义在 getAllBaseTools() 的有序数组中，编译进二进制。添加新工具需要修改源码、重新编译。通过 MCP 可以扩展外部工具，但 MCP 工具是延迟加载的二等公民。

OpenClaw 的 ClawHub 是一个完整的插件市场： 400+ SDK subpath export ，第三方可以独立开发 Provider 、 Channel 、 Memory 、 Tool 插件，实现标准接口后打包发布，运行时动态加载，无需重编译。

本质差异： Claude Code 是封闭生态（质量可控但扩展受限）， OpenClaw 是开放生态（扩展性强但质量参差不齐）。

Q24 ：多 Agent 场景的 Token 开销

OpenClaw 的多 Agent 任务消耗的 token 是单 Agent 的 4-6 倍（理想应该是 1.5-2 倍）。浪费来源：

•每个子 Agent 启动都注入完整 system prompt （没有 prompt caching ）

•每次 ~40-50 行 subagent context 注入

•父→子任务描述传播的信息膨胀

•子 Agent 结果回传的 token 消耗

Claude Code 的 Sub Agent 有同样问题吗？程度轻得多。因为 prompt caching 让相同前缀只付一次全价， Fork Agent 的字节级相同前缀共享缓存，子 agent 还默认关闭 thinking 省输出 token 。

这是 Claude Code 的结构性优势——来自 Anthropic API 的 prompt caching 能力， OpenClaw 作为 multi-provider 系统无法简单复制。

Q25 ： LLM Provider 路由决策

路由在 Agent Runtime 层做出。每个 Provider 是一个独立的 Extension 包，实现统一的 ProviderPlugin 接口。

一个请求如何决定用 GPT 还是 Claude ？

1.用户配置中设定默认 Provider 和 Model

2.可以在 Session / Agent / Skill 级别覆盖

3.Agent Runtime 根据配置实例化对应的 Provider Extension

4.每个 Provider Extension 自己维护模型目录、定价信息、 context window 大小

可以基于成本、能力、可用性做路由策略——比如简单任务用便宜的模型，复杂编程任务切换到 Claude 。

下一篇预告："Claude Code 源码自检（三）"——auth 验证到底发生在什么时候？ microCompact 为什么不需要调 LLM ？ Swarm 为什么用文件邮箱而不是 WebSocket ？ 9 道深入机制题。