OpenClaw与机器人相关项目全景综述

转载自公众号：

0. 引言

围绕 OpenClaw 的公开内容这几个月明显在加速扩张，但信息分散在 GitHub 仓库、项目页、硬件 Wiki、技能市场和部署文档里。如果只看单篇文章，很容易把某一个案例误认为“OpenClaw 在机器人领域的全部形态”；如果只看零散仓库，又会忽略它们之间的层级关系。更准确的理解方式，是把这些项目放回同一条技术链上：上层是自然语言与多通道入口，中层是技能、状态、协议与安全控制，下层才是 ROS2、仿真、机械臂接口、电机控制器和嵌入式运行时。只有把这条链路看完整，读者才能真正明白 OpenClaw 在机器人方向上的角色，不是某一台机器人本体，而是一套不断向具身系统延伸的任务操作层。

1. OpenClaw 机器人相关项目的主要类别

从公开资料梳理下来，OpenClaw 与机器人相关的项目并不是单一赛道，而是至少可以分成六类。

第一类是 OpenClaw 本体与安全运行栈，也就是 OpenClaw 本身和 NemoClaw 这类“让网关更容易长期运行、更容易受控”的基础设施。

第二类是 ROS2 接入层，典型代表是 RosClaw 与 AgenticROS，它们负责把自然语言意图映射为 ROS2 的 topic、service 和 action。

第三类是机器人技能层，也就是 AgenticROS Skills、Follow Me、SO-Arm 控制技能这类可以按包加载的能力扩展。

第四类是空域或具身控制框架，例如 AerialClaw 和 RoClaw，它们在 OpenClaw 方法论基础上进一步向无人机与微型实体机器人延伸。

第五类是研究与评测框架，例如 CaP-X，这类项目不一定直接依赖 OpenClaw 运行，但在“代码策略、执行接口、具身推理”层面与生态形成强互补。

第六类则是硬件落地与边缘部署案例，例如 Seeed 的 SO-Arm on Jetson Thor、reComputer Jetson 本地 OpenClaw 控制中心，以及 Jetson AI Lab 的本地部署路线。

OpenClaw 机器人生态已经呈现出明确的分工结构。OpenClaw 自身负责入口、会话、工具编排和技能宿主；RosClaw 与 AgenticROS 负责 ROS2 接入；AerialClaw 和 RoClaw 分别向无人机与低延迟实体控制延伸；CaP-X 提供机械臂代码策略研究基线；Jetson、SO-Arm 等项目对应实际硬件落地。各项目并非简单并列，而是在不同层级上共同构成完整生态。

2. 代表性项目总表

表中的对象同时覆盖仓库级项目、技能级项目和硬件落地案例，反映出当前 OpenClaw 机器人生态的真实组织方式：核心能力并不只集中在少数主仓库中，许多可复用能力以 skill 包、部署教程或硬件接入方案的形式存在。表内既包含 OpenClaw 的直接扩展，也包含与其方法论和接口层紧密耦合的周边框架，如 AerialClaw 与 RoClaw。由此可见，该生态的边界已经延伸至网关、技能、硬件、仿真与安全部署等多个层面。

3. 基础平台层：OpenClaw 与 NemoClaw

作为生态底座，OpenClaw 当前已经不是一个简单的命令行代理，而是一个多通道 Gateway，可以把 WhatsApp、Telegram、Slack、Discord、WebChat、移动节点和本地工具统一接到同一个长期运行的 Agent 上。其在机器人系统中的价值不在于支持多种聊天软件，而在于将任务入口标准化。用户不需要了解底层到底是 ROS2、串口、浏览器自动化还是本地脚本，只需通过统一入口发出任务，后续分派由网关、技能和工具层完成。这种设计使 OpenClaw 天然适合作为机器人系统的上层任务接口，尤其适合需要长期在线、跨设备和多角色接入的场景。

NemoClaw 则代表生态向“可控运行环境”方向的推进。NVIDIA 在 2026 年 3 月 16 日开始以 alpha 形式公开 NemoClaw，明确将其定义为运行 OpenClaw 的参考安全栈，而不是新的机器人控制框架。官方文档和 README 强调，它通过 OpenShell 提供受限容器、网络策略、推理路由、蓝图生命周期和状态迁移，把 OpenClaw 放入更可审计的执行环境。机器人 Agent 一旦具备文件、网络和工具调用能力，安全边界问题就会成为部署前提。NemoClaw 的意义不在于提升机器人“智能”本身，而在于让 OpenClaw 这类长期在线代理在边缘设备、远程 GPU、私有机房和实验环境中更容易部署、设限与回滚。

