企业官网建设流程全解析

1. 从屏幕到物理世界：为什么我们需要 Robot-Use

过去一年，围绕视觉语言模型（VLM）构建的 Computer-Use 智能体几乎成了自动化领域最热的方向。从 AutoGLM-Phone 这类模型切换方案，到各种支持多尺寸 VLM 部署的教程，整个社区都在尝试一件事：让模型看懂屏幕、理解界面、然后代替人完成点击和输入。这套逻辑在数字世界里跑得通，因为屏幕像素是结构化的、可回滚的、试错成本几乎为零。但当我们把目光从显示器移到真实机器人身上，问题立刻变得棘手起来。

真实机器人面对的是一个连续、有噪声、不可逆的物理环境。机械臂撞到桌角不会弹出“撤销”按钮，抓取失败意味着物体可能已经掉进缝隙。更麻烦的是，机器人的动作空间和屏幕点击完全不同——屏幕上的坐标是离散的像素，而机械臂的关节角度、末端位姿、夹爪开合都是连续量。VLM 擅长的是“看图说话”，它输出的是文本 token，不是力矩或轨迹。这中间的鸿沟，就是 Embodied Harness 这类框架试图填补的核心地带。

我最初接触这个方向时，脑子里冒出的第一个问题是：能不能像 Computer-Use 那样，给 VLM 一套统一的接口，让它直接输出机器人能执行的动作？答案是可以，但前提是你得把“动作”这件事重新抽象一遍。GUMI 这个关键词在热词里出现，它代表的正是这种抽象层——把机器人的底层控制封装成 VLM 能理解的语义动作单元。换句话说，VLM 不需要知道每个关节转多少度，它只需要说“把红色方块放到蓝色托盘里”，剩下的交给 Harness 去翻译成具体的运动指令。

这套思路的价值在于，它把 VLM 的泛化能力从数字世界迁移到了物理世界。你在网上看到的那些 VLM 模型部署教程，无论是 Ollama 上跑小尺寸模型，还是多尺寸 VLM 的切换策略，本质上都在解决“让模型看得懂”的问题。而 Robot-Use 要解决的是“让模型动得对”。这两件事叠在一起，才构成一个完整的具身智能闭环。适合读这篇内容的人，包括正在做机器人抓取的研究者、想把手势交互接入 VLM 的工程师，以及那些已经玩过 Computer-Use 智能体、想进一步折腾物理机器人的爱好者。哪怕你手头只有一台桌面级机械臂，下面的拆解也能帮你少走弯路。

2. 核心架构拆解：Embodied Harness 到底在做什么

2.1 从 Computer-Use 继承的接口哲学

Computer-Use 智能体的经典架构是“观察-思考-行动”循环：截屏作为观察，VLM 推理作为思考，鼠标键盘事件作为行动。这个循环之所以能跑起来，是因为有一个中间层把操作系统的原生 API 包装成了模型能调用的函数。比如“点击坐标 (x, y)”这个动作，底层可能是 pyautogui 的一次调用，但模型看到的只是一个 JSON 格式的 action。

Embodied Harness 把这套哲学原封不动地搬到了机器人上。它定义了一组语义动作原语，比如move_to、grasp、release、rotate，每个原语对应机器人 SDK 里的一段控制代码。VLM 的输出被约束在这些原语的集合里，而不是自由生成文本。这样做的好处是双重的：一方面，模型的输出空间被大幅缩小，推理难度降低；另一方面，每个原语都可以在底层做安全检查和运动规划，避免模型发出“把机械臂转 720 度”这种危险指令。

我实测下来，这种约束式接口比让 VLM 直接回归关节角度要稳得多。直接回归的问题在于，VLM 的训练数据里几乎没有关节角度的分布，它输出的数值基本是随机的。而语义原语是自然语言里常见的概念，VLM 在预训练阶段已经见过大量“抓取”“移动”“放置”的描述，迁移过来几乎没有语义障碍。

2.2 GUMI 抽象层：动作空间的语义化

GUMI 在这个架构里扮演的是“翻译官”角色。它把机器人的连续动作空间映射到离散的语义空间，同时把视觉观测映射到 VLM 能理解的图像 token。具体来说，GUMI 做了三件事。

第一，它定义了一套动作词汇表。每个词汇对应一个参数化的运动模板，比如grasp(object_id)会触发视觉伺服抓取，move_to(pose)会调用逆运动学求解。这些模板的参数不是硬编码的，而是根据当前场景动态生成的。比如object_id来自 VLM 对图像的指代，pose来自场景点云的分析。

