拿到 Show-Harness 这个项目名字的时候，我第一反应是：机器人操作终于开始从一个 VLM 智能体的视角来重新组织了。Show-Harness 的核心说法很直接——只需一个视觉语言模型作为智能体，通过“演示+推理”的方式就能操纵机器人，不需要为每个场景重新训练动作模型，也不需要堆砌几十个专用模块。它把 Harness 当作智能体的“骨架”，负责感知循环、工具调用和动作落地，VLM 负责“看懂画面并决定下一步做什么”。这套思路对做过机器人开发的人来说，冲击力在哪儿呢？传统做法是人写死状态机、写死轨迹规划，场景一变就要重新调参；而 Show-Harness 把机器人从“被程序遥控”变成了“被一个看得懂画面的智能体接管”。这篇文章我会从原理讲起，再给一套可以直接落地的最小系统方案，最后把踩过的坑和调试方法一并整理出来。整个过程用到的技术栈不复杂：一个带视觉能力的多模态大模型、一个 Harness 控制循环、一套机器人动作接口，就能跑通“看一眼、想一步、动一下”的闭环。

1. 先搞懂：为什么“一个 VLM 智能体”能操纵机器人

1.1 传统机器人操作为什么会卡在泛化性上

做过机械臂项目的朋友应该都有这种经历：你花两周时间写好一个抓取流程，包括物体检测、位姿估计、路径规划、抓取姿态计算，调试到一抓一个准，感觉大功告成。结果换一个光照环境、换一个形状接近但颜色不同的工件，或者把工件从“水平摆放”改成“斜着靠墙”，系统立刻失灵。问题不是出在某个模块不够强，而是整条流水线把“感知”和“决策”焊死了——检测模型只能认出训练过的类别，规则引擎只能处理写过的状态，轨迹规划器只能按预设路线走。这种方案的本质是“用程序模拟智能”，遇到长尾场景自然崩。

传统机器人系统还有一个隐含成本：状态表示是私有且脆弱的。你定义了一个结构体，里面存物体坐标、夹爪开合度、任务阶段编号，这些字段一旦在需求变更后对不上，整个逻辑就乱套。而大模型驱动的智能体把状态表示换成了“自然语言 + 视觉图像”，相当于把所有机器人内部细节都翻译成人类可读的形式，再由模型统一推理。这听起来像降级，实际上是把问题从“为每种场景写代码”转变成“为每种场景写描述”，后者的迁移成本低很多。

Show-Harness 给我的第一个启发就在这：它没有试图替代底层运动控制，而是用 VLM 智能体把“任务理解”和“工具调用”这两层重新做了一遍。底层还是那些经典的滤波、插补、动力学控制，但上层决策不再依赖硬编码规则，而是依靠一个能看图、能推理、能调用工具的通用模型。

1.2 VLM 给机器人带来的不是“另一个识别模型”，而是“观察-推理闭环”

VLM（Vision-Language Model）是近几年多模态大模型里最实用的分支。它接收图像或视频帧，再配合文本指令，输出文本回答。你问它“画面里有没有红色方块”，它能答；你问它“红色方块在机械臂左侧还是右侧”，它也能答。传统的目标检测模型只会告诉你“红色方块 bbox 在 (x1,y1,x2,y2)”，但不会告诉你“这个方块看起来像被什么东西压住了，强行抓可能会打滑”。VLM 能把视觉信息、空间关系、物理常识和任务语义放在同一个推理空间里处理，这是它最适合做机器人高层决策的原因。

只靠一个 VLM 还不行，因为模型输出的是文本，不是关节角。Show-Harness 的思路是让 VLM 做“上层大脑”，把它的输出格式化为结构化的动作描述，再交给 Harness 里注册好的工具函数去执行。举个例子，VLM 看完当前相机画面后输出一句“调用 pick 工具，目标物体是红色方块，放在右侧盒子”，Harness 解析这句自然语言或者 JSON 指令，调用后端抓取服务，然后把执行结果返回到模型上下文里。这个过程不是一次性问答，而是循环推进的：观察、推理、执行、再观察、再推理。

