OpenClaw vs Claude Code 面试题:架构设计 15 问

这是”框架理解自检”系列的第 4 篇，共 5 篇。本篇覆盖 Q26-Q40 ，包括架构对比、设计决策分析和开放设计题。这一层没有标准答案——好的回答应该能说出 trade-off 。

前三篇测的是”知道什么”和”知道为什么”。这一篇测的是”能不能做设计决策”——给你一个架构问题，你能不能分析出 trade-off 并给出合理方案。

Q26 ：一个比喻区分两个框架

Claude Code ≈ 专业赛车（赛道上最快，但只在赛道上跑） OpenClaw ≈ 多功能越野车（上路、下田、载人、拉货都行）

“从底盘开始就不同”： Claude Code 的底盘是 queryLoop()——单用户、单会话、深度绑定 Anthropic API 、专为代码操作优化。 OpenClaw 的底盘是 Gateway + Agent Runtime——多通道、多 Provider 、多用户、常驻后台。

Claude Code 不需要 Gateway （只有终端入口），不需要多 Provider 路由（只用 Anthropic ），不需要用户管理。这些”不需要”让它可以把所有工程力量集中在编程体验上。

Q27 ： Prompt Caching 的结构性优势

优势来自 Anthropic API 的机制：相同前缀的请求只付一次全价，后续按 cache read 计费（约 1/10 ）。

Claude Code 的架构专门为此优化： system prompt 静态部分用全局缓存、 tools schema 有序数组保证字节一致、 Fork Agent 继承完整前缀共享缓存、动态边界隔离静/动态部分。

OpenClaw 很难复制：它用 20+ 个 Provider （大部分不支持 prompt caching ）、 system prompt 不是为缓存优化的（动态内容多）、 multi-provider 抽象层无法暴露 provider-specific 的缓存控制 API 。

Q28 ：编程能力差距的根因

至少三点：

专用工具集。 Claude Code 有 Edit （ diff-based 精确替换）、 Grep （代码搜索）、 Glob （文件匹配），每个工具的 prompt 有大量编程指引。 OpenClaw 只有 exec（通用 shell ），编辑文件得靠 sed/awk。

Prompt 工程深度。 BashTool prompt 约 400 行，包含完整 Git 安全协议和工具优先级指示。 OpenClaw 的工具 prompt 相对简短。

跨 Provider 兼容性约束。 Claude Code 的精调工具只需在一个模型上调好。 OpenClaw 的 Tool 要兼容 20+ Provider ，精调效果跨 Provider 很难保证。

上下文管理。多层 compaction 保护代码上下文， Plan Mode 强制先探索再动手——OpenClaw 两者都缺。

Q29 ： Swarm vs sessions_spawn

Swarm 适合编程场景的持续协作， sessions_spawn 适合通用多 Agent 的跨通道场景。

Q30 ： Markdown 文件 vs 向量数据库

Markdown 优势：零依赖、人可读可编辑可 git 跟踪、 LLM 检索比向量检索更精准（ Sonnet 能做否定推理）、冷启动快。

向量数据库优势：大规模记忆无硬限制、模糊语义匹配强、不需要 LLM 做检索。

Claude Code 的 200 文件上限对编程助手完全够用——它只存不可推导的高价值知识（用户偏好、行为反馈），代码库知识交给 Read/Grep 实时获取。 OpenClaw 作为通用助手可能需要存大量历史对话，向量数据库的规模优势更重要。

“高级”取决于场景，不是技术栈。

Q31 ： getAllBaseTools 的设计取舍

好处：工具顺序确定 → cache 稳定；编译时 DCE → 未用工具不打包；集中管理 → 容易审查安全性。

代价：添加工具必须改源码重编译；第三方无法独立发布 Tool 包。

如果要支持第三方生态？ MCP 已经在做了——但 MCP 工具是二等公民（延迟加载、需要 ToolSearch 发现）。要提升到一等公民，需要让 MCP 工具参与缓存前缀计算、支持 concurrencySafe 声明、支持 prompt 级指导注入。

