1. 具身智能的大脑焦虑已经持续太久了这两年只要聊到人形机器人舆论场里几乎有一个固定剧本先感慨LLM多聪明再断言只要把大模型的大脑塞给机器人它就能自己叠衣服、做饭、开门。说实话我在实机上调试过机械臂之后对这种论调越来越警惕。倒不是说大模型没用而是给机器人装一个大模型这个动作本身跟让机器人在真实物理世界里可靠地做事之间隔着一层被很多人刻意忽略的系统工程。先说一个最基础的任务让机器人把桌上的一只红色杯子端起来递到你手边。拆开来看这个任务需要什么第一步听懂把那杯红色的茶拿给我这是语言理解LLM擅长。第二步在画面里找到红色杯子这是视觉检测VLM和检测模型也能干。但第三步机械臂要规划一条不会撞到旁边台灯的轨迹同时根据杯子实际位姿微调末端姿态第四步拿起杯子之后还要边走边实时修正防止茶水洒出来——这两步靠什么呢靠的是高频、低延迟的视觉反馈闭环以及把感知结果转换成空间指令的一套稳定管线。这恰恰是纯大模型最容易出问题的地方。我说句可能冒犯不少人的话具身智能真正的大脑不是单点的大模型而是感知—推理—行动的闭环系统。大模型只负责其中最显眼的推理环节而感知的实时性、行动的稳定性和闭环的控制频率才是决定一台机器人能不能从Demo走上工位的关键。本文就是围绕这个观点把LLM、VLA、LLA、SLIM这些概念逐个拆开再落到实时音视频感知底座这个真实工程节点上聊聊具身智能到底需要哪些东西。2. 从LLM到VLA大模型在机器人身上走了一步好棋但还不够2.1 LLM提供的是语义常识不是物理常识大语言模型是什么这里不赘述了本质是基于Transformer架构在海量文本上做序列预测的模型。它的强大之处在于积累了人类语言的统计规律因此能回答问题、写代码、做规划。但把LLM直接接到机器人上你会立刻发现两个别扭的地方。第一个别扭LLM不知道物理世界。它知道杯子掉地上会碎这个说法但如果你让它在仿真环境里推一个真实杯子它推过去之后杯子到底会不会碎、碎屑飞到哪里LLM完全没有建模能力。很多项目试过让GPT-4直接输出动作参数结果是它经常给出理论上正确但物理上荒谬的指令比如让机械臂以1m/s的速度撞向玻璃杯。第二个别扭LLM的推理速度太慢。以目前GPU上的主流LLM推理来说回复一个token往往要几十甚至几百毫秒。机器人的机械臂控制周期是多少典型情况下100Hz到500Hz也就是一个周期只有2到10毫秒。你让LLM去逐帧决定关节角增量它根本跟不上。这就是为什么LLM直接驱动机器人在落地时会被迫把决策频率降到1Hz以下机器人看起来像得了帕金森——每个动作都是想一下动一下再想一下。2.2 VLA尝试把三件事压进一个模型里VLA全称Vision-Language-Action Model思路很简单粗暴把视觉图像、语言指令和机器人动作输出统一到同一个模型里让模型直接从看到什么听到什么预测应该怎么动。这个方向最有名的代表是谷歌的RT-2和PaLM-E前者直接把机器人的动作表述为文本token序列让模型在预测文本的同一套范式下输出把机械臂末端从(x1,y1,z1)移动到(x2,y2,z2)这样的指令。从学术角度看VLA确实解决了多模态输入到动作输出的端到端问题。它不再是让视觉模型和语言模型各干各的、中间靠人写接口对接而是让模型自己学会图像和语言到动作的映射。RT-2在从未见过的物体和从未见过的指令组合上表现出一定的泛化能力比如它没专门学过把可乐递给爱因斯坦雕像这种指令但凭借互联网图文数据的先验知识它可以组合出正确的行动序列。但VLA落地时的问题同样明显。第一是训练数据瓶颈。机器人动作数据的获取成本极高真实数据要标注轨迹仿真数据要解决Sim2Real迁移目前公开的机器人操作数据集规模都远小于互联网文本或图片数据。VLA模型的泛化能力一旦超出训练数据分布就会迅速崩塌。第二是推理延迟。一个标准的VLA模型前向推理一次不是生成一个token而是输出一整套动作在高端GPU上也要数百毫秒到数秒而这期间机械臂还悬在半空中。你用VLA做高层规划还行做底层伺服完全来不及。我在自己的实验里做过一个对比用OpenVLA在RTX 4090上做推理单次预测一套6DoF末端位姿动作大约需要300到600毫秒。而我的机械臂在运行视觉伺服时每20毫秒就要更新一次闭环指令。这两个频率差了一到两个数量级所以VLA在当前硬件上更适合扮演慢思考的角色而不是快反应的角色。2.3 别把VLA当唯一模型它是决策链路中的一个节点很多刚开始接触具身智能的朋友会问一个特别扎心的问题那我现在该用LLM还是该用VLA我的回答通常让提问者不太满意你需要的既不是LLM也不是VLA而是它们两个加上感知模块共同组成的一条链。LLM负责把人类指令解析成抽象的子目标比如找到杯子、走过去、抓起来VLA负责根据当前视觉画面把子目标细化成末端应该去哪个位置这样的动作意图而真正的关节级运动控制还得靠传统控制算法或小模型在毫秒级完成。换句话说VLA代替的是视觉语言动作规划的中间层不是代替整个机器人软件栈。如果你强行让VLA做细粒度控制它收到的感知输入频率、反馈延迟、输出分辨率都会让系统变成睁眼瞎。我见过不少项目在这个地方翻车模型能认出杯子也能给出大致抓取点但因为推理太慢杯子被挪走了它还在执行旧指令最后抓了一团空气。这套问题只有靠底层感知底座的高频闭环才能兜住。3. LLA与SLIM的另辟蹊径轻量化和原语化是端侧生存的必然3.1 LLA把语言指令变成机器人的内部语言如果说VLA是图像语言→动作的直通车那LLA走的就是一条更隐私、更战术的路线。LLA通常被理解为Latent Language Action的缩写核心思想是不在模型外部用自然语言描述动作而是让机器人把语言指令映射到一个紧凑的、面向具身任务定制的潜在语言空间里。说白了就是发明一套机器人自己的内部黑话这套黑话既保留了语义结构又比自然语言更贴近动作空间推理时开销远小于生成完整句子。这个概念看起来抽象其实在工程上的动机非常实际。自然语言是给人类用的对机器人而言冗余太多——请你帮我把那只红色杯子拿过来这句话里真正驱动动作的只有红色杯子拿过来几个要素。如果机器人每次决策都要把整句话过一遍Transformer那是纯粹的浪费。LLA通过对齐学习把指令压缩成一小段向量序列让模型在这个压缩空间里做规划速度能快上好几倍而且对动作空间的覆盖更稠密。当然LLA现在还没到标准件的程度它更偏向研究前沿而非成熟工程方案。但它的存在提醒我们一个趋势具身智能的推理并不一定要在自然语言空间里进行。对机器人来说语言只是入口真正干活儿的还是为动作而生的表征。3.2 SLIM轻量化模型的工程妥协SLIM在我查阅的公开资料里并没有一个统一的官方定义行业里有时用Slender Language Model、Streamlined LM等说法指代为端侧场景裁剪、蒸馏、量化过的轻量语言模型。在具身智能机器人上SLIM的意义非常现实你的机器人不可能背着一块A100出门主流平台是Jetson Orin、工控机配消费级显卡再轻一些还有树莓派加NPU方案算力预算通常只有几十到一两百TOPS。在这种算力限制下标准LLM完全跑不动。你要么用7B甚至更小的模型量化到INT4要么用蒸馏后的特制小模型要么干脆只部署一个编码器和极小的解码器。我实测过4B量化模型在Jetson Orin上的推理速度大约每秒8到15个token这个速度做用户指令→动作意图的粗粒度解析够用但做密集反馈循环完全不行。所以SLIM这类轻量化方案的定位就是承担听得懂人话这一层把具体的实时活儿让给别的模块。这也是为什么我一直强调具身智能≠大模型。如果抱着一个大模型包打天下的想法你会发现在真实机器人上根本跑不动如果反过来把模型拆分成大模型做慢速规划小模型做快速反应传统算法做关节控制每个部分反而都能找到自己的生态位。3.3 端侧部署的残酷现实模型越小感知底座越要强这里我想专门强调一个反直觉的经验模型越小感知底座的重要性反而越高。道理很简单小模型的语义能力弱它自己分辨不清楚画面里哪一个是目标物体需要感知模块先把场景结构喂干净——检测框、分割掩码、深度信息、抓取点候选全部预处理好了再给模型。如果感知做得好一个4B小模型的表现可以媲美云端100B大模型加原始图像的效果反之感知数据一团糟哪怕用GPT-4级别的模型也无济于事因为它拿到的是模糊不清、时序混乱的输入。我在做机器人桌面整理任务的时候一开始直接给VLA模型扔原始720P/30FPS的相机画面结果模型经常把桌面的光影反射误判成物体边界抓取成功率只有四成。后来我把感知底座改成YOLO检测加深度相机点云聚类先把可疑区域裁剪成高分辨率小图再喂给模型成功率立刻拉升到八成以上。这个过程让我彻底认清了一件事在具身智能里感知不是模型的前传而是和模型平级的核心系统。4. 实时音视频感知底座具身智能的感官到底该怎么造4.1 为什么单独强调音视频感知提到感知很多人第一反应是视觉毕竟是个人形机器人身上都长了摄像头。但在真实任务里音频的作用一点不比视觉小。人走进房间唤醒机器人靠的是麦克风阵列机器人听到叮一声知道微波炉热好了靠的是声音事件检测两台机器人协同搬运时互相定位靠的也是声源方向。更重要的是多模态感知之间有很强的互补性视觉被遮挡时音频能提供线索音频有歧义时视觉能帮忙确认。实时音视频感知底座说的就是把听和看这两条感知通道在工程层面做成一个统一、稳定、低延迟的基础设施。这个底座一旦搭好上层接什么LLM、VLA还是传统规划器都可以都能拿到高质量的环境状态输入如果底座不稳模型再强也是巧妇难为无米之炊。4.2 底座的技术构成七个层次讲清楚我把一个完整的实时音视频感知底座拆成七层结构从硬件到应用接口这个框架在我的多个项目里反复使用基本稳定。第一层是传感器层。这是最容易被低估的一层。视觉侧需要至少一个RGB相机深度感知可以用ToF传感器或双目结构光精度要求高的场景还要考虑是否上高帧率全局快门音频侧标配四麦克风环形阵列用于波束成形和声源定位麦克风数量不足会严重影响远场识别率。IMU虽然不是音视频传感器但在时间戳同步里起锚点作用建议一并纳入。第二层是数据采集驱动层。重点解决如何低延迟地把数据拉出来。视觉侧推荐用GStreamer或者自定义的零拷贝采集线程尽量避免OpenCV的VideoCapture这种会引入帧缓冲延迟的接口音频侧用ALSA/PulseAudio但要设置好低延迟模式。这一层最常见的坑是缓冲区设置过大导致延迟虚高结果画面和声音自带的延迟高达几百毫秒机器人跟环境之间就像隔着一条0.5秒的网络。第三层是预处理层。视觉预处理包括畸变校正、曝光补偿、分辨率裁剪、帧降噪音频预处理包括回声消除AEC、噪声抑制NS、自动增益AGC和语音活动检测VAD。很多直接调云端API的项目会跳过这一层导致本地感知和云端模型各看各的、数据不一致。记住感知底座的首要任务是输出干净的、自洽的数据而不是好看的数据。第四层是时间对齐层。这是整个底座里最容易被忽略、却又最致命的一层。音频和视频来自不同硬件时钟各自有各自的延迟漂移如果不做时间戳同步和校准机器人会把先听到打碎声、后看到碎片这种错序当成正常的因果顺序在任务理解上产生严重误导。工程上通常通过多传感器时钟同步如PTP、ROS2自带的时间同步机制统一时间基准再在业务逻辑层做事件级对齐。第五层是感知算法层。视觉跑目标检测、语义分割、3D位姿估计、OCR、人体姿态估计音频跑ASR语音识别、声源定位、声音事件分类。这一层模型的选型原则是效果达标的前提下尽量小因为感知模型通常要保证不低于10FPS的实时率在边缘设备上只有轻量模型扛得住。第六层是数据融合层。把视觉感知结果检测框、语义标签、3D坐标和音频感知结果ASR文本、声源方位、事件类别融合成结构化的环境状态描述。融合的核心是以空间和时间为索引把在这个位置、这个时刻发生了这件事组织成一个事件。比如音频声源定位给出人类话语的方向视觉检测锁定说话人的位置两者通过时间和方位匹配机器人就知道人在窗边跟我说话。第七层是API接口层。把所有感知能力封装成面向决策的统一API比如获取当前场景中所有可交互物体的列表获取距离最近的人声方位监听杯子这个关键词并返回回调。上层LLM或VLA只需要调用这些接口不必关心底层数据是怎么采集的。这一层做得好整个系统就能灵活地换模型不用改动感知逻辑。4.3 时间同步这件事值得再啰嗦一遍我想专门展开说说时间同步因为这是我在实际项目中踩坑最深的环节。有一次我搭建一套移动操作机器人视觉和音频各跑各的线程当时图省事没做严格同步结果测试语音指令目标识别联动任务时系统经常出现这样的情况用户说完拿左边的杯子之后过了0.3秒麦克风才把ASR结果发出来而视觉画面已经更新了好几帧感知模块根据当前最新画面去匹配语音指令指代错乱。排查过程很痛苦一开始怀疑是ASR模型不准后来怀疑是物体检测漏检最后按时间戳逐帧比对日志才发现音频和视频的时间差已经漂移到了400毫秒。320毫秒的光速延迟在机器人身上完全不可接受。解决方法是引入统一的时钟源把音频帧和视频帧都打上同一套时钟时间戳在感知融合模块里只允许时间差小于50毫秒的数据参与事件匹配。改了这一个点之后联动任务的准确率直接提升了好几个百分点这个收益在数据表上看着不大但体感上是机器人真的知道你在说什么了。所以我的建议是做具身智能项目第一周就要把时间同步机制定下来。这比模型选型还重要。模型选错了可以换时间基准没有后面整个堆栈都要返工。4.4 感知频率和决策频率的匹配决定了机器人敏不敏捷另一个关键参数是频率匹配。典型的具身智能系统里有三个频率层级感知频率视觉10到30Hz、音频100Hz事件检测、决策频率LLM/VLA每0.5到2秒一次、控制频率机械臂200到500Hz。这三层之间如何衔接答案是事件驱动加状态缓存。感知层把高频的观测结果压缩成当前场景状态的缓存比如目标物体位置、说话人方位、抓取点坐标决策层每隔一段时间读取这个缓存做一次慢速规划控制层则在毫秒级根据目标位姿做伺服。这是最实用的一种架构感知越快缓存越新鲜决策层拿到的事实越接近当下决策越慢越需要感知层提前总结而非喂原始数据。我这里还想提一个很多工程新手会犯的错他们往往把VLA的输出直接接到运动控制器总觉得端到端才是最高级。实际上纯端到端在实验室环境可以跑通但一旦遇到传感器噪声、货物挤压、目标被遮挡这些真实情况端到端管线就会因为缺乏中间状态而完全失控。中间缓存层就相当于人类的工作记忆让机械臂在等待VLA重新规划的0.5秒里依然能稳住当前位置而不是僵在原地或乱动。5. 落地实操搭建一套感知底座轻量VLA的最小系统5.1 硬件选型从省钱到工程化三个档位这里我不谈实验室动辄几十万的装备而是给普通团队和极客爱好者一个可以自己复现的方案。最低成本的一套是一个普通的USB RGB相机200到400元、一个四麦克风USB麦克风阵列300元左右、一台带GPU的Jetson Orin Nano开发板2000到3000元、一台六自由度桌面机械臂5000到10000元。这套组合的性能足以跑通桌面物体识别语音抓取的Demo。如果想升级到接近工程验证的级别建议把相机换成内触发工业相机和深度相机RGB-D比如Intel RealSense系列麦克风换成环形阵列模块并接入专用的音频DSP芯片计算平台换成Jetson Orin NX或者AGX。这里的原则是传感器可以买普通款但计算平台不能太弱因为感知底座里的多个模型要同时跑。我见过很多人把钱花在十几万的机械臂上结果算力卡在小盒子整套系统帧率掉到5FPS反而得不偿失。5.2 软件架构ROS2加事件总线如果团队里只有你一个人写代码尽量别自己从头搭多线程数据流直接用ROS2Humble或Jazzy。ROS2提供传感器驱动、时间同步、话题通信这些基础设施你可以把相机和麦克风流发布到话题上让感知节点订阅并处理再把结构化事件发布出来供上层的LLM/VLA节点使用。我的一个推荐做法是用ROS2做底层传输但不要用ROS2的Service做高频感知调用改用事件总线状态缓存模式。具体来说视觉感知节点维护一份当前场景物体列表缓存音频感知节点维护一份最近收到的语音指令队列高层的LLM节点周期性读取这两个缓存结合目标的当前Infobox作决策。这样做的好处是上层模型即使推理得很慢底层感知也不会被阻塞机械臂依然能保持安全稳定状态。5.3 实操实现听到指令找到并抓取红色杯子我用一个具体的任务串起整个系统方便你边看边实现。任务用户说请把红色杯子放在托盘上机器人完成抓取和放置。第一步是音频通道。麦克风阵列经预处理AEC、NS、AGC后进入VAD检测说话区间VAD检测到语音后分段送入ASR模块得到一个文本兜底。这里ASR如果部署本地模型推荐使用轻量的Whisper small或中文效果较好的Paraformer小模型。关键点是要设置一个300到500毫秒的语音结束等待窗口防止ASR在用户话没说完时就输出不完整的结果。ASR输出文本后用一个小模型做意图槽位解析提取动作放、目标红色杯子、结果位置托盘。第二步是视觉通道。深度相机实时检测场景内的可抓取物体输出每个物体的类别、2D检测框、中心点3D坐标。建议用带有彩色分割能力的检测模型比如YOLOv8-seg或者直接用SAM做意识分割再结合颜色过滤定位红色这个属性。这里就体现感知底座的价值了如果感知模块能输出物体A是杯子、颜色红色、位姿(x,y,z)这样干净的结构化数据上层LLM/小模型就完全不需要去看图识字了。第三步是融合与决策。感知事件和语音意图一起进入上层模型这个环节可以用一个常规大小的LLM也可以用一个特制意图路由器当语音意图中的红色杯子与视觉缓存中的红色杯子物体框匹配成功可以通过空间位置和颜色属性做匹配决策层输出一个抓取红色杯子并放入托盘的高级任务描述。第四步是运动执行。执行层把决策层下发的目标分解成机械臂末端的抓取位姿。这里不要直接用VLA预测整数关节角而是让传统运动规划器如OMPL的RRTConnect或者MoveIt中的PTP规划在规划空间里生成轨迹然后进入视觉伺服闭环在抓取过程中深度相机的位姿估计结果以20到30Hz的频率返回末端与杯子的相对距离机械臂根据误差修正轨迹直到末端接近抓取点。抓取是否成功用机械臂力传感器如果支持的话或者末端夹爪触力传感器判断。5.4 藏在流程里的三个硬指标你把上面这套系统搭完建议用三个硬指标检验它的健壮性而不是能不能动。第一个是端到端延迟从用户说完指令到机械臂开始运动目标值在1.5秒以内算及格1秒以内算良好。第二个是感知帧率视觉检测频率低于10Hz时系统实时性会明显恶化抓取静止物体勉强够用但面对移动物体就会出问题。第三个是时间戳漂移率连续运行30分钟音视频时间差不超过100毫秒超出这个阈值就要检查同步配置。这三个指标是血泪教训得来的我们之前做项目前两个指标还能达标第三个时间漂移经常不达标。后来我养成了习惯每个版本发版前先跑一个30分钟的音视频时间戳一致性自动化测试把这个测试加进CI流程后面再也没有被这类问题半夜叫起来过。6. 常见问题与排查技巧实录6.1 VLA模型推理太慢机械臂总是一顿一顿的怎么办这是我在各类机器人工作坊里被问得最多的问题。先说结论不要用VLA直接控制关节运动。解决办法是在VLA和运动控制器之间加一个频率桥接层。VLA输出的是目标位姿或任务意图频率低运动控制器执行的是轨迹跟踪频率高。桥接层做的事情是接收低频目标指令把它转化为一条平滑的中间期望轨迹然后让高频控制器去跟踪这条轨迹。这就像开车时你定好目的地低频任务但方向盘和油门要每毫秒根据路况调整高频控制中间导航是频率适中的桥接层。另外VLA输入帧要裁剪。不要整个1080P画面塞进去先用感知模块锁定感兴趣区域裁成224×224或384×384的小图。很多VLA模型在输入分辨率上的敏感度远超参数量同样的模型720P输入推理时间可能是384P的两倍以上而精度损失很小。6.2 音频识别一直误触发机器人动不动就以为别人在叫它这个问题大概率出在语音活动检测和回声消除上。VAD阈值设得太低会把环境杂音、拍手声、电视声都当成语音麦克风阵列的波束成形方向没有对准说话人也会导致语音信号被噪声淹没。我的建议是先在离线场景下录制10分钟的背景噪声基线给VAD设置一个自适应阈值基线以上约6dB才开始启用识别同时把ASR的静音检测参数调长一些宁可让机器人觉得话还没说完也不要频繁打断。还有一个小技巧引入唤醒词指令两级结构。机器人平时不处理语音只有听到唤醒词比如小助手才启用ASR等指令说完后0.5秒再关掉。这套机制可以大幅降低误触发率也减轻计算平台的持续负载算力可以集中用在高频感知上。6.3 图像和音频明明各自都正常但联动任务就是不对如果你确认单通道测试一切正常一联动就出错八成是时间对齐问题。把音视频各自打上时间戳在日志里对比同一事件的两路到达时间。我遇到过一个典型案例视觉模块输出检测到杯子音频模块输出用户说拿起杯子在日志里这两条记录相差了400毫秒结果一融合系统把拿起杯子这句话对上了0.4秒之后的画面而此时用户已经伸手把杯子推歪了。修复时间同步后问题自然消失。还有一个隐蔽的坑多进程/多线程处理不同传感器数据时编程语言里的时间函数如果来自不同模块比如一个用了Python time.time()另一个用了ROS2的ros_time换算基准不一致也会在日志里造成看似对齐、实则错位的假象。统一用ROS2的时钟API或者统一用硬件时钟接口这是最稳妥的做法。6.4 感知底座算法太多算力不够跑满帧率感知底座里如果同时跑目标检测、分割、ASR、声源定位四个模型Jetson Orin Nano大概率扛不住30FPS。这里有三个思路按性价比排序。第一降低模型尺寸从YOLOv8x降到YOLOv8s从Whisper small降到Whisper tiny精度损失通常可以接受帧率可能翻倍。第二按需触发目标检测一直跑但ASR只在VAD检测到语音时启动声源定位只在有唤醒词时启动这样瞬时计算压力可控。第三输入降采样检测模型跑在384P分辨率上只有在需要精细识别时才由感知模块自动切换到高分辨率的目标区域做二次检测。这三招组合下来我见过不少系统在不改硬件的情况下帧率翻了两倍。6.5 模型在仿真里很正常一上真机就失灵这是最让人头大的问题也最容易劝退新人。仿真和真机之间隔着视觉域的差别材质反光、光照变化、传感器噪声、动力学差别摩擦力、惯量、动作执行误差关节回差、齿轮间隙。如果模型是在仿真数据上训练的VLA上了真机后抓取成功率断崖式下跌几乎是必然的。我的建议是域随机化真机微调双管齐下。仿真训练的时候刻意随机化光照、纹理、相机噪声、物体初始位置让模型学会不依赖看起来完美的画面到了真机阶段采集几百条真机示范数据做一小轮微调。几百条数据不够训一个大模型但足够改动VLA的最后一两层或者改造感知缓存里的抓取点输出。这种仿真预训练真机热启动的组合目前是我认为性价比最高的落地方案。7. 回到起点给我自己的三个提醒也送给你这篇文章写到这里我最想留给读者也是提醒自己的是三句跟技术栈无关的话。第一不要被大模型万能论冲昏头脑。具身智能的敌人从来不是模型不够聪明或者数据不够多而是真实物理环境里层出不穷的意外——光照变了、物体换了角度、抽屉卡住了、人忽然挡在路径上。这些东西没有一个能靠加大模型参数量解决只能靠感知层面的完整性和闭环控制层面的鲁棒性来兜底。第二架构比算法重要。很多团队一上来就追最新的VLA模型但连相机的曝光控制和音频回声消除都没做好。我给一个忠实的建议先把实时音视频感知底座打磨到任何情况下不崩、数据始终对齐、接口稳定再去换上层算法。底座稳了上层模型可以一个月换一个底座不稳上层模型换一万个都白搭。第三别贪多先做能闭环的小事。我见过太多项目目标是万能家庭机器人结果做了一年连把桌上的杯子拿起来都没稳定跑通。反过来先把听到指令→识别物体→抓取→放置这样一个小环做实、做稳、做到连续100次不失误这个环就有巨大的工程价值因为它是所有更复杂任务的基座。具身智能这片深水区终究是靠一个一个能闭环的小任务趟出来的。