这里要特别强调“闭环”。很多人在大模型落地时犯的错是只做一次推理，比如“让 VLM 看一眼图片，直接输出一串动作序列”，然后机械臂照着执行。真实场景不允许这样，因为夹爪可能没抓稳、物体可能被碰倒、手臂运动可能把目标撞偏。Show-Harness 的价值在于把 VLM 放进一个带反馈的智能体循环，每一步动作之后都把最新画面和传感器状态喂回去，模型可以校正自己的判断。这也是为什么项目名称里“Harness”很重要——它才是那个保证“循环不断”的框架。

1.3 Harness 到底是个什么角色

如果你接触过 Agent 开发，应该对 Harness 这个词不陌生。在不少智能体框架里，Harness 指的是“把模型包起来的那层执行环境”：它负责管理上下文窗口、调用工具、处理模型输出、提供推理日志。你可以把 VLM 想象成一个非常聪明但手无缚鸡之力的专家，他坐在控制室里看监控、读资料、做决策，但按钮不在他手边；Harness 就是那套按钮、仪表盘和通信系统，专家说要做什么，Harness 去按按钮，再把结果汇报回来。

Show-Harness 在机器人场景里给 Harness 增加了几个关键职责：第一，维护任务记忆，把“刚才已经完成了什么、还剩什么”记录下来；第二，定义工具白名单，模型只能调用白名单里的动作，比如 move_to、grasp、release、check_pose，不能自己发明动作；第三，做输出校验，模型输出一句不完整的指令时，不让它直接执行，而是要求重试；第四，处理失败回退，动作执行回报异常时，把错误信息整理好送回给 VLM 重新规划。

把这些职责想清楚，你就能理解为什么“只需一个 VLM 智能体即可操纵机器人”这句话不是标题党。它不需要一堆专用模型，也不需要为每个任务重新训练策略网络，只需要一个预训练好的通用 VLM，配合一个设计良好的 Harness，就能在相当宽泛的任务范围内实现机器人操作。当然，这并不意味着所有问题都解决了，精度、实时性、安全约束这些仍然要在 Harness 层补课。

2. Show-Harness 的架构设计与核心细节

2.1 感知-记忆-规划-执行闭环怎么搭

Show-Harness 的整体框架可以拆成四块：感知端、记忆区、规划器、执行器。感知端负责把相机画面、关节角度、夹爪状态、力传感器读数汇总成结构化信息；记忆区保存任务目标、历史动作、当前进度和最近一次错误；规划器由 VLM 承担，接收感知信息和记忆内容，输出下一动作意图；执行器是 Harness 里注册的一组工具函数，把意图变成真实机器人控制指令。四块串起来才是一个闭环。

我在具体实现时会把感知端分成两层。底层是经典算法，比如用 ArUco 码或者点云分割拿到物体粗略位置，用正运动学拿到机械臂末端坐标；上层是大模型描述，比如给 VLM 的 prompt 里拼接“当前夹爪状态：已闭合；机械臂末端坐标：x=0.35, y=-0.1, z=0.42；最近一次动作：移动到 A 点上方；观测结果：目标物体位于右侧区域”。这样 VLM 不需要自己算坐标，只需要基于可靠的底层感知做语义推理。很多人在这一步犯的错是让 VLM 直接读原始图像然后自己算坐标，这在没有内置空间推理微调的前提下非常不可靠，我建议坐标和几何信息交给经典算法，VLM 负责“决定做什么”，而不是“精确算怎么做”。

记忆区要小而精。最忌讳的是把 VLM 当作无限上下文，把几十分钟的对话历史全部塞进 prompt。我的做法是保留三个部分：任务描述的固定摘要、最近三轮动作的简短记录、当前失败原因的标签。比如“任务：把红色方块放到右侧盒子；已完成：移动到方块上方、夹爪闭合；最近一轮：夹爪闭合后再次检测到方块仍在原位，可能抓取失败；下一步：打开夹爪，重新对准”。这种压缩过的记忆既能让模型知道上下文，又不会把推理速度拖垮。

