行业杂谈 | 从 OpenClaw 到 Claude Code:AI 代理框架的技术解构与产业真相

行业杂谈 | 从 OpenClaw 到 Claude Code：AI 代理框架的技术解构与产业真相

1. OpenClaw 是什么：一个被误读的 AI 代理框架

OpenClaw 诞生于开源社区，本质上是一个 AI Agent 框架。它的核心能力并不复杂：通过大语言模型驱动的代理机制，让 AI 能够自主调用工具、管理任务、维持上下文记忆，并在多轮交互中持续执行复杂工作流。

从技术栈来看，OpenClaw 的架构可以拆解为三层：

这套架构并非 OpenClaw 独创。类似的设计在 LangChain、AutoGen、CrewAI 等框架中都能看到。OpenClaw 的差异化在于两点：一是它对"自主调用"的激进策略——允许 Agent 在较少人工干预的情况下连续执行多步操作；二是它的 Skill 生态——社区贡献了大量可复用的技能模块，降低了上手门槛。

但正是这种"激进的自主性"，让它在走红的同时也引发了数据隐私和安全方面的争议。短短几天内，从"上千元上门安装"到"付费卸载"的戏剧性转折，折射出公众对 AI 代理框架认知的巨大落差。

2. OpenClaw 具身化：一面镜子，而非一把万能钥匙

当 OpenClaw 被部署到机器人系统上时，它的真实表现远比外界想象的克制。

NEC 新能源开发者社区的朱佩韦是较早将 OpenClaw 接入机器人系统的实践者之一。他的描述非常直白："两行代码就安装了。"整个过程不需要重写控制程序，只是在机器人原有系统和自然语言之间加了一个中间层。

# 安装 Claude Code（OpenClaw 的底层工具）
npm install -g @anthropic-ai/claude-code

# 将机器人控制 SDK 注册为 MCP Server
claude mcp add robot-controller -- python3 robot_mcp_server.py

# 通过自然语言下发指令，Claude Code 自动调用 MCP 工具
claude "请将机械臂移动到工位A，抓取红色零件"

但朱佩韦很快发现，OpenClaw 真正的生产力价值不在"让机器人听话"，而在"让研发流程更高效"。他将 OpenClaw 嵌入整个研发流程，让它充当一个始终在线的项目管理者——记录开发进展、跟踪任务节点、同步团队状态。机器人只是被纳入管理体系的一环，而不是被赋予了新的行动能力。

这个定位非常关键。它解释了为什么 OpenClaw 看起来"很强"，却不构成技术突破。机器人执行什么动作，依然由原有控制系统决定；OpenClaw 做的是把复杂的项目推进过程变得透明、可控、可追溯。用朱佩韦的话说："它更像一个数字化 PM，而不是具身智能的大脑。"

在算法开发层面，朱佩韦坦言 Claude Code 或其他 Vibe Coding 类工具更直接好用；从机器人能力提升角度看，强化学习（RL）和视觉-语言-动作模型（VLA）才是更靠谱的路径。OpenClaw 的部署，与"机器人会不会自己工作"并没有太大关系。

3. 深浅之分：OpenClaw 在机器人上的两条路径

OpenClaw 在机器人上的应用存在明显的深浅之分。浅层实现是直接调用现成的 Skill 库，通过 SDK 快速部署，实现握手、抓取物体等基础动作。这条路径门槛低、上手快，是目前最普遍的应用方式。其核心代码逻辑大致如下：

# 浅层集成：通过 ClawHub 安装社区 Skill
clawhub install robot-grasp
clawhub install robot-handshake

# 查看已安装的 Skills
/skills list

# 直接用自然语言触发，Claude Code 自动匹配对应 Skill
claude "和我握手"
# → Claude Code 识别意图，调用 robot-handshake Skill
# → Skill 内部封装了舵机角度序列，直接下发执行

深层实现则以 RosClaw 为代表，需要修改 OpenClaw 源码，将机器人操作系统 ROS（Robot Operating System）的功能植入其中，从而调用更丰富的底层能力。这条路径的复杂度显著更高：

# 深层集成：RosClaw 模式
# 将 ROS 节点封装为 MCP Server，暴露给 Claude Code 调用

import rospy
import json
from trajectory_msgs.msg import JointTrajectory, JointTrajectoryPoint

