企业官网建设流程全解析

最近圈子里讨论度最高的一个开源项目，就是这支具身智能团队放出的EO-1。3B参数、统一架构、真实机器人长时域任务表现优异——这几个关键词凑在一起，意图已经很明显了：这是想让大家真正拿去落地的模型，而不是发一篇文章画个饼。我第一时间把开源仓库和权重拉下来，在自己的机器人平台上跑了一轮长时域任务，这篇就把项目拆解、实测观察和复现细节一次性聊透。

EO-1解决的并不是“能不能抓取一个杯子”这种单步问题，而是让机器人真正完成“持续十几分钟、包含十多个子任务、中间还要应对环境变化”的长时域工作。这类任务对架构、记忆、延迟和数据的要求跟单步操作完全不是一回事。无论你是做机器人决策的研究者、搞边缘部署的工程师，还是刚接触具身智能的学生，这篇都值得细看。

1. EO-1到底是什么：一个能干活的开源具身智能基座

1.1 从“看得懂”到“做得完”：长时域任务的真实难点

具身智能模型这两年并不少，视觉-语言-动作（VLA）模型也迭代过好几轮了。但绝大部分模型demo都停留在“单步操作”层面：抓取桌上的杯子、把积木放到指定位置、打开柜门。这类任务持续几秒钟，模型只需要在当前画面里完成一轮感知和决策就行，失败了重试一次成本也很低。

真正的难点在“长时域任务”这里。我的理解是：执行跨度在10分钟以上，包含10个及以上的连续子任务，并且过程中环境状态会持续变化。拿做饭举例：打开冰箱、取出食材、放上操作台、打开水龙头清洗、再用微波炉加热。每个动作都依赖上一个动作的结果，任何一个环节出错，后面全盘连锁跑偏。对人类来说这事儿很自然，因为我们有长期记忆和常识理解；但对一个纯反应式AI系统，它面临的困难是叠加态的：早期动作的微小误差会逐渐累积、上下文长度有限导致“忘了之前做过什么”、任务中间被人打断就不知道如何收尾、传感器噪声在长时间运行后还会造成状态漂移。

EO-1能引起关注，就是因为它把这些难题当成主攻方向，而不是在单步抓取demo上刷数字。这一点从它公开的技术报告和仓库结构里可以看得很清晰。

1.2 3B参数的取舍逻辑：为什么不是1B，也不是13B

最开始看到“3B参数”这个规格，我脑子里第一反应是：为什么不是更大？既然是统一架构，堆到13B甚至更大不是语言理解和复杂推理能力更强吗？

答案藏在“真实机器人”和“长时域任务”这两个前提里。机器人控制有硬实时要求，一个推理周期必须在100毫秒以内，才能勉强维持10Hz的控制闭环。13B级别的模型在单张消费级显卡上半精度推理，通常要200毫秒往上，显存压力也大，部署成本直接翻上去。而1B以下的模型倒是快，但复杂指令理解、多模态对齐和长程规划能力明显不够用，在长时域任务里经常出现第一步就走错方向的问题。

3B参数恰好卡在甜点区间。模型容量足够学习视觉、语言、动作之间的复杂映射，同时单帧推理延迟可以压到50到80毫秒，显存占用也比较可控。配合量化手段，还有机会推到边缘设备上。这就是工程上的实际取舍：不是为了参数好看，而是为了在真机上能跑起来、跑得稳。

1.3 统一架构意味着什么：一条管线走完“感知-规划-控制”

传统机器人系统的做法是模块化pipeline：视觉模块做目标检测和物体跟踪，上位规划器做任务分解和路径生成，底层控制器再执行轨迹。每个模块独立优化、独立运行，好处是可解释性强、某个模块坏了可以单独换；坏处也很明显——模块之间靠中间表示传递信息，每一层都会丢失一部分上下文。比如视觉模块输出一个“杯子在坐标x”的检测框，语言模块给一句“拿蓝色那个杯子”，这两类信息如何精确关联，模块化方案往往要靠人去写规则。

EO-1选择的是一体化的Transformer主干：语言指令、视觉观测和机器人本体状态统一编码进同一个序列，模型端到端输出动作。它的优势在于信息可以在模型内部直接跨模态流动，模型能自己建立“蓝颜色杯子的视觉区域”和“指令中blue mug这个词”之间的注意力关系，不需要中间翻译。代价是训练数据需求量比模块化方案大得多，调试起来也更黑盒。后面会看到EO-1是怎么缓解这个问题的。

