简介哈尔滨工业大学社会计算与信息检索研究中心出品的《大模型时代的具身智能》PDF报告面向人工智能、机器人方向的研究者与学习者系统梳理“大模型机器人”如何走向真正智能。报告从公元前9世纪偃师机器人、公元前4世纪蒸汽驱动鸟、达·芬奇人形草图讲到Unimate、KUKA等工业机器人再延伸至WABOT-1、ASIMO、Atlas等类人机器人同时结合符号推理、专家系统、机器学习到深度学习的演进说明人工智能算法如何让机器人在视觉、语音、自然语言处理等领域能力增强。资源重点拆解了智能机器人的双能力定义——自主能力与泛化能力并给出具身感知、具身推理、具身执行三部分构建路径。资源共1个PDF约12.23MB已有185人学习适合作为具身智能入门与前沿追踪的专题讲义帮助读者快速建立从机器人发展史到大模型赋能实体智能的完整认知框架。1. 大模型入场之前机器人最缺的从来不是硬件先抛一个反直觉的结论具身智能真正的瓶颈不在关节电机、灵巧手或者液压驱动而在于机器人不知道“接下来该做什么”。1961 年的 Unimate 已经能堆叠金属但它在 2024 年仍然只会堆叠金属问题不是手不够巧而是脑子没有跟上。大模型时代把这件事彻底改变了——语言模型和视觉模型第一次让机器人能理解场景、拆分任务、生成动作序列而不只是沿着预编程轨迹重复。这篇内容梳理了哈工大社会计算与信息检索研究中心关于具身智能的报告从机器人发展史讲到感知、推理、执行三层架构适合正在做机器人算法、想从传统控制转向学习路线或者准备投入具身智能方向的研究生和工程师。2. 从 WABOT-1 到 Atlas机器人演进里的三笔技术遗产2.1 “人形”不是表演而是环境适应性的结果报告里对类人机器人这条线梳理得很清楚1972 年日本早稻田大学推出 WABOT-1这是世界第一台全尺寸人形机器人行走一步需要 45 秒步伐只有 10 公分。今天看这个数字很寒碜但它证明了一件事——双足动态平衡是可以被机电系统复现的。到了 2000 年的 ASIMO本田经过数次迭代已经掌握了双足奔跑、搬运托盘、上下楼梯2008 年 Aldebaran 的 NAO 把小型人形机器人做成了教学和陪伴工具2013 年波士顿动力的 Atlas 则把运动控制推到了新高度跑跳、后空翻、越野行走都不在话下。这一百年的演进有一个清晰的趋势硬件能力在飞速逼近人类但“该做什么”的判断能力始终落后。WABOT-1 能走路但它不知道为什么要走ASIMO 能上下楼但它不知道楼梯尽头有什么。报告在这里点出了一个关键判断——运动控制型机器人解决的是“怎么动”而智能机器人必须回答“为什么动”和“动完之后怎么办”。2.2 从固定轨迹到可编程自主工业机器人补上的第二课工业侧的时间线同样值得梳理。1961 年的 Unimate 是第一台工业机器人本质上是可编程的机械臂按预定轨迹重复作业1973 年 KUKA 推出的 FAMULUS 是第一台拥有六个机电驱动轴的工业机器人六轴的引入让末端执行器可以到达空间任意位姿这是“手”的自由度基础。更关键的是FAMULUS 具备了一定的自主性——编程后可以自主运行、自主判断和决定接下来的操作。把这两条线放在一起看会发现机器人产业的早期积累其实分成了两个方向一条卷运动能力一条卷工业可靠性。但它们有一个共同的隐含假设——任务空间是预先知道的机器人在封闭环境里执行有限动作集合。医疗微创机器人、物流运输机器人、展厅服务机器人、家庭清洁机器人本质上延续了这个思路只是把应用场景从工厂扩展到了生活空间。问题在于这些机器人的“智能”是枚举出来的场景一变就失效这正是报告里强调的“泛化能力”缺失。2.3 四十年真正留下的遗产传感器与运控先于大脑成熟回顾这段历史我认为对当前做具身智能最有价值的不是某个机器人的运动表现而是一个容易被忽略的事实——传感器和运控系统已经先于大脑成熟了。触觉信号、力反馈信号、位姿信号、2D 视觉与 3D 点云信号这些硬件接口在今天已经是标准配置精度和稳定性都能满足实际需求。换句话说具身智能缺的从来不是“身体”的传感器而是把这些异构信号统一理解、统一决策的“小脑之上的大脑”。年代代表机器人关键能力对具身智能的贡献1972WABOT-1全尺寸人形、双足行走验证机电系统可复现人类运动2000ASIMO双足奔跑、上下楼梯运动控制与动态平衡的工程化标杆2008NAO小型教学陪伴人形人机交互场景的规模化探索2013Atlas跑跳、复杂地形运动运动能力的天花板反衬智能缺口这张表的阅读方式不是“看谁的功夫好”而是看“运动能力到达某个水位之后下一步该补什么”。Atlas 的运动能力已经远超大多数人类但它的每一次跳跃仍然需要人为指定目标点。身份从“遥控的机器”变成“自主的智能体”转折点不发生在关节而发生在决策。3. 具身智能的三层架构具身感知、具身推理与具身执行3.1 具身感知不是“识别画面”而是融合多模态状态报告给智能机器人下了一个操作性的定义具备自主能力即尽可能少地需要人类干预同时具备泛化能力即能应对复杂场景和多样任务。要做到这两点第一步是感知。但具身感知和 CV 里的图像识别不是一回事——机器人需要同时收集环境信息和自身状态而且这些信息来自完全不同的传感器模态。通常的系统会包含这样几路信号2D 视觉信号或 3D 点云信号用于理解外部环境语音信号用于接收人类指令触觉信号或力反馈信号用于判断接触状态位姿信号用于估计自身在空间中的位置和朝向。这里的难点不是单模态识别精度而是多模态对齐——摄像机看到“桌上有咖啡渍”力传感器感受到“抹布已经接触到桌面”IMU 告诉“手臂当前在什么姿态”这三个信息必须在同一个时间戳下被综合理解才能支撑后续的推理。这里有一个在工程里常见的误区很多人把感知模块做成一个黑盒分类器输出“桌子”“杯子”“抹布”这样的标签就结束了。但在具身智能系统里感知的结果要服务于动作光有类别标签不够还需要物体的位姿、朝向、可交互性、抓取点位置。我一般会在感知层保留几何信息而不是只保留语义信息把 2D 检测结果投影到 3D 点云上得到物体的六自由度位姿后面的抓取规划才有的放矢。3.2 具身推理从“这是什么”到“接下来做什么”报告里用了一个很具体的例子来展示具身推理的执行过程机器人通过视觉传感器采集到桌上有咖啡洒了系统分析出“应对咖啡进行清理”然后生成一个任务清单——扶正杯子并拿起杯盖、找到抹布、用抹布擦拭地面、将抹布放回、最后将杯子和杯盖扔掉。这个例子看起来简单但它包含了具身推理的两个关键层级。第一层是任务规划从“清理咖啡”这个抽象目标分解出有序的子步骤这要求系统理解“先扶正杯子再拿盖”这样的因果约束——如果先拿盖杯子可能继续倾倒。第二层是运动规划把“拿起杯盖”这个子任务映射为具体的运动轨迹包括手臂如何运动、手掌如何运动、腿部如何运动。前者是大模型擅长的事后者是传统机器人控制擅长的事两者的接口设计是具身智能系统架构的核心问题。具体来说任务规划层可以依赖大模型的常识推理能力因为“咖啡洒了需要擦”这类知识不需要物理接触就能获得。但运动规划层不能脱离机器人本体——同一个任务六轴机械臂和双足人形机器人的实现方式完全不同。所以在落地时我倾向于把推理层输出为中间表示而不是直接输出关节角比如“抓取杯盖目标位姿 x, y, z, roll, pitch, yaw”这样的技能级指令再去匹配具体的运控模块。3.3 具身执行指令必须向下位机翻译成关节目标推理层产出的是任务序列执行层要把它翻译成下位机能接受的形式。报告中把执行指令概括为三种形式代码、技能库 API、关节旋转角度。这三者的抽象层级是递减的——代码和 API 是面向任务的关节角是面向硬件的。在真实系统里我会让大模型优先输出技能库 API 调用因为这样安全性可控也便于回退到人工处理当技能库里没有匹配项时才退化为关节角直接控制。下面是一个典型的执行层调度逻辑的伪代码示意def execute_task(task_sequence: list, robot_api: RobotAPI) - bool: success True for step in task_sequence: print(f[EXEC] 执行步骤: {step[action]}, 目标: {step[target]}) # step[action] 是技能名, 例如 grasp, wipe, place # step[target] 是技能参数, 例如物体名称或目标位姿 if step[action] in robot_api.skills: ok robot_api.call_skill(step[action], step[target]) else: # 技能库无匹配时, 用低层级控制接口下发关节角轨迹 trajectory robot_api.plan_joint_trajectory(step[target]) ok robot_api.execute_trajectory(trajectory) if not ok: print(f[EXEC] 步骤失败: {step[action]}, 终止任务) success False break return success这段代码的核心设计思路是双通道下发优先走技能库 API技能库缺失时降级到关节轨迹规划。task_sequence是推理层输出的事件序列每个事件包含动作名和参数robot_api.skills是预置的技能集合比如 grasp、wipe、place 这类原子操作plan_joint_trajectory依赖运动学逆解把目标位姿换算成关节角度序列。这个设计的优点在于大模型的输出被限制在技能词表内不会凭空产生非法指令而技能库的安全边界又比端到端输出关节角容易验证得多。4. 大模型在具身智能里的真实角色被低估的接口层4.1 大模型之前AI 一直隔着屏幕报告对人工智能的发展脉络做了一个高度浓缩的概括1956 年到 60 年代初用符号推理做数学证明60 到 70 年代初启发式搜索算法能力有限70 到 80 年代中专家系统处理医疗、化学、地质等特定领域80 年代中到 90 年代中专家系统需要海量专业知识实用价值受限90 年代中到 2010 年机器学习处理实际问题2011 年之后深度学习用于图像、文本、语音2022 年之后出现可以处理通用任务的大模型。这条脉络里最值得注意的不是某个算法的兴衰而是一个持续存在的结构性缺口——AI 始终停留在电脑屏幕里没有以实体的方式进入物理世界。图像识别模型能看到一张猫的照片但它碰不到猫对话模型能回答“如何擦桌子”但它不知道桌子的材质、抹布的位置、手臂伸过去会不会撞到杯子。具身智能要补的正是这个缺口让模型不仅“知道”世界而且“作用于”世界。4.2 大模型解决的不是“控制”而是“对齐”机器人从不缺控制算法缺的是把传感器数据和人类意图对齐到同一个语义空间的能力。传统架构里检测模型输出类别和 2D 框机械臂用规划算法去抓取这两者之间的转译靠工程师手写代码硬接每个新任务都要重新写一遍胶水逻辑。大模型时代的多模态模型可以把图像、文本、位姿信息统一编码直接从“视觉观察到咖啡洒了”跳到“应该执行清理动作”。这个变化的意义在于大模型承担了传统架构里属于工程师的接口编写工作。输入是视觉特征和语言指令输出是结构化的任务描述——这一层不需要手写规则而是从大规模预训练中习得。很多人质疑大模型输出不可靠这是事实但对于具身智能来说大模型的意义不在于输出百分之百正确而在于把任务的假设空间从“工程师能枚举的”扩展到了“模型见过的”。4.3 人机交互的升级从编程到自然语言对话报告里有一句话值得反复读智能机器的自主能力追求“尽可能少的人类干预”而不是完全不需要人类。这意味着人机交互接口本身就是系统设计的一部分。传统机器人编程需要工程师写代码或拖拽示教器而大模型时代可以直接用自然语言描述任务目标机器人生成执行方案后由人确认或修正。# 自然语言到任务序列的转换示意: 假设有 LLM 服务接口 def plan_from_instruction(instruction: str, visual_state: dict) - list: # visual_state 包含当前环境的物体列表、位姿、可交互性 prompt f场景中有: {visual_state}. 任务: {instruction}. 请输出步骤序列。 # 调用 LLM 得到 JSON 格式步骤列表 steps llm_plan(prompt, temperature0.2) # 低温减少随机性 return validate_and_constrain(steps) # 检查动作词是否在技能库内这里的temperature0.2是一个值得记住的参数任务规划任务里我们不想让模型发挥创造力需要的是稳定的、可复现的步骤序列所以温度要压低而如果是让模型提出多种可行方案才需要把温度调高到 0.7 以上。validate_and_constrain的作用是把模型输出的自由文本映射到受控的技能词表里这一步是安全兜底不能省。5. 可落地的实现路线VLA 与动作空间设计5.1 具身智能 agent 的两条技术路线把“具身智能 agent”拆开看要决策两个问题用什么模型做决策动作以什么形式离开模型。当前主流落地方案有两条路线。第一条是把语言模型当大脑感知模块和运动模块独立存在模型负责从视觉语言输入生成任务序列再由底层的运动库执行——本质上就是前面 3.3 描述的架构。第二条是视觉语言动作模型VLA把感知、推理、动作输出压缩进一个端到端模型输入图像和文本指令直接输出动作信息代表工作有 RT-2、PaLM-E 这一脉。维度语言模型规划 运动库VLA 端到端模型任务分解强依赖 LLM 常识中等需要数据学习动作精度高运动库精调取决于训练数据质量数据需求少量任务指令数据海量机器人轨迹数据可解释性高中间有任务序列低端到端黑盒扩展新技能快加技能库 API 即可慢需要重训或微调适合场景结构化环境、已知技能集合开放环境、技能难以枚举从工程落地角度看我建议优先走第一条路线因为技能库方案每个环节都可以单独调试感知错了改感知规划错了改 prompt运控错了改轨迹生成。VLA 端到端方案虽然优雅但出了问题很难定位——输出一个错误的关节角你不知道是视觉误解了场景还是推理选了错策略还是动作头拟合出了问题。5.2 动作空间的三种表达方式无论选哪条路线都要面对同一个问题模型的输出如何表达成机器人能执行的动作。常见有三种表达方式。第一是关节角位置空间直接输出每个电机目标角度信息最完整但维度高、难学第二是末端执行器位姿空间EEF输出手爪的六自由度目标位姿机械臂用逆解换算成关节角这是工业界的常见做法第三是任务级技能模式模型输出“抓取”“放置”“擦拭”这类离散动作加参数由底层系统映射为具体轨迹。三者之间不是互斥的一个成熟系统往往混用。比如 VLA 训练数据里整体任务用技能级标签组织末端动作用 EEF 位姿标注关节角只在实际控制层出现。在准备训练数据时数据集的一条样本通常长这样{ instruction: 把桌上的杯子拿到厨房水槽, observation: { image: camera_top_view_001.jpg, depth: depth_001.npy, robot_state: [0.12, -0.34, 0.56, 0.0, 0.0, 1.0, 0.0] }, action: { type: eef_pose, target: [0.45, -0.12, 0.78, 0.0, 0.0, 0.0], gripper: close } }这份数据设计要注意两点。robot_state是七维向量前三位是末端位置后四位是姿态四元数这是机械臂控制的标准表示action.target同样用 EEF 位姿但实际下发给底层时还要做一次逆解。gripper: close是离散指令控制夹爪开合。如果动作空间里混入了关节角和 EEF 位姿模型会学到混乱的映射关系所以每一条数据的动作类型必须严格一致。5.3 从仿真到真机的“最后一公里”仿真训练是当前具身智能绕不开的一环因为真机数据太贵了。常见做法是在仿真环境里采样大量任务数据再用域随机化domain randomization缩小 sim-to-real gap——随机光照、纹理、物体质量、摩擦力系数让模型在仿真里见到的分布足够宽部署到真机时才不会因为某个材质没见到就表现崩盘。这几年网上流传的具身智能学习路线基本都绕不开仿真到真机迁移这一步。我的经验是仿真里模型成功率要做到 95% 以上再考虑上真机真机成功率通常会打个七到八折如果仿真成功率不到 90% 就急着上真机调试成本会高得离谱。另外真机验证时一定要先跑低速模式确认轨迹规划没有碰撞风险再逐步放开速度上限。6. 一个验证技巧用轨迹完成率读出具身系统的真实水平评估一个具身智能系统只看“任务成功率”是不够的。假设系统在 100 次测试里成功了 60 次这 60 次里有多少次是中途需要人工介入拉回来的有多少次是碰巧抓到了物体但位置不准要回答这类问题需要把评估指标拆到轨迹级别。轨迹完成率Trajectory Success Rate的定义是一条任务轨迹被完整执行、没有丢失关键步骤、且最终状态满足判定条件的比例。和它配合使用的是阶段完成率——把轨迹切成多个关键点统计每个关键点的通过率这样能定位失败发生的位置。还有一个被低估的指标是失败模式分布它决定了你下一步该优化什么。def evaluate_episodes(episodes: list, criteria: dict) - dict: phase_success {phase: [0, 0] for phase in criteria[phases]} for ep in episodes: for phase in criteria[phases]: phase_success[phase][1] 1 if ep[phase] and ep[phase][passed]: phase_success[phase][0] 1 # 轨迹完成率要求所有阶段都通过且无人工干预 completed all(ep[p][passed] for p in criteria[phases]) and not ep[human_rescue] ep[trajectory_success] completed traj_rate sum(e[trajectory_success] for e in episodes) / len(episodes) return { trajectory_success_rate: round(traj_rate, 3), phase_completion: {k: round(v[0] / v[1], 3) for k, v in phase_success.items()}, failure_modes: count_failure_modes(episodes) }这个脚本的核心思路是把一次任务执行拆成可审计的阶段。criteria[phases]里通常包含“移动到目标区域”“抓取成功”“到达放置点”“释放成功”这样的关键节点每个节点由传感器信号或人工标注判定。human_rescue字段标记了是否有人类介入——这一点很重要因为很多系统表面成功实际上是人在关键节点推了一把。当轨迹完成率和阶段完成率出现明显落差时哪个阶段拉垮了一目了然失败模式分布则告诉你瓶颈是抓取精度、路径规划还是任务理解直接决定下一步改感知还是改大模型 prompt。本文还有配套的精品资源点击获取 具身智能与大模型：机器人从感知到执行的三层架构解析
简介哈尔滨工业大学社会计算与信息检索研究中心出品的《大模型时代的具身智能》PDF报告面向人工智能、机器人方向的研究者与学习者系统梳理“大模型机器人”如何走向真正智能。报告从公元前9世纪偃师机器人、公元前4世纪蒸汽驱动鸟、达·芬奇人形草图讲到Unimate、KUKA等工业机器人再延伸至WABOT-1、ASIMO、Atlas等类人机器人同时结合符号推理、专家系统、机器学习到深度学习的演进说明人工智能算法如何让机器人在视觉、语音、自然语言处理等领域能力增强。资源重点拆解了智能机器人的双能力定义——自主能力与泛化能力并给出具身感知、具身推理、具身执行三部分构建路径。资源共1个PDF约12.23MB已有185人学习适合作为具身智能入门与前沿追踪的专题讲义帮助读者快速建立从机器人发展史到大模型赋能实体智能的完整认知框架。1. 大模型入场之前机器人最缺的从来不是硬件先抛一个反直觉的结论具身智能真正的瓶颈不在关节电机、灵巧手或者液压驱动而在于机器人不知道“接下来该做什么”。1961 年的 Unimate 已经能堆叠金属但它在 2024 年仍然只会堆叠金属问题不是手不够巧而是脑子没有跟上。大模型时代把这件事彻底改变了——语言模型和视觉模型第一次让机器人能理解场景、拆分任务、生成动作序列而不只是沿着预编程轨迹重复。这篇内容梳理了哈工大社会计算与信息检索研究中心关于具身智能的报告从机器人发展史讲到感知、推理、执行三层架构适合正在做机器人算法、想从传统控制转向学习路线或者准备投入具身智能方向的研究生和工程师。2. 从 WABOT-1 到 Atlas机器人演进里的三笔技术遗产2.1 “人形”不是表演而是环境适应性的结果报告里对类人机器人这条线梳理得很清楚1972 年日本早稻田大学推出 WABOT-1这是世界第一台全尺寸人形机器人行走一步需要 45 秒步伐只有 10 公分。今天看这个数字很寒碜但它证明了一件事——双足动态平衡是可以被机电系统复现的。到了 2000 年的 ASIMO本田经过数次迭代已经掌握了双足奔跑、搬运托盘、上下楼梯2008 年 Aldebaran 的 NAO 把小型人形机器人做成了教学和陪伴工具2013 年波士顿动力的 Atlas 则把运动控制推到了新高度跑跳、后空翻、越野行走都不在话下。这一百年的演进有一个清晰的趋势硬件能力在飞速逼近人类但“该做什么”的判断能力始终落后。WABOT-1 能走路但它不知道为什么要走ASIMO 能上下楼但它不知道楼梯尽头有什么。报告在这里点出了一个关键判断——运动控制型机器人解决的是“怎么动”而智能机器人必须回答“为什么动”和“动完之后怎么办”。2.2 从固定轨迹到可编程自主工业机器人补上的第二课工业侧的时间线同样值得梳理。1961 年的 Unimate 是第一台工业机器人本质上是可编程的机械臂按预定轨迹重复作业1973 年 KUKA 推出的 FAMULUS 是第一台拥有六个机电驱动轴的工业机器人六轴的引入让末端执行器可以到达空间任意位姿这是“手”的自由度基础。更关键的是FAMULUS 具备了一定的自主性——编程后可以自主运行、自主判断和决定接下来的操作。把这两条线放在一起看会发现机器人产业的早期积累其实分成了两个方向一条卷运动能力一条卷工业可靠性。但它们有一个共同的隐含假设——任务空间是预先知道的机器人在封闭环境里执行有限动作集合。医疗微创机器人、物流运输机器人、展厅服务机器人、家庭清洁机器人本质上延续了这个思路只是把应用场景从工厂扩展到了生活空间。问题在于这些机器人的“智能”是枚举出来的场景一变就失效这正是报告里强调的“泛化能力”缺失。2.3 四十年真正留下的遗产传感器与运控先于大脑成熟回顾这段历史我认为对当前做具身智能最有价值的不是某个机器人的运动表现而是一个容易被忽略的事实——传感器和运控系统已经先于大脑成熟了。触觉信号、力反馈信号、位姿信号、2D 视觉与 3D 点云信号这些硬件接口在今天已经是标准配置精度和稳定性都能满足实际需求。换句话说具身智能缺的从来不是“身体”的传感器而是把这些异构信号统一理解、统一决策的“小脑之上的大脑”。年代代表机器人关键能力对具身智能的贡献1972WABOT-1全尺寸人形、双足行走验证机电系统可复现人类运动2000ASIMO双足奔跑、上下楼梯运动控制与动态平衡的工程化标杆2008NAO小型教学陪伴人形人机交互场景的规模化探索2013Atlas跑跳、复杂地形运动运动能力的天花板反衬智能缺口这张表的阅读方式不是“看谁的功夫好”而是看“运动能力到达某个水位之后下一步该补什么”。Atlas 的运动能力已经远超大多数人类但它的每一次跳跃仍然需要人为指定目标点。身份从“遥控的机器”变成“自主的智能体”转折点不发生在关节而发生在决策。3. 具身智能的三层架构具身感知、具身推理与具身执行3.1 具身感知不是“识别画面”而是融合多模态状态报告给智能机器人下了一个操作性的定义具备自主能力即尽可能少地需要人类干预同时具备泛化能力即能应对复杂场景和多样任务。要做到这两点第一步是感知。但具身感知和 CV 里的图像识别不是一回事——机器人需要同时收集环境信息和自身状态而且这些信息来自完全不同的传感器模态。通常的系统会包含这样几路信号2D 视觉信号或 3D 点云信号用于理解外部环境语音信号用于接收人类指令触觉信号或力反馈信号用于判断接触状态位姿信号用于估计自身在空间中的位置和朝向。这里的难点不是单模态识别精度而是多模态对齐——摄像机看到“桌上有咖啡渍”力传感器感受到“抹布已经接触到桌面”IMU 告诉“手臂当前在什么姿态”这三个信息必须在同一个时间戳下被综合理解才能支撑后续的推理。这里有一个在工程里常见的误区很多人把感知模块做成一个黑盒分类器输出“桌子”“杯子”“抹布”这样的标签就结束了。但在具身智能系统里感知的结果要服务于动作光有类别标签不够还需要物体的位姿、朝向、可交互性、抓取点位置。我一般会在感知层保留几何信息而不是只保留语义信息把 2D 检测结果投影到 3D 点云上得到物体的六自由度位姿后面的抓取规划才有的放矢。3.2 具身推理从“这是什么”到“接下来做什么”报告里用了一个很具体的例子来展示具身推理的执行过程机器人通过视觉传感器采集到桌上有咖啡洒了系统分析出“应对咖啡进行清理”然后生成一个任务清单——扶正杯子并拿起杯盖、找到抹布、用抹布擦拭地面、将抹布放回、最后将杯子和杯盖扔掉。这个例子看起来简单但它包含了具身推理的两个关键层级。第一层是任务规划从“清理咖啡”这个抽象目标分解出有序的子步骤这要求系统理解“先扶正杯子再拿盖”这样的因果约束——如果先拿盖杯子可能继续倾倒。第二层是运动规划把“拿起杯盖”这个子任务映射为具体的运动轨迹包括手臂如何运动、手掌如何运动、腿部如何运动。前者是大模型擅长的事后者是传统机器人控制擅长的事两者的接口设计是具身智能系统架构的核心问题。具体来说任务规划层可以依赖大模型的常识推理能力因为“咖啡洒了需要擦”这类知识不需要物理接触就能获得。但运动规划层不能脱离机器人本体——同一个任务六轴机械臂和双足人形机器人的实现方式完全不同。所以在落地时我倾向于把推理层输出为中间表示而不是直接输出关节角比如“抓取杯盖目标位姿 x, y, z, roll, pitch, yaw”这样的技能级指令再去匹配具体的运控模块。3.3 具身执行指令必须向下位机翻译成关节目标推理层产出的是任务序列执行层要把它翻译成下位机能接受的形式。报告中把执行指令概括为三种形式代码、技能库 API、关节旋转角度。这三者的抽象层级是递减的——代码和 API 是面向任务的关节角是面向硬件的。在真实系统里我会让大模型优先输出技能库 API 调用因为这样安全性可控也便于回退到人工处理当技能库里没有匹配项时才退化为关节角直接控制。下面是一个典型的执行层调度逻辑的伪代码示意def execute_task(task_sequence: list, robot_api: RobotAPI) - bool: success True for step in task_sequence: print(f[EXEC] 执行步骤: {step[action]}, 目标: {step[target]}) # step[action] 是技能名, 例如 grasp, wipe, place # step[target] 是技能参数, 例如物体名称或目标位姿 if step[action] in robot_api.skills: ok robot_api.call_skill(step[action], step[target]) else: # 技能库无匹配时, 用低层级控制接口下发关节角轨迹 trajectory robot_api.plan_joint_trajectory(step[target]) ok robot_api.execute_trajectory(trajectory) if not ok: print(f[EXEC] 步骤失败: {step[action]}, 终止任务) success False break return success这段代码的核心设计思路是双通道下发优先走技能库 API技能库缺失时降级到关节轨迹规划。task_sequence是推理层输出的事件序列每个事件包含动作名和参数robot_api.skills是预置的技能集合比如 grasp、wipe、place 这类原子操作plan_joint_trajectory依赖运动学逆解把目标位姿换算成关节角度序列。这个设计的优点在于大模型的输出被限制在技能词表内不会凭空产生非法指令而技能库的安全边界又比端到端输出关节角容易验证得多。4. 大模型在具身智能里的真实角色被低估的接口层4.1 大模型之前AI 一直隔着屏幕报告对人工智能的发展脉络做了一个高度浓缩的概括1956 年到 60 年代初用符号推理做数学证明60 到 70 年代初启发式搜索算法能力有限70 到 80 年代中专家系统处理医疗、化学、地质等特定领域80 年代中到 90 年代中专家系统需要海量专业知识实用价值受限90 年代中到 2010 年机器学习处理实际问题2011 年之后深度学习用于图像、文本、语音2022 年之后出现可以处理通用任务的大模型。这条脉络里最值得注意的不是某个算法的兴衰而是一个持续存在的结构性缺口——AI 始终停留在电脑屏幕里没有以实体的方式进入物理世界。图像识别模型能看到一张猫的照片但它碰不到猫对话模型能回答“如何擦桌子”但它不知道桌子的材质、抹布的位置、手臂伸过去会不会撞到杯子。具身智能要补的正是这个缺口让模型不仅“知道”世界而且“作用于”世界。4.2 大模型解决的不是“控制”而是“对齐”机器人从不缺控制算法缺的是把传感器数据和人类意图对齐到同一个语义空间的能力。传统架构里检测模型输出类别和 2D 框机械臂用规划算法去抓取这两者之间的转译靠工程师手写代码硬接每个新任务都要重新写一遍胶水逻辑。大模型时代的多模态模型可以把图像、文本、位姿信息统一编码直接从“视觉观察到咖啡洒了”跳到“应该执行清理动作”。这个变化的意义在于大模型承担了传统架构里属于工程师的接口编写工作。输入是视觉特征和语言指令输出是结构化的任务描述——这一层不需要手写规则而是从大规模预训练中习得。很多人质疑大模型输出不可靠这是事实但对于具身智能来说大模型的意义不在于输出百分之百正确而在于把任务的假设空间从“工程师能枚举的”扩展到了“模型见过的”。4.3 人机交互的升级从编程到自然语言对话报告里有一句话值得反复读智能机器的自主能力追求“尽可能少的人类干预”而不是完全不需要人类。这意味着人机交互接口本身就是系统设计的一部分。传统机器人编程需要工程师写代码或拖拽示教器而大模型时代可以直接用自然语言描述任务目标机器人生成执行方案后由人确认或修正。# 自然语言到任务序列的转换示意: 假设有 LLM 服务接口 def plan_from_instruction(instruction: str, visual_state: dict) - list: # visual_state 包含当前环境的物体列表、位姿、可交互性 prompt f场景中有: {visual_state}. 任务: {instruction}. 请输出步骤序列。 # 调用 LLM 得到 JSON 格式步骤列表 steps llm_plan(prompt, temperature0.2) # 低温减少随机性 return validate_and_constrain(steps) # 检查动作词是否在技能库内这里的temperature0.2是一个值得记住的参数任务规划任务里我们不想让模型发挥创造力需要的是稳定的、可复现的步骤序列所以温度要压低而如果是让模型提出多种可行方案才需要把温度调高到 0.7 以上。validate_and_constrain的作用是把模型输出的自由文本映射到受控的技能词表里这一步是安全兜底不能省。5. 可落地的实现路线VLA 与动作空间设计5.1 具身智能 agent 的两条技术路线把“具身智能 agent”拆开看要决策两个问题用什么模型做决策动作以什么形式离开模型。当前主流落地方案有两条路线。第一条是把语言模型当大脑感知模块和运动模块独立存在模型负责从视觉语言输入生成任务序列再由底层的运动库执行——本质上就是前面 3.3 描述的架构。第二条是视觉语言动作模型VLA把感知、推理、动作输出压缩进一个端到端模型输入图像和文本指令直接输出动作信息代表工作有 RT-2、PaLM-E 这一脉。维度语言模型规划 运动库VLA 端到端模型任务分解强依赖 LLM 常识中等需要数据学习动作精度高运动库精调取决于训练数据质量数据需求少量任务指令数据海量机器人轨迹数据可解释性高中间有任务序列低端到端黑盒扩展新技能快加技能库 API 即可慢需要重训或微调适合场景结构化环境、已知技能集合开放环境、技能难以枚举从工程落地角度看我建议优先走第一条路线因为技能库方案每个环节都可以单独调试感知错了改感知规划错了改 prompt运控错了改轨迹生成。VLA 端到端方案虽然优雅但出了问题很难定位——输出一个错误的关节角你不知道是视觉误解了场景还是推理选了错策略还是动作头拟合出了问题。5.2 动作空间的三种表达方式无论选哪条路线都要面对同一个问题模型的输出如何表达成机器人能执行的动作。常见有三种表达方式。第一是关节角位置空间直接输出每个电机目标角度信息最完整但维度高、难学第二是末端执行器位姿空间EEF输出手爪的六自由度目标位姿机械臂用逆解换算成关节角这是工业界的常见做法第三是任务级技能模式模型输出“抓取”“放置”“擦拭”这类离散动作加参数由底层系统映射为具体轨迹。三者之间不是互斥的一个成熟系统往往混用。比如 VLA 训练数据里整体任务用技能级标签组织末端动作用 EEF 位姿标注关节角只在实际控制层出现。在准备训练数据时数据集的一条样本通常长这样{ instruction: 把桌上的杯子拿到厨房水槽, observation: { image: camera_top_view_001.jpg, depth: depth_001.npy, robot_state: [0.12, -0.34, 0.56, 0.0, 0.0, 1.0, 0.0] }, action: { type: eef_pose, target: [0.45, -0.12, 0.78, 0.0, 0.0, 0.0], gripper: close } }这份数据设计要注意两点。robot_state是七维向量前三位是末端位置后四位是姿态四元数这是机械臂控制的标准表示action.target同样用 EEF 位姿但实际下发给底层时还要做一次逆解。gripper: close是离散指令控制夹爪开合。如果动作空间里混入了关节角和 EEF 位姿模型会学到混乱的映射关系所以每一条数据的动作类型必须严格一致。5.3 从仿真到真机的“最后一公里”仿真训练是当前具身智能绕不开的一环因为真机数据太贵了。常见做法是在仿真环境里采样大量任务数据再用域随机化domain randomization缩小 sim-to-real gap——随机光照、纹理、物体质量、摩擦力系数让模型在仿真里见到的分布足够宽部署到真机时才不会因为某个材质没见到就表现崩盘。这几年网上流传的具身智能学习路线基本都绕不开仿真到真机迁移这一步。我的经验是仿真里模型成功率要做到 95% 以上再考虑上真机真机成功率通常会打个七到八折如果仿真成功率不到 90% 就急着上真机调试成本会高得离谱。另外真机验证时一定要先跑低速模式确认轨迹规划没有碰撞风险再逐步放开速度上限。6. 一个验证技巧用轨迹完成率读出具身系统的真实水平评估一个具身智能系统只看“任务成功率”是不够的。假设系统在 100 次测试里成功了 60 次这 60 次里有多少次是中途需要人工介入拉回来的有多少次是碰巧抓到了物体但位置不准要回答这类问题需要把评估指标拆到轨迹级别。轨迹完成率Trajectory Success Rate的定义是一条任务轨迹被完整执行、没有丢失关键步骤、且最终状态满足判定条件的比例。和它配合使用的是阶段完成率——把轨迹切成多个关键点统计每个关键点的通过率这样能定位失败发生的位置。还有一个被低估的指标是失败模式分布它决定了你下一步该优化什么。def evaluate_episodes(episodes: list, criteria: dict) - dict: phase_success {phase: [0, 0] for phase in criteria[phases]} for ep in episodes: for phase in criteria[phases]: phase_success[phase][1] 1 if ep[phase] and ep[phase][passed]: phase_success[phase][0] 1 # 轨迹完成率要求所有阶段都通过且无人工干预 completed all(ep[p][passed] for p in criteria[phases]) and not ep[human_rescue] ep[trajectory_success] completed traj_rate sum(e[trajectory_success] for e in episodes) / len(episodes) return { trajectory_success_rate: round(traj_rate, 3), phase_completion: {k: round(v[0] / v[1], 3) for k, v in phase_success.items()}, failure_modes: count_failure_modes(episodes) }这个脚本的核心思路是把一次任务执行拆成可审计的阶段。criteria[phases]里通常包含“移动到目标区域”“抓取成功”“到达放置点”“释放成功”这样的关键节点每个节点由传感器信号或人工标注判定。human_rescue字段标记了是否有人类介入——这一点很重要因为很多系统表面成功实际上是人在关键节点推了一把。当轨迹完成率和阶段完成率出现明显落差时哪个阶段拉垮了一目了然失败模式分布则告诉你瓶颈是抓取精度、路径规划还是任务理解直接决定下一步改感知还是改大模型 prompt。本文还有配套的精品资源点击获取