物理Agent的瓶颈不在模型，而在Harness系统设计

做机器人的朋友应该都有同感：这几年新模型一个接一个，参数越卷越大，Demo 里抓取、导航、叠衣服都做得像模像样，可真到了自己那台机器人上，换上最新最强的模型，成功率往往纹丝不动。问题出在哪？出在我们一直盯着“模型”这个大脑，却忽略了真正在物理世界里兜底的那个外挂系统——Harness。今天我想认真聊聊这个话题：为什么物理 Agent 的瓶颈正在从“更强的模型”转移到“更好的系统”，以及这个 Harness 到底是什么、该怎么搭、有哪些坑。

文章主要面向三类人：正在做机器人和物理 Agent 落地的工程师、准备从纯大模型应用转向具身智能的开发者，以及被各种 Demo 迷惑、想搞清楚“差距到底在哪”的产品和技术负责人。我会用实际案例和踩坑记录来讲，尽量不堆术语，但该说透的原理一个都不落。

1. 先想明白一件事：物理 Agent 的“Harness”到底绑的是什么

1.1 物理 Agent 和聊天机器人不是一回事

先把这个词拆开。物理 Agent 指的是能在真实物理环境中感知、决策、行动的智能体，最常见的形态就是机械臂、四足机器人、轮式底盘，甚至是带执行机构的无人机。和 ChatBot 那种“输入文本、输出文本”的闭环不同，物理 Agent 的闭环是“传感器读数进、电机指令出”，整个循环跑在毫秒到百毫秒级的时间窗口里。

在这个闭环里，模型只是中间一小段。你有一个视觉语言模型也好，有一个专门训练的运动控制模型也罢，它输出的都是“意图”或“高层动作”，而不是直接能发给伺服驱动器的电流指令。从意图到电流，中间隔着坐标变换、轨迹插值、速度限制、力矩保护、状态估计、异常恢复——这一整套东西，就是 Harness。

我习惯把 Harness 理解成“接口纪律”。它不是某个具体框架，不是 ROS 2 这种通信中间件，更不是某个厂商的 SDK，而是一套围绕着模型建立的能力管道。它的职责是：把模型保护起来，让模型只做自己擅长的高层决策；同时把世界翻译给模型，把模型的输出翻译回世界。没有这套管道，模型再聪明也只是个关在笼子里的脑子。

1.2 用一个类比讲清楚系统和模型的分工

你可以把物理 Agent 想成一支射箭队。模型是那个闭眼就能算出弹道的“神算手”，但箭能不能中靶，还得看弓的张力、箭杆的笔直度、射手的呼吸，甚至风偏偏向哪边。Harness 就是这支箭队里负责调弓、选箭、报风速、在脱靶时喊“停下来”的教练组和器材组。

更直白一点：模型负责“想”，Harness 负责“做”。想错了，Harness 可能还能拦一下；做不出来，Harness 就得把“做不出来”这件事反馈回去，让模型换一个思路。也就是说，Harness 本身是带有反馈和回退能力的。它不是一个死板的流水线，而是能在关键时刻干预决策的“系统层智能”。

这也是为什么我现在跟团队聊方案时，第一句话往往不是“你准备上哪个模型”，而是“你打算怎么把它 harness 起来”。模型选择是战术问题，Harness 设计是战略问题。战略错了，战术再好都白搭。

2. 为什么“更强的模型”解决不了产线上的成功率：3 个真实案例

2.1 抓取任务：模型精度上去了，成功率却没动

去年我帮一个做上下料项目的朋友调机械臂抓取。一开始用的是通用视觉模型，对常见工件的识别准确率大概 80%。后来换了一个更大的开源 VLA 模型，识别准确率提到了 85%，听起来挺美，结果真机跑下来，整体抓取成功率从 70% 只涨到了 71%。

原因很典型：识别准确率只是整条链路的一个环节。抓取失败更多发生在机械臂运动过程中——工件在相机拍完到夹爪闭合这零点几秒里被传送带带走了、目标位置标定有偏差、接近速度太快把工件推歪了。这些全是 Harness 层的问题，模型根本看不到，也不该由模型来解决。后来我们没换模型，而是做了三件事：加了一个轻量视觉跟踪模块，把目标位姿的更新频率从 3Hz 提到 30Hz；在接近段强制降速；给夹爪加了一个碰撞检测后的回退策略。就这三板斧，整体成功率直接干到了 89%。

2.2 导航任务：机器人“想明白”了，却“跑不动”