第二，它维护了一个世界状态缓存。机器人的关节状态、夹爪开合度、物体位姿都被实时更新到一个结构化表示里。VLM 每次推理时，除了看到当前图像，还能拿到这个状态摘要。这相当于给模型提供了一个“记忆”，让它知道上一秒自己做了什么、物体现在在哪。

第三，它处理异常和重试。如果抓取失败，GUMI 会把失败信号转成文本反馈给 VLM，比如“抓取失败，物体滑落”。VLM 收到这个反馈后，可以决定重新抓取还是换一个策略。这个闭环是 Computer-Use 里没有的，因为屏幕操作很少需要“重试”这个概念——点错了再点一次就行，但机器人抓空了可能意味着物体已经移位。

2.3 VLM 在回路中的角色定位

很多人误以为 VLM 要负责所有决策，其实在 Robot-Use 架构里，VLM 只做高层规划。低层的运动规划、碰撞检测、力控都由传统机器人栈处理。VLM 的输入是一张或多张 RGB 图像，加上任务描述和状态摘要，输出是一个动作序列或单个动作。这个分工很关键，因为 VLM 的推理速度通常在几百毫秒到几秒之间，而机器人的控制循环需要几十赫兹。如果让 VLM 直接闭环控制，延迟根本扛不住。

我试过用一个小尺寸 VLM 跑在本地，推理一次大概 300 毫秒。对于“拿起方块”这种任务，VLM 只需要在关键节点做决策，比如“现在可以抓了”“抓完该放哪”，中间的运动执行交给底层控制器。这样整体响应是流畅的。如果你用的是云端大模型，延迟可能到一两秒，那就更适合做任务级的规划，而不是实时控制。

注意：VLM 的输出必须经过一层安全校验，比如检查目标位姿是否在工作空间内、夹爪力是否超过阈值。这层校验不能省，否则模型偶尔的幻觉会直接变成物理碰撞。

3. 实操环境搭建：从零跑通一套最小闭环

3.1 硬件选型与基础软件栈

要复现这套东西，你不需要工业级机械臂。一台桌面级的六轴臂或者三轴臂就够，关键是它得有可编程接口。我手头用的是一台支持 Python SDK 的桌面臂，重复定位精度在 0.5 毫米左右，对于方块抓取任务完全够用。夹爪用的是电动平行夹爪，开合行程 50 毫米，力控可调。相机方面，一个普通的 RGB 摄像头固定在腕部或外部支架上都行，腕部相机的好处是视角随动，外部相机的好处是能看到全局。

软件栈分三层。底层是机器人厂商提供的 SDK，负责关节控制和运动学求解。中间层是 ROS 或者直接基于 Python 的封装，我为了简化依赖，直接用 Python 写了一个轻量级的控制器，通过串口和机械臂通信。上层就是 Embodied Harness 和 VLM 的接口。VLM 我选了一个参数量在 7B 左右的模型，跑在一张消费级显卡上，量化到 4bit 后显存占用不到 6GB。

这里有个坑：不同厂商的 SDK 对位姿的定义不一样，有的用欧拉角，有的用四元数，有的甚至用关节角直接插值。你在写 GUMI 抽象层的时候，一定要先把坐标变换统一到同一个参考系。我一开始没注意，结果 VLM 说“向左移动”，机械臂实际往右跑了，排查了半天才发现是坐标系定义反了。

3.2 VLM 部署与多尺寸切换策略

热词里提到的“autoglm-phone模型切换”和“多尺寸vlm部署教程”，其实指向一个很实际的问题：不同任务需要不同大小的模型。简单任务比如“有没有红色方块”，用 2B 的小模型就够了，推理快、显存省。复杂任务比如“把方块按颜色分类堆叠”，可能需要 7B 甚至更大的模型来理解空间关系。

我的做法是维护一个模型池，每个模型对应一个尺寸档位。Harness 根据任务复杂度动态选择模型。判断复杂度的方式很简单：如果任务描述里包含多个物体、多个步骤或者空间关系词（如“旁边”“上面”“之间”），就切到大模型；否则用小模型。切换的代价是加载时间，所以我会把常用模型常驻显存，不常用的按需加载。

在 Ollama 上部署 VLM 是个不错的选择，它帮你处理了量化、显存管理和 API 封装。你只需要拉取模型，然后通过 HTTP 接口调用。我实测下来，7B 模型在 4bit 量化下，单次推理大概 400 毫秒，对于非实时任务完全够用。如果你追求更低延迟，可以考虑 3B 左右的模型，但代价是空间推理能力会下降。

3.3 接口定义与动作原语实现

动作原语的设计是整个系统的核心。我定义的原语包括：move_to(x, y, z)、grasp()、release()、rotate(axis, angle)、home()。每个原语在底层对应一段 Python 函数，函数内部做逆运动学求解和轨迹规划。

