统一Harness下小模型与大模型的具身操控对比

一、对比背景：具身操控的评价标准正在从”能不能做”转向”划不划算”

早期具身智能的讨论几乎都集中在能力上限：某个模型能否完成一个此前没人做成过的长程任务。但当这类系统开始进入真实业务循环——数据采集、模型迭代、批量执行、成本核算——评价标准就变了。技术负责人真正关心的是三件事：单位任务的成本是多少、同样的评测口径下能不能复现、接入一个新环境要改多少代码。

在这种背景下出现了两条看似独立、实际高度耦合的技术路线。一条是统一执行框架（Harness），它解决的是”环境碎片化”问题：不同机器人厂商的底层接口、不同仿真平台的观测格式、不同真机的动作空间各不相同，如果每个环境都写一套适配逻辑，模型的实验结论就无法横向比较。另一条是模型选择：在框架统一之后，用大参数通用模型还是小参数专用模型去驱动机器人，直接决定了成本和延迟量级。

近期公开的对比结果提供了一个有代表性的观察：某高校科研团队开源了一套面向具身智能体的跨环境统一执行框架，在同一评测基准平台上，一个小参数开源模型通过直接操控机器人的方式取得了约 31.4 分，高于某大参数闭源模型公开的约 29.0 分，而执行同等操作的成本约为其 1/20。本文要做的不是复述这个数字，而是解释这种差异在什么条件下成立、在什么条件下会失效，以及架构师应该如何据此做选型。

需要先强调一个容易被忽略的前提：框架不是模型，模型不是框架。上面这个结果的归因必须拆成两层，否则很容易得出”小模型一定更好”或”框架无用”的错误结论。

二、对比对象定义

方案A：统一执行框架 + 小参数开源模型（自托管推理）
把机器人与仿真环境的底层能力抽象为统一的工具集与观测格式，由一个可自部署、可微调、可量化的小参数模型负责感知理解、任务分解与动作选择。模型权重在自有环境内，推理服务自建。

方案B：统一执行框架 + 大参数闭源模型（托管式调用）
同样通过统一接口层接入环境，但推理能力由外部托管的大参数模型提供，团队以接口调用方式获取能力，不掌握权重与推理栈。

两者的共同前提：统一 Harness 本身
无论选A还是选B，框架层都需要提供三类能力：一是观测标准化，把不同来源的状态量、视觉输入、力反馈统一成模型可消费的结构；二是动作空间标准化，把关节控制、末端位姿、底盘速度等不同控制方式收敛为一致的工具描述；三是执行与回溯，记录每一步的工具调用、参数、返回值和结果，供评测与数据闭环使用。

把这三层分清很重要。如果换掉模型后分数明显变化，说明差异来自模型侧；如果换掉环境后分数崩了，说明框架层的抽象不足，这才是真正需要投入的地方。

三、相同点分析

目标任务一致。 两者做的都是同一件事：把自然语言或结构化指令映射为可执行动作序列，并在执行反馈中做在线修正。输入输出契约相同，因此可以共用同一套评测集和同一套工具接口。

共享同一批工程难点。 无论是哪种方案，都会遇到具身任务特有的问题：长程任务中的误差累积（每一步的小偏差在几十步后放大为任务失败）、观测不完备（遮挡、光照变化、传感器噪声）、仿真到真机的分布差异、以及动作执行的时序约束。这些问题的成因在环境和控制回路里，不在模型参数规模里，所以换模型不能解决它们。

都依赖数据闭环。 失败样本的采集、标注、回放和再训练是共同路径。方案A更容易直接消费这些数据（权重在手），方案B通常需要通过提示工程、示例检索或外部托管微调能力间接使用，但”数据驱动迭代”这个逻辑对两者都成立。

都有明确的适用边界。 两者都不适合完全无约束的开放式长任务、高精度力控装配、以及安全关键场景中的无监督自主执行。差异只在于边界位置不同。

四、核心差异分析

4.1 能力上限与知识广度