另一个做室内巡检机器人的团队，原来用的是经典导航栈，遇到动态障碍物经常卡死。后来接了一个能力很强的多模态模型，可以理解“把那个蓝色箱子旁边的通道让出来”这类自然语言指令。模型确实想明白了，路径规划也确实算出了一条新路，但机器人就是没动——因为模型输出的新目标点，和底层路径规划器之间的坐标帧没对齐，而且高频障碍物信息根本没送到规划器里。

这就是典型的“大脑升级了，身体没跟上”。模型输出的是一个语义级别的目标，而底盘需要一个世界坐标系下、带朝向、带容差的具体位姿。中间这层转换，就是 Harness 的活。坐标帧校准、成本地图更新、局部规划器重规划触发条件，每一项都比模型选型更影响最后的“能不能动起来”。

2.3 换模型的成本，比换系统大得多

还有一次是帮客户做产线改造评估。客户问：我们把机械臂的视觉模型从 A 换成 B，大概要多久？我说模型本身可能就半天，但模型跑在什么卡上、输入图像尺寸和帧率变不变、输出格式和现有控制代码匹不匹配、异常行为会不会触发安全停机——这些才是真正的工作量。如果 Harness 设计得好，模型只是插在中间的一个“可替换组件”；如果 Harness 和模型耦合在一起，那换模型等于把整个系统重写一遍。

2.4 模型主导 vs 系统主导：两张路线图对比

我做了个对比表，大家可以对号入座。

我不是说模型不重要。模型决定了这个 Agent 的能力上限，但 Harness 决定的是它能多稳定地逼近这个上限。对落地项目来说，99% 的场景缺的不是上限，是稳定性。

3. 一个合格的物理 Agent Harness，至少要装下这四个模块

3.1 感知入口：把世界“翻译”给模型

感知入口要解决两件事：一是传感器数据的清洗和对齐，二是把原始数据变成模型能用的特征表达。很多新手上来就让模型直接吃相机原始帧，再加上几个 IMU 数字，以为这就是多模态。实测下来问题很大：相机是 30Hz，IMU 是 200Hz，夹爪的力传感器是 500Hz，这三者时间戳不对齐，模型看到的“世界”是撕裂的。

所以感知入口的第一步是搞一个统一的时间基准。要么用硬件同步，要么在软件层做时间戳插值。第二步是空间同步：相机坐标系、机械臂基坐标系、工具坐标系，必须先标定好，否则模型在图像上把目标框得再准，转成机械臂坐标之后也是偏的。第三步才是特征编码：是把图像缩放到固定尺寸，还是转成 token，取决于你选的模型。但记住一点：模型看到的输入维度越稳定，系统越可控。

3.2 决策调度：分层不是越俎代庖

Harness 里最容易被忽略的是“什么时候该调用大模型”。把一个大模型当主循环、每 10 毫秒调一次，这不是智能，是灾难。模型推理耗时摆在那里，你的控制频率就上不去；模型在低层次控制上本身也不擅长，反而会把简单问题复杂化。

我建议的决策调度方式是分层：最底层是固定频率的经典控制器，做轨迹跟踪；中间层是局部的行为选择，比如抓取还是避让，可以用行为树或有限状态机；最上层才是模型，只在“需要语义理解、长程规划、异常情况重新规划”的时候被唤醒。这样模型用的是“低频脑”，控制器用的是“高频身”，各司其职。

3.3 执行出口：单位时间里的控制律

执行出口是 Harness 和物理世界接触的最后一层。它要做的不是简单把模型输出的“目标点”发给电机，而是生成一段可执行的轨迹，并且满足运动学、动力学和安全约束。比如模型输出“5 秒内把末端移动到那个坐标”，Harness 就得去算：这段路径会不会碰到奇异点？关节速度会不会超限？加速度突变会不会让工件甩出去？

这块做得好不好，直接体现一个工程师的功底。在仿真里，你随便发一个位置指令，仿真器都会忠实地执行；但在真机上，同样的指令可能直接触发驱动器报警，甚至把机构撞坏。Harness 里一定要有一段“轨迹整形”的逻辑：速度规划、加加速度限制、笛卡尔空间与关节空间插值的切换、以及最后的限位保护。

3.4 闭环反馈：让模型学会“认错重来”

最后一个模块，也是最容易被砍掉的一个——反馈与回退。很多团队做 Demo 时，模型给一个动作，执行完就算了。但在真实任务里，一次成功的概率不可能 100%，你需要让系统在失败时能“自己察觉并重来一次”。

实现方式包括：在执行过程中持续检查关键状态量有没有按预期变化，比如夹爪有没有闭合到位、末端有没有在接近目标；如果没有，就触发重规划；重规划几次还不行，就把状态上报给模型，让模型重新理解场景。我在机械臂抓取项目里加了一个非常简单有效的回退策略：抓取失败后，机械臂先退回到安全位姿，重新拍照识别一次，再尝试第二次。就这一个策略，把最终成功率从 71% 提到了 81%。