OpenClaw 与 NemoClaw 在生态中的分工已经较为明确：前者负责人与模型、技能和工具之间的交互组织，后者负责受限环境中的运行控制与审计约束。对于涉及持续联网、摄像头访问、硬件控制和宿主机工具调用的机器人系统，这一分层是进入严肃部署场景的前提条件。没有安全运行栈时，OpenClaw 更接近高能力个人代理；引入 NemoClaw 后，其才具备进入更严格机器人运行环境的基础。

4. ROS2 接入层之一：RosClaw

RosClaw 是当前公开可见的早期 OpenClaw × ROS2 连接原型。它的 README 给出的链路非常清楚：用户通过 WhatsApp、Telegram、Discord 或 Slack 发消息，OpenClaw Gateway 里的 Agent 使用 RosClaw 插件注册的工具，经由 rosbridge_server 与 ROS2 图通信，最后落到 Nav2、MoveIt2、相机和传感器上。就工程成熟度来说，RosClaw 仍在重构中，README 甚至直接说明项目正在经历 major re-architecture 和拆仓。但这并不影响它的重要性。因为 RosClaw 首次把一个关键问题讲清楚了：OpenClaw 进入机器人世界，真正需要的不是“更聪明的提示词”，而是一层能把自然语言意图翻译成 ROS2 操作的桥接插件。

RosClaw 的另一个价值，是它明确了插件工具集的边界。当前公开列出的工具包括ros2_publish、ros2_subscribe_once、ros2_service_call、ros2_action_goal、ros2_param_get/set、ros2_list_topics和ros2_camera_snapshot。这组工具非常有代表性，因为它们几乎就是 ROS2 机器人的最低公共语义层。只要一个机器人系统能稳定暴露这些接口，上层 OpenClaw Agent 就可以在很大程度上脱离具体机器人品牌与节点实现去工作。也正因如此，RosClaw 虽然还是原型，但它已经把 OpenClaw 机器人路线中的核心难题抽象得很清楚：任务解释不是最难的，难的是如何构造一层稳定、可发现、可约束的 ROS2 工具界面。

RosClaw 在生态中的意义更多体现为问题定义阶段。后续出现的 AgenticROS，实质上是对 RosClaw 原型阶段暴露问题的结构化重组：将 transport core、平台适配器与 skill 扩展进一步拆分并稳定化。因此，RosClaw 更接近第一阶段的桥接原型，而 AgenticROS 则代表第二阶段的接口层产品化。

5. ROS2 接入层之二：AgenticROS

AgenticROS 是目前 OpenClaw 机器人生态里最像“正式接入层产品”的项目。它与 RosClaw 最大的差别，不是支持了更多工具，而是把架构彻底拆开了。其 packages/core 负责 transport、配置 schema 与共享类型，不依赖任何单一模型厂商；packages/agenticros 作为 OpenClaw 插件提供配置页面和 teleop 页面；packages/agenticros-claude-code 作为 MCP 服务器接入 Claude；packages/agenticros-gemini 则允许 Gemini CLI 直接复用同一套工具，不再依赖 MCP。这样设计之后，机器人能力第一次从“某个聊天入口的插件”变成了“可复用的机器人接口层”。

AgenticROS 的平台无关设计显著扩展了 OpenClaw 生态的接口外延。相同的 ROS2 工具可以同时服务于 OpenClaw、Claude Code 和 Gemini CLI，使研究者能够在固定机器人接口层的前提下，仅比较上层交互形态。这种条件减少了桥接代码、传输方式和机器人封装差异对实验结论的干扰，也使“只比较交互层，而不重写机器人底层”成为现实。

官方 README 还给出了两个关键工程约束。其一，项目建议与 OpenClaw 2026.3.11 或之后版本配合使用，说明它与上游网关的插件路由能力存在明确版本依赖。其二，文档反复强调 robot.namespace 与题目命名空间必须一致，否则系统可能出现已连接但机器人无响应的情况。这些约束反映出 AgenticROS 已将部分 ROS2 集成中的隐性经验前置到配置层。

