1. 为什么更强的模型不再是唯一答案过去两年我参与过好几个机器人操作和物理仿真相关的项目从最早的纯视觉抓取到后来的语言指令驱动机器人再到最近这一波 VLAVision-Language-Action模型的落地尝试。有一个感受越来越强烈模型本身的能力提升和系统整体表现之间存在一条巨大的鸿沟。这条鸿沟不是靠换一个更大的 LLM 或者训一个更强的 VLA 就能填上的。我见过太多团队把 80% 的精力砸在模型选型和微调上结果部署到真实环境里成功率惨不忍睹。问题出在哪出在模型外面那一圈东西——我把它统称为Harness。所谓 Harness直译是马具挽具在软件工程里它指的是包裹在核心逻辑外面、负责调度、约束、容错、观测的那一层基础设施。放到机器人和物理 Agent 的场景里Harness 就是那个把 LLM 的文本输出翻译成机器人可执行动作、把传感器数据整理成模型能吃的格式、在动作失败时决定重试还是放弃、在长任务里维护状态和记忆的操作系统层。这个标题想聊的核心就是从更强的模型到更好的系统这个范式转移。它适合谁看如果你正在做 Agent 开发、机器人学习入门、VLA 模型落地或者你只是好奇为什么 demo 很惊艳但产品很拉胯这篇内容应该能给你一些实在的参考。我会尽量把 Harness 这个抽象概念拆成能上手的东西而不是停留在架构图上。先说一个反直觉的结论在很多物理 Agent 任务里一个中等能力的模型配一套精心设计的 Harness表现会稳定超过一个顶级模型配一套粗糙的 Harness。这不是玄学后面我会用具体的机制来解释为什么。2. Harness 到底管什么拆开那层被忽视的操作系统很多人第一次听到 Harness 这个词会懵觉得它和 Agent 框架、和 LLM 编排orchestration有什么区别。我自己的理解是Agent 框架更偏向能力组织比如怎么定义工具、怎么串联多个 Agent而 Harness 更偏向运行保障它关心的是这个系统在真实、嘈杂、会出错的环境里能不能稳定跑下去。两者有重叠但侧重点不同。2.1 从一次失败的抓取任务说起我拿一个真实踩过的坑来开场。当时我们做一个把桌上的杯子放进托盘的任务用的是某开源 VLA 模型输入是 RGB 图像加一句自然语言指令输出是末端执行器的位姿增量。在仿真里成功率能到 85%一上真机就掉到 40% 出头。排查了两周最后发现问题根本不在模型。真机上的光照和仿真差异导致图像分布偏移模型输出的位姿抖动很大而我们的执行层是模型输出什么就直接执行什么没有任何平滑、没有失败检测、没有重试。杯子抓空一次整个任务就卡死在那里因为 Harness 里根本没有判断这次抓取是否成功的逻辑。后来我们加了三样东西动作平滑滤波、基于力反馈的抓取成功检测、以及一个简单的重试状态机。模型一个字没改真机成功率直接回到 70% 以上。这就是 Harness 的价值——它不提升模型的上限但它决定了模型的下限能不能被守住。2.2 Harness 的五个核心职责把上面这个案例抽象一下我认为一个物理 Agent 的 Harness 至少要承担五件事我列个表方便对照职责具体内容缺失后的典型症状输入整形传感器数据对齐、归一化、时序同步模型输入分布漂移输出抖动输出翻译把模型输出转成可执行动作、限幅、平滑动作突变、超出机械限位状态管理维护任务进度、记忆、上下文长任务中途失忆重复动作容错恢复失败检测、重试、降级、回滚一次失败导致整个任务卡死可观测性日志、指标、回放、调试接口出问题无法定位只能瞎猜这五件事里容错恢复和可观测性是最容易被忽略的因为它们不产生 demo 里的惊艳效果只在出问题的时候才体现价值。但恰恰是这两块决定了系统能不能从实验室走到真实场景。2.3 Harness 和 Agent 框架的边界在哪经常有人问harness 和 agent 区别到底是什么。我的划分方式是Agent 框架回答这个系统能做什么Harness 回答这个系统怎么稳定地做。举个例子你用某个 Agent 框架定义了一个导航到目标点的工具这是 Agent 层的事但这个工具调用超时了怎么办、返回的坐标超出地图范围怎么办、连续三次导航失败要不要切换策略这些是 Harness 层的事。实际项目里两者往往是混在一起实现的但心里要有这条分界线。因为当你把稳定性问题误当成能力问题去解决时就会陷入不断换模型、不断调 prompt的死循环而真正的病根在 Harness 里。3. VLA 模型接入 Harness 时的真实摩擦点VLA 是这两年被讨论很多的模型形态它把视觉、语言、动作统一到一个模型里。热词里vla 模型是一个模型还是 2 个模型vla 是怎样训练的这些问题说明大家对它的结构还比较模糊。我先用一句话说清楚VLA 通常是一个多模态模型视觉和语言作为输入编码动作作为输出解码但工程上经常拆成感知编码器 动作解码器两段来部署。所以它既可以说是一个模型也可以说是两个模块取决于你从训练视角还是部署视角看。3.1 模型输出不是动作是动作的意图这是接入时最大的认知误区。VLA 模型输出的往往是一个动作分布或者一段动作序列的 token它表达的是意图不是指令。比如模型输出向右移动但右移多少、以什么速度、遇到障碍怎么办这些都得 Harness 来补。我一般会在 Harness 里加一层动作解释器把模型的粗粒度输出翻译成带参数的、可执行的控制指令。这一层要处理的事情包括单位换算模型可能用归一化坐标机器人用米或弧度、坐标系变换相机坐标系到基座坐标系、速度限幅保护机械结构、以及轨迹插值模型给的是目标点执行需要连续轨迹。提示动作解释器这一层一定要做成可配置的不同机器人、不同任务需要的变换差别很大硬编码进去后期改起来非常痛苦。3.2 时序对齐被低估的稳定性杀手物理 Agent 和纯文本 Agent 最大的区别是它有实时性要求。视觉帧率、控制频率、模型推理耗时这三者的节奏往往对不上。我遇到过模型推理要 200ms但控制循环是 50ms 一次的情况如果不做处理控制循环就会读到重复的旧动作表现为机器人一顿一顿的。Harness 里需要一个时序缓冲与插值模块。常见做法是维护一个动作队列控制循环从队列里取动作队列空了就用上一个动作做外推或者减速停止。这个模块写起来不复杂但没有它系统在负载波动时就会表现得极不稳定。3.3 模型置信度怎么用很多 VLA 模型会输出动作的置信度或者方差。这个信息在 Harness 里非常有用置信度低的时候可以降低执行速度、请求更多观测、或者直接触发重试。我见过不少项目把置信度直接丢掉只取 argmax 的动作等于浪费了模型提供的一个重要的自我怀疑信号。我的做法是设一个置信度阈值低于阈值时进入谨慎模式动作幅度减半、增加一次额外的视觉确认。实测下来这个简单的策略能把误操作率降下来不少代价只是任务稍微慢一点。4. 长任务里的状态管理Agent 为什么会失忆物理 Agent 经常要执行多步骤的长任务比如先清理桌面再把物品分类放进抽屉最后关上抽屉。这类任务里状态管理是 Harness 的核心难点也是agent execution terminated due to error这类报错的高发区。4.1 上下文窗口装不下整个任务历史LLM 的上下文是有限的物理 Agent 跑一个长任务可能产生几千帧观测和几百次动作。全塞进上下文既不现实也没必要。Harness 需要做状态压缩把历史观测提炼成结构化的任务状态比如已完成步骤列表当前子目标已知的障碍物位置。我常用的做法是维护一个显式的状态对象用 JSON 或者类似结构存关键信息每次调用模型时只把当前状态和最近几帧观测喂进去。这样上下文占用可控而且状态是可读的调试的时候一眼就能看出系统以为自己在哪一步。4.2 子目标分解与回退长任务一定要做子目标分解而且每个子目标要有明确的成功判据。这样当某个子目标失败时Harness 可以回退到上一个稳定状态重试而不是整个任务从头再来。这里有个经验子目标的粒度要适中。太粗失败后回退代价大太细状态机复杂度爆炸而且频繁的模型调用会拖慢整体节奏。我一般按一次可观测的物理状态变化来切分比如抓取成功放置到位这种。4.3 记忆的持久化如果任务跨越较长时间或者需要跨会话状态还得持久化到磁盘。我踩过一个坑把状态只存在内存里结果进程崩溃重启后机器人完全不知道自己刚才在干什么直接从头开始把已经整理好的东西又弄乱了。后来加了定期快照重启后能从最近的稳定状态恢复体验好很多。5. 容错设计让系统在出错时优雅地烂容错是 Harness 里最考验工程功力的部分。我的原则是假设一切都会出错然后为每种错误准备一个体面的退路。5.1 失败检测的三种信号源判断一个动作是否失败不能只靠模型自己说。我一般综合三类信号物理信号力传感器、电流、关节位置误差。抓取时力反馈突然归零基本就是抓空了。视觉信号动作执行前后的图像对比。如果目标物体位置没变说明动作没生效。逻辑信号超时、越界、状态不一致。比如导航指令发出后 10 秒位置没变化。单一信号容易误判多信号交叉验证会稳很多。比如力反馈归零加上视觉确认物体没动才能比较确信是抓取失败。5.2 重试策略不是简单的再来一次重试要有变化否则大概率还是失败。我常用的策略是带扰动的重试第二次尝试时稍微改变抓取角度、或者换个接近方向。如果连续三次都失败就降级——比如放弃这个物体标记为无法处理继续下一个。注意重试次数一定要设上限并且要有全局超时。我见过因为重试逻辑没上限机器人在一个抓取失败的动作上死循环了半小时直到有人手动断电。5.3 安全兜底永远在 Harness 层不管模型多聪明安全兜底必须放在 Harness 里而且要是确定性的、不依赖模型的逻辑。比如关节限位检查、速度上限、碰撞前的紧急停止。这些逻辑用最简单的 if-else 写就行不要试图让模型来判断我是不是要撞了那个延迟和不确定性在安全场景里是不可接受的。6. 可观测性出问题时你能看到什么一个没有可观测性的 Agent 系统出问题的时候你就是盲人摸象。我坚持在 Harness 里做三件事结构化日志、关键指标、以及可回放的数据记录。6.1 结构化日志要记什么不要只记出错了要记清楚出错时的完整上下文当前任务状态、最近几次模型输入输出、传感器读数、执行的动作。我一般用 JSON 格式打日志每条记录带时间戳和任务 ID方便后续用脚本分析。6.2 关键指标至少监控这几个任务成功率、平均完成时间、模型调用延迟、重试次数、失败类型分布。这些指标能帮你快速定位系统瓶颈。比如模型调用延迟突然升高可能是推理资源被抢占了重试次数上升可能是环境发生了变化。6.3 数据回放把传感器数据和动作序列录下来出问题后能离线回放这是排查疑难问题的利器。我遇到过一个只在特定光照下出现的抓取失败靠回放录像才定位到是反光导致视觉误判。没有回放这种问题基本无解。7. 从 Demo 到产品Harness 工程的取舍经验最后聊点更宏观的。做物理 Agent从 demo 到产品之间隔着的就是 Harness 工程。我总结几条自己的取舍经验。第一不要追求一步到位。Harness 是长出来的不是设计出来的。先跑通最小闭环然后根据实际暴露的问题逐步加模块。一上来就设计一个完美架构大概率会过度工程。第二模型和 Harness 要解耦。让 Harness 通过一个清晰的接口调用模型这样换模型的时候不用动 Harness。我见过模型和业务逻辑深度耦合的代码换个模型要改几百行非常痛苦。第三把调试能力当成一等公民。开发阶段多花时间做日志、回放、可视化后期排查问题省下的时间远超投入。物理 Agent 的问题往往偶发、难复现没有好的调试工具就是大海捞针。第四接受不完美。真实环境里没有 100% 的成功率。Harness 的目标不是消灭失败而是让失败可控、可恢复、可观测。一个能优雅处理失败的 70% 成功率系统比一个失败就崩溃的 90% 成功率系统更有产品价值。我自己在实际项目里最大的体会是当你把注意力从怎么让模型更聪明转移到怎么让系统更稳时很多之前觉得无解的问题会突然有了出路。模型是引擎Harness 是底盘和传动系统。引擎再强底盘不行车也跑不起来。这个道理做物理 Agent 的人迟早都会懂早懂早省事。
