★ FEATURED ARTICLE 1. 从模型崇拜到系统思维为什么“更好的系统”正在取代“更强的模型”过去两年我接触过不少做机器人方向的朋友大家见面第一句话往往是“你们用的什么模型”。但到了今年这个问题悄悄变了越来越多人开始问“你们的 Harness 怎么搭的”。这个转变不是偶然的它背后是整个行业从模型竞赛转向系统工程的集体觉醒。先把概念说清楚。Agent Harness直译过来叫“智能体挽具”你可以把它理解成一套把大模型、感知模块、执行器、工具调用、状态管理全部串起来的“操作系统层”。它不负责产生智能它负责让智能在物理世界里跑起来、跑得稳、跑得可复现。而VLAVision-Language-Action模型则是把视觉、语言、动作统一到一个模型里做端到端决策的技术路线。LLM在这里扮演的是高层任务规划与语义理解的角色。这三者的关系我用一个类比来说明LLM 是大脑里负责“想”的部分VLA 是负责“看和动”的部分而 Harness 是连接大脑、感官和四肢的神经系统加上骨架。你光有一个聪明的大脑没有神经和骨架它连一杯水都端不起来。这篇文章适合谁看如果你正在做机器人项目、Agent 开发或者你是一个对具身智能感兴趣但还没入门的开发者这篇文章会帮你建立一套完整的系统视角。我不会只讲概念我会把 Harness 的设计思路、VLA 的训练要点、LLM 在其中的角色定位以及实际搭建过程中踩过的坑全部摊开来讲。核心观点先摆出来在当前的工程实践中一个设计良好的 Harness 对最终任务成功率的贡献往往大于换一个更强的模型。这不是说模型不重要而是说当模型能力达到某个阈值之后系统层面的瓶颈就变成了主要矛盾。下面我分几个层面来拆解这个判断。2. Agent Harness 到底是什么拆开“挽具”看内部结构2.1 Harness 与 Agent 的区别一个容易被混淆的核心问题很多人把 Harness 和 Agent 混着用其实两者有明确的层次关系。Agent 是一个逻辑概念它描述的是“一个能感知环境、做出决策、执行动作的实体”。而Harness 是工程概念它描述的是“支撑这个 Agent 运行的基础设施和接口层”。打个比方Agent 是司机Harness 是方向盘、油门、刹车、仪表盘这一整套人机接口。司机再厉害如果方向盘有虚位、刹车响应延迟车也开不好。Harness 的核心职责包括状态管理维护 Agent 的短期记忆和长期记忆确保多步任务中上下文不丢失工具调用编排把 LLM 输出的自然语言指令翻译成具体的 API 调用或机器人指令安全约束在动作执行前做合法性检查防止危险操作错误恢复当某个步骤失败时决定是重试、回退还是放弃可观测性记录每一步的输入输出方便调试和复现我见过太多项目模型选得很激进但 Harness 写得像临时脚本结果就是 demo 能跑、上线就崩。Harness 的质量直接决定了系统的鲁棒性上限。2.2 一个典型 Harness 的架构分层从工程实现角度我习惯把 Harness 分成四层层级职责典型组件接口层接收任务、输出结果CLI、HTTP API、ROS Topic编排层任务分解、步骤调度Planner、Task Queue、State Machine执行层调用模型和工具LLM Client、VLA Inference、Tool Executor基础层日志、监控、配置Logger、Tracer、Config Manager这个分层不是教条但它能帮你理清代码结构。我实际搭过的一个项目里最初把编排和执行混在一起后来任务一复杂就完全没法调试。拆开之后每个环节的输入输出都清晰了排查问题的时间至少省了一半。2.3 为什么 Harness 决定了系统的“下限”模型决定的是系统的“上限”——它能做到多好。但 Harness 决定的是“下限”——它最差能差到什么程度。在实际部署中下限比上限重要得多。一个任务成功率 95% 但偶尔会做出危险动作的系统不如一个成功率 80% 但永远不会出错的系统。Harness 通过以下机制保障下限输入校验LLM 输出的动作指令在执行前必须经过 schema 校验格式不对直接拒绝权限控制不同级别的动作需要不同的确认机制比如移动机械臂需要二次确认超时与重试每个步骤都有超时限制超时后按预设策略处理回滚机制关键操作前保存状态快照失败时可以回退这些机制听起来很基础但我在实际项目中见过太多因为缺少这些“基础设施”而导致的翻车案例。有一个做分拣机器人的团队模型识别准确率很高但因为没有做动作前的碰撞检测机械臂直接把传送带上的工件撞飞了。这就是典型的 Harness 缺失。3. VLA 模型的核心机制它到底是一个模型还是两个3.1 VLA 的架构本质统一还是拼接“VLA 模型是一个模型还是两个模型”这个问题在社区里被反复讨论。从架构上看主流 VLA 方案是一个统一模型但在训练和推理时可能采用分阶段策略。一个典型的 VLA 模型包含三个部分视觉编码器把图像输入压缩成特征向量常用 ViT 或 ResNet backbone语言编码器把任务描述编码成语义向量通常复用预训练 LLM 的 tokenizer 和 embedding 层动作解码器把融合后的特征映射成动作序列可能是离散的 token 序列也可能是连续的轨迹参数关键在于这三部分是通过联合训练或多阶段训练融合在一起的。联合训练就是端到端一起训多阶段训练则是先分别预训练再对齐融合。目前工业界更倾向于多阶段训练因为端到端训练对数据量和算力的要求太高了。3.2 VLA 是怎么训练的数据、目标和技巧VLA 的训练数据通常包含三类机器人演示数据人类遥操作机器人完成任务记录视觉、语言指令和动作序列仿真数据在物理仿真环境中生成的大规模交互数据互联网视频数据用于预训练视觉和语言理解能力训练目标一般是动作预测损失加上辅助任务损失。动作预测损失衡量模型输出的动作和真实动作的差距辅助任务损失可能包括视觉对比学习、语言理解等。我实际参与过的一个 VLA 训练项目里最大的坑是数据分布偏移。训练数据里抓取的都是规则形状的物体部署时遇到不规则物体成功率直接掉了一半。后来我们在数据增强上花了很多功夫包括随机遮挡、光照变化、物体姿态扰动才把泛化能力提上来。提示VLA 训练中数据质量比数据数量重要得多。1000 条高质量、多样化的演示数据往往比 10000 条单一场景的数据更有效。3.3 VLA 与 LLM 的协作模式在实际系统中VLA 和 LLM 通常是分层协作的关系LLM 负责高层规划把“把桌子收拾干净”分解成“拿起杯子、放到架子上、擦桌子”等子任务VLA 负责底层执行接收子任务描述和当前视觉输入输出具体的动作指令这种分层的好处是LLM 不需要理解物理世界的细节VLA 不需要处理复杂的语义推理。两者通过一个中间表示层通信通常是一组结构化的任务描述。但这里有个常见的坑中间表示的设计。如果 LLM 输出的子任务描述太抽象VLA 理解不了如果太具体LLM 的规划能力又发挥不出来。我试过几种方案最后发现用“动词对象约束”的格式比较平衡比如“抓取(红色杯子, 轻拿轻放)”。4. 从零搭建一个机器人 Agent Harness实操全流程4.1 环境准备与依赖选型假设你要从零搭一个机器人 Agent Harness第一步是选型。我的建议是编程语言Python 为主因为生态最全。性能敏感的部分可以用 C 写扩展通信中间件ROS2 或 ZeroMQ前者适合复杂机器人系统后者适合轻量级应用LLM 接入用 OpenAI 兼容的 API 接口方便切换不同模型VLA 推理如果自己训练用 PyTorch如果调 API注意延迟和吞吐配置管理YAML 或 TOML别用硬编码依赖安装示例pip install torch transformers openai pyyaml pip install rclpy # 如果使用 ROS2注意LLM API 密钥千万不要硬编码在代码里用环境变量或密钥管理服务。我见过有人把密钥提交到公开仓库结果被刷了几百美元的账单。4.2 核心模块实现状态机与任务编排Harness 的核心是一个任务状态机。每个任务有多个状态状态之间通过条件转移。我用一个简化版的任务执行流程来说明class TaskState: PENDING pending PLANNING planning EXECUTING executing VERIFYING verifying COMPLETED completed FAILED failed class TaskOrchestrator: def __init__(self, llm_client, vla_client, tool_registry): self.llm llm_client self.vla vla_client self.tools tool_registry self.state TaskState.PENDING self.history [] def run(self, task_description): self.state TaskState.PLANNING plan self.llm.plan(task_description) self.history.append((plan, plan)) for step in plan.steps: self.state TaskState.EXECUTING result self.execute_step(step) self.history.append((execute, step, result)) self.state TaskState.VERIFYING if not self.verify(result): return self.handle_failure(step, result) self.state TaskState.COMPLETED return self.history这个骨架看起来简单但每个方法里面都有大量细节。比如execute_step需要判断这个步骤是调用 LLM、VLA 还是传统工具verify需要根据步骤类型选择不同的验证策略。4.3 工具调用的编排与错误处理工具调用是 Harness 最容易出问题的环节。LLM 输出的工具调用请求可能有以下问题工具名拼写错误参数类型不对缺少必填参数调用了不存在的工具我的处理策略是三层防护Schema 校验每个工具定义严格的输入 schema用 Pydantic 或 JSON Schema 校验模糊匹配如果工具名拼写错误尝试用编辑距离找最接近的工具降级策略如果工具调用失败返回错误信息给 LLM让它重新规划from pydantic import BaseModel, ValidationError class GrabParams(BaseModel): object_id: str force: float 0.5 timeout: int 10 def execute_tool(tool_name, params): tool registry.get(tool_name) if not tool: closest find_closest_tool(tool_name) return {error: fTool not found, did you mean {closest}?} try: validated tool.schema(**params) except ValidationError as e: return {error: fInvalid params: {e}} return tool.execute(validated)这套机制在实际项目中帮我省了很多调试时间。特别是模糊匹配LLM 偶尔会把grab写成grap有了这个就能自动纠正。4.4 可观测性日志、追踪与回放没有可观测性的 Harness 就是黑盒。我要求每个项目必须做到结构化日志每条日志包含时间戳、任务 ID、步骤 ID、输入输出链路追踪用 OpenTelemetry 或类似工具记录跨模块调用回放能力保存每一步的完整状态可以离线复现问题回放能力特别重要。有一次线上任务失败日志只显示“动作执行失败”没有更多信息。后来加了状态快照发现是 VLA 模型在某张特定图像上输出了异常动作。如果没有回放这个问题根本定位不到。5. 常见问题与排查技巧实录5.1 LLM 请求失败从报错到解决llm request failed: provider rejected the request schema or tool payload这个报错我遇到过好几次。原因通常有三类报错原因排查方法解决方案Schema 不兼容检查工具定义是否符合 API 规范简化 schema避免嵌套过深Payload 过大打印请求体大小截断历史上下文减少 token模型不支持该工具格式查阅模型文档切换模型或调整工具描述格式我踩过最坑的一次是工具定义里用了oneOf但模型 API 不支持这个关键字。改成anyOf就好了。这种问题文档里不会写只能靠试。5.2 Agent 执行中断错误恢复策略agent execution terminated due to error是另一个高频问题。我的经验是不要让它直接终止而是要有恢复机制重试对于网络超时等临时错误自动重试 2-3 次回退对于状态不一致的错误回退到上一个稳定状态降级对于模型调用失败切换到备用模型或规则引擎人工介入对于无法自动处理的错误暂停任务并通知人工def execute_with_recovery(step, max_retries3): for attempt in range(max_retries): try: return execute_step(step) except TransientError: time.sleep(2 ** attempt) except StateError: rollback_to_last_stable() except ModelError: switch_to_fallback_model() notify_human(step) raise TaskAborted()5.3 密钥泄露防护LLM 使用中的安全实践“使用 LLM 时如何防止密钥等鉴权信息泄露”这个问题值得单独讲。我的做法是环境变量隔离密钥只存在于环境变量不写入代码和配置文件代理层所有 LLM 调用经过内部代理代理负责注入密钥业务代码不接触密钥日志脱敏日志中自动过滤密钥模式比如sk-开头的字符串权限最小化不同服务使用不同的密钥限制每个密钥的权限范围注意即使做了这些也要定期轮换密钥。我建议至少每季度换一次关键系统每月换一次。5.4 VLA 推理延迟优化VLA 模型通常比较大推理延迟是实际部署中的瓶颈。我试过几种优化方案模型量化FP16 或 INT8 量化延迟降低 30-50%精度损失通常在可接受范围推理缓存对于相似的视觉输入缓存推理结果异步执行VLA 推理和动作执行异步化重叠计算和通信时间模型蒸馏用大模型教小模型部署时用小模型实测下来量化加异步执行是最容易落地的组合延迟能从 200ms 降到 80ms 左右。6. 系统设计中的关键取舍我踩过的坑和总结的经验6.1 模型选型不要盲目追新我见过太多团队每次有新模型发布就想着换。但换模型的成本很高要重新调 prompt、重新测工具调用、重新验证边界情况。我的建议是除非新模型在 your specific task 上有显著提升否则不要轻易换。判断标准很简单在固定的测试集上跑一遍看任务成功率、延迟、成本三个指标。如果综合提升不到 20%不值得换。6.2 架构设计简单优先Harness 的架构越简单越好。我最初设计过一个非常“优雅”的多层架构结果调试的时候要在五六个模块之间跳来跳去。后来重构成三层代码量少了 40%可维护性反而更好。简单优先的具体做法能用同步就不用异步能用函数就不用类能用配置文件就不用代码能用一个服务就不用微服务6.3 测试策略仿真加真机机器人系统的测试不能只靠仿真也不能只靠真机。我的做法是单元测试测每个模块的输入输出用 mock 替代外部依赖集成测试在仿真环境中跑完整任务流程真机测试每周至少一次真机验证发现仿真中不存在的问题仿真和真机的差距往往在传感器噪声和执行器误差上。仿真里完美的抓取真机上可能因为摩擦力变化而失败。所以真机测试不能省。6.4 团队协作接口先行如果是多人协作开发 Harness接口定义要先行。我们团队的做法是先用 Protocol Buffer 或 JSON Schema 定义好所有模块之间的接口然后各自并行开发。这样即使某个模块还没实现其他模块也可以用 mock 先跑起来。接口定义还有一个好处它是天然的文档。新人加入时看接口定义就能理解系统结构比看代码快得多。7. 关于学习路径的一点个人建议如果你是从零开始学机器人 Agent 开发我建议的路径是先花两周把 Python 和基础的工具调用跑通写一个最简单的 Agent能调用一两个工具就行。然后花一个月学 ROS2 或类似的机器人中间件理解话题、服务、动作这些概念。接着花两个月深入 VLA 和 LLM 的接入包括 prompt 工程、工具编排、错误处理。最后花一个月做完整的项目实战从仿真到真机跑通一个任务。六个月听起来很长但如果每天能投入两三个小时这个节奏是合理的。关键是不要只看不练每个阶段都要有可运行的代码产出。我在实际带新人的过程中发现进步最快的往往是那些愿意动手写“脏代码”的人。他们不追求一开始就写出完美的架构而是先让东西跑起来再逐步重构。这种迭代式的学习方式比一开始就追求完美设计要高效得多。最后分享一个小技巧养成写“开发日志”的习惯。每天花五分钟记录今天做了什么、遇到什么问题、怎么解决的。三个月后回头看你会发现自己踩过的坑都变成了经验而且这些记录在写文档、做分享的时候直接就能用。
阅读完成 · 觉得有帮助？
