企业官网建设流程全解析

1. 为什么"更强的模型"不再是唯一答案

过去两年，我参与过好几个机器人操作和物理仿真相关的项目，从最早的纯视觉抓取，到后来的语言指令驱动机器人，再到最近这一波 VLA（Vision-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 的人迟早都会懂，早懂早省事。