6. 技能扩展层：AgenticROS Skills 与 Follow Me

AgenticROS Skills 仓库标志着这一生态开始进入技能包扩展阶段。它将技能定义为 AgenticROS 的可选插件包，这些包在 Gateway 启动时被加载，为机器人新增工具与行为，而不需要修改 core 层。该设计说明机器人能力正在从写死在插件内部转向按需装配。对于机型差异显著的机器人场景，只有技能层具备拆分能力，平台才可能同时适配移动底盘、深度相机、跟随模块和专用任务逻辑。

公开列出的第一个参考技能是 agenticros-skill-followme。它的 README 很具体：控制环以固定频率运行，从深度话题读取距离，必要时调用 Ollama/VLM 判断左右方向，再向 cmd_vel 发布速度命令，让机器人保持目标距离并在目标离开视野时原地旋转搜索。该技能的意义不在于单独实现“跟随”能力，而在于表明机器人行为已经可以按照标准化 skill package 形式封装。其独立入口、配置切片、工具注册方式以及对 config.skills.followme、context.getTransport() 和 context.getDepthDistance(...) 等宿主接口的依赖约定，说明生态接口已经具备承载第三方技能包的稳定性。

AgenticROS Skills 与 Follow Me 的出现表明，OpenClaw 的机器人路线正从仓库导向转向包生态导向。后续能力扩展可以通过安装 skill package 并填写相机话题、深度话题、目标距离等参数完成，而不必反复修改主插件。随着技能包数量增加，OpenClaw 在机器人方向上的价值也将更多体现为可组合能力市场。

7. 无人机方向：AerialClaw

AerialClaw 是当前最典型的“OpenClaw 方法论外溢”项目之一。其中文 README 与架构文档写得非常明确：项目的目标不是单纯让 LLM 给无人机下命令，而是把无人机建模成一个拥有 SOUL.md、BODY.md、MEMORY.md、SKILLS.md、WORLD_MAP.md 的个性化 Agent，再由 LLM 在实时环境感知基础上动态组合原子技能执行任务。截至 2026 年 3 月 24 日，AerialClaw README 已公开 v2.0 更新，加入安全包线、四层记忆、通用设备协议、自进化引擎和 AirSim 上海城市场景等内容，说明它已从概念 demo 明显向框架化迈进。

AerialClaw 与 OpenClaw 的关系并非代码层合并，而是架构哲学的高度同构。OpenClaw 强调工作区文件、技能、工具与会话状态；AerialClaw 将这一思路迁移到无人机场景，以文档化状态和可组合技能替代预编排飞行脚本。该项目表明 OpenClaw 方法并不局限于桌面设备或消息机器人，而可以扩展到高动态、强感知、高风险的物理系统。

AerialClaw 同时说明，OpenClaw 机器人生态并不局限于 ROS2 路线。ROS2 更适合地面机器人与研究平台，而无人机系统更常涉及 PX4、MAVSDK、AirSim、Gazebo 与安全控制。由此可见，OpenClaw 可迁移的核心并非某一种中间件，而是“自然语言任务 -> 状态文件 -> 技能调用 -> 适配器执行”的层次关系。

8. 机械臂研究框架：CaP-X

CaP-X 补足了当前生态中较薄弱的一环：机械臂代码策略研究的统一评测基线。CaP-X 项目页和 README 明确将其定义为“Benchmarking and Improving Coding Agents for Robot Manipulation”的框架，核心由 CaP-Gym、CaP-Bench、CaP-Agent0 和 CaP-RL 四部分组成。它覆盖 Robosuite、LIBERO-PRO 和 BEHAVIOR 等任务族，并把单轮、多轮、视觉接地、技能合成和 RL 后训练系统化组织到同一套实验流程里。它与 OpenClaw 形成的是互补关系：OpenClaw 更强在工程入口和技能编排，CaP-X 更强在研究测量与策略验证。

研究框架与部署框架在生态中的角色并不相同。OpenClaw 在工程入口、技能编排与硬件链路方面推进较快，但在机械臂策略优劣比较上仍缺少统一坐标。CaP-X 提供的正是这套坐标，使代码式机器人策略能够在不同任务层级、交互轮次和视觉模式下被系统测试。对于希望将 OpenClaw 进一步引入机械臂操控的工作，这种评测基线具有直接参考价值。