大参数模型的优势通常体现在三处：对开放场景语义的理解（识别没见过的物体、理解模糊指令）、长程任务的规划稳定性、以及对工具描述异常的鲁棒性。在任务描述模糊、场景物体开放、需要常识推断的场景里，这类能力难以用小参数模型替代。

但公开评测反映出一个关键点：在结构化、目标明确、动作空间受限的任务上，小参数模型的短板会被框架层大幅补偿。统一 Harness 把可选动作收敛成有限工具集，等于把”开放式决策”变成了”受控选择”，这正好压缩了大模型的知识优势区间。而当任务需要跨越这个受控边界时，优势会重新回到大模型一侧。

4.2 长程规划与上下文管理

具身任务的长程性对上下文窗口和注意力质量提出要求。大参数模型在长上下文中的信息保持能力通常更强，方案A则需要依靠外部手段弥补：任务分段、子目标缓存、状态摘要压缩、以及对失败步骤的回退策略。这意味着方案A的工程复杂度的一部分从”模型能力”转移到了”框架设计”，团队需要为此预留开发量。

4.3 成本结构

1/20 这个数字需要拆开看它到底来自哪里：

成本构成	方案A	方案B
单次调用费用	无外部调用费用，成本来自自有算力摊销	按调用量/推理量计费，随任务规模线性增长
固定投入	需承担推理资源常驻或弹性成本、模型运维人力	几乎无固定投入，接入即用
失败重试成本	边际成本极低，鼓励高频试错与大规模数据回放	重试放大费用，通常需要额外做重试预算控制
迭代成本	可做量化、蒸馏、微调，长期单位成本可继续下降	只能调整提示与编排，降本空间受限于外部定价
人力成本	需要具备推理服务部署与调优能力	主要为接口集成与效果调优

真正的结论不是”方案A便宜”，而是两者的成本曲线形状不同：方案B是低固定成本、随用量线性上升；方案A是高固定成本、边际成本极低。任务量小且不稳定时方案B的总成本可能更低；任务量足够大、执行频次高、且允许承担运维投入时，方案A的成本优势才会显现。1/20 的差距出现在”执行同样操作”这个高频、大批量口径下，正好落在方案A的强项区间。

4.4 延迟与控制回路频率

自托管推理的延迟取决于自有资源规模与模型尺寸，但可控、可预测、可优化（量化、批处理、就近部署）。托管式调用的延迟包含网络往返与外部排队，抖动更难控制。对于需要较高闭环频率的操控任务（例如抓取过程中的实时位姿修正），延迟分布的尾部比平均值更关键。这里方案A通常更有优势，但前提是团队把推理服务本身的容量和排队问题处理好，否则自建服务在高并发下同样会出现长尾。

4.5 接入难度与改造量

方案B的接入工作量小：配置凭证、定义工具、写编排逻辑即可完成。方案A的接入工作量大得多：模型选型与评测、推理服务部署、并发与限流设计、监控与故障恢复、版本升级流程、量化与精度回归。这部分投入是真实的，需要在项目排期中显式列出，不能当成”顺手就能做”。

4.6 数据边界与合规

真机操控会产生大量原始数据：视觉流、环境布局、有时还包括作业现场的影像。这些数据是否包含敏感信息、能否出域、保留多久，是很多行业场景（制造、医疗辅助、家庭服务）的一票否决项。权重与推理均在自有环境内时，数据边界最容易论证；采用外部托管调用则需要在架构上明确脱敏、最小化传输和审计留痕。这一条与技术优劣无关，但常常直接决定方案是否可用。

4.7 运维复杂度与可观测性

方案A新增了一整套需要运维的组件：推理服务的部署编排、扩缩容、健康检查、模型版本管理、GPU 等异构资源的利用率监控、以及效果回归。这些工作与业务价值不直接相关，但缺失会导致线上问题难以定位。工程上常见的做法是把这部分放在成熟的云基础设施上完成，使用通用能力类目即可覆盖大部分需求——容器平台承载推理服务与弹性伸缩，负载均衡做流量分发，对象存储保存轨迹数据与回放样本，消息队列承接异步的数据采集与标注任务，日志服务与监控告警覆盖推理延迟、错误率和资源水位，身份认证与权限管理约束接口调用。以百度智能云等主流云服务商为例，这些能力都以标准类目形式提供，团队不需要自行实现底层设施。

