1. OpenClaw 是什么一个被误读的 AI 代理框架OpenClaw 诞生于开源社区本质上是一个 AI Agent 框架。它的核心能力并不复杂通过大语言模型驱动的代理机制让 AI 能够自主调用工具、管理任务、维持上下文记忆并在多轮交互中持续执行复杂工作流。从技术栈来看OpenClaw 的架构可以拆解为三层这套架构并非 OpenClaw 独创。类似的设计在 LangChain、AutoGen、CrewAI 等框架中都能看到。OpenClaw 的差异化在于两点一是它对自主调用的激进策略——允许 Agent 在较少人工干预的情况下连续执行多步操作二是它的 Skill 生态——社区贡献了大量可复用的技能模块降低了上手门槛。但正是这种激进的自主性让它在走红的同时也引发了数据隐私和安全方面的争议。短短几天内从上千元上门安装到付费卸载的戏剧性转折折射出公众对 AI 代理框架认知的巨大落差。2. OpenClaw 具身化一面镜子而非一把万能钥匙当 OpenClaw 被部署到机器人系统上时它的真实表现远比外界想象的克制。NEC 新能源开发者社区的朱佩韦是较早将 OpenClaw 接入机器人系统的实践者之一。他的描述非常直白两行代码就安装了。整个过程不需要重写控制程序只是在机器人原有系统和自然语言之间加了一个中间层。# 安装 Claude CodeOpenClaw 的底层工具npminstall-ganthropic-ai/claude-code# 将机器人控制 SDK 注册为 MCP Serverclaude mcpaddrobot-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 安装社区 Skillclawhubinstallrobot-grasp clawhubinstallrobot-handshake# 查看已安装的 Skills/skills list# 直接用自然语言触发Claude Code 自动匹配对应 Skillclaude和我握手# → Claude Code 识别意图调用 robot-handshake Skill# → Skill 内部封装了舵机角度序列直接下发执行深层实现则以 RosClaw 为代表需要修改 OpenClaw 源码将机器人操作系统 ROSRobot Operating System的功能植入其中从而调用更丰富的底层能力。这条路径的复杂度显著更高# 深层集成RosClaw 模式# 将 ROS 节点封装为 MCP Server暴露给 Claude Code 调用importrospyimportjsonfromtrajectory_msgs.msgimportJointTrajectory,JointTrajectoryPointclassRosClawMCPServer:将 ROS 能力封装为 MCP Tool供 Claude Code 调用def__init__(self):rospy.init_node(rosclaw_mcp_server)self.arm_pubrospy.Publisher(/arm_controller/joint_trajectory,JointTrajectory,queue_size10)defhandle_tool_call(self,tool_name,params):响应 Claude Code 的 MCP 工具调用iftool_namemove_arm:trajJointTrajectory()pointJointTrajectoryPoint()point.positionsparams[joint_positions]point.time_from_startrospy.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 — 验证钩子脚本importrospyimportsysimportjsonfromsensor_msgs.msgimportJointStatedefverify():读取关节传感器对比期望状态msgrospy.wait_for_message(/joint_states,JointState,timeout5.0)currentlist(msg.position)expectedjson.loads(sys.argv[2])iflen(sys.argv)2elseNoneifexpectedandall(abs(c-e)0.05forc,einzip(current,expected)):print(PASS: 机械臂到达目标位置)sys.exit(0)else:print(FAIL: 位置偏差超出阈值触发重试)sys.exit(1)# 非零退出码会让 Claude Code 感知到失败if__name____main__:verify()4. 被误读的空间记忆SpatialRAG 才是核心近期广泛流传的宇树机器人空间记忆演示常被归功于 OpenClaw。但廖登廷指出实现该能力的核心更可能来自 SpatialRAG 技术——这种技术将环境视频或点云数据构建为可调用的空间数据库使机器人具备环境记忆能力。对应代码已经在Github开源了。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: 当需要处理内部计费逻辑、创建发票、或调试账单问题时使用此 Skill5.1 九大分类覆盖软件开发的完整生命周期Thariq 团队将内部所有 Skills 梳理归类发现基本上能分成九类。最有意思的地方是不少工程师写了一堆 Skills但只覆盖了其中两三类——有些场景根本没想到可以用 Skill 来解决。第一类是知识与参考类Knowledge Reference。这类 Skill告诉 Claude 如何正确使用内部库、CLI 或 SDK通常包含一个参考代码片段目录以及一份 Claude 写这类代码时要主动避开的坑列表。Anthropic 内部的典型案例包括billing-lib 记录了内部计费库的各种边界情况和 footguninternal-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 functionsClaude 动态生成脚本来调用这些函数完成复杂分析任务比如上周二发生了什么。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 CLInpminstall-gclawhub-cli clawhubinstallcapability-evolver# 方式二手动安装直接克隆到 Skills 目录gitclone https://github.com/clawhub/capability-evolver.git\.claude/skills/capability-evolver# 确认技能已激活claude/skills list# 输出中应包含 capability-evolver# 手动触发第一次进化需要先积累一些对话历史/evolve# 查看被自动更新的规则文件catCLAUDE.md触发后的输出类似这样分析中... 发现 3 条可优化的行为模式 1. 用户多次要求缩短回答长度 → 添加规则默认回复不超过 200 字 2. 用户偏好代码示例直接给出不要先问需求 → 添加规则技术问题直接给示例 3. 用户不接受 emoji → 添加规则禁止使用 emoji 正在更新 CLAUDE.md...完成。…详情请参照古月居