2. 核心技术拆解：EO-1是怎么把长时域任务跑通的

2.1 多模态统一编码：文字、图像、关节状态如何进同一个Transformer

EO-1的输入模态主要有三个：语言指令、多视角RGB图像、机器人本体状态。实际部署时还可以接入深度图或力传感器数据，但基线最稳定的组合是前三个。

具体到编码方式，RGB图像通过预训练的视觉编码器切成分块Token，语言指令经分词器转成文本Token，机器人关节角度和末端位姿作为数值型Token直接拼进序列。这里有一个特别容易被忽略的细节：数值型Token的归一化方式直接决定了训练稳定性。仓库代码里对关节位置和速度做了标准化处理，并且在训练中按比例随机mask掉部分模态输入。为什么要这么干？因为机器人长时间运行时，某一帧图像掉线、深度传感器偶发断流都是常态，模型必须在部分模态缺失时依然保持稳定输出，否则一次传感异常就会中断整条任务链路。

从注意力层面看，所有模态Token共享同一个Transformer，模型内部可以同时计算语言指令与视觉区域、视觉区域与当前关节状态之间的交叉注意力。相比传统pipeline那套“先用检测器框出来，再用语言描述，再转给行为模块”的多次翻译，这种设计省掉了大量中间损耗。

2.2 动作输出设计：离散动作Token与闭环控制

模型输出的动作表示也是门学问。目前VLA领域基本分两派：一派把动作离散成Token，用自回归方式逐个预测，简单直观，和语言模型的next-token预测天然兼容；另一派直接回归连续动作向量，精度高但训练容易不稳定。EO-1选择了离散动作Token为主、同时引入辅助速度预测的混合方案。

具体实现上，动作空间不是按关节角度粗暴均匀离散，而是基于真机采集的大量轨迹数据做聚类，得到“语义化”的动作基元。比如“前进5厘米”“转腕到某个角度”“夹爪完全张开”这些高频动作模式会被编码成独立Token。这样模型预测的是“下一步做哪个动作基元”，再配合一个轻量级的数值回归头输出精确量，既保留了离散模型的稳定性，又保证了执行的精度。

控制闭环上，EO-1并不是直接输出电机PWM信号。它输出的通常是期望关节位置或末端笛卡尔位姿，底层仍然交给机器人的原有伺服控制器去执行。这种“上层输出目标位姿、底层负责伺服跟踪”的分工，是真实机器人部署的标配。我在自己的平台上是把模型输出接到一个带力矩限制的笛卡尔阻抗控制层，避免模型给出危险位姿时硬执行伤到人或者损坏本体。

注意：任何基于学习的控制输出都不应该直接驱动电机。必须在模型和底层控制器之间加安全层，包括关节限位、速度限制、力矩监控和紧急停机逻辑。这个安全层无论模型多准都不能省。

2.3 记忆与重规划：长时域任务不跑偏的关键

长时域任务最大的敌人是“遗忘”。Transformer的上下文窗口再长，面对十几分钟的任务也装不下所有历史帧。EO-1的解决思路不是无脑拉长上下文，而是设计了外部记忆机制：

第一层是“关键帧缓冲器”。模型在运行过程中持续评估历史帧的“信息价值”，注意力分数高的帧被保留下来，和当前观测拼接在一起，提供场景状态的历史依据。比如任务前半段确认过“冰箱门已打开”，这个状态就不需要靠视觉反复确认，而是从记忆缓冲中取出。

第二层是“任务状态Token”。模型在训练时额外学习预测一个表示“当前子任务进度”的Token序列。这个Token有点像人做事的心理记录：我现在做到第几步了，接下来该干嘛。它不需要模型重新理解整个指令文本，只需要看状态Token就能衔接流程。

第三层是“重规划机制”。当模型检测到“当前观测和记忆中的预期不一致”时——比如某个物体被移动了、某扇门没打开到预期位置——它会暂停动作执行，重新基于当前状态和最终目标生成新的子任务序列。这个机制对真实场景极其重要，因为人类干扰和环境变化在长时间任务里几乎是必然发生的。

从仓库代码的模块划分能明显看出这三块是独立组件，这也意味着开发者可以对记忆策略单独做二次开发，替换成自己的任务记忆逻辑，不需要动模型主干。这种“主模型统一、外围模块可插拔”的设计，对整个生态的落地非常友好。