AerialClaw、AgenticROS 和 RoClaw 主要解决系统构建问题，CaP-X 则主要承担策略评估角色。将研究基线与工程基线同时纳入综述，才能更准确地呈现当前生态在不同层面的成熟度差异。现阶段，OpenClaw 机器人路线在工程接入上的推进速度明显快于统一评测与策略研究，因此仍需要 CaP-X 这类外部框架补位。

9. 底层控制方向：RoClaw

如果说 AgenticROS 代表的是“把 OpenClaw 接上 ROS2”，那么 RoClaw 代表的就是“把 OpenClaw 一路压缩到最接近电机协议的层面”。RoClaw 官方 README 直接将自己定义为三件套认知生态中的 Cerebellum，也就是实体化身体和快速运动控制层。它采用双脑设计：Cortex 负责高层策略，Cerebellum 负责视觉闭环与运动字节码编译。最核心的技术特征是把运动命令编码成 6 字节或 8 字节帧，让 ESP32-S3 这样的微控制器几乎无需解析就能执行。对于实体机器人而言，这比任何高层对话能力都更稀缺，因为它解决的是延迟、带宽和可靠执行的问题。

RoClaw 的公开资料还有两个很值得记住的细节。第一，项目明确支持两种感知策略：默认的 VLMMotorPolicy 让 VLM 直接返回动作函数调用；可选的 SceneGraphPolicy 则把 VLM 限制为感知器，由本地确定性控制器生成动作。两条路径最终都落到相同的字节码接口上，这说明其架构刻意保持了“上游感知可变、下游执行稳定”。第二，Gemini Robotics-ER 1.6 集成报告里明确写出遥测引导导航流程，即桥接层持续计算方位角和距离，并把它们注入到 VLM 提示中。这表明项目并不迷信端到端，而是把模型与传统几何控制融合起来，用最务实的方式提升闭环表现。

RoClaw 的位置进一步补全了生态分层：上层 OpenClaw 负责会话、计划与工具宿主，中层承载技能、记忆或场景图，最底层则可经由 RoClaw 一类系统收敛为极短的电机命令帧。这种结构比端到端单模型方案更符合机器人系统的工程规律，也更能体现 OpenClaw 方法向实体控制底层的延伸。

10. 机械臂技能案例：soarm-control

技能市场层面，soarm-control 是目前一个很值得注意的信号。ClawHub 页面将其描述为通过 OpenClaw SOARM API 控制机械臂，可执行读取关节状态、按关节角控制、按 XYZ 坐标移动等任务。从公开页面看，它不仅包含 Pinocchio 驱动的逆运动学脚本、关节控制脚本和本地后端服务，还直接说明了安装路径、依赖环境、校准文件位置和安全提示。相比一般性的“机器人控制 skill”，它已经相当接近可运行工程包的粒度。

soarm-control 的出现表明 OpenClaw 在机器人方向已经不再停留在简单命令转发阶段。技能包开始携带身体结构知识、逆解逻辑、校准依赖与执行约束，使 OpenClaw 在通用入口之外逐步吸纳机器人本体知识。尽管 ClawHub 安全扫描仍提示依赖说明不充分和安装风险，这种状态也反映出生态已从概念展示推进到可用工程包阶段。

Seeed Studio 于 2026 年 3 月 9 日更新的教程《Control SO-Arm by OpenClaw on Jetson Thor》，是目前最清楚的 OpenClaw 机械臂落地案例之一。该教程明确给出链路分工：Jetson AGX Thor 提供边缘算力，OpenClaw 作为高层控制接口，LeRobot 负责 SO-Arm 的底层电机通信与标定，soarm-control skill 则充当从自然语言到运动脚本的桥接层。教程甚至把硬件连接、串口检测、lerobot-calibrate 命令、OpenClaw 配置、skill 安装位置和演示启动顺序都写得很细。这种文档形态非常重要，因为它说明 OpenClaw 在机械臂方向上已经不只是“有思路”，而是开始形成可以被第三方厂商复刻的交付链。

该方案可以视为当前 OpenClaw 机械臂集成的标准结构：OpenClaw 负责任务解析、skill 调用、工具组织与交互界面，LeRobot 负责硬件通信、标定与控制，SO-Arm 承担具体执行。这种分工避免让 OpenClaw 取代成熟控制库，而是将其稳定放在任务层和编排层，更有利于复用与维护。

