简介：这份报告为哈尔滨工业大学社会计算与信息检索研究中心出品的《大模型时代的具身智能》，面向人工智能与机器人领域研究者、开发者及对具身智能感兴趣的技术爱好者。报告从公元前九世纪偃师造人的典故讲起，梳理机器人从早期装置、工业机械臂到类人机器人的演变，并结合人工智能从符号推理、专家系统、机器学习到深度学习与大模型的发展脉络，尝试回答“大模型是否能让机器人真正智能”。内容涵盖智能机器人的自主性与泛化能力，如医疗、物流、展厅、家庭清洁等场景，也介绍了WABOT-1、ASIMO、NAO、Atlas等典型机器人，还展开具身感知、具身推理、具身执行等构建智能机器人的关键环节，并以清理咖啡为例说明完整交互流程。资源为单份PDF文档，共1个文件，压缩包大小约12.23MB，阅读清晰，目前已有185人学习下载，适合快速掌握大模型时代具身智能的整体框架与核心概念。
1. 大模型时代的具身智能：为什么“有脑”不等于“智能”
哈工大社会计算与信息检索研究中心的这份《大模型时代的具身智能》报告，最值得读的不是“大模型”三个字，而是那个关于“机器人能不能真正智能”的追问。报告里反复出现一个等式：机器人＋人工智能≈人类。注意是约等于，不是等于。我在拆这份材料时最大的感受是，硬件层面——高精度传感器、双足平衡、机械臂运控——已经相当成熟，真正卡住整个行业的是“综合分析当前状态并决定下一步做什么”这一层。报告用“清理咖啡”的例子把这个链路讲得极清楚：机器人先看到桌上有洒落的咖啡，再规划出扶正杯子、找抹布、擦地、放回抹布这几步，最后生成手臂和腿部的运动轨迹。这份报告非常适合两类人：刚入行想建立具身智能学习路线的新手，以及想判断“大模型能否接管机器人决策层”的技术负责人。它不教你调参，但能帮你在动手之前先想清楚系统边界。
2. 从偃师到Atlas：机器人定义与智能路线演进
2.1 智能机器人的两个硬指标：自主能力与泛化能力
报告对智能机器人的定义很精简：自主能力，即在尽可能少的人类干预下运行；泛化能力，即应对复杂场景和任务的综合能力。这两个指标放在一起，其实是在挑选“真具身智能”与“伪自动化”的分界线。传统工业机器人，比如1961年的Unimate，能按固定程序堆叠金属件，但换个工件形状、换个摆放角度就要重新编程，这属于“确定场景的自动化”，不满足泛化能力的要求。而21世纪之后出现的医疗微创机器人、物流运输机器人、家庭清洁机器人，开始要同时应对环境扰动和任务变化，才算进入具身智能的讨论范畴。
我看报告里最容易被忽略的一句话是：“机器人＋人工智能≈人类”。这个约等号很讲究——它不是说机器人要全面超越人类，而是指机器人从“工具”切换成了“代理”（agent）这个质变过程。工具的特点是“人给出每一步指令”，代理的特点是“你给它一个高层目标，它自己拆解、自己执行、自己处理异常”。所以判断一个系统是不是具身智能，不用纠结它长不长人形，关键看它被丢进一个没见过的场景时，能不能靠自己完成从感知到行动的闭环。如果只是把几个深度学习模型串在一起，遇到场景变化就僵住，那本质上还是在做自动化，和具身智能没什么关系。
2.2 从WABOT-1到Atlas：四十年人形机器人能力演进
报告按时间线梳理了类人机器人的几个里程碑节点，我把它整理成了下面这张表，方便对照看运动控制和智能决策两条线的进度差距。
| 时间 | 型号 | 研发方 | 代表性能力 | 局限 |
|---|---|---|---|---|
| 1972 | WABOT-1 | 日本早稻田大学 | 世界第一台全尺寸人形机器人，能步行 | 走一步需要45秒，步幅仅10公分 |
| 2000 | ASIMO | 日本本田 | 双足奔跑、搬运托盘、上下楼梯 | 运动能力大幅进步，但决策依赖预设 |
| 2008 | NAO | 法国Aldebaran | 小型教学陪伴人形机器人 | 偏交互展示，物理操作能力有限 |
| 2013 | Atlas | 美国波士顿动力 | 很强的运动控制能力 | 智能决策层尚未打通 |
这张表最有价值的点是“隐含的断层”：从WABOT-1到Atlas，进步集中在“怎么动”的问题上——平衡、步态、跑跳、抗扰动。但到了Atlas时代，波士顿动力自己也承认，难点已经不再是运动控制，而是“机器人不知道为什么要做这些动作”。报告原文点了一句：“新的关注点：机器人智能。”这句话放在2024年的语境里翻译一下就是：硬件这条腿已经走得很远，决策这条腿还停在原地。早年大家觉得机器人智能是运动控制的副产品，后来发现跑得再稳也不等于知道该往哪儿跑，这正是大模型出现的意义所在。
2.3 硬件的账已经算清，缺的是“大脑”
报告里有一句很直白的判断：“我们已经能造出具备基本性能的机器人硬件和高精度的传感器。”这句话基本可以看作给硬件领域定了调——不是说不该继续优化，而是说从系统集成的角度，硬件已经不再是主要瓶颈。2D视觉或3D点云信号、语音信号、触觉或力反馈信号、位姿信号，这些传感器模块都有成熟产品可用，机器人躯体的自由度、关节电机、减速器这些核心部件也都有了商用方案。
真正的缺口在哪儿？报告指出，在“收集所有传感器信息之后”——机器人需要把视觉、语音、触觉、位姿融合成一个完整的“当前状态”理解，然后基于这个理解对下一步运动做决策和规划。这一步在报告里叫具身推理，本质上是要让机器人在物理世界里建立“场景图”和“任务链”。这类问题恰恰是传统机器人学不擅长、而大模型天然具备一定能力的事情。我个人的判断是，未来两三年内具身智能项目的主要工作量，会从机械结构设计和底层运动控制，转移到“怎么把大模型的推理能力稳定地接到机器人执行链路里”。这也是读了这份报告之后最值得关注的技术方向。
3. 具身智能三段式架构：感知、推理、执行如何串起来
3.1 具身感知：不是拍照识别，而是状态融合
报告把机器人接收外部信息的通道拆成了五类：2D视觉信号或3D点云信号、语音信号、触觉信号或力反馈信号、位姿信号，以及环境自身的状态信号。这里要注意，具身感知和单纯的AI视觉识别有个本质区别——视觉识别是“这张图里有什么物体”，具身感知是“我现在处在什么状态、这个状态是否需要我干预”。报告里的清理咖啡案例就是典型：视觉模块检测到桌上有洒落的咖啡，这是目标检测的结论；但“咖啡洒了需要清理”这个判断，需要把液体位置、杯子的倾倒状态、周围有没有抹布这些信息合并起来才得出来。
我在实际项目里常见的做法是，把感知层的输出做成一个“场景状态描述”，而不是一堆零散的检测框。比如视觉模块输出“桌面（x:1.2,y:0.8）区域检测到液体，°杯盖脱落”，力觉模块输出“机械爪未受力”，位姿模块输出“机器人当前位于餐桌正前方0.5米”。这些信息合并到一个统一的状态结构里，供推理层使用。感知层的设计要点是“对齐”：不同传感器的时间戳要同步，坐标系要统一，否则到了推理层会出现“视觉说杯子在左边，但机械臂按右边去抓”的尴尬情况。报告里说的“综合分析当前所有状态”，落到工程上就是这一步。
3.2 具身推理：从高层目标到可执行任务序列
具身推理是整份报告的核心段落，也是清理咖啡案例最有参考价值的部分。机器人通过视觉发现桌上有洒落的咖啡之后，推理层要做的事是：先得出“应该清理咖啡”这个结论，然后把清理这个高层目标分解成一个有序的动作序列。报告列举的序列是：扶正杯子并拿起杯盖、找到抹布、用抹布擦拭地面、将抹布放回、将杯子和杯盖扔掉。这里面有个容易被忽视的设计思想——推理层输出的不是关节角度，而是“技能级”的指令。每个技能项都对应一个预先实现好的原子操作，推理层只负责编排和选序。
大模型在这个环节的优势就很明显了：它能把“清理咖啡”这个高层目标，拆成一个符合物理世界常识的动作列表。但这里也有个工程前提：你必须在推理层之外建立技能库（skill library），也就是告诉大模型“机器人会做哪些动作”，它只能在已知技能里挑选组合，而不是自由发挥。我习惯把技能库用JSON定义为机器可读的清单，每个技能标注输入参数和前置条件，比如“扶正_cup”需要机械臂可用、“查找_cloth”需要视觉模块可用。推理层只负责从技能库里选出合理的序列，不负责发明新动作，这样既能发挥大模型的泛化能力，又能约束它在物理可行的范围内做规划。
3.3 具身执行：指令怎么下发，运控怎么接管
报告把执行层的角色描述为“下位机通过运控技术执行指令”，并列举了指令的几种形式：代码、技能库API、关节旋转角度。这三者的抽象层级是递减的：技能库API最高层，直接说“扶正杯子”；中间层是代码片段，描述一段连贯动作；最底层是关节角度，直接控制电机转动。从工程角度看，三条路径各有各的适用场景。技能库API适合大模型输出后的快速映射，响应快、可控性强；代码片段适合处理需要动态计算的轨迹；关节角度适合底层调试，不适合做高层规划的输出格式。
我一般会建议团队把执行链路拆成“大脑—小脑”两层。大脑指大模型和推理规划模块，负责出任务序列；小脑指运控系统，负责把任务指令转换成具体的关节轨迹并实时调节平衡。这样拆的好处是，大模型不会直接控制电机，它的输出即使有延迟，也不会造成物理上的危险；小脑部分继续用传统机器人学的控制方法，保证稳定性。报告里说的“向下位机下发送运动指令”，本质就是一套大脑和小脑之间的通信协议。近两年行业里常说的“具身智能操作系统”，做的事情也差不多——把感知、推理、执行封装成可调度的模块服务，让上层应用能像调用函数一样调用机器人的物理能力。
4. 大模型在具身智能中的定位：从会说话到能干活
4.1 人工智能七十年：每个阶段真正卡住的是什么
报告用一小段历史回顾了人工智能的发展脉络：1956年到60年代初，大家用符号推理做数学证明；60到70年代初，启发式搜索算法能力有限；70到80年代中，专家系统开始在医疗、化学这些特定领域落地；80年代中到90年代中，专家系统暴露了知识获取的瓶颈；90年代中到2010年，机器学习接管了实际问题；2011年之后深度学习全面铺开；2022年之后，能处理通用任务的大模型登场。这段历史的价值在于，它揭示了一个规律：每一轮AI技术演进，都是在解决上一轮“卡点”的过程中发生的。
| 阶段 | 代表技术 | 当时解决的核心问题 | 最终卡点 |
|---|---|---|---|
| 1956–1960s | 符号推理、数学证明 | 让机器做逻辑推理 | 搜索空间爆炸 |
| 1960s–1970s | 启发式搜索 | 缩小搜索范围 | 计算能力有限 |
| 1970s–1980s | 专家系统 | 沉淀领域知识 | 知识获取与维护成本过高 |
| 1980s–1990s | 专家系统衰落期 | 反思知识工程路线 | 需要海量专业知识 |
| 1990s–2010 | 机器学习 | 从数据中自动学规律 | 特征工程依赖人工 |
| 2011–2022 | 深度学习 | 端到端学习图像/文本/语音 | 数据需求量大，泛化受限 |
| 2022– | 大模型 | 通用任务处理能力 | 物理世界交互缺失 |
4.2 大模型的三个特性：正好打在泛化能力的缺口上
报告对智能机器人的定义里有“泛化能力”这个硬指标，而大模型恰好在这三方面表现出优势。第一是跨任务迁移能力：一个在大规模语料上预训练过的模型，不需要针对“清理咖啡”专门标注训练数据，就能给出合理的任务序列，这在以前的专家系统时代是不可想象的。第二是长上下文理解：机器人面对的场景往往涉及多模态信息——视觉描述、距离估计、物体状态、历史操作记录，大模型可以把这些信息放在同一段上下文里综合判断，相当于一个容量足够大的“工作记忆”。第三是结构化输出能力：只要在提示词里约定JSON格式，模型就能输出机器可解析的任务序列，这把“推理结果”和“执行调度”之间的鸿沟直接填平了。
我自己的体会是，大模型在具身智能里的角色更像是“调度大脑”而不是“知识仓库”。它不需要知道抹布的具体材质，也不需要计算机械臂的逆解，那些东西由技能库和运控系统去管。它要做的是在高层目标与可用技能之间搭一座桥：给定当前场景，从技能库里选出最合理的执行序列，并对异常情况做出应对。这个定位把大模型限制在它擅长的范围内——语言理解和任务规划——同时避开它不擅长的实时控制和精确定量计算。
4.3 大模型的物理边界：幻觉、时延与不可解释
大模型在具身推理里有三个绕不开的边界。第一个是幻觉问题：模型可能基于上下文“合理猜测”出场景里不存在的物体，比如报告里没提到的“水槽在厨房右侧”，一旦模型把这些编造的实体写进任务序列，执行层就会去找一个不存在的东西。缓解手段是在提示词里加约束，推理层只允许使用感知层显式给出的物体名称，禁止自行引入新实体。第二个是响应延迟：本地部署的7B模型一次推理可能要几百毫秒到几秒，这个速度做高层任务规划没问题，但做不了高频反馈控制；所以架构上必须保证大模型只出“任务级”指令，不介入毫秒级的运控循环。第三是不可解释性：模型给出的任务序列没有“为什么这么排序”的可靠依据，这在安全相关的场景里是很大的风险。
所以报告通篇想表达的技术判断其实很清晰：大模型不是用来替代机器人原有系统的，而是作为新增的“决策规划层”插入感知与执行之间的。它给出的定位不是“把大模型装进机器人”，而是“用大模型把机器人已有的能力编排起来”。谁先想清楚这条边界，谁就能少走弯路。
5. 具身智能避坑指南：五个最容易翻车的环节
5.1 坑一：感知识别正确，但物理状态没对齐
现象：视觉模块准确识别出桌上有杯子、有咖啡污渍，但机器人伸手去扶杯子时，机械臂的轨迹和杯子的实际位置偏差很大，甚至撞倒杯子。
原因：感知层和规划层之间缺少“状态对齐”环节。视觉检测出来的是一个像素坐标或2D框，而机械臂规划需要的是世界坐标系下的三维位置，中间缺了一个坐标映射；或者传感器时间戳不同步，图像里杯子的位置是100毫秒前的，机器人按这个位置去抓当然对不上。
解决：在感知输出和推理输入之间加一个状态融合模块，把视觉检测结果、深度点云、位姿信息统一到机器人基座坐标系下，并做时间对齐。我通常的做法是定义一个统一的PerceptionState结构，所有传感器数据都转成这个结构再往上层送，推理层永远只读融合后的状态，不直接读原始检测结果。
5.2 坑二：大模型任务分解“看着合理”，实际不可执行
现象：大模型输出的任务序列是“扶正杯子→拿起杯盖→找到抹布→擦拭桌面→放回抹布”，每一步单独看都没问题，但机器人卡在“拿起杯盖”这一步——因为技能库里根本没有“拿起”这个技能，只有“抓取”和“放置”。
原因：推理层对自身能力边界缺乏约束。大模型从通用语料里学到了大量动作词汇，但机器人的技能库是有限的，模型很可能输出一个技能库里不存在的动作名称，或者输出一个参数类型不匹配的调用。
解决：把技能库以显式清单的形式写进提示词，并且要求模型只能从清单中选择技能。同时在推理输出后加一道校验逻辑，分解出的每个技能必须能在技能库里匹配到，否则丢弃并重新调用一次模型。我在第6章会给出这个校验逻辑的代码示例，这一步看起来简单，但能避免一半以上的线上翻车事故。
5.3 坑三：只验证了推理，没验证闭环
现象：演示时大模型成功给出了正确的任务序列，展示效果很好，但一到真实环境，机器人执行到第三步就卡住了，整个流程走不通。
原因：把“推理正确”当成了“系统正确”。具身智能是一个闭环系统，推理只是其中一个环节，感知的误差、执行的偏差都会在闭环里被放大。推理层规划了五步动作，其中任何一步因为物理原因没执行到位，后续动作就全乱套了。
解决：在做demo之前，先明确这条闭环的验证指标。至少要有三个层面的测试：感知层能不能在目标场景稳定输出正确状态；执行层能不能按指令完成动作并返回完成信号；推理层在感知和执行都正常时，能不能持续给出正确任务序列。三层都过了再合起来跑端到端，否则出了问题根本定位不到是哪一层掉了链子。
5.4 坑四：把大模型API直接接进实时控制链路
现象：机器人已经通过目标检测确认了物体位置，正准备抓取，但大模型推理耗时才几百毫秒，控制循环等不及，导致机械臂动作滞后甚至抖动。
原因：有的团队为了“引入大模型”，直接把模型调用写进了实时控制循环里，每做一个动作就请求一次大模型。大模型的响应速度天然做不到实时，毫秒级的控制周期被拉长到秒级，整个系统就退化成了“慢速脚本执行”。
解决：架构上强制分层。大模型只处理“事件级”决策，比如“检测到咖啡洒了，规划清理序列”；一旦任务序列确定，就把它下发到执行层，由运控系统在毫秒级周期内完成动作。高层规划不需要实时，底层执行不允许被大模型拖慢，这是具身智能系统设计的基本原则。
5.5 坑五：demo阶段就忽略安全与标准
现象：端到端demo跑通了，但机器人执行任务的边界条件完全没定义——比如在人类靠近工作区域时，系统没有任何减速或急停机制；执行动作的力度、速度上限也没有约束。
原因：demo阶段的关注点都在“能不能跑通”上，很少有人认真考虑“跑通了之后，怎么保证不出事故”。具身智能机器人和纯软件应用不一样，它的动作直接影响物理世界，一旦失控就是真实伤害。行业里从2024年开始密集讨论《人形机器人与具身智能标准体系》这类文件，本质就是在给这些边界条件补课。
解决：即使是实验室demo，也要在架构里预留安全开关。至少做到两点：一是在技能库里定义最大速度、最大力矩阈值，执行层超限自动停止；二是保留人工急停通道，大模型规划的任务序列在进入执行层之前，允许操作人员一键否决。这个习惯越早养成，后面做产品化的时候越省事。
6. 进阶复现：把一个具身智能案例跑通的最小方案
聊到这里，报告里的理论脉络其实已经很清楚了。接下来我想给一个能真正跑起来的路径：拿“清理咖啡”这个案例，用最小代价复现一个具身智能闭环的demo版本。不需要真机器人，也可以先用仿真环境代替，但决策链路和真实系统保持一致。这个方案适合拿来验证“大模型做任务分解”这个核心环节。
先看整体流程：感知模块输出场景描述，大模型基于场景描述和技能库生成任务序列，校验模块过滤不可执行项，最后输出一份规整的指令表。下面这段代码实现了核心调度逻辑：
# 技能库定义：只允许大模型从这些技能里做选择 SKILL_LIBRARY = { "grasp": {"params": ["object"], "requires": ["arm_available"]}, "place": {"params": ["object", "position"], "requires": ["arm_available"]}, "find": {"params": ["object"], "requires": ["vision_available"]}, "wipe": {"params": ["surface"], "requires": ["cloth_gripped"]}, "locate": {"params": ["object"], "requires": ["vision_available"]}, } # 感知模块输出，实际项目中由视觉/点云管线生成 perception_result = { "scene": "桌面有洒落咖啡，杯子侧倒，杯盖在杯子旁边，抹布在左侧抽屉里", "objects": ["cup", "lid", "cloth"], "layout": {"cup": "table_center", "lid": "table_right", "cloth": "left_drawer"} }这段代码定义了整个系统的骨架。SKILL_LIBRARY是机器人的能力边界，感知输出是物理世界的快照。大模型的任务就是把“场景”映射成“技能序列”，并且只能使用定义好的技能名，参数也只能从感知结果里取。接下来是调用大模型做任务分解的部分，我习惯用本地部署的Ollama来跑，避免把真实控制链路依赖在公网API上：
# 调用本地大模型生成任务序列 import requests, json def ask_llm_for_plan(scene_desc: str, skill_keys: list) -> str: prompt = f""" 你是一个机器人任务规划器。给定场景描述和可用技能，输出任务序列。 场景: {scene_desc} 可用技能（只能选这些）: {skill_keys} 规则: 参数只能引用场景中出现的物体；输出JSON数组，格式为 [{{"skill": "技能名", "params": {{"object": "物体名"}}}}] """ resp = requests.post( "http://localhost:11434/api/generate", json={ "model": "qwen2.5:7b", "prompt": prompt, "stream": False, "format": "json", }, timeout=60, ) return resp.json()["response"]这里注意几个参数：Ollama默认监听11434端口；stream设为False表示关闭流式输出，直接拿完整结果；format="json"是让模型尽量按JSON结构返回，降低解析出错率；模型名换成你本地部署的任何模型都行，不一定用qwen2.5。大模型返回后，还要加一道硬校验，把不在技能库里的输出全部拦下来：
def validate_plan(raw_plan: str) -> list: plan = json.loads(raw_plan) valid = [] for step in plan: skill = step.get("skill") if skill not in SKILL_LIBRARY: print(f"[WARN] 技能不存在: {skill}") continue # 检查参数是否引用了场景中不存在的物体 for k, v in step.get("params", {}).items(): if v not in perception_result["objects"] and v not in ["table", "drawer"]: print(f"[WARN] 引用了未知物体: {v}") continue valid.append(step) return valid这段校验逻辑是血泪经验换来的——大模型生成的序列十次里至少有两次会编造物体或技能名，不校验直接下发，执行层必翻车。我把校验放在生成之后、执行之前，本质上相当于给大模型加了一道“物理可行性”过滤网。跑完这个流程，你手里会得到一份从感知到任务序列的完整闭环代码，替换掉perception_result里的场景数据，就能把同一个流程迁移到其他具身智能任务上。
最后说一个我自己的习惯：从那以后，每次搭具身智能方案，我都强制先跑一遍感知—推理—执行的闭环验证，再谈优化。先确保每个环节都能稳定输出，再考虑用更好的模型、更快的推理。这份报告给我最大的启发不是某个具体算法，而是“先把系统边界画清楚，再往里面填技术”的做事顺序。希望帮到你。
本文还有配套的精品资源，点击获取