以grasp()为例，它的实现逻辑是：先读取当前末端位姿，然后调用视觉伺服让夹爪对准目标物体，最后闭合夹爪并检测电流是否超过阈值。如果电流超限，说明夹住了物体；如果没超限，说明抓空了。这个反馈会返回给 Harness，再转成文本给 VLM。

VLM 的输出格式我约束成 JSON，比如{"action": "move_to", "params": {"x": 0.2, "y": 0.1, "z": 0.05}}。解析这个 JSON 后，Harness 会检查参数是否在安全范围内，然后调用对应的原语。如果 VLM 输出了不存在的动作名，Harness 会返回错误信息让它重试。

提示：动作原语的粒度要适中。太细了 VLM 学不会，比如“关节 1 转 0.1 弧度”这种它根本理解不了；太粗了又失去灵活性，比如“完成整个任务”这种它没法执行。我的经验是，原语数量控制在 10 到 20 个之间比较合适。

4. 任务执行全流程：一次完整的抓取放置实验

4.1 场景初始化与视觉观测

实验场景很简单：桌面上放一个红色方块和一个蓝色托盘，任务是“把红色方块放到蓝色托盘里”。初始化时，我先让机械臂回到 home 位，然后拍一张全局图。这张图会送给 VLM，同时也会跑一个轻量的目标检测模型，把红色方块和蓝色托盘的像素坐标提取出来。

目标检测这一步不是必须的，但加上它能大幅提升稳定性。VLM 有时候会把红色方块误判成橙色，或者把托盘的边界搞错。有了检测结果作为锚点，VLM 只需要做“选择”而不是“定位”，难度降低很多。检测模型我用的是 YOLO 的 nano 版本，推理时间不到 20 毫秒，几乎不影响整体延迟。

检测结果会转成文本描述，比如“红色方块在图像中心偏左，蓝色托盘在右下角”。这个描述和原始图像一起送给 VLM。VLM 的任务是输出第一个动作，通常是move_to到方块上方。

4.2 VLM 推理与动作序列生成

VLM 收到图像和文本后，会输出一个 JSON 动作。我用的提示词模板大致是这样的：你是一个机器人控制助手，当前场景是……可用动作有……请输出下一步动作。提示词里会附上动作原语的说明和参数范围。

第一次推理，VLM 输出了{"action": "move_to", "params": {"x": 0.15, "y": -0.05, "z": 0.1}}。Harness 检查参数后发现 z 值偏高，但还在安全范围内，于是执行。机械臂移动到方块上方 10 厘米处。然后 Harness 自动拍一张腕部相机的图，连同“已到达目标上方”的状态一起送给 VLM。

第二次推理，VLM 输出{"action": "grasp", "params": {}}。Harness 执行抓取，夹爪闭合后电流上升到阈值，判定抓取成功。状态更新为“已抓取红色方块”。第三次推理，VLM 输出{"action": "move_to", "params": {"x": 0.3, "y": 0.2, "z": 0.15}}，这是托盘上方的位置。第四次推理，VLM 输出{"action": "release", "params": {}}，方块被放入托盘。

整个序列用了四次 VLM 推理，总耗时大约 2 秒，其中 VLM 推理占了 1.6 秒，机械臂运动占了 0.4 秒。这个速度对于演示来说够用，但如果要提速，可以把 VLM 推理和机械臂运动重叠起来——在机械臂移动的同时，VLM 已经在预测下一个动作了。

4.3 执行监控与异常恢复

执行过程中最容易出问题的是抓取环节。我遇到过几次抓空的情况，原因是方块表面太滑，夹爪闭合时方块被推开了。这时候电流没有达到阈值，Harness 判定抓取失败，把“抓取失败，物体可能移位”的文本反馈给 VLM。VLM 收到后，重新输出一个move_to动作，这次它会根据新的图像调整位置。

还有一种异常是运动超时。如果机械臂在指定时间内没有到达目标位姿，Harness 会中断执行并报错。这种情况通常是逆运动学无解，比如目标点超出了工作空间。VLM 收到超时反馈后，会尝试换一个接近的位置。

注意：异常恢复的次数要设上限，比如最多重试三次。否则 VLM 可能陷入死循环，反复输出同一个无效动作。我在 Harness 里加了一个计数器，超过三次就强制回到 home 位并终止任务。

5. 常见问题与排查技巧实录

5.1 VLM 输出格式错误怎么办

