夜雨聆风
源码级拆解:OpenClaw vs Claude Code,两种 AI Agent 设计哲学
上一篇文章我们讲了故事，这一篇我们拆引擎。我把 OpenClaw 和 Claude Code 的源码都 clone 下来，逐行阅读了核心模块。一个是 45 万行 TypeScript 的”瑞士军刀”，一个是 183 个文件、几乎全是 Markdown 的”提示词操作系统”。两个项目对”AI Agent 应该怎么造”这个问题，给出了截然相反的答案。如果你正在做 AI Agent，这篇文章可能会改变你的架构决策。
一、先看数字：两个项目到底有多不一样
在深入源码之前，先感受一下量级差异：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这不是”谁多谁少”的问题——这是两种完全不同的设计哲学在源码层面的体现。
二、架构总览：提示词操作系统 vs 全栈运行时
Claude Code：一切皆 Markdown
打开 Claude Code 的仓库，你会发现一个令人震惊的事实：几乎没有可执行代码。
Claude Code 的核心运行时是闭源的。开源仓库里放的是插件生态的定义层——用 Markdown 描述 Agent 该做什么，用 JSON 描述权限边界，用 YAML frontmatter 声明工具白名单。
这意味着什么？Claude Code 把 Markdown 当成了编程语言。
OpenClaw：一个完整的分布式系统
OpenClaw 的源码则是另一个极端：
OpenClaw 不是一个 CLI 工具——它是一个带网关的分布式 Agent 运行时。
三、Agent 定义：Markdown 声明式 vs TypeScript 命令式
这是两个项目最核心的分歧。
Claude Code：一个 Agent = 一个 Markdown 文件
来看 Claude Code 的code-reviewerAgent 定义（完整源码）：
就这么多。一个 YAML 头部声明名字、描述、可用工具和模型，剩下的全是自然语言指令。
再看code-review命令的定义——它是一个 200 多行的 Markdown 文件，用自然语言描述了一个复杂的多 Agent 协作流程：
这段 Markdown 描述了一个7 步流水线，涉及 10+ 个并行子 Agent，但没有一行代码。Claude Code 的运行时会解析这段自然语言，自动编排 Agent 的调度。
设计哲学：信任模型的理解能力，用自然语言替代代码。
OpenClaw：Agent 是一个工程系统
OpenClaw 的 Agent 系统完全不同。看src/agents/agent-scope.ts（精简版）：
每个 Agent 有明确的配置结构：模型选择（含 fallback 链）、工作空间隔离、子 Agent 生成深度控制、沙箱策略、工具白名单/黑名单。
再看子 Agent 的能力控制（src/agents/subagent-capabilities.ts）：
OpenClaw 用代码精确控制了 Agent 的生成深度——main可以生成orchestrator，orchestrator可以生成leaf，但leaf不能再生成子 Agent。这防止了 Agent 无限递归。
设计哲学：不信任模型的自我约束能力，用代码构建确定性边界。
四、插件系统：声明式配置 vs 运行时注册
Claude Code：插件 = 文件夹约定
Claude Code 的插件结构是纯约定式的：
没有register()函数，没有生命周期钩子，没有 API 调用。运行时扫描文件夹结构，自动发现和加载。
Hook 的实现也很有意思。看security-guidance插件的 hook——它是一个 Markdown 文件，描述了 9 种安全模式（命令注入、XSS、eval 使用等），Claude Code 运行时在每次工具调用前读取这个 Markdown，让模型自己判断是否存在安全风险。
而如果你需要确定性的 hook 逻辑，可以用外部脚本。看官方示例bash_command_validator_example.py：
进程间通信，用 exit code 当 API。简单到令人发指，但确实有效。
OpenClaw：插件是一等公民的运行时模块
OpenClaw 的插件系统是一个完整的模块加载框架。看src/plugins/types.ts中的插件 API：
一个插件可以注册：工具、钩子、HTTP 路由、消息通道、网关方法、CLI 命令、后台服务、模型提供商、上下文引擎。这不是插件——这是微内核架构的扩展点。
OpenClaw 定义了24 种生命周期钩子：
插件加载器（src/plugins/loader.ts，600+ 行）实现了：
多来源发现（bundled / global / workspace / config）
优先级排序和去重
内存插槽互斥（同时只能有一个 memory 插件）
配置 schema 校验
安全边界检查（路径逃逸检测）
LRU 缓存（最多 32 个注册表实例）
通过 Jiti 实现 TypeScript 热加载
设计哲学：插件是系统的一部分，不是系统的附属品。
五、多模型支持：单一供应商 vs 模型路由器
Claude Code：只有 Claude
Claude Code 只支持 Anthropic 的 Claude 模型。这不是技术限制——这是产品决策。当你的 Agent 定义是自然语言时，模型的理解能力就是你的运行时。换一个模型，整个系统的行为可能完全不同。
在插件的 Agent 定义中，模型选择极其简洁：
三个选项，没有 fallback，没有路由逻辑。
OpenClaw：20+ 提供商的路由引擎
OpenClaw 的src/agents/models-config.providers.ts是一个 32,000 行的模型配置系统，支持：
Anthropic、OpenAI、Google Gemini
Ollama（本地模型）、vLLM、sglang
Amazon Bedrock、Azure
通义千问、Moonshot（Kimi）、MiniMax、字节跳动（豆包/BytePlus）、小米
OpenRouter、Together、Nvidia、Huggingface
GitHub Copilot、Vercel AI Gateway
…以及通过插件扩展的任意提供商
每个提供商有独立的能力声明（src/agents/provider-capabilities.ts）：
不同提供商的工具调用格式、思考链处理、tool call ID 规范都不一样，OpenClaw 在运行时自动适配。
Agent 还支持模型 fallback 链：
主模型不可用时自动降级——这在 Claude Code 的世界里是不存在的概念。
六、消息通道：终端 vs 全平台
Claude Code：终端 + IDE + GitHub
Claude Code 的交互面是：命令行终端、VS Code/JetBrains 插件、GitHub PR 评论。全部面向开发者。
OpenClaw：40+ 消息通道的网关架构
OpenClaw 的src/gateway/目录有 341 个文件，实现了一个完整的消息网关：
每个通道是一个独立的 extension 包，通过插件 API 的registerChannel()注册。消息路由系统（src/routing/resolve-route.ts）根据通道、账号、对话类型、群组角色等维度，将消息路由到正确的 Agent 会话。
这就是为什么 OpenClaw 的代码量是 Claude Code 的 16 倍——它不只是一个 Agent，它是一个Agent 运行平台。
七、安全模型：信任模型 vs 信任代码
Claude Code：分层权限 + 沙箱
Claude Code 的安全模型通过 JSON 配置实现，看官方的settings-strict.json：
三层权限（allow / ask / deny），Bash 沙箱隔离，网络域名白名单。企业管理员可以通过managed-settings.json强制覆盖用户配置。
OpenClaw：代码级的安全边界
OpenClaw 的安全是代码级的。工具策略系统（src/agents/tool-policy.ts）：
因为 OpenClaw 面向多用户（通过消息通道），它必须区分 owner 和普通用户。whatsapp_login、cron、gateway、nodes这些敏感工具，非 owner 用户连工具列表里都看不到——不是”禁止调用”，而是”不知道存在”。
插件加载器还有路径逃逸检测：
八、设计哲学总结：给 Agent 开发者的启示
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
如果你在做 AI Agent，该怎么选？
选 Claude Code 路线（声明式/Markdown 驱动），如果：
你的 Agent 面向单一场景（比如代码审查、文档生成）
你信任底层模型的能力，愿意用提示词工程替代代码
你希望非程序员也能定义 Agent 行为
你的用户群体是开发者，交互面是终端/IDE
你追求快速迭代，不想维护复杂的运行时
选 OpenClaw 路线（命令式/代码驱动），如果：
你的 Agent 需要支持多个 LLM 提供商
你需要精确控制 Agent 的行为边界（尤其是多用户场景）
你的 Agent 需要跨平台部署（消息通道、API、原生客户端）
你需要确定性的安全保证，不能依赖模型的”自觉”
你在构建一个 Agent 平台，而不是单个 Agent
最深层的分歧
Claude Code 和 OpenClaw 的分歧，本质上是对一个问题的不同回答：
“AI 模型的理解能力，能否替代代码的确定性？”
Claude Code 说：能。自然语言足够表达意图，模型足够理解意图，代码只是不必要的中间层。当模型能力提升时，整个系统自动变强。
OpenClaw 说：不能。模型会幻觉、会越权、会在边界条件下失控。代码是唯一可审计、可测试、可证明的控制手段。安全和可靠性不能建立在概率之上。
两个答案都对，取决于你在造什么。
如果你在造一把瑞士军刀给程序员用——Claude Code 的路线更优雅。
如果你在造一个 7×24 小时运行的 Agent 平台给所有人用——OpenClaw 的路线更稳健。
而最有趣的是，这两条路线正在相向而行。Claude Code 在加强代码级的安全控制（沙箱、managed settings），OpenClaw 在引入更多声明式配置（skills、YAML 配置）。也许最终的答案，是两者的融合。
本文基于 2026 年 3 月 15 日的源码分析。Claude Code 仓库：github.com/anthropics/claude-code，OpenClaw 仓库：github.com/openclaw/openclaw。