4. 从零搭一套物理 Agent Harness：选型、接法与最小实现

4.1 三种路线对比：一体式 VLA、分层管线、经典控制栈

市面上常见的物理 Agent Harness 基本可以分为三类，我直接说结论。

我给绝大多数团队的组合是：经典控制栈做底座，分层管线做框架，在语义理解和异常重规划这两个点位上谨慎接入模型。这套组合最稳，也最好迭代。

4.2 硬件与通信选型：总线、算力、频率

Harness 的硬件选型，核心看三个数：通信带宽、算力余量、控制周期。机械臂、底盘这类设备，关节指令通常走 CAN、EtherCAT 或串口；视觉和其他传感器走 USB 或网口；算力平台我常用的是 Jetson Orin 系列配一个实时 MCU（如 STM32F103C8T6 这种经典最小系统板），大模型跑在 Orin 上，底层关节控制交给 MCU。

这里有一个很容易踩的坑：模型推理的延迟和控制的实时性脱节。有一次我把视觉模型跑在同一块板子上，发现相机采图、推理、发指令一条链走下来，延迟已经 300ms 了。底层的伺服还在以 1kHz 的频率等待指令，两边完全不是一个节奏。后面我把控制拆出来放到 MCU 上，用 CAN 走关节状态反馈，模型只更新高层目标，延迟问题才解决。物理 Agent 的 Harness 一定不要是单进程大循环，而应该是分布式的、有明确频率分级的。

4.3 模块串联要点：状态机、超时机制与日志

模块之间怎么串？我个人始终坚持三件事：状态机驱动、所有调用都要有超时、全程落日志。

状态机的价值在于，它让系统在每一步都知道自己“处于什么阶段、能接受什么输入、下一步去哪”。大模型偶尔会给出不靠谱的输出，状态机可以把这种输出挡在正确的位置。超时机制更直接——模型推理卡死、传感器断连、执行器无响应，如果没有超时，整个系统就冻在那一刻，轻则任务失败，重则机器人乱动出安全事故。日志则是排障的基础，我会把每一帧的传感器原始值、模型输出、控制指令、状态机跳转全部记录下来，格式类似 ROS 的 rosbag 或 HDF5，方便事后重放和分析。

4.4 一个最小可跑的 Harness 伪代码

下面给一个简化版本，展示主循环里各个模块的协作节奏。它不是一个能直接用的产品代码，但结构是真实的。

# 简化版物理 Agent Harness 主循环 while robot.is_alive(): obs = capture_observation(camera, imu, joint_state) state = estimate_state(obs, last_action) # 时间戳对齐 + 滤波 # 1. 安全层永远优先 if not safety_layer.check(state, last_action): action = safety_layer.fallback(state) # 紧急回退/停机 robot.send(action) continue # 2. 高层模型低频唤醒，只在需要时重新规划 if high_level.is_replan_required(goal, state): plan = high_level.replan(goal, state) # 频率通常 1-10Hz # 3. 底层控制器高频跟踪 action = low_level.track(plan, state, dt=0.01) # 频率 100Hz+ robot.send(action) # 4. 永远留痕 log(state, action, plan, safety_layer.status)

对应的最小配置文件长这样：

harness: model: "openvla-7b" model_frequency: 5 # 模型重规划频率 control_frequency: 100 # 底层控制频率 sensors: camera: 30 # Hz imu: 200 # Hz safety: max_velocity: 0.5 # m/s torque_limit: 8.0 # Nm enable_emergency_stop: true

你会发现，这个结构的核心思想就是“降频使用模型，高频执行控制，安全永远最高优先级”。这套思路在 ROS 2 框架下实现时，我会把传感器、模型、控制器分别做成独立节点，用话题通信。网上关于 ROS 2 编程入门的电子版资料很多，但真正关键的往往不是节点怎么建，而是上面说的频率分级和时间对齐，这一点资料里很少强调。

5. 实测排雷：物理 Agent 开发中最容易翻车的 6 个环节

5.1 模拟到现实的落差

Mujoco 这类仿真器里四足机器人跑得虎虎生风，一上真机就原地抽搐，这是最常见的事故现场。仿真里的物理参数是理想化的，摩擦力、关节阻尼、电机响应延迟都没法完全复刻。我在做足式机器人时踩过一个典型问题：仿真里模型输出的关节力矩直接调就能站稳，但真机上同样的力矩指令，由于电机启动延迟，相位总是慢一拍，结果就是越调越抖。

