OpenClaw vs Claude Code 面试题:陷阱题与全链路 10 问-夜雨聆风

OpenClaw vs Claude Code 面试题:陷阱题与全链路 10 问

这是”框架理解自检”系列的最后一篇，共 5 篇。本篇覆盖 Q41-Q50 ： 5 道陷阱题测试常见误解， 5 道综合题串联完整处理链路。

前四篇测的是”知道什么、为什么、怎么设计”。这一篇测的是你会不会被常见的错误直觉骗到，以及能不能把所有知识串成一条完整的链路。

陷阱题的规则：每题给你一个看起来合理的说法，你来判断对不对、为什么。

Q41 ：”代码量 70 倍 = 功能 70 倍？”

“OpenClaw 14,700 个文件 vs Claude Code 200 个文件，所以功能强 70 倍。”

错。

OpenClaw 14,700 个文件中，大量是 20+ Provider 的适配代码（同样的逻辑为每个 Provider 写一遍）、 20+ Channel 的适配代码、 143 个插件扩展。这些是广度不是深度。

Claude Code 约 200 个文件高度浓缩——单个核心文件可以有 3,000+ 行。在共同的编程领域， 200 个文件实现的功能深度远超 14,700 个文件。

代码量反映的是产品范围（ scope ），不是功能深度（ depth ）。一个做 20 件事做得浅，一个做 1 件事做到极致。

Q42 ：”Claude Code 没有记忆系统？”

完全错误。 Claude Code 有至少 5 层记忆机制：

1.Auto Memory — 跨会话持久化， 4 种类型（ user/feedback/project/reference ）， Markdown 文件 + MEMORY.md 索引 + Sonnet 智能召回

2.Session Memory — 会话内增量更新， 9 section 模板， compact 后恢复上下文

3.CLAUDE.md — 用户手写的项目级操作手册

4.Extract Memories — 后台 fork agent 自动提取记忆

5.Auto Dream — 后台定期整合零散记忆

它不只有记忆系统，它的记忆系统还比大多数框架更精巧——写入端用 Agent 判断该不该存，读取端用 Sonnet 做智能召回。

Q43 ：”Sub Agent 就是开一个新进程？”

只有一种形态接近这个描述。

•普通 Sub Agent：不是新进程。在同一 Node.js 进程中递归调用 query()，用独立的上下文做状态隔离。

•Fork Agent：不是新进程。同样在同一进程中调用 query()，继承父的完整上下文。

•Teammate （ Tmux/iTerm2 ）：是一个全新的 claude 进程，在独立终端 pane 中运行。

•Teammate （ In-Process ）：不是新进程。同一 Node.js 中用 AsyncLocalStorage 隔离。

“开新进程”只适用于 Tmux/iTerm2 后端的 Teammate 。其他三种都是进程内的逻辑隔离。

Q44 ：”框架不干预工具选择？”

“Tool 是模型自己选择的，框架不干预。”

不完全正确。框架在多个层面干预：

禁止使用： Plan Mode 禁止写操作； Sub Agent 有 ALL_AGENT_DISALLOWED_TOOLS 黑名单；异步 Agent 只允许白名单内工具；alwaysDeny 规则可以完全禁止特定工具； feature flag 可以编译时移除工具。

强制使用：tool_choice: { type: "tool", name: "xxx" } 可以强制模型用特定工具； stop hooks 返回阻塞错误时系统注入错误消息让模型重新考虑； token budget continuation 注入 nudge 让模型继续工作。

模型选择工具，但框架划定了选择的边界。

Q45 ：”向量数据库比 Markdown 高级？”

“OpenClaw 用向量数据库做记忆，比 Claude Code 的 markdown 文件高级。”

不合理。 “高级”取决于场景。

向量数据库的优势是大规模模糊语义搜索——适合存数万条记忆。但 Claude Code 的 Sonnet 召回比向量检索更精准（能做否定推理），文件人可读可编辑可 git 跟踪，零基础设施依赖。

Claude Code 的 200 文件上限对编程助手完全够用。它只存不可推导的高价值知识，代码库知识交给 Read/Grep 实时获取。向量数据库在这个量级下的规模优势没有意义，反而增加了 embedding 模型和数据库基础设施的复杂度。

工具没有高低，只有适不适合。

Q46 ：从输入到编辑文件的完整链路

用户输入 “fix the bug in auth.ts” 后，经过的关键模块：

1.输入处理 → REPL 输入框接收文本