class RosClawMCPServer:
    """将 ROS 能力封装为 MCP Tool，供 Claude Code 调用"""

    def __init__(self):
        rospy.init_node('rosclaw_mcp_server')
        self.arm_pub = rospy.Publisher(
            '/arm_controller/joint_trajectory',
            JointTrajectory, queue_size=10
        )

    def handle_tool_call(self, tool_name, params):
        """响应 Claude Code 的 MCP 工具调用"""
        if tool_name == "move_arm":
            traj = JointTrajectory()
            point = JointTrajectoryPoint()
            point.positions = params["joint_positions"]
            point.time_from_start = rospy.Duration(params.get("duration", 2.0))
            traj.points.append(point)
            self.arm_pub.publish(traj)
            return {"status": "published", "topic": "/arm_controller/joint_trajectory"}

# 启动后，在 Claude Code 中注册：
# claude mcp add rosclaw -- python3 rosclaw_mcp_server.py

从实际效果来看，OpenClaw 展现出较强的可扩展性，能够在未经明确指令的情况下自动拼接命令，完成复合任务。但缺点同样明显：响应慢（每次调用都需要将上下文送入大模型），可靠性存疑（指令序列较长时，中间环节出现遗漏或执行失败，系统并不会主动感知异常）。

廖登廷提出了一个可行的改进思路：在任务完成后插入检验钩子（Hook），验证执行结果，失败则触发重试。这相当于将原本的开环系统改造为闭环：

// .claude/settings.json — 通过 Hooks 实现闭环验证
// PostToolUse Hook：每次工具调用后自动验证执行结果
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "mcp__rosclaw__move_arm",
        "command": "python3 verify_arm_position.py --expected=$EXPECTED_STATE"
      }
    ]
  }
}

# verify_arm_position.py — 验证钩子脚本
import rospy
import sys
import json
from sensor_msgs.msg import JointState

def verify():
    """读取关节传感器，对比期望状态"""
    msg = rospy.wait_for_message('/joint_states', JointState, timeout=5.0)
    current = list(msg.position)
    expected = json.loads(sys.argv[2]) if len(sys.argv) > 2 else None

    if expected and all(abs(c - e) < 0.05 for c, e in zip(current, expected)):
        print("PASS: 机械臂到达目标位置")
        sys.exit(0)
    else:
        print("FAIL: 位置偏差超出阈值，触发重试")
        sys.exit(1)  # 非零退出码会让 Claude Code 感知到失败

if __name__ == "__main__":
    verify()

4. 被误读的"空间记忆"：SpatialRAG 才是核心

近期广泛流传的宇树机器人"空间记忆"演示，常被归功于 OpenClaw。但廖登廷指出，实现该能力的核心更可能来自 SpatialRAG 技术——这种技术将环境视频或点云数据构建为可调用的空间数据库，使机器人具备环境记忆能力。

Github主页：https://github.com/dimensionalOS/dimos

OpenClaw 在其中的角色，只是调用了这项能力，换用其他 Agent 框架同样可以实现。更值得关注的是，OpenClaw 的长短期记忆均以明文形式存储，而非经过编码的结构化信息，难以高效处理机器人系统中涉及多传感器维度的复杂数据。真正意义上的空间记忆能力，仍有赖于大脑与记忆系统层面的优化，与 Agent 框架的关系并不大。

5. Claude Code Skills：从"会用"到"会组织"的跨越

如果说 OpenClaw 展示了 AI Agent 的可能性，那么 Claude Code 的 Skills 系统则展示了如何将这种可能性工程化。Anthropic 工程师 Thariq 披露，公司内部已经在使用数百个 Claude Code Skills。他指出了一个被大多数人忽略的关键认知：Skills 不是 Markdown 文件，是文件夹。文件夹里可以放脚本、资产文件、引用文档、配置，整个文件系统都是上下文工程的一部分。把 Skills 当文件夹来设计，而不是当 Markdown 来写——这个思路一变，能做到的事完全不同。

# 一个典型的 Skill 目录结构（真实路径）
.claude/skills/billing-lib/
├── SKILL.md              # 技能描述和触发条件
├── assets/
│   └── report-template.md  # 输出模板（Claude 直接复制填充，而非凭空生成）
├── references/
│   └── api.md              # API 参考文档（按需读取，不占启动上下文）
├── scripts/
│   └── validate.sh         # 验证脚本（确定性校验，不依赖模型判断）
└── gotchas.md              # 踩坑记录（含金量最高的部分）

其中 SKILL.md 的真实格式如下：

---
description: 当需要处理内部计费逻辑、创建发票、或调试账单问题时使用此 Skill
---

5.1 九大分类：覆盖软件开发的完整生命周期

Thariq 团队将内部所有 Skills 梳理归类，发现基本上能分成九类。最有意思的地方是，不少工程师写了一堆 Skills，但只覆盖了其中两三类——有些场景根本没想到可以用 Skill 来解决。

