最近大半年我一直在折腾机器人侧的模型落地，有两个现象特别有意思：一个是不少人还在执着地拼模型参数，觉得模型一换、任务全通；另一个是真正把机器人顶到实际环境里跑的团队，反而把大量精力花在模型外面那一层壳上。这个壳，其实就是题目里说的 Agent Harness。对物理智能来说，Harness 不是可有可无的皮囊，它决定了模型能不能把智慧真正“倒”进电机、关节、轮子和传感器组成的现实系统里。
这篇内容不是泛泛聊概念，而是我从项目里抽出来的模型与 Harness 综合对比复盘：它是什么、和普通 Agent 有什么区别、为什么从“更强的模型”转向“更好的系统”反而是当前更值得做的工程投入，以及我在对比实验和真机调试中踩过的坑。适合正在做机器人上大模型、或者做具身智能中控的工程师参考，也适合想搞明白“模型之外还有哪些决定成败的环节”的人读。
1. 先搞清楚：物理 Agent Harness 到底是什么
1.1 它与 Agent 的区别和边界
“Harness”这个词最早在网络里指的是安全绑带、安全带，引入到 Agent 领域之后，意思慢慢变成了“模型外面那一整套运行时工程结构”。常规理解里，一个 LLM Agent 由模型、提示词、工具调用循环组成，模型收到请求，决定调用哪个工具，拿到结果继续推理。这层结构对聊天、知识库、网页操作没问题，因为环境是符号化的，错误可以反复重试，最多浪费一点 token。
但物理 Agent 不是这个玩法。机器人要处理的是连续的、带噪声的、时间敏感的物理世界。模型输出“把杯子往左移 5 厘米”只是一行文字，接下来谁去把这条文字转成关节角度？谁去平滑速度曲线？谁去判断杯子真的被抓稳了？谁去处理抓空之后的重试？这些全都得靠 Harness。所以我的定义很直白：物理 Agent Harness，是包裹在模型外面的、与真实机器人强相关的运行时层，负责感知对齐、动作映射、状态管理、安全约束、错误恢复和评测闭环。
有一个容易混淆的点：它不是一个“框架”，虽然很多框架实现了 Harness 的一部分能力。ROS、Isaac Lab、MoveIt 这些工具扮演的是执行能力层，而 Harness 要负责的是把模型的高级意图翻译成可执行任务，再把执行结果翻译回模型能理解的观测。这层“翻译+保险”才是我认为需要单独拉出来研究的东西，因为大多数失败都不发生在模型推理环节，而是发生在翻译和执行的缝隙里。
1.2 为什么不是“换更强的模型”这么简单
我见过一个很有意思的现象：一个机械臂抓取任务，基线系统成功率 70%，大家第一反应是换更强基座模型。换了之后数据集、prompt 全部重调，成功率爬到 76%，成本加了三倍。后来我什么都没动，只修了两个 Harness 里的问题——一个是对齐传感器时间戳，另一个是在夹爪闭合时增加力反馈判定——成功率直接跳到 88%。这个对比瞬间让我明白，模型是上限，Harness 是下限，而真实项目里决定产品能不能用的，往往是下限。
这不是说模型不重要。很强的模型确实能理解更复杂的任务、生成更合理的规划，但如果下游执行层没有建立反馈闭环，模型再聪明也只会“想当然”。物理世界和文字世界不同，它充满摩擦系数变化、关节限位、意外碰撞、传感器漂移。这些问题，你给它再大的模型也不会直接消失，但一个把状态机、安全限位、重试策略组织好的 Harness 可以即刻cover 住。
另外还有一层更实际的考量：更换模型是有沉没成本的。大模型迭代快，每次换模型都要重新评测、重新调 prompt，甚至调整工具定义。而好的 Harness 可以做到比较干净的模型无关，让你今天接 GPT 系，明天接开源模型，后天接自家微调模型，所有感知和动作契约不变。这带来的工程杠杆，比单纯“追模型版本”要大得多。
2. 从“更强的模型”到“更好的系统”：转变的逻辑
2.1 强模型解决了什么，没解决什么
必须承认，模型变强的收益非常直观。指令理解更准、上下文更长、多模态能力更强，这让机器人能够处理“把桌上的红色杯子放到蓝色托盘里”这种带属性绑定的复合指令，也让它能按自然语言生成粗略的任务步骤。这些能力在旧版模型上需要写大量规则才能完成，现在一个 prompt 就能搞定。可以说，模型决定了智能的“上限”，也就是它理论上能理解多复杂的任务。
但模型没有解决的是“稳定地把理解变成动作”。这是很多做 Demo 很酷、做产品就崩的根本原因。模型输出是概率性的，同样的指令今天生成的动作序列还不错，明天可能因为输入措辞变化就换了个思路；模型也不清楚真实的关节角度范围，它可能规划出一条理论上合理、实际上超出限位的轨迹。模型更不知道执行器刚才打滑了、夹爪已经老化了、轮子空转了。这些事情，模型不具备感知能力，也不应该是模型去负责的内容，它们天然属于 Harness 的领域。
所以转变的逻辑非常清楚：不是“模型不行”，而是“单靠模型不够”。如果你把系统当成一个整体看待，模型的升级只是其中一个变量，Harness 的水平决定了这个变量的价值能发挥出多少。
2.2 物理世界给系统增加的五个不确定性
做物理 Agent 最难受的一点是，几乎所有问题都是耦合的。我在项目里总结出五个最典型的不确定性，它们每一项都能让一个“聪明”模型变得束手无策。
第一是观测噪声。IMU 有漂移、视觉有反光遮挡、编码器有累计误差。模型直接拿原始观测去理解世界，几乎一定会产生错误判断。第二是时间延迟。从传感器读数到模型拿到数据，再到模型输出指令到达电机，这中间可能隔了几十到几百毫秒，对高速控制来说这是灾难。第三是执行误差。关节指令发送后，实际运动轨迹与期望轨迹有偏差，累积起来任务就偏了。第四是环境动态变化。桌面突然被碰了一下、光照变化、目标物体移动，模型对环境状态的假设瞬间失效。第五是安全边界。电机过流、关节碰撞、重心失稳，这些不是“错了重试”就能解决的，需要实时防护。
Harness 要做的，本质上就是把这几类不确定性变成可管理模块。它不追求模型一次性理解所有情况，而是给模型提供一份“被过滤后的、对齐过时间轴的、相对稳定的世界快照”，同时把不安全动作在到达执行器之前拦掉。
2.3 模型、Harness、机器人本体三者的协作边界
我习惯把整条链路画成三块：模型负责“意图生成”，Harness 负责“意图执行”，机器人本体负责“物理响应”。三者之间有明确的接口契约。
模型侧输出的是高层任务描述，比如“移动到位置A，抓取物体B，放到位置C”，或者是专家策略模块给出的动作意图；Harness 侧把它拆解成可验证的子目标、绑定具体传感器、检查前置条件、规划安全轨迹、监控执行状态；机器人本体侧只负责执行底层控制指令，把关节状态、力矩信息、接触信息上报。
这个分工里最容易翻车的地方是：模型和 Harness 之间没有共同的“状态语言”。模型说“抓稳了”，Harness 需要知道这句话对应夹爪电流阈值还是位置偏差阈值。模型说“移动”，Harness 需要明确是全速直行还是带避障规划。没有这套接口契约，模型输出越强，越容易造成工程灾难。我见过一个产品搞了很强的大模型规划层，结果 Harness 跟不上模型的理解速度，机器人都快撞上了，上层还没发下一条指令，就是因为接口定义太粗。
3. 一个可落地的 Harness 架构参考
3.1 感知对齐与状态估计
我搭建 Harness 时最先做的是感知对齐层。这一层的作用不是做多模态理解，而是确保模型拿到的“世界”是真实可算的。具体分三步：
第一步，原始数据打时间戳。视觉、激光雷达、IMU、关节编码器，所有消息进 Harness 时统一时间戳基准，完成硬同步或软同步。第二步，做一次可解释的降维。针对当前任务，把休眠信息过滤掉。比如桌面操作任务里，把静态背景移除，只保留目标物体和工作台区域；导航任务里，把深度图降采样成占据栅格。这一步很关键，因为给模型太多无关信息，模型注意力就会被干扰。第三步，形成统一观测缓冲。Harness 维护最近 N 帧的状态，带有置信度，任务状态机按需读取。
状态估计里我强烈建议做一层滑动窗口滤波。原始位姿数据抖动剧烈，直接进决策会让模型犹豫不决甚至重复规划。滑动窗口滤波不是新东西，但配合不同模态的置信度加权之后，稳定性提升非常明显。实现上要注意一个点：滤波后的延迟要实时更新到观测时间戳里，否则模型以为自己决策的是“当前状态”，实际是几百毫秒前的状态。
3.2 记忆与上下文管理
物理 Agent 需要记忆，但和聊天机器人那种记对话摘要还不一样。物理任务的特点是：短时上下文极其关键——比如当前机械臂末端高度、目标物体的最新坐标、已经完成了哪一步——长时上下文也非常重要——比如历史失败原因、环境布局记忆、操作偏好。
我实现的记忆分三层。低级缓冲层存最近几十个状态动作对，用于局部决策；工作记忆层存当前任务的子目标序列和已完成动作集合，用于任务推进；长期记忆层存场景布局和失败模式库，用于复用经验。
记忆层特别容易犯的错是无限增长。机器人任务跑一天，观测数据上万个，如果不做窗口切片和抽象摘要，上下文很快就会被塞满。我的做法是：按任务粒度归并，把“连续N帧状态变化”压缩成“状态A变换到状态B”，这样模型看到的是有意义的事件，而不是海量的数字变化。
另外，记忆里要保存“不确定信息”。比如目标物体被遮挡了、传感器温度异常，这些信息单独标出来，模型在规划时会主动避开盲区。很多失败的案例是模型不知道“自己不知道什么”，Harness 有责任把边界划出来。
3.3 动作执行、安全熔断与错误恢复
这一层在 Harness 里承担的是“刹车和保险带”。模型输出的意图到达动作层后，不直接下发到机器人，而是先经过一个约束检查器。它会校验目标位置是否在运动范围内、目标速度是否超限、规划轨迹是否与已知障碍物碰撞。一旦违反约束，有两种处理：能纠正的，Harness 自动修正后继续；不能纠正的，直接拒绝动作，并产生一条结构性错误信息反馈给模型。
安全熔断是必须做的。我习惯把熔断条件分成三级：软告警，比如关节电流接近阈值，此时 Harness 开始降速并请求上层重新规划；硬熔断，比如碰撞检测触发或者位置超限，Harness 立刻停止电机并进入安全姿态；急停，比如外部急停信号或者系统心跳丢失，直接切断动力输出。没有熔断机制的 Harness 是不完整的，因为模型永远有可能产生计划外的行为，你不是赌它不发生，而是确保发生之后损失可控。
错误恢复策略也要提前设计好。机器人执行中失败太常见了，抓取失败、滑倒、推偏、目标物体被碰撞移位。Harness 需要维护一个失败分类表：可重试、需要调整策略、需要人工介入。可重试的自动回退到安全位置重新执行；需要调整策略的，把失败原因封装成消息发给模型，让模型换一种思路；需要人工介入的，停下等待，并且把完整日志记录好。
3.4 外部工具与评测接口
物理 Agent Harness 不只是连接单个机器人，它往往需要连接仿真器、数字孪生、遥控操作台、自动评测系统等外部工具。仿真器这块我用的比较多的是 MuJoCo 和机器人厂商自带的仿真环境。Harness 在仿真和真机之间要保证接口一致，这样模型训练、评测、真机部署可以在同一套契约下运行，极大降低迁移成本。
工具注册机制要做得比较轻。每个工具其实就是一系列接口定义：输入参数、输出格式、可执行动作、状态响应。Harness 根据任务需要动态给模型暴露工具列表，而不是把所有工具全塞进 prompt。这样可以减少模型决策负担，也能控制误调用概率。
评测接口经常被忽略，但对 Harness 迭代来说至关重要。我做的评测接口会记录每一次动作决策、执行延迟、成功率、平均完成时间、安全事件数。这些指标最终汇成一张表，用来判断一次改动到底是不是真改进。没有评测接口，优化就是盲人摸象。
4. 模型与 Harness 的对比评估设计
4.1 评估维度与指标
要想回答“换模型还是改善 Harness”的问题，必须有一套可量化的对比体系。我在项目里常用的维度有六个：任务成功率、平均完成时间、安全事件数量、异常恢复率、开发成本和鲁棒性迁移度。
成功率比较好理解，就是任务完成的比例。但光看成功率会掩盖很多问题，所以我会加一个“分阶段成功率”，把任务拆成导航、定位、抓取、放置等多个阶段，看问题具体出在哪一层。平均完成时间衡量效率，模型反应慢或 Harness 重试太多都会拉高这个指标。安全事件数量是硬指标，碰撞、超限、急停都要记录。异常恢复率指的是任务第一次失败后，系统能不能自己恢复并成功完成。开发成本就是我花在调模型和调 Harness 上的人工时。鲁棒性迁移度则是把系统搬到另一个环境或者另一个机器人本体上，看能力掉多少。
这些指标看着多，但实际用的时候会形成一个雷达图。每一次改动，不管是换模型还是改 Harness，我都在雷达图上打点，这样半年下来就能很直观地看出哪个方向带来的收益更大。
4.2 消融实验设计
消融实验是我最推荐的对比方法，核心思路是控制变量。具体做法是固定一个基线版本，然后每次只动一个变量。
第一组：固定 Harness 不变，把模型从基础版换成更强的新版。记录上面六项指标的变化。第二组：固定模型不变，把 Harness 做成两个版本，H0 是最简单直连版本，H1 是加了感知对齐、安全熔断和错误恢复的完整版本。同样是记录指标。第三组可以再加一个组合实验，最强模型+最好 Harness，看是不是线性叠加收益。
这个实验设计看上去很傻瓜，但执行起来特别考验工程洁癖。因为很多人改着改着就偷偷把 Harness 也改了，导致最后说不清楚是哪个变量起的作用。我在实验里每个变量都保持固定，哪怕发现了明显可以优化的点，也忍住不改，否则整个对比就废了。
任务场景也要铺开阔一点。我一般选三类：一类是静态桌面操作，比如抓取固定位置的物体；一类是动态导航，比如避开移动障碍物到达目标点；一类是长程复合任务，比如整理桌面上多个物体。三类任务对模型和 Harness 的侧重完全不同，能有效暴露系统短板。
4.3 我实际观察到的对比结果
做了一轮对比后，我得出的数据很有代表性。固定 Harness 只换模型，成功率大概提升了五到八个点，代价是延迟增加、成本上升，而且安全事件减少得不多，因为安全问题大多发生在执行层，与模型智力关系不大。固定模型只升级 Harness，成功率提升十个点以上，而且安全事件明显减少，平均完成时间反而下降，因为重试变少了。
还有一组数据让我印象很深：不加 Harness 时，模型会在抓取失败后盲目重试五次，每次都按同一个动作死磕；加了 Harness 的错误恢复后，模型会收到“夹爪闭合力度不足，物体可能未完全接触”的结构化错误，然后自动调整夹爪位置重新抓取。同样是失败，前者最终失败，后者大概率转成功。这就是 Harness 的价值。
当然，最理想的状态是强模型+好 Harness 一起上。但所有资源都有限的情况下，我会坚定地优先投 Harness。原因很简单：模型的上限提升需要漫长的研发周期，而 Harness 的优化是立竿见影的工程改进，且每天都能在你自己的系统里验证。
5. 关键实现细节、常见坑与实操心得
5.1 时间戳和观测延迟是隐形杀手
很多做物理 Agent 的团队，第一个坑就栽在时间戳上。新手最容易犯的错是：把传感器数据送到模型时，没有携带采集时间，结果模型拿“现在”的决策逻辑去推理“过去”的状态。在机器人控制里，50 毫秒的延迟都足以让一个抓取动作落空。
我踩过最狠的一次，视觉识别节点因为 GPU 显存不足出现排队，处理一帧图像花了 400 毫秒，但下游关节控制一直在按最新状态执行，最终导致机械臂运动到错误位置。排查了两天才发现是时间戳没对齐。现在我在 Harness 里强制所有观测数据必须带时间戳，任何没有时间戳的数据直接丢弃，宁缺毋滥。
另一个实操心得是滑动窗口滤波的窗口大小要按场景调。窗口太小，噪声没滤干净，模型看着目标位置像跳来跳去；窗口太大，状态更新变慢，模型会做出滞后决策。一般动态任务窗口调小，静态操作任务可以稍微调大。参数这种东西，没有万能值，只能在自己数据集上跑一遍，观察抖动曲线再定。
5.2 动作命令的限幅和平滑必须前置
模型生成的轨迹几乎不可能直接下发电机。原因很简单，模型对物理限度没有直觉。我见过模型规划出末端速度 2 米每秒的指令，对机械臂来说早就超出安全范围了。Harness 里的动作层要做三层处理。
第一层限幅：位置、速度、加速度全部设置上限，超限的自动 clamp 到临界值并把超限标志位写入日志。第二层平滑：对连续动作做低通滤波，避免阶跃式命令造成机构冲击，很多电机抖动就是这么来的。第三层插值：将离散的动作命令变成时间连续的轨迹，让关节运动看起来自然，也给安全监测留出窗口。
这三层看着简单，顺序很重要。必须先限幅再平滑最后插值，顺序反了会导致滤波后的值又超出限位，或者插值产生中间点碰撞。
5.3 任务超时和重试机制要防呆
物理任务里最磨人的是任务迟迟完成不了，系统却一直“以为自己在推进”。我刚开始做的时候，任务没有超时限制，结果机械臂在原地反复尝试抓取一个被卡住的物体，整整转了十分钟，直到电机过热报警。这之后我所有的任务都加了超时机制。
超时设定不能太长也不能太短，太长没有保护意义，太短会让复杂任务频繁误杀。我的经验是：先跑 50 次样本任务，统计正常耗时分布，取 1.5 到 2 倍作为初版超时阈值，再根据实际误杀率调整。超时触发后 Harness 要做的不是简单终止，而是先尝试恢复，比如回退到上一个已知安全状态，再决定是重新规划还是上报失败。
重试机制也要设计得聪明一点。盲目重试是最差的策略，每次重试前要确认“当前状态与失败前状态是否一致”，如果目标物体已经被碰走了，就不该重试原动作，而应该重新感知再规划。我习惯在 Harness 里定义最大重试次数，超过后强制转人工或者切换到安全兜底策略，避免死循环。
5.4 不同机器人平台的移植差异
物理 Agent Harness 最容易被低估的问题是平台可移植性。同一个模型和 Harness 架构，在不同机器人上表现差异极大。机械臂、轮式机器人、四足机器人，它们的状态维度、控制频率、传感器配置都不一样。
我做过的对比中，从机械臂迁到轮式机器人时，Harness 里的动作层几乎要重写。机械臂关注的是末端位姿和关节角度，轮式机器人关注的是线速度、角速度和里程计。模型层基本不动，但 Harness 的状态转换逻辑全得调整。这给我一个启示：设计 Harness 时尽量分层抽象，让感知层和动作层都基于中间表示而不是特定平台的原始数据，这样迁移成本会低一些。
ROS2 在中间层帮了大忙，它的消息机制天然适合做时间戳对齐和不同模块解耦。但 ROS2 不能替代 Harness，它只是一个基础设施，真正决策、约束、恢复的逻辑还是要自己写。仿真到真机的迁移也一样，MuJoCo 里跑得顺的轨迹，到了真机可能有摩擦、回程差、控制延迟，Harness 里必须有一层补偿模块来做修正，否则仿真评测再好也是白搭。
我个人在实际操作中最深的体会是：做物理 Agent 不能只盯着模型榜单。把 Harness 看成第一公民，从感知对齐、动作安全到错误恢复一次性设计到位，很多看似玄学的问题其实都是工程问题。如果你现在团队在纠结要不要换最新大模型，我的建议是先把你当前的 Harness 翻出来，看看感知层的延迟是不是呛住了决策层，动作层有没有做限幅，失败之后能不能自己站起来。把这些修完，你会发现系统的进步比想象中大得多。后面再有余力，才去升级模型也不迟。