规划器和执行器的衔接是 Harness 的核心。我要求 VLM 输出严格格式的 JSON，字段包括 action（工具名）、params（参数字典）、reason（一句话说明）。Harness 解析 JSON 后，先去工具白名单里查这个 action 是否存在，再对 params 做类型和范围校验，比如“speed 必须在 0.0 到 0.5 之间”，校验通过才真正调用执行器。这样即使模型产生了幻觉指令，Harness 也能兜底拦住。

2.2 VLM 选型与 Prompt 设计的几个关键选择

不是随便拿一个开源 VLM 就能直接上机器人。选型时我会重点看四点：视觉分辨率是否支持细粒度物体识别，是否支持多图或视频输入，长上下文能力是否够用，推理速度能不能跟上闭环频率。做桌面机械臂抓取，物体通常是几厘米到十几厘米大小，模型输入分辨率如果只有 224x224，很容易把相邻物体分不清。推荐优先考虑 Qwen2-VL、MiniCPM-V 这些支持更高分辨率输入的开源模型，或者使用 GPT-4o、Claude 这类闭源 API 做快速验证。真机实时控制如果要求每轮 2 秒内出结果，纯本地 7B 模型用 vLLM 部署能跑，14B 以上就得看 GPU 余量了。

Prompt 设计直接决定 VLM 的输出质量。我会在系统提示词里写清楚：当前场景是“桌面机械臂操作任务”；模型的身份是“任务规划器，不是运动控制器”；必须从工具白名单里选择动作，不能编造新动作；输出必须是合法 JSON，禁止输出解释性长文本；当无法确认下一步时，输出 wait 并附上原因。这些约束看起来简单，实际能减少至少一半的无效输出。每次请求的用户消息部分则包含“当前图像 + 记忆摘要 + 工具列表 + 上一轮执行结果”，图像用 base64 或 URL 传入，记忆摘要用纯文本。

Show-Harness 名字里的“Show”其实指向一个非常实用的技巧：一次演示注入。在 prompt 里给 VLM 放一张“成功演示”的截图，旁边标注“这就是正确做法：先移到物体上方，再下降，然后闭合夹爪”，模型在回答当前问题时就会模仿演示里的动作顺序。这比单纯用文字描述任务要管用得多，因为视觉语言模型对图像对比和动作序列的迁移能力比纯文本强。演示不一定要很多，一两张典型状态图就能把任务意图表达清楚，这也是“Show”能撑住整个项目名字的原因。

2.3 动作工具接口与安全阀

Harness 里注册的工具接口要设计成“小颗粒、白名单、可观测”。小颗粒的意思是每个工具只做一件简单事，比如 move_to(x, y, z)、open_gripper()、close_gripper()、get_pose()、check_grasp()。如果工具太复杂，比如一个 “do_task()”，VLM 就无法在中间步骤进行干预，闭环就断了。白名单很容易理解，模型只能调用注册过的函数，任何未匹配的 action 直接拒绝。可观测性是指每个工具被调用时都写入日志，包括调用参数、开始时间、结束时间、返回值、异常信息，这些日志既用于调试，也用于在出错时回灌给 VLM。

安全阀必须放在 Harness 层而不是模型层。我不会相信 VLM 每时每刻都保持谨慎，所以要强制在工具执行前做物理安全校验：速度上限、加速度上限、工作空间边界、夹爪夹紧力上限。move_to 的目标点如果超出机械臂可达范围，Harness 直接拒绝并回传“目标点不可达”；close_gripper 之后如果力传感器显示夹紧力异常，就自动停止并标记失败。这样即使 VLM 规划错了，物理设备也不会硬来。

3. 实操：搭一个 Show-Harness 风格的最小系统

3.1 环境准备：一台 GPU 机器、一个机械臂或仿真器

我建议第一次跑通 Show-Harness 用仿真环境，原因很简单：真机调试时机械臂乱动很危险，而且 VLM 推理延迟会放大不确定性。仿真推荐用 Gazebo + MoveIt 或者 Isaac Sim，RoboSuite 这类开源的桌面操作环境也可以。如果你手上只有真机，一定要确保有急停按钮，并把速度上限设到安全的 20% 以内。操作系统我用的 Ubuntu 22.04，ROS2 Humble，Python 3.10，机械臂模型用的一个六轴协作臂，夹爪是两指平行夹爪，相机固定朝下安装，分辨率 1280x720。