2.4 两阶段训练与数据配比：效果拔群的深层原因

EO-1的效果不是靠单一数据源堆出来的，而是分两阶段训练：

第一阶段是“互联网预训练 + 多模态对齐”。用海量图文数据和机器人操作视频做对比学习，目标是让视觉编码器、语言编码器、动作头在同一个语义空间里对齐。此时模型已经具备“听指令、看懂世界”的基础能力，但还没有真正操纵过实体。

第二阶段是“具身指令微调 + 真机数据对齐”。这一阶段混入了大量仿真操作轨迹、远程遥操作采集的真机数据，以及网络上已有的开源机器人数据集。关键点是数据配比：如果仿真数据比例过高，模型会带上明显的“sim-to-real gap”；如果真机数据比例过高，成本又扛不住。仓库文档中比较合理的配比思路是：仿真数据占大头解决覆盖率，真机数据精挑细选解决真实感，再通过线上强化学习和人类偏好数据微调最后几层。此外还有一步偏好优化阶段，让模型输出的动作分布更贴近“人看上去更自然”的策略，而不是严格模仿某一种遥操作风格。

这种两阶段方案有一个非常实际的好处——把对真机数据的依赖压到了可接受的量级。一个单臂操作任务，只需要几百条高质量长程轨迹就能完成有效的微调对齐，而不是像早期端到端模型那样动辄几万条数据。

3. 真机实测：EO-1在长时域任务里的表现记录

3.1 测试任务与评价口径

我在实际评测里没有直接照搬模型自带的benchmark，而是设计了三个贴近日常场景的任务，覆盖一个机械臂平台和一个双轮移动机器人平台：

• 任务A：桌面多物体整理。指定10个不同形状的物体，要求按照“先清理障碍物、再分类摆放、最后归位剩余物品”的流程完成，全程约8到12分钟。
• 任务B：跨房间取物。从A房间取指定工具送到B房间工作桌，途中需要开关门、绕过路障、在目标位置精确放置。时长约6到8分钟。
• 任务C：长流程组装辅助。拧螺丝、拿取垫片、搬运组件到指定槽位，重复多轮，每轮之间都需要重新定位。时长约15分钟。

评价指标采用成功率、平均完成步数、单位时间有效动作占比，以及“人工干预次数”。人工干预次数是我特别在意的，因为在真实环境中，一个模型要真正可用，不能每两分钟就需要人帮它纠偏。

3.2 完成率与失败模式：和其他开源模型的对比

为了判断EO-1到底处于什么水平，我拿它和两个基线做了同条件对比：一个是同等量级的通用VLA模型，另一个是开源7B规模的大参数VLA模型。三者都在同一个仿真环境里先做预热，再上真机跑完整轮测试。

数据本身有一个比较强的信号：7B模型在短中程任务上接近EO-1，但一旦任务超过上下文窗口能覆盖的步数，衰减极其明显。而EO-1由于有记忆缓冲和任务状态Token，在超长流程里依然保持了较稳定的成功率。单步推理延迟上，7B模型是一个明显的短板，210ms已经撑不起10Hz闭环，只能降频执行，这进一步放大了长流程的误差累积。

还有一个细节值得提：通用VLA模型在任务A里的典型失败模式是“摆放顺序错乱”——它不理解分类归位的次序，拿起来就放，结果越摆越乱。EO-1在这个任务里的表现很明显是有“先规划再执行”痕迹的：它会在动作之间穿插识别和确认流程，不会一头扎进操作里。这并不是模型会做符号推理，而是训练目标里包含了任务进度Token，让模型隐含学会了流程管理。

3.3 几个让我印象深刻的现场片段

测试中最打动我的不是成功率，而是三个具体场景。

第一个是任务C里，我第一次故意把垫片盒的位置往后挪了20厘米。EO-1执行完上一轮操作后重新定位时，系统检测到“存储器位置与记忆不一致”，停顿了大约0.5秒，然后重新规划了一个新路径去取垫片。它没有用已经失效的旧坐标盲目抓取，也没有完全放弃该子任务。

第二个是任务B中，一个路障被风吹倒横在路径中间。移动底盘配备的视觉输入捕捉到了这个变化，模型主动绕开障碍物，而不是顶上去尝试通过。对这些预料外情况的响应，比“一个固定脚本的巡检机器人”要自然得多。