第一类是知识与参考类（Knowledge & Reference）。这类 Skill 告诉 Claude 如何正确使用内部库、CLI 或 SDK，通常包含一个参考代码片段目录，以及一份 Claude 写这类代码时要主动避开的坑列表。Anthropic 内部的典型案例包括：billing-lib 记录了内部计费库的各种边界情况和 footgun；internal-platform-cli 列出了内部 CLI 的每个子命令，附带"什么时候用哪个"的示例；frontend-design 则让 Claude 更好地理解团队的设计系统。

第二类是验证类（Verification）。这类 Skill 描述如何测试或验证代码是否正确，通常搭配 Playwright、tmux 等外部工具做实际验证。Thariq 专门强调：让工程师花一周时间把验证 Skills 做好，是值得的投资。可以考虑让 Claude 录制操作视频，或者在每一步用断言验证程序状态。内部案例包括：signup-flow-driver 自动跑注册到邮箱验证到 onboarding 全流程，每步断言状态；checkout-verifier 用 Stripe 测试卡驱动结账 UI，验证发票状态；tmux-cli-driver 专门用于需要 TTY 的交互式 CLI 测试。

第三类是数据访问类（Data Access）。这类 Skill 连接数据和监控系统，通常包含带凭证的数据获取库、仪表盘 ID，以及常见查询工作流说明。比如 funnel-query 告诉 Claude "我该 join 哪些事件才能看到注册到激活到付费的路径"，附带真实的 user_id 表；grafana 则包含数据源 UID、集群名称、以及"症状到对应仪表盘"的查找表。

第四类是自动化工作流类（Automation）。把重复操作压缩成一条命令，指令通常比较简单，但可能依赖其他 Skills 或 MCP。Thariq 提示：把每次执行的结果存进日志文件，能帮模型在多次执行之间保持一致性，也方便它反思"上次干了什么"。典型案例如 standup-post，汇总工单系统、GitHub 活动、前一天 Slack 内容，生成格式化日报，只写增量变化；weekly-recap 则将已合并 PR、已关闭工单和部署记录整合为格式化周报。

第五类是脚手架类（Scaffolding）。为代码库的特定模块生成框架样板，特别适合当你的脚手架里有自然语言要求、无法完全用代码表达的时候。案例包括 new-workflow 提供带注解的新服务脚手架，new-migration 提供数据库迁移文件模板并附带常见踩坑提示，create-app 则预置好认证、日志、部署配置的内部应用模板。

第六类是代码审查类（Code Review）。执行代码质量检查，可以包含确定性脚本或工具以保证可靠性，也可以放到 Git Hook 或 GitHub Action 里自动触发。其中最有意思的是 adversarial-review——起一个独立子 agent 专门批评代码，实施修复，反复迭代直到问题只剩小细节。code-style 则强制执行代码风格，尤其是 Claude 默认不会做好的那些。

第七类是部署类（Deploy）。拉取、推送、部署代码，这类 Skill 可能会引用其他 Skills 来收集数据。babysit-pr 能监控 PR、重试 flaky CI、解决合并冲突、开启自动合并；deploy 则实现构建到冒烟测试到灰度流量切换的完整流程，持续对比错误率，回归时自动回滚。

第八类是调试类（Debugging）。接收症状（比如 Slack 消息、告警、错误签名），走一遍多工具调查流程，输出结构化排查报告。oncall-runner 能拉取告警、排查常见嫌疑、整理发现；log-correlator 给一个 request ID，就能从所有可能经手的系统里拉取对应日志。

第九类是运维类（Operations）。执行例行维护和操作流程，尤其是涉及破坏性操作的场景——加上防护步骤，让工程师在关键操作上更容易遵守最佳实践。orphans 能找出孤立的 pod 和 volume，发到 Slack，经过冷却期和用户确认后才执行级联清理；cost-investigation 则专门回答"为什么存储或流量费用突然暴涨"，附带具体的 bucket 和查询模式。

在这九类中，验证类和运维类是最容易被忽略但价值最高的两类。大多数开发者只写了知识类和脚手架类的 Skills，而验证类 Skills 能让 Claude 自己校验输出质量，运维类 Skills 则能在破坏性操作上加入防护步骤。对照这九类检查一下自己有没有盲点，往往能发现被忽略的高价值场景。

5.1 Skill 编写的核心原则