这一案例也明确界定了 OpenClaw 在机器人系统中的角色：它既不是新的电机 SDK，也不是 ROS2 或 LeRobot 的替代控制器，而是统一自然语言意图、安全边界、技能调用与 WebUI 的高层宿主。相同架构因此可以扩展至 SO-Arm、ROS2 机器人、无人机和微型移动平台。

11. 实践中的一条忠告

在机器人研发语境里，最容易被高估的并不是某个仓库的功能列表，而是“接上了自然语言入口”这件事本身。OpenClaw、RosClaw、AgenticROS、soarm-control 以及 Jetson 落地案例共同说明，机器人系统里的关键问题从来不只是“能不能把任务说出来”，而是“这条链路能不能被验证、能不能被约束、能不能在版本迭代后继续稳定工作”。一旦把“能跑通 demo”误当成“可以进入长期运行环境”，后续的返工成本往往来自接口漂移、权限失控、命名空间不一致、技能依赖变化以及真实硬件上的异常行为，而不是最初那几百行生成出来的代码。

因此，OpenClaw 在机器人方向上更适合被理解为任务层与编排层的宿主，而不是对底层控制栈的替代。涉及 ROS2 运动执行、机械臂逆解、无人机飞控、限位逻辑、急停链路和 MCU 字节码控制的部分，仍应保留各自原有的验证路径、仿真流程和安全边界。更稳妥的工程策略，是先把 OpenClaw 放在入口、会话、工具组织和技能调度层，再通过 RosClaw、AgenticROS、LeRobot、PX4、ESP32 或其他既有执行栈逐层下沉，而不是让自然语言入口直接越过这些分层。只有在接口定义、权限边界、仿真验证、日志追踪和回滚机制都足够清晰的前提下，OpenClaw 生态的速度优势才会转化为真实工程收益，而不会演变成部署风险。

12. 结语

综合目前公开资料，OpenClaw 在机器人方向上的演进已经超出“让聊天软件控制机器人”的早期形态，正在逐渐形成一个跨入口、跨技能、跨协议、跨硬件的分层软件栈。最上面是 Gateway、沙箱和模型路由，中间是 ROS2 与技能扩展，下面是无人机、机械臂、移动机器人和 MCU 字节码控制，再往外是 Jetson 等边缘部署平台。就成熟度而言，这一生态仍未定型，许多项目仍处在快速重构阶段，部分技能与案例也停留在早期版本，但整体架构轮廓已经较为清晰。

后续演进的关键不在于单个 demo 的展示效果，而在于这些层次、接口与边界能否继续稳定下来。一旦稳定性持续提高，OpenClaw 就可能从高能力个人 AI 网关进一步演化为机器人任务层的通用宿主。届时，不同身体之间的主要差别将更多体现在底层执行协议，而上层任务表达、状态管理和技能组织将趋于相似。

参考链接

• OpenClaw GitHub (https://github.com/openclaw/openclaw)• OpenClaw Docs (https://docs.openclaw.ai/)• NemoClaw GitHub (https://github.com/NVIDIA/NemoClaw)• NemoClaw Docs (https://docs.nvidia.com/nemoclaw/latest/index.html)• RosClaw GitHub (https://github.com/PlaiPin/rosclaw)• AgenticROS GitHub (https://github.com/agenticros/agenticros)• AgenticROS Skills (https://github.com/agenticros/agenticros-skills)• AgenticROS Follow Me Skill (https://github.com/agenticros/agenticros-skill-followme)• AerialClaw GitHub (https://github.com/XDEI-Group/AerialClaw)• CaP-X GitHub (https://github.com/capgym/cap-x)• CaP-X 项目页 (https://capgym.github.io/)• RoClaw GitHub (https://github.com/EvolvingAgentsLabs/RoClaw)• soarm-control 技能页 (https://clawhub.ai/yuyoujiang/soarm-control)• Seeed SO-Arm 教程 (https://wiki.seeedstudio.com/ai_robotics_control_soarm_by_openclaw_on_jetson_thor/)• Seeed reComputer Jetson 教程 (https://wiki.seeedstudio.com/local_openclaw_on_recomputer_jetson/)• Jetson AI Lab OpenClaw 教程 (https://www.jetson-ai-lab.com/tutorials/openclaw/)