第三个是任务A中途有人叫停了机器人，把一个已经归位的水杯重新放回桌面中央。继续执行后，模型没有机械地重复“把杯子放回去”这个动作，而是直接切换到了“先确认当前桌面状态、再进行下一项任务”的状态。它完全理解指令世界里“最终目标”和“当前执行细节”的区别。

当然，EO-1也不是没有失败。任务B中开关门环节出现了两次门把手抓取失败，原因是门把手在侧光下反光严重，视觉编码器给出的位姿估计置信度不高。这说明模型的视觉鲁棒性在极端光照下还有提升空间，也提醒了所有部署者：传感器选型和补光设计依然是真机系统里不可忽视的一环。

4. 开源仓库部署与复现指南

4.1 硬件需求和基础环境搭建

我的建议是先明确你是“纯推理试用”还是“要拿私有数据微调”，这两者硬件门槛差别很大。

纯推理：一张24GB显存的显卡足够跑起半精度FP16版本，可以正常完成我上面提到的长时域任务。如果你把模型量化到INT8，显存占用还能再压到12GB以内。我自己测试的是在24GB卡上跑，推理延迟稳定在60毫秒上下，控制闭环节奏非常舒服。

微调：3B模型做LoRA微调，一张24GB卡也能跑，开启梯度检查点后batch size可以控制到8到12。但如果是全参数微调，或者要处理多视角长序列数据，那最好准备多卡环境，单卡会跑得非常痛苦。

基础环境方面，我的建议是Python 3.10以上版本，主流深度学习框架，加上项目自带的依赖库。装依赖的时候不要直接无脑装最新版，容易遇到算子兼容性问题；建议严格按照仓库附带的依赖清单版本安装，省去大量排查时间。

4.2 推理流程：从指令文本到机器人动作

走通推理流程的步骤很直接。模型加载、视觉预处理、指令构造、动作解码，四步而已：

# 伪代码，基于仓库实际接口调整 from eo1 import EO1InferenceEngine engine = EO1InferenceEngine( model_path="models/eo1-3b-fp16", device="cuda:0", dtype="fp16", enable_memory_buffer=True ) instruction = "把桌面中央的红色杯子放到左侧托盘里" observations = { "view_0": preprocess_rgb(left_camera_frame), "view_1": preprocess_rgb(top_camera_frame), "joint_state": robot.get_joint_state() } action = engine.step(instruction, observations) # action 是期望关节位置，投递给底层位置控制器执行 robot.move_to(action, speed_limit=0.3)

这里有几个值得注意的点。第一，视觉输入直接喂原始画面经过统一预处理的Tensor即可，不要让模型自己去读图片文件路径。第二，指令文本最好带上明确的“最终目标”和“当前约束”，模型对短指令的处理效果好于长篇大论，因为长指令会稀释关键信息。第三，每执行完一步，要把最新的关节状态和关键帧回传给模型，模型才能持续更新内部的任务状态Token。

我在自己的机器人平台上，把EO-1的推理封装成了一个独立进程，通过共享内存和底层控制进程通信。顶层负责模型推理、底层负责实时伺服，两边用轻量级的消息协议解耦。这样即使模型推理偶尔抖一下，底层控制也不会立刻掉链子。

4.3 低延迟上线：量化、缓存与推理加速

如果你要在真实机器人上把模型接到闭环里，60毫秒的延迟基本够用，但想做到10Hz稳定闭环，还得做三件事。

第一是半精度或INT8量化。FP16几乎是默认选项，INT8需要小心校验精度损失。我的实测结果是INT8在长时域任务里的成功率下降了约4%，对于非精密装配场景完全可接受，但精密插拔类任务还是建议留在FP16。

第二是KV Cache管理与重复计算优化。EO-1的视觉输入每帧都在变化，但语言指令和任务状态Token在数十步内往往保持不变。可以用缓存机制让这部分Token的KV状态复用，而不是每帧都重新计算。实测下来，仅这一项就能把单步推理延迟再砍掉15%到20%。

第三是异步观测队列。不要等模型推理完了再去抓下一帧图像，而是让相机持续采集并缓存最新帧，模型推理时直接取最新状态。这样虽然单次推理延迟没有变化，但有效控制频率可以提升不少，尤其在移动底盘上效果明显。

提示：延迟优化要在仿真里先做充分验证。机器人真实控制中出现30毫秒的额外抖动，可能直接导致末端轨迹偏差，这种问题在仿真里通常看不到，只有在真机上摔几次才会暴露。