这是最常见的问题。VLM 有时候会输出自然语言而不是 JSON，比如“我将移动到方块上方”。这种情况通常是提示词不够严格，或者模型太小、指令遵循能力弱。我的解决办法是在提示词里加 few-shot 示例，给出两三个正确的 JSON 输出样例。另外，Harness 里要加一个解析器，尝试从文本里提取 JSON 片段，如果提取失败就返回错误让 VLM 重试。

如果重试多次仍然失败，可以考虑换一个指令遵循能力更强的模型。我试过几个不同尺寸的 VLM，发现 7B 以上的模型基本能稳定输出 JSON，3B 以下的就经常跑偏。所以如果你要做 Robot-Use，模型尺寸不建议低于 7B。

5.2 坐标系不一致导致动作反向

前面提过这个坑，这里展开说。机器人的位姿定义通常有三种：基坐标系、工具坐标系、工件坐标系。VLM 看到的图像是相机坐标系，它输出的坐标需要经过一系列变换才能变成机器人能执行的指令。如果变换矩阵搞错了，就会出现“说左往右”的情况。

排查方法是先做一个简单的测试：让 VLM 输出一个固定的move_to指令，比如 x 方向移动 5 厘米，然后观察机械臂实际移动方向。如果方向反了，检查变换矩阵的符号。我建议在 Harness 里加一个坐标变换的单元测试，每次启动时自动跑一遍，确保映射关系正确。

5.3 抓取成功率低的优化思路

抓取成功率受很多因素影响：光照、物体表面材质、夹爪力控参数、视觉伺服精度。我踩过的坑包括：光照太强导致方块边缘过曝，检测框偏移；夹爪闭合速度太快，方块被弹飞；视觉伺服的目标点选在方块中心，但夹爪需要对准边缘。

优化手段有几个。第一，加一个简单的光照补偿，用直方图均衡化预处理图像。第二，夹爪闭合速度调慢，给视觉伺服留出调整时间。第三，抓取点不要选几何中心，而是选在物体上方偏后的位置，这样夹爪闭合时物体不容易滑脱。第四，如果条件允许，加一个腕部力传感器，实时检测接触力，比单纯看电流更准。

5.4 多尺寸 VLM 切换的显存管理

如果你同时部署了多个尺寸的 VLM，显存管理是个问题。我的做法是只把当前任务需要的模型加载到显存，其他模型放在内存里。切换时用 Ollama 的 API 卸载当前模型，再加载新模型。这个过程大概需要几秒钟，对于非连续任务可以接受。

另一个方案是用模型量化。4bit 量化能把 7B 模型的显存占用压到 6GB 以下，一张 8GB 的显卡就能跑。但量化会损失一些精度，尤其是空间推理任务。我实测下来，4bit 量化的 7B 模型在简单抓取任务上和全精度模型表现差不多，但在复杂空间关系任务上会差一些。所以如果你的任务对精度要求高，建议用 8bit 量化或者全精度。

6. 从演示到落地：这套方案还能怎么扩展

跑通最小闭环之后，我试过几个扩展方向。第一个是增加物体数量，从单一方块扩展到多个不同颜色和形状的物体。这时候 VLM 的指代能力就很重要了，它需要理解“红色方块”“蓝色圆柱”这些描述，并对应到正确的检测框。我发现在提示词里加入物体的属性列表能显著提升准确率。

第二个扩展是引入力反馈。桌面臂通常没有力传感器，但夹爪电流可以间接反映接触力。我把电流值也作为状态的一部分送给 VLM，让它知道“现在夹得紧不紧”。这个信息在放置易碎物体时特别有用，VLM 可以据此决定释放的高度和速度。

第三个扩展是长程任务。比如“把方块按颜色分类堆叠”，这需要 VLM 做多步规划。我的做法是把任务拆成子目标，每个子目标完成后重新拍图、重新推理。这样虽然增加了推理次数，但每一步的决策难度降低了，整体成功率反而更高。

还有一个有意思的方向是把 Computer-Use 和 Robot-Use 结合起来。比如让 VLM 先在电脑上查资料、生成操作步骤，然后再控制机器人执行。这需要两个 Harness 之间的协调，目前我还在折腾中，但初步测试显示，VLM 在数字世界里的规划能力可以迁移到物理世界，只是需要额外的安全约束。

我个人在实际操作中的体会是，Robot-Use 的难点不在 VLM 本身，而在接口设计和异常处理。VLM 的推理能力已经足够强，只要你能把物理世界的状态准确地翻译给它，再把它的决策安全地翻译回物理世界，整套系统就能跑起来。最后再分享一个小技巧：在 Harness 里加一个“动作回放”功能，把每次执行的图像、状态和动作都存下来，出问题的时候回放一遍，比看日志快得多。