如果你正想把基础模型接进 humanoid 机器人，这篇要解决的不是“模型够不够聪明”，而是“怎样让它在真实系统里不乱说、不乱调度、不越过安全边界”。这篇更适合已经有基础控制、感知或技能模块的人。最关键的工程判断是：基础模型不要直接接管机器人，它更适合站在任务理解、意图拆解、参数生成和异常解释这一层，而把实时控制、安全联锁、运动约束和执行确认留给传统机器人栈。
这篇适合谁
- 已经有 humanoid 原型机，想加入自然语言指令、任务拆解或更灵活的操作接口的人
- 正在做机器人“大脑”层，但不想把系统做成一个难以调试的黑箱的人
- 做技能库、任务编排、遥操作辅助、故障解释、数据回放工具链的人
如果你现在连底层控制、状态估计、基础感知和动作技能都还没有稳定跑通，那先别急着把基础模型接上来。模型会把问题说得更像“智能不足”，但很多时候真正卡住的是系统接口没有定义清楚。
先纠正几个很常见的误区
误区 1：模型越大，机器人越接近通用
真实情况通常相反。模型越强，越容易让团队高估高层推理的价值，低估执行链路里的状态漂移、抓取失败、夹具公差、相机偏移、地面摩擦变化和人机共处安全约束。
误区 2：把相机、麦克风、机械臂、双足控制都接给一个端到端模型最先进
对演示视频来说也许很酷，对工程交付通常很危险。因为一旦行为失败，你很难分清是视觉理解错了、任务拆解错了、技能参数错了，还是底层控制没跟上。
误区 3：只要模型能输出动作序列，就说明系统可上线
真正决定能不能上线的，是动作序列有没有经过技能层约束、前置检查、执行确认、失败回退和人工接管，而不是模型回答得像不像一个聪明助理。
关键实现判断：基础模型在 humanoid 里该放哪一层
更稳妥的做法，是把系统拆成 4 层：
- 实时控制层：关节控制、平衡、接触约束、急停、限力、碰撞保护。这层不要交给基础模型。
- 技能执行层：例如走到工位、识别托盘、抓取把手、开门、扫码、放置、复位。这层应该是可单测、可回放、可统计成功率的技能接口。
- 任务编排层：把“去把箱子送到工位 B”拆成导航、确认目标、抓取、搬运、放置、回报状态。基础模型可以参与这一层，但输出必须是受限结构化指令。
- 交互与解释层：理解自然语言、补全上下文、向人解释失败原因、生成工单摘要、辅助遥操作员判断下一步。这一层最适合先引入基础模型。
一句话说，模型更像“任务接口”和“解释接口”，不是“伺服器”。
在真机接入前，先过 4 个停点
- 技能边界停点：你能不能把可调用动作压成有限技能集合，而不是留给模型自由发挥？如果不能，先别接。
- 校验链停点：模型输出后，是否一定会经过 schema 校验、场景检查和安全策略检查？如果答案是否定的，先别接。
- 回退链停点：执行失败后，是不是能明确落到重试、换技能、人工接管三类出口，而不是让模型继续补一句再试？如果不能，先别接。
- 回放停点：你能不能完整回放一次“输入什么, 模型怎么拆, 校验器为什么放行, 技能为什么失败”？如果不能，先别把真机测试当成调 prompt 工具。
这 4 个停点里，只要有 1 个站不住，当前最该做的都不是继续补模型能力，而是先把接口和回退链补齐。
分步实践指南
第 1 步，先把可调用技能收敛成有限集合
不要一开始就让模型“自由控制机器人”。先定义一组离散技能，每个技能都要有明确输入、输出和失败码。
navigate_to_station(station_id)locate_object(object_type, region_id)pick_object(grasp_profile, target_pose)handover_to_human(confirm_token)request_teleop(reason_code)
如果一个技能接口写不出参数说明、前置条件和失败定义，那它还不适合交给模型调度。
第 2 步，把模型输出限制成结构化中间表示
最怕的是模型直接吐一段自然语言，然后由另一个脚本“猜”该执行什么。更好的办法是让模型只输出固定 schema，例如 JSON 任务计划：
{
"goal": "deliver-bin",
"steps": [
{"skill": "navigate_to_station", "args": {"station_id": "A3"}},
{"skill": "locate_object", "args": {"object_type": "bin", "region_id": "shelf-left"}},
{"skill": "pick_object", "args": {"grasp_profile": "side-grasp"}}
],
"fallback": "request_teleop"
}这样做的价值不是“更优雅”，而是便于校验、拦截、重放和统计。
第 3 步，在技能执行前做三类检查
模型给出的步骤再合理，也要先过三道门：
- 参数合法性检查：目标工位是否存在，抓取配置是否属于允许集合，动作时长是否超出上限。
- 场景可执行性检查：目标是否已被视觉确认，机器人当前姿态、电量、地图定位、站位空间是否满足执行条件。
- 安全策略检查：是否进入禁区，是否需要双确认，是否需要降速，是否必须切到人工监护模式。
只要任何一项没过，就不要执行，而是回到解释层或人工接管层。
第 4 步，把“模型调用失败”单独做成错误类别
很多团队把所有失败都记成“任务失败”，这样后面根本无法优化。至少要区分：
- 意图理解失败
- 任务拆解不合理
- 技能参数不合法
- 场景感知不足
- 底层技能执行失败
- 安全策略拦截
- 需要人工接管
你不把失败桶分开，后面就会一直在错的层上修 bug。
第 5 步，先从“低风险高收益”入口接模型
我更推荐按下面顺序接入，而不是一步到位追求全自主：
- 自然语言转工单或任务参数
- 异常日志解释与复盘摘要
- 技能选择建议
- 多步骤任务规划
- 人机协同下的半自主操作
- 最后才考虑更开放的自主长时任务
前两项往往最先产生价值，因为它们能减少操作门槛，却不会立刻把执行风险推高。
如果你今天只做一个 PoC，我建议只做这一条：自然语言指令 → 结构化任务参数 → 校验器 → 已有技能。先不要碰开放式长时任务，也不要让模型自己改技能库。这个 PoC 的目标不是让机器人显得更聪明，而是验证你的接口、校验链和失败回退到底站不站得住。
第 6 步，给模型留出“说不知道”的出口
如果你的系统要求模型永远给答案，它迟早会胡编。工程上要明确允许以下输出：
- 信息不足，无法规划
- 需要补拍图像或重新确认目标
- 需要人工指定对象或区域
- 任务超出当前技能库能力范围
愿意承认不知道，通常比自信地做错更值钱。
第 7 步，用回放和离线评测先打磨，再放到真机
不要拿真机当 prompt 调参器。先把历史相机画面、状态日志、任务指令和成功/失败标签整理出来，做离线评测：
- 同一类口头指令，模型是否稳定映射到同一技能集合
- 参数抽取是否会漏掉工位号、数量、朝向等关键字段
- 场景变化后，模型是否更容易调用错误技能
- 失败时，是否能正确触发回退而不是继续硬做
离线评测过不了，线上只会更糟。
一个比较现实的系统架构
对多数团队来说，一个够务实的架构通常是：
- 视觉与状态估计模块输出结构化世界状态
- 技能库暴露受限 API 和统一失败码
- 任务管理器维护工单状态、超时、重试次数和人工接管点
- 基础模型只读取经过筛选的上下文，不直接访问所有底层控制接口
- 安全监督器始终有最终否决权
- 日志系统记录 prompt、上下文、模型输出、执行结果和回退链路
这个架构不性感，但很适合调试，也更适合以后做灰度上线和版本回滚。
最容易翻车的地方
1. 技能名字取得像自然语言，结果边界模糊
例如“处理箱子”“整理工位”这种词很像产品语言，不像工程接口。技能名必须能对应清晰执行单元。
2. 给模型的上下文太多，真正关键的状态反而被淹没
别把所有日志一股脑塞进去。只保留当前任务目标、环境摘要、可用技能、最近失败原因和关键约束。
3. 没做版本冻结，线上表现时好时坏
模型版本、prompt 模板、技能 schema、校验规则都要一起记录。不然你很难知道效果变化是哪里引起的。
4. 只看成功 demo，不统计被拦截的危险决策
真正该夸的是“危险动作被系统挡住了多少次”，不是“模型看起来多像人”。
5. 人工接管入口设计得太晚
如果遥操作员只能在快撞上、快跌倒、或者已经抓歪之后才接管，那说明你的升级路径设计错了。
怎么验证你接得对不对
- 同类任务的计划结构是否稳定，而不是每次换一种说法
- 模型输出被校验器拦截的比例是否在下降
- 需要人工澄清的任务是否集中在少数可定义类别
- 真机测试中，失败是否更早暴露在规划层，而不是拖到执行层才爆炸
- 上线后，是否能快速从日志中还原“模型为什么这样选”
如果这些问题答不上来，那说明你接入的还不是“能力”，只是一个更复杂的演示层。
最小验收标准，别只看 demo 能跑
- 稳定性：同一类指令重复跑 10 次，任务拆解和技能选择基本一致。
- 可拦截性：当参数缺失、目标未确认或安全条件不满足时，系统会稳定拒绝执行，而不是硬做。
- 可回退性：失败会落到明确出口，比如重试、换技能、人工接管，而不是继续让模型自由补救。
- 可解释性：你能从日志里看清这次失败到底是理解错了、参数错了、校验没过，还是技能本身没执行成功。
如果这 4 条里有 2 条还做不到，就别急着讨论“接更大的模型”或“开放更复杂的任务”。那不是能力升级，只是在把调试成本往后推。
下一步怎么做
- 先整理现有技能库，补齐每个技能的参数定义、前置条件和失败码。
- 选 20 到 50 条真实任务指令，建立离线评测集。
- 先把基础模型放在任务理解和异常解释层，而不是直接发动作。
- 把所有模型输出都接到统一校验器，再进入任务管理器。
- 先把单技能或双技能 PoC 跑稳，再决定要不要往多步骤任务规划推进。
- 最后才做真机灰度测试，并保留随时切回规则系统或人工接管的能力。
延伸阅读方向
- 人形机器人任务规划与技能编排
- 人形机器人状态估计与世界状态表示
- 人机协同下的遥操作与异常升级闭环
- 真机部署中的日志回放、回归测试与版本治理