1. 项目缘起为什么我们要从零开始“造轮子”最近在社区里OpenClaw 这个词的热度有点高。无论是技术论坛还是开源项目列表时不时就能看到关于它的讨论或者更常见的是——关于它安装失败的求助帖。我自己也尝试过从 GitHub 拉取代码按照 README 一步步操作结果在openclaw gateway这一步卡住了屏幕上赫然显示着[openclaw] could not start the cli.。这让我想起了很多开源项目早期都会经历的阵痛期文档不完善、环境依赖复杂、部署流程脆弱。对于一个有志于探索具身智能Embodied AI和智能体Agent的开发者来说这种挫败感尤其强烈因为我们面对的不仅仅是代码更是一个需要与现实物理世界交互的复杂系统。正是这种“想用却用不起来”的困境促使我萌生了一个想法与其在别人的框架里反复踩坑、等待更新不如我们自己动手从最核心的原理出发一步步构建一个属于自己的、可理解、可掌控的“智能体骨架”。这就是“从零实现 OpenClaw”系列文章的初衷。我们不是要做一个功能上完全对标原版 OpenClaw 的复刻品那没有意义。我们的目标是通过重新设计和实现一个类似的架构来彻底吃透“具身智能体”背后的设计哲学、核心组件和实现路径。具身智能简单来说就是让 AI 拥有一个“身体”能够通过传感器感知环境并通过执行器比如机械臂、轮子去改变环境。它不再是纯粹在数字世界里处理文本和图像的模型而是需要将大语言模型LLM的推理规划能力与机器人学、控制论、实时系统等传统领域结合起来。这听起来很酷但门槛也极高。市面上已有的框架无论是 OpenClaw 还是其他一些项目往往试图提供一个“一站式”的解决方案这固然降低了入门难度但也像黑盒一样封装了太多细节。当你想要定制一个特殊的行为或者系统在某个环节出错时你会感到无从下手。因此这个系列将采取一种“白盒”教学的方式。我们将从零开始定义我们自己的智能体架构。我们会讨论一个具身智能体到底需要哪些模块感知、规划、控制、记忆这些功能如何划分职责LLM 在其中扮演什么角色是作为核心的“大脑”进行一切决策还是作为一个高级的“顾问”提供任务分解和常识不同的选择将导向完全不同的系统复杂度和性能表现。这就是所谓的“路径选择”它没有绝对的对错只有适合不同场景的权衡。在开始敲代码之前我们必须先把这些顶层设计想清楚。这篇文章就是这个系列的开篇我们将聚焦于架构总览。我会分享我对于构建一个现代具身智能体核心架构的思考对比几种主流的设计范式并阐述我们最终选择的路径及其背后的理由。我们的目标不是追求最前沿的论文复现而是构建一个足够清晰、健壮、且易于扩展和调试的基础框架为后续深入各个模块的实现打下坚实的基础。如果你也对如何将 LLM 的能力注入到一个能动的“身体”里感兴趣却苦于找不到一个清晰的入门和实操路径那么请跟着我一起从这个架构图开始踏上我们的“造轮子”之旅。2. 核心架构拆解一个具身智能体的“五脏六腑”在动手画架构图之前我们得先达成一个共识一个能够有效工作的具身智能体应该由哪些不可或缺的部分组成经过对现有研究和开源项目包括 OpenClaw、RoboAgent 等的梳理并结合机器人领域的经典范式我提炼出了一个相对通用且层次分明的四层架构。这个架构将成为我们后续所有开发工作的蓝图。2.1 感知层为智能体装上“眼睛”和“耳朵”感知层是智能体与物理世界交互的起点。它的核心任务是将原始的、高维的、非结构化的传感器数据转化为智能体内部其他模块能够理解和处理的结构化表征。数据源这包括但不限于 RGB 摄像头提供颜色和纹理、深度摄像头或激光雷达提供 3D 几何信息、麦克风音频、惯性测量单元IMU提供自身运动状态、关节编码器提供机械臂或机器人本体的姿态等。在我们的实现初期为了简化可能会从 RGB 图像和深度图开始。核心处理感知层不是简单的数据转发。它需要完成重要的信息提取和压缩工作。例如物体检测与识别从图像中找出并识别出“杯子”、“桌子”、“门把手”等物体。我们可以使用现成的模型如 YOLOv8 或 DETR。这里的关键是不仅要输出边界框和类别最好还能输出在机器人坐标系下的 3D 位置这需要结合深度信息。语义分割理解图像中每一个像素属于什么类别如地面、墙壁、可操作物体。这对于导航和避障至关重要。场景理解生成一个对当前环境的简洁、高层次的描述例如“这是一个厨房中央有一个岛台岛台上放着一个红色的马克杯和一个金属水壶”。这个描述可以直接喂给 LLM。输出感知层的输出应该是多种模态、不同抽象层次的信息的集合。我们可以将其组织成一个结构化的“感知字典”或“场景图”包含物体列表带位置、类别、属性、场景描述文本、可通行区域地图等。一个重要的设计原则是感知层应尽量保持“客观”它描述“是什么”而不预设“要做什么”。这为后续规划层的灵活性留出了空间。2.2 认知与规划层智能体的“大脑”与“谋士”这是整个系统的智能核心也是 LLM 大显身手的地方。这一层接收来自感知层的结构化信息结合任务目标例如“把桌上的杯子拿给我”和内部记忆生成一系列可执行的动作指令序列。任务理解与分解LLM 在这里扮演“高级指挥官”的角色。它首先理解用户的自然语言指令然后将其分解为一系列原子子任务。例如“泡一杯茶”可能被分解为“1. 移动到水壶旁2. 拿起水壶3. 移动到茶杯旁4. 将水倒入茶杯5. 放下水壶。”常识与物理推理LLM 提供了宝贵的常识。它知道水壶通常放在厨房茶杯可能放在橱柜或餐桌上倒水时壶嘴要对准杯口。这些人类觉得理所当然的知识对于机器人而言是极其宝贵的信息能避免大量无意义的探索和试错。动作序列生成分解后的子任务需要被进一步转化为机器人底层控制器能理解的动作原语。这里有两种主流路径LLM 直接输出底层指令例如直接输出“移动机械臂到坐标 (x, y, z)”或“闭合夹爪”。这种方式简单直接但对 LLM 的要求极高需要它精确理解机器人的运动学和动力学且非常容易因微小误差导致失败或危险。LLM 输出高级技能调用这是我们更倾向的路径。我们预先定义好一系列可靠的“技能”Skills如NavigateTo(object)PickUp(object)Place(object, location)。LLM 的工作是规划出调用这些技能的序列和参数。例如输出[Skill: PickUp, Params: {“object”: “red_cup”}]。这种方式将复杂的底层控制封装在技能内部由专门的控制器实现大大降低了 LLM 的负担提高了系统的稳定性和安全性。记忆与状态管理智能体需要有“记忆力”。它需要记住自己已经完成了哪些步骤当前正在执行哪个子任务之前尝试过但失败的动作等。这通常通过一个“工作记忆”或“状态机”来维护。LLM 也可以参与到状态管理中例如根据当前状态判断下一步该做什么或者在任务中断后重新规划。2.3 技能与执行层智能体的“双手”与“小脑”规划层决定了“做什么”而执行层则负责“怎么做”。这一层由一系列封装好的、可重用的“技能”模块构成。技能抽象每个技能都是一个独立的、功能完备的模块。它接收明确的输入如目标物体ID、目标位置调用底层的感知和控制算法完成一个具体的物理动作并返回执行结果成功/失败及原因。例如PickSkill输入一个检测到的物体输出是机械臂成功抓取该物体。其内部可能包含视觉伺服、运动规划、力控等复杂算法。PlaceSkill输入一个物体和一个放置位置可以是另一个物体如“桌子”完成放置动作。NavigateSkill输入一个目标点或目标物体控制机器人底盘移动到该位置并避开障碍物。控制器每个技能内部都包含一个或多个专用的控制器。这些控制器是传统机器人技术的结晶例如运动规划器计算从当前位置到目标位置的无碰撞路径。视觉伺服控制器利用实时视觉反馈来精细调整机械臂的末端位姿实现精准抓取。力/位混合控制器在接触任务如插拔、旋拧中同时控制位置和接触力。设计价值将技能层独立出来是实现系统模块化和可维护性的关键。我们可以单独开发和测试每一个技能用传统机器人学的方法确保其鲁棒性。当 LLM 提出新的任务需求时我们只需要教会它调用现有的技能库或者为它开发一个新的技能模块而不需要重新训练或调整 LLM 本身。2.4 控制与接口层智能体的“神经末梢”与“对外窗口”这是最底层直接与硬件或仿真环境打交道的一层。它负责将高层技能发出的抽象命令翻译成硬件驱动能理解的具体指令同时管理着整个系统的生命周期和对外通信。硬件抽象为了兼容不同的机器人平台如 UR5、Franka Emika 机械臂TurtleBot 移动底盘我们需要一个硬件抽象层。它定义统一的接口如move_to_pose(pose),gripper_close()不同的硬件驱动去实现这些接口。这样上层的技能代码就与具体硬件解耦了。仿真接口在开发初期和算法测试阶段我们几乎必然要使用仿真环境如 PyBullet、MuJoCo 或 NVIDIA Isaac Sim。控制层需要提供与这些仿真器通信的客户端将控制指令发送给仿真器并从仿真器读取传感器数据。一个良好的设计是同一套技能代码只需更换底层的接口实现就能无缝在仿真和真实机器人上运行。通信总线与消息管理一个复杂的智能体系统内部模块众多它们之间需要高效、可靠地通信。我们会引入一个消息中间件例如 ROS2 的 Topic/Service 或者更轻量级的 ZeroMQ、Redis Pub/Sub。感知数据、规划指令、技能状态、控制命令等都通过这条“总线”进行流转。这带来了松耦合的好处但也增加了系统调试的复杂度。人机交互接口智能体需要与人交互。这包括命令行界面就像我们尝试运行openclaw gateway时想启动的那个 CLI用于系统启动、状态监控和调试。Web API提供 RESTful 或 WebSocket 接口允许其他应用程序如手机 App、桌面 GUI向智能体发送任务、查询状态。自然语言接口通常由规划层的 LLM 直接处理但需要本层提供一个接收用户语音或文本输入的通道。将这四层画成一张图它们之间的关系是清晰的数据流感知 → 认知/规划 → 技能/执行 → 控制/接口同时底层的状态和结果也会作为反馈逆向流回上层用于更新记忆和重新规划。这个架构图就是我们后续所有工作的总纲。3. 路径选择LLM 作为“大脑”还是“顾问”架构确定了组件但如何分配这些组件之间的权责尤其是 LLM 的职责范围是设计一个具身智能体时最关键的决策点之一。这直接决定了系统的能力边界、复杂度和可靠性。目前社区里主要有两种范式我称之为“LLM-Centric”以LLM为核心和“LLM-as-Controller”LLM作为控制器以及我们折中选择的“LLM-as-Supervisor”LLM作为监督者路径。3.1 路径一LLM 作为核心控制器在这种模式下LLM 被赋予最大的权力。它直接接收原始的或轻度处理的感知信息如图像描述、物体列表然后直接输出底层的、具体的控制指令比如机器人的关节角度、轮子速度、夹爪开合度。优点极致灵活理论上LLM 可以应对任何未知场景生成任何它“想象”出的动作序列不受预设技能的限制。端到端简化架构看起来非常简洁感知后直接就是LLM然后输出动作似乎减少了中间模块的复杂度。缺点与风险可靠性灾难LLM 的生成具有随机性和幻觉。一个微小的指令偏差如坐标差了几厘米就可能导致机械臂撞到物体或自己。在物理世界中这种错误是昂贵且危险的。缺乏物理常识LLM 在文本上理解的“拿起”与机器人学中需要精确力控、接触检测的“拿起”相去甚远。它无法理解摩擦力、惯性、质心等物理概念。实时性差LLM 推理速度较慢尤其是大参数模型难以满足机器人控制对毫秒级响应的要求。难以调试当系统出错时你很难定位是感知不准、LLM 规划错误还是底层控制失效因为所有环节都耦合在一起。注意这条路径目前更多出现在学术研究的“概念验证”演示中用于展示 LLM 理解场景和任务的能力。但在要求稳定、安全、可重复执行的现实应用或长期运行的系统中我强烈不建议采用这种架构作为基础。3.2 路径二LLM 作为高级规划器与技能调度器这是我们推荐并将在本系列中采用的路径。在这种模式下LLM 被限制在“认知”的高层领域它的核心工作是理解人类指令。进行任务分解和逻辑推理。调用预先定义好的、经过严格测试的技能。它不直接输出joint_angles[0.1, 0.5, ...]这样的底层命令而是输出像[Skill: Pick, Target: red_cup]这样的高级指令。具体的“如何抓取”这个红色杯子则由PickSkill这个模块全权负责该模块内部封装了运动规划、视觉伺服等成熟、可靠的机器人算法。优点安全可靠将危险的底层控制与可能出错的 LLM 隔离开。技能模块可以用传统方法保证其稳定性和安全性。模块化与可维护性技能可以独立开发、测试和优化。LLM 部分和技能部分可以分别升级。可解释性强系统状态清晰。如果任务失败我们可以很容易地查看是 LLM 的规划不合理如调用了错误的技能还是某个技能本身执行失败如抓取时滑脱从而有针对性地进行修复。效率更高LLM 只需要在关键决策点如任务分解、技能选择被调用而不是在每一个控制周期都被调用大大减少了计算开销。挑战技能库的完备性智能体的能力受限于技能库。如果遇到一个需要“折叠衣服”的任务而技能库里没有FoldClothSkillLLM 将无能为力。这就需要我们不断地扩展技能库。LLM 与技能的“对齐”需要精心设计技能的描述和接口并用合适的示例few-shot来教会 LLM 何时以及如何使用这些技能。这涉及到提示工程和可能的行为克隆微调。3.3 我们的选择分层协同的“LLM-as-Supervisor”架构在路径二的基础上我们会进一步细化采用一种更工程化的“监督者”模式。在这个架构中LLM 是战略家它专注于高层任务解析、场景理解和异常处理。例如当PickSkill多次报告抓取失败时LLM 可以介入分析可能的原因“物体太滑”“遮挡了”并尝试重新规划“先移动到另一个角度再试一次”或“放弃这个物体寻找替代品”。技能模块是战术专家每个技能都是一个自包含的、鲁棒的“反射弧”。给定目标它负责用最优的方式完成并处理执行过程中的局部异常如轻微的位置偏差。一个专用的“协调器”模块这是介于 LLM 和技能层之间的一个轻量级组件。它维护当前的任务状态机管理技能的执行队列处理技能的返回结果成功/失败并决定是继续执行下一个技能还是需要将异常情况上报给 LLM 请求重新规划。这个协调器可以用简单的规则或一个轻量级模型来实现避免频繁调用大模型。为什么选择这条路径因为它在灵活性和可靠性之间取得了最佳平衡。它既利用了 LLM 强大的泛化理解和推理能力又用传统的、可靠的机器人技术为物理交互兜底。这套架构清晰、易于调试、便于扩展非常适合作为我们从零开始学习和实现具身智能体的起点。它让我们能够分而治之先集中精力打造一个稳定可靠的技能执行层然后再逐步完善 LLM 的规划能力最后通过协调器将它们优雅地粘合在一起。4. 技术栈选型构建我们的开发地基确定了架构和路径接下来就要选择实现它们的具体工具。选型的原则是成熟、开源、社区活跃、易于集成。我们不追求最炫酷的新技术而是选择那些能让我们快速搭建起可运行原型并且有大量资料可供参考的技术。4.1 编程语言与核心框架Python这是毋庸置疑的首选。它在机器学习、机器人学领域拥有最庞大的生态系统NumPy, SciPy, OpenCV, PyTorch/TensorFlow。我们所有的感知模型、LLM 接口、算法原型都将用 Python 编写。ROS 2机器人操作系统。这是一个非常重要的选择。ROS 2 提供了我们架构中梦寐以求的通信中间件和节点化编程模型。为什么是 ROS 2 而不是 ROS 1ROS 2 解决了 ROS 1 在实时性、安全性、跨平台部署上的诸多痛点更适合生产环境。其基于 DDS 的通信机制也更可靠。如何对应我们的架构我们的每一个模块如物体检测节点、LLM规划节点、导航技能节点、机械臂驱动节点都可以是一个独立的 ROS 2 节点。它们通过 Topic发布/订阅用于流式数据如图像和 Service请求/响应用于执行命令如调用技能进行通信。这完美实现了我们设想的松耦合、模块化架构。学习曲线对于新手ROS 2 有一定学习成本但它是机器人软件的事实标准。掌握它将使你未来能更容易地集成其他机器人硬件和算法。4.2 仿真与环境在拥有真机之前仿真环境是我们的主战场。PyBullet我们的首选仿真器。理由如下轻量快速启动快对硬件要求相对较低适合快速迭代和测试。Python 原生API 完全基于 Python与我们的主开发语言无缝集成调试非常方便。物理引擎足够真实对于抓取、放置、移动等我们关心的任务其物理模拟精度是足够的。丰富的 URDF 支持可以轻松导入各种机器人模型URDF 文件。仿真场景构建我们将使用 PyBullet 构建一个简单的桌面操作场景包含一张桌子、几个不同形状的积木立方体、圆柱体和一个模拟的机械臂如 Franka Panda。这足以验证我们核心的感知-规划-执行链路。4.3 感知与模型视觉感知物体检测使用YOLOv8。它提供了极佳的精度和速度平衡并且有非常友好的 PyTorch 接口和预训练模型。我们将使用其官方ultralytics库进行推理。深度估计在仿真中我们可以直接从 PyBullet 的 API 获取精确的深度图。这省去了用单目深度估计模型的麻烦和误差。坐标转换这是感知层的关键一步。我们需要将图像中检测到的 2D 边界框结合相机内参和深度图转换到机器人基坐标系的 3D 位置。这将涉及相机标定和坐标变换链图像坐标系 - 相机坐标系 - 机器人基坐标系的计算。LLM 接口本地部署 vs. API 调用为了开发的灵活性和稳定性避免网络问题我们优先考虑在本地部署一个轻量级但能力足够的开源模型。Qwen2.5-7B-Instruct或Llama 3.2-3B-Instruct这类模型是不错的选择它们对硬件要求相对友好需要一张显存足够的 GPU如 RTX 4060 16G 或以上且指令跟随能力很强。推理框架使用Ollama或vLLM来运行和管理本地模型。Ollama 更简单易用vLLM 则性能更高。我们将编写一个简单的 Python 客户端通过 HTTP 或 gRPC 与 LLM 服务通信发送提示词并获取规划结果。4.4 规划与控制运动规划我们将从简单的逆运动学和直线轨迹规划开始。可以使用pybullet自带的逆运动学求解器或者更专业的ikpy库。对于避障路径规划初期可以假设环境是静态的使用OMPL库的简化接口。技能实现每个技能Pick, Place将被实现为一个 ROS 2 的Action Server。Action 是 ROS 2 中一种适合长时间运行、可反馈、可取消的通信机制非常适合技能执行。例如PickAction的目标是物体ID反馈是当前执行状态“移动中”、“对准中”、“抓取中”结果是最终的成功与否。4.5 系统集成与部署容器化为了环境一致性和便于部署我们使用Docker。可以为一个复杂的模块如包含 YOLOv8 和 PyTorch 的感知节点单独制作镜像或者为整个系统制作一个组合的docker-compose.yml文件。这也是解决类似openclaw那种环境依赖问题的好方法。监控与调试ROS 2 自带的rqt工具套件如rqt_graph查看节点拓扑rqt_console查看日志是我们的主要调试工具。同时我们会为关键数据如检测框、规划指令添加可视化在 RViz 2 中显示。这个技术栈组合覆盖了从仿真、感知、智能规划到底层控制的完整链条且每一个组件都有广泛的社区支持和学习资源。它足够我们搭建起一个功能完整、且能深入理解其每一处细节的具身智能体原型。5. 从蓝图到代码我们的实现路线图有了清晰的架构和选型接下来就是将蓝图转化为代码的实战阶段。这个过程不会一蹴而就我们需要一个循序渐进的路线图确保每一步都走得稳每一步都有可验证的成果。以下是本系列文章后续的初步规划每一篇都将聚焦一个具体的模块并产出可运行的代码。5.1 第一阶段搭建仿真舞台与“脊柱”目标建立一个可用的仿真环境并实现系统的基础通信框架。内容仿真环境搭建用 PyBullet 创建包含桌子、若干物体和 Franka Panda 机械臂的场景。编写脚本加载模型并实现基本的视角控制。ROS 2 基础框架创建我们的 ROS 2 工作空间和包。实现第一个简单的节点一个“世界状态发布者”以固定频率发布仿真中所有物体和机器人关节的位姿作为后续感知的“Ground Truth”参考便于调试。相机模拟在仿真中设置一个虚拟相机固定在机械臂末端或某个全局位置。编写节点通过 PyBullet 获取相机视图的 RGB 图像和深度图并将其作为 ROS 2 的 Image 消息发布出去。产出一个运行在 PyBullet 中的仿真世界以及通过 ROS 2 话题流式传输的视觉数据。这是整个系统的“舞台”和“感官输入源”。5.2 第二阶段赋予智能体“视觉”目标实现感知层让智能体能“看到”并理解仿真世界中的物体。内容YOLOv8 检测节点创建一个 ROS 2 节点订阅虚拟相机发布的 RGB 图像。在回调函数中使用 YOLOv8 模型进行物体检测。将检测结果类别、2D 边界框、置信度发布到新的 Topic。3D 位置估计创建另一个节点同时订阅 RGB 图像、深度图和相机内参。它接收 YOLOv8 的 2D 检测结果结合深度信息通过坐标变换计算出每个检测物体在机器人基坐标系下的 3D 位置x, y, z。输出一个结构化的“物体列表”消息。场景描述生成基于“物体列表”编写一个简单的规则或模板生成文本形式的场景描述例如“视野中有一个红色的立方体在桌子中央一个蓝色的圆柱体在立方体左边。”产出智能体能够输出类似[{‘name’: ‘red_cube’ ‘position’: [0.5, 0.1, 0.8]}, …]的感知信息以及一句场景描述文本。这构成了规划层的输入。5.3 第三阶段注入“思维”与“记忆”目标集成 LLM实现任务分解和规划并建立简单的状态管理。内容本地 LLM 服务部署使用 Ollama 在本地部署 Qwen2.5-7B 模型。编写一个 Python 客户端测试其基础对话能力。LLM 规划节点创建一个 ROS 2 Service Server。该服务接收两个参数用户指令如 “pick up the red cube”和当前的场景描述文本。在服务处理函数中构造提示词Prompt调用本地 LLM请求它将任务分解为技能调用序列。例如返回[‘NavigateTo(red_cube)’ ‘Pick(red_cube)’]。提示词工程设计并迭代我们的提示词。这是让 LLM 理解我们的技能库的关键。提示词需要明确说明可用的技能、输入输出格式并给出几个示例。状态协调器实现一个简单的状态机例如使用pytransitions库它接收 LLM 规划的技能序列依次执行并记录当前执行状态。产出用户可以通过 ROS 服务发送指令智能体能够返回一个结构化的技能执行计划。这是系统的“大脑”。5.4 第四阶段锤炼“肢体”与技能目标实现核心的机器人技能特别是抓取技能。内容运动规划基础实现一个工具函数根据目标位置计算机械臂末端的运动轨迹。初期使用简单的直线轨迹和 PyBullet 的逆运动学求解。PickSkill 实现将抓取技能实现为一个 ROS 2 Action Server。其目标Goal是物体ID。内部逻辑包括a) 查询该物体的 3D 位置b) 规划机械臂移动到物体上方的预抓取位姿c) 沿直线下降至抓取位姿d) 控制虚拟夹爪闭合e) 提升物体。过程中通过 Action 的反馈Feedback发布执行状态。PlaceSkill 实现类似地实现放置技能。目标可能是某个位置或另一个物体。产出可被规划层调用的、稳定可靠的Pick和Place技能。这是系统的“双手”。5.5 第五阶段系统集成与闭环测试目标将以上所有模块连接起来完成一个端到端的任务演示。内容串联所有节点编写一个启动文件Launch File一次性启动仿真环境、感知节点、LLM 规划节点、技能节点和状态协调器节点。端到端流程测试发送指令 “stack the blue cylinder on top of the red cube”。观察系统能否自动完成检测物体 - 规划出[Pick(blue_cylinder) Place(blue_cylinder on_top_of red_cube)]- 成功执行抓取 - 成功执行放置。错误处理与重规划增加简单容错。例如如果PickSkill返回失败比如因为物体位置估计有偏差没抓到状态协调器应能捕获这个失败并通知 LLM 重新规划例如 “抓取失败尝试重新调整姿态抓取” 或 “放弃”。产出一个完整的、能够理解自然语言指令并在仿真环境中完成简单操作任务的具身智能体原型。这是我们的“最小可行产品”。5.6 后续展望在完成这个基础闭环之后我们便拥有了一个功能完整且完全透明的系统。在此基础上有无数个方向可以深入和优化技能扩展增加PushSlideOpenDrawer等更复杂的技能。感知增强引入点云处理、6D 姿态估计让抓取更精准。规划优化让 LLM 学会使用工具如用棍子去拨动远处的物体或者进行多步推理。仿真到真实迁移将技能模块部署到真实的机械臂上研究 Sim2Real 的技术。多模态交互增加语音输入和输出。这个路线图的意义在于它不是一个空中楼阁式的理论阐述而是一个个可执行、可验证的代码里程碑。每一步我们都能看到、运行并调试我们的智能体。通过这个“造轮子”的过程你对具身智能的每个组成部分将不再有模糊的概念而是有清晰、深刻、源于实践的理解。这正是本系列希望带给你的核心价值。在下一篇文章中我们将从第一步开始搭建起我们的仿真舞台。