软件依赖主要包括几个部分：VLM 推理服务用 vLLM 部署，加载 Qwen2-VL-7B-Instruct；机器人控制用 ROS2 action；通信层用一个简单的 Python 服务进程把 VLM 和机器人连起来。如果你不想用 ROS2，也可以直接调用机械臂厂商的 Python SDK，比如对接真实机械臂的 SDK，逻辑是一样的，只是工具函数内部实现不同。

记得先做一次底层自检。手动发几个 move_to 指令，确认机械臂能正常运动到指定坐标；手动开合夹爪，确认反馈状态准确；拍一张当前画面，确认图像能实时传入推理服务。这些基础能力不稳，后面所有问题都会难以定位，所以不要省这一步。

3.2 部署 VLM 推理服务：以 Qwen2-VL 为例

本地部署 Qwen2-VL 我用的是 vLLM 的 OpenAI 兼容接口，这样在代码里可以直接用 openai 客户端调用，后续想换成 GPT-4o 或者别的模型，只改 base_url 和模型名就行。启动命令大致如下：

python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2-VL-7B-Instruct \ --dtype bfloat16 \ --max-model-len 8192 \ --limit-mm-per-prompt 'image=4' \ --port 8000

这里关键参数是 limit-mm-per-prompt，我设置为 image=4，表示每次请求最多带 4 张图片。机器人闭环里通常不会超过这个数量，一张当前画面、一张成功演示、一张历史关键帧，就够了。max-model-len 设 8192，够上下文记忆加工具描述使用，太大推理会变慢。

启动成功后，可以用一个简单的 Python 脚本验证服务能返回结果。注意请求图片字段格式。