Q32 ：为什么不支持多 Provider ？

产品决策，不是技术限制。 Claude Code 是 Anthropic 官方工具，深度绑定是战略选择： prompt caching 、 extended thinking 、精调的 tool_use 协议、 beta features 。

如果要加？改动量极大： API 客户端要为每个 Provider 写 SDK 、 3000+ 行请求参数组装几乎全是 Anthropic-specific 、所有缓存优化需要条件化、 Tool schema 格式可能不同。

Q33 ： Gateway 常驻设计的好与坏

好处：多通道 webhook 不中断、定时任务后台运行、 Session 状态持久化、多用户共享实例。

引入的复杂度：进程管理（守护进程配置）、多用户隔离和认证、内存泄漏防护、连接池管理（ 20+ 通道长连接）、优雅重启（不丢消息的热更新）、监控告警。

Claude Code 是 CLI ，进程随终端启停，完全不需要处理这些。少即是多。

Q34 ： Compaction 管道的可移植性

可以直接移植到 OpenClaw： microCompact （纯字符串操作）、 think-then-summarize （只要 LLM 支持结构化输出）、 post-compact 文件恢复（纯工程实现）。

因架构差异无法移植： partial compaction （需要精确控制消息数组切分）、 session memory 持久化（与 compact 触发机制紧密耦合， OpenClaw 的记忆系统走向量路线）、 prompt cache 优化（非 Anthropic Provider 没有这个目标）。

Q35 ： Skill 注入 Markdown 的优劣

最大优势：可扩展性极强，零代码门槛。写一个 .md 文件就能创建 Skill ，不需要 TypeScript 、不需要编译。同一套 .md 还能给 Cursor 、 Windsurf 等其他 agent 复用。

最大限制：执行精度依赖模型理解能力。模型可能拼错参数、忘记步骤、误解指令。对 Opus 级别模型问题不大，对较弱模型可能不可靠。

Q36 ：结合两者优势的新框架

最大挑战：编程深度要求深度绑定单一 Provider （利用 caching 、 thinking ），平台广度要求 provider-agnostic 抽象。这两个需求根本矛盾。

可能方案：底层 provider-agnostic （参考 OpenClaw ），上层有 Provider 专属优化适配器。检测到 Anthropic 时自动启用 Claude Code 级别的缓存优化；其他 Provider 降级为通用模式。从 OpenClaw 的 Gateway 底盘开始，移植 Claude Code 的编程工具集和多层 compaction 。

Q37 ：真正并行 Agentic Loop 的挑战

需要解决：状态一致性（多 loop 并行改文件的冲突）、上下文分裂（一个 loop 读了文件另一个改了同一个文件）、终止协调（关键发现需要通知其他 loop ）、 token 预算分配、用户交互冲突（多 loop 同时需要审批）、 compact 同步。

Swarm 已经部分解决了这些（独立进程隔离 + 文件邮箱通信），但它是粗粒度并行，不是同一 loop 内的细粒度并行。

Q38 ：给 Claude Code 加语音交互

改动最大的是输入层：需要音频捕获、流式 STT 引擎、 Buffer 管理、 barge-in 检测。现有架构完全没有音频处理管道。

输出层（ TTS ）相对简单，消息处理层（ STT 结果作为 user message ）改动不大， system prompt 可能需要增加语音友好指令（避免代码块等不适合朗读的内容）。

Q39 ： MCP vs OpenClaw 插件系统

MCP 能覆盖工具型插件（数据库查询、 API 调用），但不能覆盖框架级扩展（接入新 LLM Provider 、新消息通道、新记忆后端）。

MCP 是协议标准化（关注互操作性，像 USB ）， OpenClaw 插件是接口标准化（关注生态繁荣，像 App Store ）。

Q40 ： Compaction 压力测试设计

下一篇预告：最后一篇”综合自检（五）”——5 道陷阱题测试你的常见误解， 5 道综合题串联完整处理链路，包括终极问题：”为什么不能直接调 API ？”