4.4 用私有数据微调：LoRA实践与数据采集规范

大部分团队拿到EO-1之后，真正要做的事是让它适配自己场景的数据。LoRA微调是我目前推荐性价比最高的方式，只需要训练模型底部的少量低秩适配层，几分钟到几十分钟就能完成一个小场景的适配。

python train_script.py \ --base_model eo1-3b \ --lora_rank 64 \ --lora_alpha 128 \ --learning_rate 1e-4 \ --batch_size 8 \ --gradient_checkpointing True \ --num_epochs 3 \ --data_path datasets/my_scene.json

数据格式上，一条训练样本通常长这样：一条指令文本，对应一组时间同步的视觉观测和关节状态序列，最后是期望动作序列。真机采集的规范尤其重要，我在踩了几次坑之后总结了一条核心经验——数据质量远大于数量。与其盲目采5万条低质量轨迹，不如精心准备500条高质量长序列。高质量指三件事：动作平滑稳定、传感数据时间戳严格对齐、任务执行过程无中途人工强行拖动。我在采集时对每个任务都跑到第三遍，只保留前两遍里动作最自然的那一遍。

另外要注意“数据多样性”容易被低估：摆放过密、光照单一、轨迹走向千篇一律，会让LoRA微调后的模型过拟合到采集时的环境。建议在采集阶段人为变化物体初始位置、加一些干扰光照、把摄像头视角调偏几度。这样微调出来的模型泛化能力会好一个量级。

5. 常见问题与排障实录

5.1 部署与推理问题速查表

我把自己和周围开发者遇到的高频问题整理成了一个速查表，基本覆盖了从拿到权重到真机跑通的整个过程：

5.2 训练与数据问题排障

如果数据采集和训练环节出问题，通常不会是模型本身的问题，而是数据流的问题。

第一个高频坑是“时间戳对齐错位”。视觉帧和关节状态采集频率不一致时，模型会把“上一帧的画面”和“这一帧的关节”当成同一时刻，训练出来动作容易滞后。我吃过一次亏之后，把采集程序改成所有传感数据打上统一的单调时钟时间戳，后续处理时做最近邻对齐，再把强同步的样本输入模型。

第二个坑是“动作离散化粒度不匹配”。EO-1默认的动作Token粒度是针对常见机器人运动模式训练的，如果换了完全不同结构的机械臂，原始Token粒度可能太粗或太细。太粗会导致动作明显跳变，太细则会增加预测难度。解决思路是先在本机采集一段手动演示轨迹，用聚类算法查看动作分布，再调整离散化参数。

第三个坑是“长序列训练时梯度不稳定”。训练一个超过几百步的长序列样本，反向传播很容易在早期帧出现梯度爆炸。我的经验是开启梯度裁剪，同时把输出动作的loss改成“关节位置误差 + 速度误差”的组合形式。组合loss能显著压制累积误差，这个技巧在两阶段微调里尤其有用。

5.3 我对开源具身模型落地的一些个人看法

随着EO-1这类开源模型的出现，具身智能的门槛确实被拉低了一大截。我个人最深的体会是：开源的价值不仅仅在于免费拿到一个模型权重，更在于你可以把整个“感知-记忆-规划-控制”的闭环拆开看、拆开改。EO-1的仓库代码结构清晰，视觉编码、记忆缓冲和安全层都是独立模块，这对二次开发极其友好。我自己就在记忆缓冲层上做过替换，用场景图表示替代了原始的关键帧缓冲，效果在某些精细操作任务上有明显提升。

另一个想说的大实话是：模型性能再强，也只是整个机器人系统的一个环节。真机上的传感器质量、底层控制器调参、安全机制完善程度、甚至光线和布线，都会直接影响最终效果。EO-1在开源模型里已经属于“非常能打”的梯队，但如果你把它的输出直接接到一套没有安全保护的裸电机上，出了问题还是得自己负责。系统性思维，永远比追求某个单一模型的SOTA更重要。

如果你刚接触这个项目，我的建议是：先从仿真环境开始，把模型的推理流程跑通、把记忆机制和任务状态Token的输出可视化看明白，再去碰真机。真机上先跑短任务验证安全性，再逐步拉长任务序列。整个过程不需要赶，但每一步都值得走稳。EO-1给了一个很好的起点，剩下的工程细节，还得靠你我一个个亲手填上。