from openai import OpenAI import base64 client = OpenAI(base_url="http://localhost:8000/v1", api_key="unused") def encode_image(path): with open(path, "rb") as f: return base64.b64encode(f.read()).decode("utf-8") resp = client.chat.completions.create( model="Qwen/Qwen2-VL-7B-Instruct", messages=[ { "role": "user", "content": [ {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{encode_image('test.jpg')}"}}, {"type": "text", "text": "描述画面中的物体和相对位置。"}, ], } ], max_tokens=256, ) print(resp.choices[0].message.content)

这一步如果跑通，说明推理服务没问题，可以进入下一节写 Harness 循环。实测下来，7B 模型在单张 A100 或者 4090 上，单轮带图推理大约在 1 到 3 秒，桌面操作场景可以接受。如果用的是 CPU 推理，基本没法做闭环，强烈建议至少搞一块消费级 GPU。

3.3 编写 Harness 控制循环：核心代码逐段拆解

最小系统的控制循环不复杂，核心就是轮询：拍照、组装 prompt、调 VLM、解析 JSON、执行工具、收集反馈、写入记忆。我用一个 Python 类来组织代码，先定义工具函数，再写主循环。

class ToolRegistry: def __init__(self): self.tools = {} self.logs = [] def register(self, name, func, param_schema=None): self.tools[name] = {"func": func, "schema": param_schema or {}} def call(self, name, params): if name not in self.tools: return {"ok": False, "error": f"unknown tool: {name}"} self.logs.append({"tool": name, "params": params}) try: result = self.tools[name]["func"](**params) return {"ok": True, "result": result} except Exception as e: return {"ok": False, "error": str(e)}

工具注册的好处是，VLM 能看到的工具列表可以直接从注册表生成。接下来定义几个机器人动作工具，在仿真里它们调用 ROS2 action 客户端，代码里简化成打印加反馈模拟。

def move_to(x, y, z, speed=0.2): # 这里应调用 ROS2 action client 或机械臂 SDK # 返回最终末端坐标，用于闭环校验 return {"x": x, "y": y, "z": z} def open_gripper(): return {"gripper_state": "open"} def close_gripper(): return {"gripper_state": "closed", "force": 5.2} def get_object_pose(name): # 返回物体位置估计，实际项目中可以由感知模块提供 return {"x": 0.30, "y": 0.10, "z": 0.02} registry = ToolRegistry() registry.register("move_to", move_to, param_schema={"x": float, "y": float, "z": float, "speed": float}) registry.register("open_gripper", open_gripper) registry.register("close_gripper", close_gripper) registry.register("get_object_pose", get_object_pose)

工具列表生成后，主循环里拼 prompt。这里有几个容易忽视的细节：一是上一轮执行的结果必须原始透传给模型，不要替它做太多总结，让模型自己理解错误信息；二是把工具列表放在每次请求里，格式要稳定；三是要求模型输出一个 JSON 对象，不要带 markdown 代码块标记，方便解析。

def build_prompt(image_b64, memory_str, tool_list, exec_result): system = { "role": "system", "content": "你是一个机械臂任务规划器。你只能从工具列表中选择动作，并输出 JSON。" "JSON 格式: {\"action\": \"工具名\", \"params\": {...}, \"reason\": \"简短原因\"}。" "不要输出其他文字。", } user_text = f"记忆摘要:\n{memory_str}\n\n工具列表:\n{tool_list}\n\n上一轮执行结果:\n{exec_result}\n\n请决定下一步。" user = { "role": "user", "content": [ {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_b64}"}}, {"type": "text", "text": user_text}, ], } return [system, user]

主循环我设置了最大步数上限，默认 20 步，超过就停止并输出失败报告，防止 VLM 陷入死循环。每一步流程如下：拍摄当前画面 -> 调用 VLM -> 解析输出 -> 如果 JSON 解析失败，重试最多三次 -> 调用工具 -> 把结果追加到记忆 -> 判断任务完成条件。

import json def run_harness(max_steps=20): memory = {"done": [], "last_feedback": "none"} for step in range(max_steps): image_b64 = camera.capture() # 自定义函数 prompt = build_prompt(image_b64, json.dumps(memory), registry.get_tool_names(), memory["last_feedback"]) reply = vlm_chat(prompt) # 上一节中的openai调用 parsed = parse_vlm_json(reply) if not parsed: memory["last_feedback"] = "模型输出无法解析，请重新输出JSON" continue action = parsed.get("action") params = parsed.get("params", {}) result = registry.call(action, params) memory["done"].append({"action": action, "params": params, "result": result}) memory["last_feedback"] = json.dumps(result) if action == "close_gripper" and result.get("ok"): # 简化完成判断：在真实任务中要检测目标是否落入目标区域 print("task finished at step", step) break

这里有个非常值得调的点：parse_vlm_json。VLM 经常会在 JSON 前后加一些解释性文字，或者把单引号当成双引号用。我建议不要用强正则，而是先提取第一个 { 到最后一个 } 之间的子串，然后 json.loads，失败再用宽松模式匹配 action 和 params 字段。宽松模式本质上是从回复文本里找动作名和参数列表，返回一个可能不完整的 JSON。这个兜底逻辑在演示和初跑阶段非常有用。

3.4 把动作执行器接到真实机器人或 ROS2

仿真跑通后，接真机其实只改工具函数内部实现。比如 move_to 原本是打印坐标，现在改成调用 ROS2 action client 或者机械臂 SDK。我建议把机器人控制封装成独立服务，通过 gRPC 或 ROS2 通信，避免 Harness 进程直接持有机械臂连接，这样隔离性更好，Harness 崩溃了不会把机械臂留在危险状态。如果使用 ROS2，可以在工具函数里发 action goal：

import rclpy from rclpy.action import ActionClient from control_msgs.action import FollowJointTrajectory def move_to(x, y, z, speed=0.2): # 创建 action client 并向机械臂控制器发送目标 goal = FollowJointTrajectory.Goal() # 填充末端坐标对应关节角，这里通常需要运动学逆解 # 如果使用 MoveIt 的 Cartesian path，则填路径点 return send_goal(goal)

注意逆解问题。VLM 输出的坐标是任务空间坐标，但机械臂执行需要关节角。我的做法是不让 VLM 处理关节角，而是由底层运动控制器完成逆解。如果逆解失败，就把错误信息返回给 Harness，VLM 看到“目标点不可达”就会换一个目标点。这个设计非常重要，它屏蔽了机器人运动学细节，让模型专注于高层语义。

真机接入后，一定要在代码里加软限位检查。move_to 执行前先判断目标坐标是否在机械臂工作空间内，比如 x 在 0.2 到 0.6 之间，y 在 -0.4 到 0.4 之间，z 在 0.0 到 0.6 之间，超范围就拒绝执行。加上这个检查，VLM 有空间幻觉时最多是报错，不会把机械臂送到奇怪位置。

3.5 跑通“抓取红色方块”任务：一次演示注入的完整案例

我用一个简单任务验证整个闭环：桌面上有一个红色方块，机械臂需要把它抓到右侧的盒子里。任务开始前，我先拍一张红色方块在桌面中央的图片，标注好“这是正确示范：末端移动到方块正上方 -> 下降 -> 闭合夹爪 -> 抬升 -> 移动到右侧盒子上方 -> 张开夹爪”。这张图片和文字作为演示注入到系统 prompt 或第一轮请求里。

实际运行中 VLM 第一轮输出通常是 move_to 到方块上方坐标，这个坐标哪里来的呢？如果感知模块已经通过视觉检测给出了物体坐标，我会把坐标放在记忆或工具列表里，比如在 get_object_pose 工具说明中注明返回当前物体坐标。VLM 看到物体坐标后，调用 get_object_pose 获取坐标，再调用 move_to 到上方，然后 close_gripper。此时如果夹爪反馈 force 太小或者检测到夹爪内没有物体，Harness 会把失败反馈给 VLM，VLM 会尝试重新调整位置或者换个角度抓取。

这个任务跑通后，我建议做两个变体验证泛化性：把红色方块换成绿色方块，或者把方块位置移到桌面边缘。正常情况下，只要视觉检测能给出新坐标，VLM 就能顺着同样的演示逻辑完成任务，不需要重新训练任何模型。这就是“只需一个 VLM 智能体即可操纵机器人”的真实含义：模型本身没变，变的只是环境输入和记忆内容。

4. 踩坑记录与调试口诀：Show-Harness 常见问题速查

4.1 常见问题速查表

下面这张表是我在跑 Show-Harness 过程中遇到的高频问题，按“现象-可能原因-排查手段-设置建议”整理。每次系统行为诡异时，我都会先对着表格过一遍。

这些问题的根源大多是同一个：职责边界不清。VLM 擅长的是“基于当前画面的语义决策”，不擅长“精确测量”和“记忆大量细节”。Harness 的角色就是帮它补上这两块短板。调试时我第一件事就是看监控日志里的“工具输入输出”，确认是不是有工具被传入异常参数，这个基本能排除一大半问题。

4.2 我的五条调试经验

第一条，先跑模拟器，再上真机。模拟器里出错没有成本，而且可以随时重置状态。我见过太多人直接拿真机调 VLM，结果模型输出一个飞出工作空间的坐标，机械臂直接朝桌面砸下去，好在有软限位才没出事故。第二步一定要加物理级安全限制，尤其速度上限和空间边界。

第二条，动作粒度要小。move_to 一次只移动一小段，不要指望 VLM 生成一个完整的轨迹点序列。小粒度动作虽然会增加循环次数，但每次动作都有反馈，模型就能及时纠偏。实测下来，桌面抓取任务平均要 8 到 15 步，比传统脚本慢很多，但胜在鲁棒。

第三条，反馈信息要具体。执行器返回“ok: false”是不够的，要让工具函数返回详细的错误码和状态快照，比如“返回坐标超出工作空间 x=0.85, 最大值0.6”。模型看到具体数字才能调整自己的判断。示范：错误信息里包含“当前夹爪力为 0.3N，疑似空抓”这类可行动的描述。

第四条，准备一套录制回放工具。把每一轮的图像、prompt、模型 raw 输出、工具调用结果全部记录成 JSONL 文件。当任务失败时回放这些日志，通常能一眼看出是哪一步导致跑偏。这也是 Harness 比传统状态机容易调试的优势，整个推理轨迹都是可读的。

第五条，温度参数调低。VLM 做机器人决策时不需要创造力，temperature 设置在 0.1 到 0.2 之间最合适。太高会随机输出不稳定的动作，太低又可能重复同一个动作。另外可以把 top_p 也调到 0.9 以下，减少随机性。

4.3 安全硬约束不能靠模型自觉

我做 Show-Harness 项目时给自己定了一条铁律：物理世界不可逆动作必须由 Harness 把守，VLM 只能负责“建议”，不能负责“决定”是否执行高危险动作。具体到代码里，会给工具调用加一个三层检查：第一层是静态白名单和参数范围校验；第二层是当前状态校验，比如移动前必须知道末端当前位置，夹爪闭合前必须确认夹爪处于打开状态；第三层是外部急停和软限位，防住前两层都失效的情况。

在真机上尤其要注意：夹爪夹紧力要限幅，防止捏碎工件；机械臂移动速度不能超过预设定值；工具调用频率要限流，避免 VLM 在死循环里连续给机械臂发指令。即使这些都做了，我还是建议人在回路上保留一个“最后确认”机制，尤其是遇到新的、之前没试过的任务时，让开发的确认按钮通过审批后工具才真正下发，熟练之后再放开。

5. 从“最小系统”到真实部署：还能扩展什么

5.1 空间场景扩展：从桌面机械臂到移动机器人

Show-Harness 的思维方式不限于固定机械臂。移动机器人导航场景里，同样可以用一个 VLM 智能体去处理“看懂环境、决定下一步去哪、调用导航工具”的任务。比如巡检机器人拍摄到走廊尽头有障碍物，VLM 判断需要绕行，Harness 调用导航重规划服务，把新路径点返回给底盘控制器。和机械臂的区别主要是动作工具换了一批：移动、转向、避障、等待、请求远程帮助。

我在个人项目里试过把 Show-Harness 的框架移植到四轮机器人上，效果比预期好很多。因为导航任务本身就是语义驱动的，VLM 可以理解“前方蓝色门牌写着仓库，应该右转”这种对话级别的信息，而传统导航系统需要接入文本识别和地点映射，集成成本高很多。VLM 直接把图像和语义连起来，减少了中间对齐步骤。

当然要清醒认识局限。VLM 在精度要求高的场景，比如毫米级装配、力控打磨，完全不适合做决策层。它适合的是语义明确、容错率较高的任务，比如搬运、分拣、巡检、服务机器人交互。真实落地时，可以用 VLM 做全局决策，底层用经典控制做局部精调，两者各司其职。

5.2 框架扩展方向：记忆增强、多智能体协同与人工监督

最小系统里我用的是简单字符串记忆，实际任务复杂以后，可以升级成结构化的“任务黑板”。黑板是一个共享状态表，包含目标状态、当前状态、已尝试过的动作、失败原因标签。VLM 每次推理前读取黑板，动作完成后更新黑板。这比把整个历史塞进 prompt 要稳定得多，也方便接入多智能体协作，因为多个智能体可以在同一块黑板上读写信息。

多智能体协同是 Show-Harness 很自然的扩展方向。比如一个机器人负责看全局，另一个负责精细操作，二者通过一个共享 Harness 交换信息。或者“调度智能体”拆任务给“执行智能体”，执行智能体只关注自己手里的动作工具。这样的结构比单个 VLM 塞满上下文更有扩展性。

还有一点值得投入：人工反馈接管机制。当 Harness 检测到连续失败步数超过阈值时，自动暂停并请求人类介入。人类通过自然语言或其他指令直接告诉系统下一步怎么走，走完一步之后系统再交还给 VLM 继续自治。人机协同的“人在回路”模式，在真实部署中比纯自治可靠得多，也能在项目初期积累大量修正数据，反哺 prompt 设计和模型微调。

最后再分享一个我反复摸出来的小细节：给工具函数起名时，一定要用“动作 + 对象”的明确格式，比如 move_to、open_gripper、close_gripper，不要用含义模糊的 do_action 或者 execute_step。VLM 对语义清晰的工具名理解准确率远高于抽象名称，有时一行好名字，能省下几十次无效重试。顺着这个方向继续往下做，你会发现 Show-Harness 真正撬动的不是某个模型参数，而是把机器人开发范式从“手写规则”变成了“定义工具、提供演示、验证闭环”三层架构，而这种事情，一旦上手就很难再退回旧方式了。