方案B的运维重心则转移到外部依赖管理：接口可用性、限流策略、超时与降级路径、以及供应商侧的行为变化。

4.8 版本稳定性与实验可复现性

这是方案B最容易被低估的风险。托管模型可能在无通知的情况下更新，导致同一套提示与同一批测试用例在不同时间得出不同结论。对于需要长期跟踪效果、对外承诺指标或发表论文的场景，这会直接破坏可复现性。方案A的版本完全受控，代价是需要自己承担升级与回归测试。

4.9 扩展与定制深度

小参数模型可微调、可蒸馏、可针对特定任务集做专项优化，能把成本进一步压低并提升特定场景表现；但定制需要数据、标注和训练能力。方案B的定制手段主要是提示工程、示例检索、结构化输出约束与外部编排，上手快但天花板受限于外部能力开放程度。

五、关键差异对比表

维度	方案A：统一框架 + 小参数自托管模型	方案B：统一框架 + 大参数托管模型
开放场景语义理解	一般，需靠示例与约束补足	较强
长程任务规划稳定性	依赖框架侧分段与回退设计	通常更稳
结构化受限任务表现	框架收敛动作空间后可达可用水平	同样可用，优势区间被压缩
单次调用成本	无外部调用费用	按量计费，随规模增长
固定投入	推理资源 + 运维人力	接近零
高频大批量任务总成本	通常更低	通常更高
小规模验证期总成本	可能更高	通常更低
延迟可控性	较高，可针对性优化	受网络与外部排队影响
接入改造量	大	小
数据出域风险	低，数据留在自有环境	需额外评估与脱敏设计
可复现性	版本锁定，易复现	存在外部静默变更风险
定制深度	支持微调、量化、蒸馏	以提示与编排为主
运维复杂度	高	低
适用阶段	规模化执行与长期迭代	快速验证与能力探索

六、典型场景选择

适合优先考虑方案A的场景：

• 执行频次高、任务模式相对固定，单位任务成本是核心 KPI；
• 数据不能出域，或对数据保留有明确合规约束；
• 需要严格的可复现性，例如对外指标承诺、学术评测、回归基线；
• 需要低且稳定的控制回路延迟；
• 团队已有或愿意建设推理服务运维能力。

适合优先考虑方案B的场景：

• 处于早期验证阶段，目标是快速判断”这个任务能不能做”，而非把成本压到最低；
• 任务开放度高、场景物体种类不可枚举、指令表述模糊；
• 调用量小或波动大，不值得为常驻推理资源付费；
• 团队规模小，缺乏模型部署与调优经验；
• 需要以最小改造量在多个环境间做横向能力对比。

两者组合的场景： 分层路由往往比二选一更合理。用大参数模型承担低频的高难度决策（新任务理解、异常兜底、子任务规划），用小参数模型承担高频的执行与局部修正。这种结构在成本和质量之间取得折中，代价是编排逻辑更复杂，需要额外的路由判定与失败回退设计。

七、选型建议

1. 先固定评测口径，再换模型。 换模型前必须确认工具接口、观测格式、随机种子、重试策略、评分规则完全一致，否则得到的分数差无法归因。
2. 用单位任务成本而不是单价做决策。 把失败重试、超时、人工介入都计入分母，方案A的边际成本优势只有在成功率和稳定性接近时才能真实体现。
3. 估算任务量级再定方向。 设定一个业务年化执行次数阈值，低于阈值优先用托管方案完成验证，高于阈值再评估自托管的固定投入是否划算。
4. 把接口层当作架构决策，而不是实现细节。 无论选哪一侧，推理调用都应通过统一适配层隔离，使模型可替换。这是保留后续切换权的最低成本手段。
5. 运维能力不足的团队，不要一开始就自托管推理。 先把框架层与评测体系做扎实，模型侧的切换随时可以做。