Gotchas（踩坑记录）是整个 Skill 里信号最强的内容。Claude 对代码库和通用编程已经知道很多了，如果你的 Skill 主要是重复它已经知道的东西，价值有限。真正有用的是把 Claude 的默认行为推到你需要的方向——不管是设计品味、组织规范，还是特定的边界情况。Thariq 举了一个 Anthropic 内部的"设计品味 Skill"的例子：一个工程师通过反复和客户迭代，让 Claude 避免常见的设计陋习（比如 Inter 字体加紫色渐变），形成了一套独到的设计偏好库。Gotchas 应该从 Claude 在使用这个 Skill 时真正踩过的坑里积累，每次遇到新的失败模式就更新进去。

# gotchas.md 示例：内部计费库的踩坑记录

## 已知陷阱

### 1. 时区处理
billing-lib 内部所有时间戳使用 UTC，但 API 返回给客户端时
会自动转换为用户时区。如果你在服务端做时间比较，必须统一
为 UTC，否则月末账单会出现重复计费。

### 2. 幂等性
create_invoice() 不是幂等的。重复调用会创建多张发票。
必须先调用 get_or_create_invoice() 检查是否已存在。

### 3. 测试环境差异
staging 环境的税率计算使用硬编码值（0.1），与生产环境
的动态税率服务不同。不要用 staging 的测试结果验证税率逻辑。

指令别写死，给 Claude 留空间。这个点有点反直觉。写 Skill 的本能是"写得越详细越好"，但 Thariq 说恰恰相反——Skills 复用率很高，太具体的指令反而会让它在边缘情况下变死板。给 Claude 它需要的信息，但留足灵活度去适应具体情境。比较典型的场景是需要用户输入的 Skill：一个发日报到 Slack 的 Skill，你可能需要先问用户发到哪个频道。做法是把这些配置存到 config.json 文件里——如果配置不存在，Claude 就问用户；如果已有配置，直接用。

description 字段决定了 Skill 能不能被触发。Claude Code 启动时会把所有可用 Skill 的 description 读进来形成索引，每次用户发请求时扫描这个索引来判断"有没有适合这个任务的 Skill"。所以 description 不是说明，是触发条件。它应该描述"什么情况下应该用这个 Skill"，而不是"这个 Skill 能做什么"：

# SKILL.md 的 YAML front matter 中定义 description

# 错误写法：描述能力（太笼统，Claude Code 难以精准匹配）
---
description: "这个 Skill 可以帮助你管理数据库迁移"
---

# 正确写法：描述触发场景（列出具体动作，提高匹配命中率）
---
description: "当需要创建数据库迁移文件、修改表结构、添加索引、回滚迁移、或处理数据迁移时使用此 Skill"
---

5.4 给 Claude 代码，让它只操心"做什么"

这是 Thariq 认为最强的 Skill 设计模式之一：把脚本和工具库放进 Skill 里，让 Claude 专注于组合和决策，而不是重建样板代码。举个例子：数据分析 Skill 里放一组从事件源取数据的 helper functions，Claude 动态生成脚本来调用这些函数，完成复杂分析任务，比如"上周二发生了什么"。Claude 的每一步都在思考"接下来做什么"，而不是在写取数函数。工作效率的提升非常直接。

5.5 Skill 可以有自己的"记忆"

Skills 可以把数据存在自己目录里——简单的可以是一个 append-only 文本日志，复杂的可以是 SQLite 数据库。这让 Skill 有了跨会话的记忆。比如 standup-post Skill 可以维护一个 standups.log，记录每次生成的日报内容。下次运行时，Claude 读取这份历史，就能判断"自上次以来发生了什么变化"，而不是每次从零开始。需要注意的一点：存在 Skill 目录下的数据，升级 Skill 时可能被删掉。Thariq 建议把这类数据存到 ${CLAUDE_PLUGIN_DATA} 提供的稳定目录下。

5.6 Hooks 只在被调用时激活

Skills 可以内嵌 Hooks，但这些 Hooks 只在 Skill 被调用时生效，会话结束就消失。这个设计很适合"场景化防护"：/careful 禁止 rm -rf、DROP TABLE、强制推送、kubectl delete，触碰生产环境时用；/freeze 限制只能在特定目录下修改文件，调试时防止 Claude 误改不相关代码。如果这类 Hook 全局常驻，会烦死人。作为 Skill 按需激活，刚好。

5.7 在团队里分发 Skills

两种方式：把Skills 提交到 repo 的 .claude/skills 目录，或者建内部插件市场。前者适合小团队，简单直接。但每个 Skill 都会给模型上下文加一点负担，规模大了就需要插件市场——让团队自己选安装哪些。Anthropic 内部的做法是没有中心化审核团队，而是靠自然传播。有好 Skill 就发到 GitHub 沙盒目录，在 Slack 里分享，自然获得使用和反馈。等它有了足够的关注度，技能作者自己提 PR 把它并入市场。Thariq 还提到他们用 PreToolUse hook 记录公司内部每个 Skill 的调用日志，这样就能找出最受欢迎的 Skill，或者发现某个 Skill 触发频率远低于预期——这通常说明 description 没写好。