解决思路只有一个：从一开始就给仿真加上“现实感”——关节响应延迟、传感器噪声、通信丢包这些都要建进仿真里。另外，所有在仿真里调好的控制参数，到真机上必须从保守值开始重新整定，不要直接沿用。

5.2 模型输出与执行器频率对不上

模型输出 10Hz，控制器执行 500Hz，怎么办？答案是插值和缓冲。Harness 里需要一个轨迹缓存区，把模型输出的稀疏目标点，转换成一条平滑、可跟踪的连续轨迹。这个轨迹要满足速度连续、加速度不跳变。我见过有人直接把模型的稀疏点当目标做 PID 跟踪，结果机器人像喝醉了一样，末端运动一顿一顿的。

5.3 多传感器时间戳不同步

前面提到的时间戳问题，再展开一下。相机 30Hz，IMU 200Hz，力传感器 1kHz，如果各算各的，状态估计时拿到的就是“错位世界”。我常用的办法是把所有传感器数据统一到主时钟上：哪个传感器的消息进来，先按时间戳存到对应缓存区，状态估计需要某一时刻的值时，从缓存区里找最近的两个样本做插值。这是 Harness 的感知入口必须做的活儿，不能省。

5.4 安全层与学习层的“权限打架”

安全层说“停”，模型说“继续”，听谁的？当然是安全层。但实际工程里，这种“打架”经常出现，而且很隐蔽。有一次机械臂在接近目标的过程中，二指夹爪突然检测到异常阻力，安全层准备触发停机，但视觉模型同时输出了“目标已被夹住，继续闭合”的判断，结果安全层的停机条件被判为“干扰”，被绕了过去。那次之后，我定了一条铁律：安全层独立于模型运行，它的传感器输入不做任何语义加工，触发条件写死在控制器里，任何学习模块都不能修改或覆盖。

5.5 国产设备与系统兼容性的坑

很多国产机械臂、底盘、伺服驱动都有自己的通信协议和报警机制，文档往往只有厂商手册。比如有一类机械臂的控制器报警，错误码 7990 这类 79xx 区间的代码，手册里指向伺服相关的异常，你需要先看伺服驱动器的详细状态字，而不是简单地在应用层清报警。这类问题处理多了，我的习惯是：在任何项目开始前，先花一天把厂商的报警码表通读一遍，把可能会出现的错误码提前映射到 Harness 的安全动作里。比如 7990 这种伺服异常，对应的安全动作就是“立即停止下发新指令，并保持当前位置”，而不是让模型继续跑。

另外，在国产的欧拉、麒麟这类 Linux 系统上做机器人开发时，需要注意系统自带的实时内核补丁和 ROS 2 的兼容性。系统不是不能用，但 DDS 多播在某些网络配置下会出问题，需要手动配置共享内存和单播发现。我现在遇到这类系统，会先跑一轮 ROS 2 的话题延迟测试，确认通信延迟在可接受范围内，再继续往上搭。

5.6 日志与复现：没有可重放就没有迭代

最后一个是工程习惯问题。物理 Agent 的开发，90% 的时间都在“看现场为什么没按预期走”。如果每次测试只记录“成功了 / 失败了”，那等于没有记录。我现在的规矩是：每次真机测试必须录制完整状态流——传感器原始数据、模型输入输出、控制指令、状态机跳转、安全层触发记录。这样出问题时，可以在办公桌上像看电影一样重放现场，再定位是模型推理错误、坐标转换错误，还是执行器没跟上。

下面整理一张高频问题排查速查表，都是我实际碰过的：

写在最后

我个人的体会是：物理 Agent 这个方向，现在最缺的不是更强的模型，而是更多愿意在 Harness 层下功夫的人。模型决定了一台机器人“聪明不聪明”，系统决定它“靠谱不靠谱”——而对于真实用户来说，靠谱远比聪明值钱。

如果你正准备从零搭一套，我的建议是先别急着上大模型。用经典控制栈把你的机械臂或底盘跑稳，跑出第一批日志，然后重新审视：哪一个环节最频繁地让整个任务失败？那个环节，就是你 Harness 的第一个突破口。等这套系统能稳定跑 30 分钟不挂，再往上嫁接模型，你会发现原来“接模型”这么轻松，因为你的系统已经具备把任何模型“包裹住”的能力。

最后再分享一个小技巧：每次迭代 Harness 的时候，只改一个变量。要么只动安全层的阈值，要么只动轨迹插值的参数，不要同时改模型和系统。物理世界的变量本身就够多了，如果系统变量也在乱动，出了问题你连重现都做不到。抓住这个原则，你的机器人会比绝大多数 Demo 更早“毕业”。

祝各位的机器人，不仅脑子转得快，手脚也稳得很。