2.Attachment 收集 → CLAUDE.md 、 git diff 、 IDE 状态以 <system-reminder> 注入

3.消息组装 → getSystemPrompt() 构建 system prompt → appendSystemContext() 追加 git 状态 → prependUserContext() 前置 CLAUDE.md → 组成 messages 数组

4.上下文预处理 → tool result budget → snip → collapse → autocompact （如需要）

5.API 调用 → 流式请求发出（唯一的网络请求）

6.流式响应 → 提取 text block 和 tool_use block

7.工具执行 → 假设模型先调 Read(auth.ts)，StreamingToolExecutor 边流边执行

8.下一轮循环 → messages + tool_results → 回到步骤 4

9.编辑文件 → 模型调用 Edit(auth.ts, old_string, new_string) → 验证（是否已 Read 过） → 权限检查 → 执行替换

从输入到编辑至少经过 2 轮 API 调用：第一轮读文件，第二轮改文件。

Q47 ：数据流中哪些是网络请求？

System Prompt 组装 .......... [本地]Messages 数组组装 ............ [本地]normalizeMessagesForAPI ..... [本地]buildSystemPromptBlocks ..... [本地]anthropic.messages.create() . [★ 网络请求]流式响应接收 ................. [★ 网络 SSE]提取 tool_use blocks ........ [本地]工具执行（Read/Edit/Bash）... [本地文件系统]构建 tool_result ............ [本地]下一轮 API 调用 ............. [★ 网络请求]

涉及网络的只有 API 调用。 Side query （ memory recall 、 extract agent ）也是 API 调用。所有工具执行都是本地操作。

Q48 ：两个框架的启动流程对比

Claude Code（相对轻量， 1-2 秒）：设置引导 → 加载 settings → 初始化 feature flags → 连接 MCP servers → 构建 system prompt → 加载 tools + skills → 等待输入。

OpenClaw（明显更重）： Gateway 守护进程启动 → 加载 20+ Channel 适配器 → 建立各平台连接 → 初始化 Agent Runtime → 加载 Provider 配置 → 初始化 LanceDB 向量数据库 → 启动 Cron 调度器 → 加载 143 个插件 → 等待消息。

Claude Code 是 CLI 随开随关， OpenClaw 是常驻服务需要初始化整个基础设施。

Q49 ：同一个任务的不同实现路径

任务：”读取 GitHub PR diff → 分析 bug → 写评论”。

Claude Code：Bash("gh pr view 123 --json diff") 获取 diff → 模型直接在上下文中分析 → 可能派 Explore 子 agent → Bash("gh pr review 123 --comment --body '...'") 写评论。全程终端内，单会话。

OpenClaw：通过 Channel Gateway 接收消息（可能来自 Slack ） → exec("gh pr view ...") 获取 diff → 可能 spawn 子 session 并行分析 → exec("gh api ...") 写评论 → 结果通过原通道回复 → 还能设 Cron 定时检查新 PR 。

Claude Code 的 Edit/Grep 精调工具让 diff 分析更精准； OpenClaw 的多通道让触发方式更灵活。

Q50 ：为什么不能直接调 API ？

直接调 API 就像给你一部电话，但没有通讯录、没有自动拨号、没有留言、没有转接。

AI Agent 框架解决的核心问题是：让 LLM 能持续、自主地完成多步骤任务。

直接调 API 只能一问一答。但真实的编程任务是：读文件 → 理解代码 → 决定改哪里 → 修改 → 测试 → 发现新问题 → 再修改。这个循环需要：

•工具执行 — 让模型不只是说”你应该改这里”，而是真的去改

•上下文管理 — 对话越来越长时自动压缩，不让窗口爆掉

•错误恢复 — API 超限、工具失败时自动恢复

•权限控制 — 危险操作要问人

•记忆系统 — 跨会话记住用户偏好和项目背景

框架的价值就是把这些”围绕 API 的工程问题”全部解决，让你只需要说 “fix the bug”，而不是手动编排 20 次 API 调用。

评分参考

正确数	水平
40-50	可以给别人做源码培训了
30-39	核心理解扎实，细节再过一遍
20-29	大框架清楚，建议重读笔记
< 20	建议带着问题重新过一遍源码

这个系列到这里就结束了。 50 道题覆盖了 Claude Code 和 OpenClaw 从核心概念到架构设计的方方面面。如果你全部答对了——恭喜，你对这两个框架的理解已经到了可以做技术分享的水平。如果有些题答不上来，正好说明还有值得重新深入的领域。