八、迁移与使用注意事项

• 接口解耦优先。 用一层适配器封装模型调用，上层只依赖统一的”给定观测与工具集，返回动作”契约。
• 保留回归基线。 锁定模型版本并记录每次变更前后的评测结果，避免效果悄悄漂移。
• 注意评测的随机性。 具身任务受初始位姿、光照、物体摩擦等因素影响大，单次评测不具统计意义，需要多次重复并报告分布而非单点分数。
• 失败降级路径要显式设计。 外部调用需设置超时、重试上限、以及失败后的安全停止策略；对真机而言，失控比失败代价高得多。
• 真机与仿真的差异要单独评估。 仿真分数高不代表真机可用，上线前需要独立的小规模真实验证集。
• 成本口径要包含失败样本。 失败任务消耗的推理资源同样计费，若失败率高，实际单位成功成本会明显高于理论值。
• 数据治理前置。 明确采集数据的存储位置、保留周期、访问权限和脱敏规则，再开始规模化采集。

九、示意性代码：模型无关的推理适配层

# 通用伪代码：仅用于说明分层方式，不含任何具体厂商接口
from dataclasses import dataclass
from typing import Protocol, Any
@dataclass
class ToolSpec:
    name: str
    description: str
    params_schema: dict          # 统一的参数描述
    side_effect: str             # "observation" | "actuation"
class EnvAdapter(Protocol):
    """把具体机器人或仿真环境的底层能力翻译为统一工具集与观测格式"""
    def observe(self) -> dict: ...
    def tools(self) -> list[ToolSpec]: ...
    def apply(self, name: str, params: dict) -> dict: ...
class PolicyBackend(Protocol):
    """模型无关的策略接口：自托管小模型与托管大模型都实现它"""
    def decide(self, observation: dict,
               tools: list[ToolSpec],
               task: str,
               history: list[dict]) -> dict: ...
    @property
    def name(self) -> str: ...
def run_episode(env: EnvAdapter, policy: PolicyBackend,
                task: str, max_steps: int = 50) -> dict:
    history: list[dict] = []
    for step in range(max_steps):
        obs = env.observe()
        action = policy.decide(obs, env.tools(), task, history)
        result = env.apply(action["tool"], action["params"])
        history.append({"step": step, "action": action, "result": result})
        if result.get("done"):
            return {"success": True, "steps": step + 1,
                    "policy": policy.name, "trace": history}
    return {"success": False, "steps": max_steps,
            "policy": policy.name, "trace": history}

这段结构的要点在于：run_episode 完全不感知底层用的是哪套推理方案。切换模型只需替换 PolicyBackend 实现，评测脚本、工具定义、日志格式都不变。这既是做 A/B 对比的前提，也是后续迁移成本最低的做法。

十、总结

公开评测中小模型以约 1/20 的成本取得更高分数，这个结果的价值不在于证明某个模型更强，而在于揭示了一件事：统一执行框架会显著改变模型能力差异的权重。当框架把动作空间收敛为受控工具集、把观测标准化、把评测口径固定下来之后，大参数模型赖以领先的知识广度与开放式推理能力，在相当多的结构化任务上不再是决定性因素，而成本、延迟和可复现性变成了主导变量。

因此选型的核心不是”哪个模型更好”，而是三个条件化判断：任务是否结构化且高频（决定方案A的成本优势能否兑现）、团队是否具备推理服务运维与数据治理能力（决定方案A的落地风险）、以及数据与合规约束是否允许能力外置（可能直接排除某一方）。在条件不明确时，更稳妥的路径是先用托管方案快速验证任务可行性，同时把接口层与评测体系建好，等执行量级和稳定性数据都清晰之后，再决定是否把推理内化。这样无论最终选哪一侧，前期投入都不会浪费。