6. capability-evolver：让 AI 从对话中自我进化

在 OpenClaw 的 Skill 生态中，下载量排名第一的技能叫 capability-evolver，安装量超过 35000 次。它的定位是"元技能"——不帮你做某件具体的事，而是帮 AI 提升做所有事的能力。

其工作原理并不复杂。OpenClaw 有一个配置文件（CLAUDE.md），里面写着 AI 的行为规则。capability-evolver 的做法是定期让 AI 回顾最近的对话，找出规律，自动更新这份规则文件：

capability-evolver 工作流程：

对话历史积累（N 轮）
       │
       ▼
  触发自我分析（/evolve 或自动触发）
       │
       ▼
  模式识别：
  ├── 用户反复纠正的行为 → 提取为负面规则
  ├── 用户明确表达的偏好 → 提取为正面规则
  └── 高频出现的上下文 → 提取为默认假设
       │
       ▼
  自动更新 CLAUDE.md
       │
       ▼
  下次对话生效

安装和使用流程如下：

# 方式一：从 ClawHub 社区安装（需要 clawhub CLI）
npm install -g clawhub-cli
clawhub install capability-evolver

# 方式二：手动安装（直接克隆到 Skills 目录）
git clone <https://github.com/clawhub/capability-evolver.git> \
  .claude/skills/capability-evolver

# 确认技能已激活
claude
> /skills list
# 输出中应包含 capability-evolver

# 手动触发第一次进化（需要先积累一些对话历史）
> /evolve

# 查看被自动更新的规则文件
cat CLAUDE.md

触发后的输出类似这样：

分析中...

发现 3 条可优化的行为模式：
1. 用户多次要求缩短回答长度 → 添加规则：默认回复不超过 200 字
2. 用户偏好代码示例直接给出，不要先问需求 → 添加规则：技术问题直接给示例
3. 用户不接受 emoji → 添加规则：禁止使用 emoji

正在更新 CLAUDE.md...完成。

这套机制的本质是：不是模型变聪明了，是规则文件越来越懂你了。模型本身没有变化，变化的是每次对话开始时注入的行为约束。这是一种务实的"个性化"方案——不需要微调模型，只需要持续优化提示词。

7. Claude Code 工作流的分层架构

如果把 Claude Code 的能力体系拆开来看，它实际上是一个五层架构：

每一层的职责边界非常清晰：

• Command 适合做入口和触发词。你希望一句话拉起一套动作，就放这里。
• Skill 适合放可复用的方法和判断标准。凡是以后还会反复用到的经验，都应该沉淀成 Skill。
• Agent/Subagent 适合处理需要独立上下文的重任务。不要把所有复杂活都塞在主会话里。
• Settings 适合放稳定规则和全局偏好。不必每次重讲。
• Memory 适合放持续性背景和长期记忆。解决"这件事以后也得记得"的问题。
• MCP 适合接入外部工具和数据源。重点不是"连上了没有"，而是有没有进入日常流程。

这套分工一旦清楚，Claude Code 才会从"能聊"变成"能跑流程"。

8. Ruflo：从单兵作战到蜂群协作

当单个 Agent 的能力遇到瓶颈时，多智能体协作成为自然的演进方向。Ruflo（前名 Claude Flow）是专为 Claude Code 打造的多智能体编排框架，采用蜂群式（Hive Mind）架构协调多个智能体完成软件开发任务。

其核心架构采用 Queen-Worker 层级调度：

Ruflo 通过 MCP 协议无缝接入 Claude Code，安装和使用流程如下：

# 前置条件：Node.js 20+，已安装 Claude Code
node --version  # 确认 >= 20.x
claude --version  # 确认已安装

# 初始化 Ruflo 项目
npx ruflo@latest init

# 将 Ruflo 注册为 Claude Code 的 MCP 服务器
claude mcp add ruflo -- npx -y ruflo@latest mcp start

# 验证 MCP 注册成功
claude mcp list
# 输出应包含：ruflo (npx -y ruflo@latest mcp start)

# 使用特定智能体执行任务
npx ruflo@latest --agent coder --task "Implement user authentication"

# 查看所有可用的 60+ 专业智能体
npx ruflo@latest --list

# 升级 Ruflo（保留已有数据和配置）
npx ruflo@v3alpha init upgrade --add-missing