具身导航大模型与coding-agent路线之争：混合架构才是答案

最近圈子里有个现象很有意思一批专门为具身导航训练的“大模型”刚发布没多久另一拨人却直接把代码生成智能体coding-agent接到机器人上跑了一圈导航任务成功率报到了78%把不少“工业级专用模型”都比下去了。于是有人开始嘀咕花大力气训练导航大模型是不是白训了我的判断比较折中但方向很明确纯通用 coding-agent 裸接机器人能在部分评测集上跑出高成功率这背后有真实的技术逻辑但它不是“专用模型白训了”而是“专用模型的训练方式可能该换思路了”。本文不打算站队而是把这个现象拆开看coding-agent 为什么能接导航任务它的 78% 到底意味着什么它在什么条件下会翻车以及最重要的——做具身导航的团队能从中学到什么不用推倒重来但可能需要调整架构。文章会从概念对比、原理解析、一个混合架构的代码示例、评测指标设计到排错清单逐步展开尽量让对这个话题感兴趣但还没动手的读者读完能形成一条自己的判断线。1. 具身导航大模型与 coding-agent 的路线之争先把名词对齐。具身导航大模型通常指那些输入“视觉观测 语言指令”输出机器人动作序列或导航目标点的模型。它们往往在仿真环境里预训练再迁移到真机上训练目标非常明确让机器人从 A 点走到 B 点途中避开障碍完成语义任务比如“去厨房拿杯子”。coding-agent 则是另一类东西。它本身不是为机器人设计的它的核心能力是理解自然语言描述的需求生成或调用代码完成任务。典型场景是你告诉它“写一个 Python 脚本处理这批 CSV 文件”它给你返回可运行的代码或者直接调用某个接口执行。路线之争的起点是既然 coding-agent 已经能“理解复杂指令 调用工具 执行结果”那为什么不把它直接接到机器人的传感器和执行器上让机器人把“导航到茶几旁边”当成一个 API 调用让 coding-agent 来调度和决策这比专门训练一个导航模型成本低得多。从表面看这确实有吸引力。专用导航大模型的训练数据要采集、要标注、要仿真对齐周期以月计。而 coding-agent 是现成的接上 ROS 或机器人 SDK再写几个工具函数看起来一两天就能跑通。成功率数字又那么漂亮自然会冲击“专用模型才可靠”的传统判断。但这个路线之争的实质并不只是“通用对专用”的胜负。它真正挑战的是机器人导航这类任务到底需要多少“具身经验”又有多少可以靠“常识推理 工具调用”解决如果后者占比很高那通用模型经过轻量适配就能替代专用模型的大部分功能如果占比不高那 78% 就只是一个评测集上的偶然。后面几节我会用更具体的技术机制来解释这个判断。先说明一点这不是一个“谁替代谁”的问题而是一个“任务复杂度分层”的问题。2. 为什么 coding-agent 能接到机器人导航上很多做机器人的同学第一反应是“coding-agent 又没学过机器人控制它怎么知道怎么走” 这个疑问来自一个隐含假设导航必须由“熟悉机器人运动学”的模型来完成。但 coding-agent 的性能来源其实不在运动控制而在下面三层2.1 对自然语言指令的语义理解导航任务的第一步是“理解要去哪”。这看起来简单实际很复杂。指令“把客厅桌子上的纸巾拿过来”机器人需要解析出目标物体是纸巾、目标位置是客厅桌子、任务边界是“拿过来”。传统专用模型通常用固定模板解析意图遇到长尾表达就会退化。coding-agent 在大量代码和文档语料上预训练过语义理解覆盖面广对这种复杂指令的解析能力往往更强。这在“具身导航大模型”里其实是个常被忽略的短板很多导航模型在训练时把指令编码成固定长度的向量长指令、多子句指令、指代消解都会丢信息。而 coding-agent 擅长把指令先转成结构化的中间表示再映射为工具调用这本质上是一种更稳健的“意图理解”。2.2 用“代码即策略”的方式连接感知与执行coding-agent 不直接输出“左转 30 度前进 2 米”这样的底层控制量而是生成代码来调用现成的导航模块。比如它可能会生成下面这段逻辑# 伪代码coding-agent 可能生成的导航调度逻辑 from robot_api import Robot robot Robot() target robot.semantic_search(客厅茶几) # 语义搜索目标点 if not target: robot.ask_user(我没有找到客厅茶几请确认附近是否有遮挡) else: plan robot.plan_path(target) # 调用全局路径规划 while not plan.completed: robot.follow_path(plan) if robot.detected_obstacle(): plan.reroute() # 动态避障这段代码本身没有任何“智能”但它展示了 coding-agent 的真实价值把不熟悉的机器人硬件能力封装成可组合的软件逻辑。机器人的底层导航栈可能已经提供了路径规划、动态避障、里程计定位等功能coding-agent 要做的不是重新发明这些能力而是像写业务代码一样把流程编排起来。这解释了为什么它能“裸接”机器人只要你给它提供清晰的工具 API 文档它就能像使用代码库一样使用机器人能力。传统专用导航模型是把“感知到控制”的映射放进神经网络权重里而 coding-agent 是把“感知到决策”的逻辑写成了显式代码。2.3 任务失败时的自我修正能力专用导航模型遇到规划失败往往直接返回“无法到达目标”。coding-agent 则有一个专用模型通常不具备的机制它能看到错误信息修改代码重新执行。这种“看错误信息 → 改策略 → 重试”的循环让它在真实环境中更有韧性。比如第一次调用路径规划接口时因为起点和目标点距离太近规划器报错。coding-agent 可能会改成先让机器人小幅后退再重新规划。这种问题在仿真评测里很少出现但在真实机器人上非常常见。2.4 这套路线对传统技术栈的依赖仍然很深但注意上面所有机制都建立在一个前提上机器人底层已经具备可调用的导航能力。如果没有成熟的 SLAM、路径规划、避障模块coding-agent 就算写出花来也只是在空壳上做决策。这也正是“裸接”两个字最容易误导人的地方——它不是不需要导航技术栈而是把导航技术栈从“模型参数”搬到了“系统组件”。这个区别非常重要后面会说清楚为什么它既给了 coding-agent 机会也限制了它的天花板。3. 成功率 78% 是怎么来的又意味着什么先声明一下这个 78% 的数据来自行业讨论和评测场景不同评测集、不同机器人平台、不同指令复杂度下数字会明显波动。我不打算把它当成一个严格复现的实验结论而是当作一个“方向性信号”来看。3.1 成功率指标的常见陷阱评测“成功率”有一个经典问题任务成功的定义边界在哪里。对导航任务来说至少有三个口径口径定义评价端到端到达率机器人最终是否到达目标区域常用但忽略路径质量和安全性无碰撞到达率到达目标且全程没有发生碰撞更严格能过滤掉“莽撞成功”任务完成度到达目标且完成语义任务如取物、交互最接近真实价值但评测成本高很多“高成功率”只统计了第一项。如果机器人绕远路、贴墙蹭过去、甚至多次倒退只要最终到达就算成功那这个数字会虚高。所以 78% 这个数字本身不能直接说明“超越了专用模型”必须看评测口径是否一致。如果专用模型用无碰撞到达率而 coding-agent 用端到端到达率那两者根本不具备可比性。3.2 coding-agent 在什么场景下容易刷出高分结合编码智能体的能力特点它在下面几类场景中表现较好指令类型丰富但语义清晰。比如“去卧室窗户附近看一下”目标位置可以通过语义搜索得到不依赖精确坐标记忆。环境结构化程度较高。比如室内走廊、房间布局规整底层路径规划器本身就能处理大部分情况。允许重试和交互。如果机器人错过了目标点可以“掉头再找”这种容错空间对 coding-agent 的自我修正能力非常有利。反过来说如果评测集中在“只给一次规划机会不允许失败重试”或者目标点在没有任何语义标签的开放环境中coding-agent 的优势就会被大幅削弱。3.3 为什么专用模型反而可能吃亏专用导航大模型的训练范式往往是“端到端学习”输入图像和指令直接输出动作分布。这个范式的优势是反应快、不依赖外部模块但劣势也很明显对不在训练分布中的场景泛化能力不足。换一个光照条件、换一类地砖纹理模型可能就“不认识路”了。端到端模型更像一个黑盒错误一旦发生很难定位是感知错了、决策错了还是控制错了。训练数据通常来自固定环境的仿真采集评测环境如果和训练环境差异大性能会快速下滑。所以“coding-agent 反超专用模型”这个现象更准确的解释是在不少“语义导航 结构化环境”任务上用现成工具组件 大模型调度比在有限训练数据上硬学端到端策略更稳。4. 具身导航真正需要的是多层架构而非单一模型写到这里可以给出本文的核心判断了具身导航大模型“白训了”是一个过于绝对的结论但“单一端到端大模型包打天下”的思路确实在面对真实环境时显得吃力。从工程角度看更值得采用的是分层架构通用模型负责高层语义决策传统算法模块负责底层运动执行中间用工具接口衔接。这种架构并不新鲜在自动驾驶和工业机器人领域早有类似做法。但 coding-agent 的介入让“高层语义决策”这一层的实现成本大幅降低。4.1 分层架构里的职责划分层级职责推荐实现为什么任务理解层解析自然语言指令提取目标物体、目标位置、任务约束大语言模型 / VLM语义理解是通用模型强项空间推理层判断目标是否可见、规划大致方向、评估可行性VLM 或语义地图模块需要结合感知信息不一定要端到端路径规划层在全局地图上计算可行路径传统算法如 A*、RRT、Dijkstra成熟、稳定、可解释运动执行层把路径转换成速度指令控制底盘机器人底层控制器高频控制不适合大模型失败恢复层检测异常并决定重规划、回溯或求助基于规则或由大模型生成恢复策略灵活性和稳定性之间取平衡关键点在第二层和第五层这两层正好是专用导航模型主攻的方向也是 coding-agent 相对容易切入的地方。专用导航模型通常想把第一层到第四层全部压缩进一个网络里而分层架构允许每一层使用最适合的工具。4.2 代码示例一个最小混合架构下面给一个最小示例展示如何用 Python 把“语言模型调度 底层规划”组合起来。这个示例不依赖具体机器人厂商用接口占位的方式演示逻辑。# 文件路径mixed_navigation_demo.py # 功能演示大模型高层调度 传统路径规划的分层导航架构 # 注意这是一个架构演示RobotAPI 需要根据实际机器人 SDK 实现 import json from robot_api import RobotAPI # 假设已有机器人接口封装 class LayeredNavigationSystem: def __init__(self, llm_client): self.robot RobotAPI() self.llm llm_client # 任意大模型 API 客户端 self.known_locations { 客厅茶几: [1.2, 3.4], 卧室书桌: [2.5, 1.8], 厨房冰箱: [4.0, 2.2], } def parse_instruction(self, instruction: str) - dict: prompt f 请从机器人导航指令中提取目标位置和约束条件。 指令{instruction} 只输出 JSON包含 target 和 constraint 两个字段。 response self.llm.chat(prompt) return json.loads(response) def locate_target(self, parsed: dict): target parsed.get(target) if target in self.known_locations: return self.known_locations[target] # 如果目标不在已知位置调用语义搜索接口 return self.robot.semantic_search(target) def execute_navigation(self, instruction: str): parsed self.parse_instruction(instruction) target_pos self.locate_target(parsed) if target_pos is None: return {status: target_not_found, message: 无法定位目标} plan self.robot.plan_path(target_pos) if not plan: return {status: plan_failed, message: 路径规划失败} max_retry 3 for attempt in range(max_retry): result self.robot.follow_path(plan) if result.get(collision): # 碰撞后让 LLM 决策下一步 recovery self.llm.chat( f机器人执行路径时发生碰撞错误信息{result}请给出恢复策略 ) plan self.robot.plan_path(target_pos, avoidresult.get(obstacle_pos)) continue return {status: success, attempts: attempt 1} return {status: failed, message: 多次重试仍失败} # 运行示例 if __name__ __main__: llm_client lambda prompt: {target: 客厅茶几, constraint: 无} # 简化示例 system LayeredNavigationSystem(llm_client) result system.execute_navigation(去客厅茶几旁边等我) print(result)这个示例的核心逻辑很简单大模型负责把指令解析成结构化信息传统的plan_path和follow_path负责实际导航碰撞后由大模型给出恢复建议。它没有让模型直接控制电机而是把模型放在“决策链”的高层。4.3 更工程化的调度配置在实际项目中大模型调度往往不是硬编码在 Python 里的而是通过配置中心管理。下面是一个 yaml 风格的配置示例表示不同任务类型使用的导航策略# 文件路径config/navigation_strategy.yaml navigation: default: planner: AStarPlanner obstacle_check: true max_retry: 3 semantic_task: planner: HybridAStarPlanner semantic_search: enabled target_timeout_sec: 30 emergency_recovery: planner: RRTPlanner allow_backward: true fallback_strategy: ask_user把策略配置从代码中解耦出来的好处是评估时可以快速切换不同规划器组合找出哪个配置在目标场景下最稳。这也是“调试大模型机器人”最重要的工程手段之一——不是你换一个大模型就行而是系统里每一层都可能成为瓶颈需要单独验证。5. 评估具身导航模型不能只看成功率既然标题里的 78% 声称“反超专用模型”那我们必须认真讨论评估标准。如果评估指标本身偏了任何“反超”都只是数字游戏。5.1 成功率之外至少要看 5 个维度碰撞率到达目标的过程中机器人是否与障碍物发生过接触。真实环境中碰撞会导致设备损坏是比失败更严重的问题。路径效率实际行驶路径与理论最短路径的比值。绕远路到达任务完成了但用户体验很差。任务耗时包含思考时间、规划时间、执行时间。大模型调度如果每一步都思考 5 秒真实场景根本不可用。指令泛化性训练集之外的指令模型还能不能理解。这是专用模型最容易翻车的地方。故障恢复成功率首次失败后系统能否通过重试或调整策略完成任务。coding-agent 的价值主要体现这里。5.2 一个可落地的评测脚本框架下面给一个评测脚本的骨架便于把“成功率”扩展成多维指标# 文件路径eval_navigation.py # 功能统计多维度导航指标 import time import statistics def evaluate(task_list, robot_runner, max_steps10): metrics { success_rate: [], collision_rate: [], path_efficiency: [], task_time: [], recovery_success: [], } for task in task_list: start time.time() result robot_runner.run(task, max_stepsmax_steps) metrics[success_rate].append(result.get(success, 0)) metrics[collision_rate].append(result.get(has_collision, 0)) metrics[task_time].append(time.time() - start) actual_path result.get(path_length, 0) shortest result.get(shortest_path, 0) efficiency actual_path / shortest if shortest else 0 metrics[path_efficiency].append(efficiency) metrics[recovery_success].append(result.get(recovery_success, 0)) summary { success_rate: statistics.mean(metrics[success_rate]), collision_rate: statistics.mean(metrics[collision_rate]), avg_path_efficiency: statistics.mean(metrics[path_efficiency]), avg_task_time: statistics.mean(metrics[task_time]), recovery_success_rate: statistics.mean(metrics[recovery_success]), } return summary在真实项目中建议把每个任务的具体指令、地图 ID、传感器配置、失败原因都记录下来方便后续定位是哪一层出了问题。这个脚本骨架还可以扩展成把结果写回数据库或对象存储形成长周期回归数据。5.3 评测集设计的两个原则第一训练集和评测集不能“同分布”。如果评测场景都是训练数据的轻微扰动那测出来的数字没有迁移意义。第二必须包含失败场景。比如目标物体被遮挡、地图未更新、传感器噪声异常等这些才是真实使用中决定系统可用性的场景。很多团队的评测报告看起来很漂亮因为选的任务都是模型擅长处理的任务。真正有价值的评测是让模型在“它不擅长”的任务上也跑一遍看它怎么失败、失败后能不能恢复。6. 当前 coding-agent 裸接机器人有哪些硬伤前面说了不少 coding-agent 路线的好处但工程上必须把风险说透否则读者照着做会踩大坑。6.1 延迟和成本问题一次导航决策如果是“大模型 API 调用”网络往返加解码时间通常需要几秒。这在“机器人停下来思考”的任务里可以接受但在人流密集环境中机器人每走几步就要停下来思考几秒体验和安全性都堪忧。具体数据因模型和网络环境而异但从架构判断任何把大模型放进“高频控制环路”的设计都不合适。高频控制应该保持在 10Hz 以上交给局部避障和底盘控制器大模型最多只能出现在 0.1Hz 到 1Hz 的低频决策层。6.2 安全与可解释性风险大模型生成的恢复策略从语义上看起来合理但可能在真实环境中产生意外后果。比如模型建议“尝试穿过门缝”如果门缝宽度小于机器人本体就会导致卡住甚至损坏设备。工程上必须有“安全卫士”机制大模型的建议只能作为候选指令必须经过合法性校验比如检查目标点是否在可通行区域、路径长度是否在合理范围、速度指令是否超过阈值。校验不过则丢弃并回到默认策略。下面是一个最小安全校验逻辑# 文件路径safety_check.py # 功能对大模型建议做基础安全校验 class SafetyGuardian: def __init__(self, max_speed0.5, max_path_length50.0): self.max_speed max_speed self.max_path_length max_path_length def check_command(self, command: dict) - bool: # 检查速度限制 if command.get(type) move: speed command.get(speed, 0) if speed self.max_speed: return False # 检查目标点距离 if command.get(type) goto: distance command.get(distance, 0) if distance self.max_path_length: return False return True这种校验不是限制大模型的能力而是把安全责任重新交还给可验证的代码逻辑。当前大模型的输出本质上是一种概率采样概率再高也不等于真实环境中的安全。6.3 环境动态变化的感知盲区coding-agent 的“世界模型”来自训练语料而不是当前环境的实时状态。如果机器人所在环境发生了结构变化比如施工导致走廊临时封闭大模型并不知道。它可能会执着地建议走那条“最短路径”反而比传统规划器更容易犯错。所以编码智能体不能是唯一决策者。它需要和实时地图、传感器融合模块组成一套系统动态地图信息必须优先于模型先验知识。6.4 机器人厂商 SDK 的接口文档质量决定上限coding-agent 要“会调用”机器人接口就得“看懂”SDK 文档。如果文档质量差、接口命名混乱、缺少示例代码coding-agent 的调度能力会急剧下降。这也是“裸接”很容易翻车的工程原因——不是模型能力不够而是接口本身没有为模型调用优化。做法是专门为模型维护一份“机器人能力图谱”用统一格式描述每个接口的用途、参数、返回值和失败模式。模型调用前先读这份图谱比直接让它读原始 SDK 文档可靠得多。7. 专用导航大模型还有没有必要继续训这个问题是标题留给读者的核心疑问。我的观点是专用模型没有“白训”但其训练目标和架构需要调整。7.1 专用模型仍然有不可替代的场景在算力受限的边缘设备上一个几亿参数的专用导航模型可以做到低延迟、离线运行、输入输出固定不需要依赖云端 API。这在工业现场、医疗物流、偏远地区等场景里是刚需。coding-agent 路线依赖大模型推理要么本地跑大模型对硬件要求高要么连云端对网络要求高这些约束在不少真实场景里根本满足不了。另外当任务对实时性要求极高时比如动态避障、人机协作端到端专用模型的一步推理延迟通常远低于“调用大模型 API”。这个优势在物理世界里是决定性的。所以更准确的说法是专用模型在某些维度上仍然更强但它在“语义理解”和“长尾泛化”这两个维度上确实不如通用大模型。7.2 专用模型的训练范式需要进化从 coding-agent 的表现里可以提炼出三个对专用模型训练有启发的方向训练数据中增加“工具调用”样本。让模型学会调用语义地图、路径规划器等外部模块而不是把所有能力塞进神经网络权值里。增加“恢复策略”训练。当前大多数导航模型只训练“怎么走”不训练“走错了怎么办”。在评测中加入失败恢复科目模型实用性能大幅提升。用大模型生成仿真训练数据。利用 LLM/VLM 设计更多样化的指令和场景缓解专用模型在长尾指令上的数据不足问题。7.3 混合路线可能是最终形态未来更可能的业界形态是一个中等规模的专用导航模型负责底层感知与运动控制一个通用大模型比如 coding-agent 类模型负责高层语义决策与异常恢复两者通过标准接口协作。这不是“谁替代谁”而是各司其职。对团队来说这意味着大模型技术栈和传统机器人技术栈不是二选一而是要同时建设。机器人团队需要有人懂大模型 API 接入和 prompt 设计大模型团队需要有人懂机器人 SDK 和实时约束。这个交叉能力可能比“训练一个更强的专用模型”更稀缺。8. 实际落地建议与避坑指南如果你正在评估“要不要用 coding-agent 做具身导航”下面几条建议可以根据自己的项目情况参考。8.1 先判断任务层级再决定模型路线任务特征推荐路线原因高层语义导航环境较结构化coding-agent 传统导航栈灵活、成本低、易扩展高频动态避障要求毫秒级响应专用端到端模型或局部规划器延迟不可妥协边缘设备、离线运行、算力受限专用轻量模型资源约束决定复杂长尾指令 强交互需求大模型 工具调用混合架构语义能力是关键瓶颈8.2 先做仿真回归再上真机这不是套话。具身导航模型改动的回归风险很高因为真机测试成本大、周期长。建议先在仿真环境里跑一个固定任务集记录成功率、碰撞率、路径效率等指标。每次修改模型、prompt 或工具调用逻辑后先跑回归指标不下降再上真机。仿真环境的选择可以参考机器人仿真平台对比目前主流有 Gazebo、Isaac Sim、MuJoCo 等具体选型取决于是否有现成机器人模型、是否需要物理精度、团队熟悉度等。没有“最好”的平台只有“匹配”的平台。8.3 prompt 设计要包含“失败处理”做 coding-agent 导航时很多人只写任务指令和工具说明忽略了“失败后怎么办”这一关键部分。建议在系统提示词中明确写入第一次规划失败时可以尝试哪些替代策略。哪些操作是禁止的比如强行穿越窄缝、超速移动。当多次尝试失败时必须向用户求助而不是无限重试。# 系统提示词片段可放入大模型 API 的 system message 你是机器人导航调度助手。你可以调用以下工具完成导航任务 - semantic_search(target): 通过语义检索定位目标位置 - plan_path(target_pos): 计算全局路径 - follow_path(plan): 沿路径执行 - ask_user(question): 向用户提问 约束 1. 如果 plan_path 失败最多重试 2 次并尝试调整目标点附近的可通行区域。 2. 禁止在未确认安全宽度的情况下穿过狭窄空间。 3. 如果 3 次尝试后仍无法完成调用 ask_user 请求协助不得自行尝试未经验证的策略。这段提示词能显著减少 coding-agent 在真实环境中的“天马行空”行为。不要指望模型自动遵守安全规则必须写进提示词里并在安全校验层再做一次硬拦截。8.4 建立失败日志与回放系统每次真机运行都应该记录传感器数据、模型输入输出、规划路径、执行结果。一旦出现问题可以像回放视频一样分析失败因果。很多具身导航团队在模型训练上投入大量资源却忽略了工程化的问题追踪体系导致同样的错误反复出现。实践中可以把运行数据保存为 bag 文件ROS 场景或一份带时间戳的 JSON 日志配合对应的地图和任务描述。排错时先找“是哪一层出问题”再决定是否需要换模型、改提示词还是修底层模块。8.5 团队配置建议如果团队要同时走“大模型 机器人”路线建议至少有三类角色机器人工程师负责底层导航栈、传感器集成、安全校验。大模型应用工程师负责 prompt 设计、API 接入、工具调用编排。评测工程师负责设计评测集、构建仿真回归环境、维护失败日志库。三个角色可以重叠但不能缺失。很多项目失败不是因为模型不够强而是没人从全局视角去设计“模型和机器人之间的接口”。9. 常见问题与排查方法问题现象可能原因排查方式解决方案大模型频繁生成无效工具调用工具文档格式不清晰检查模型请求日志确认传入的工具描述用“能力图谱”格式重写工具描述机器人导航时频繁停下等待模型单次决策耗时过长统计 API 调用耗时和频率将高频决策下沉到局部规划器大模型只处理低频任务导航路径绕远成功率虚高路径效率未被纳入优化目标对比实际路径与最短路径在评测中加入路径效率指标并调低重试上限同一指令在不同运行中结果差异大大模型随机采样查看采样温度和随机种子配置将温度调低或评估时固定随机种子模型建议危险动作安全规则未在底层拦截审查安全校验逻辑增加硬性安全卫士校验不通过直接丢弃专用模型在长尾指令上表现差训练数据覆盖不足分析失败指令的语义分布用大模型生成仿真数据补齐长尾仿真通过但真机失败仿真与真实的感知差异大对比 sim-to-real 的传感器数据分布增加领域随机化或先做真机小范围验证这些问题没有一个是靠“换更强模型”解决的大多数要靠工程体系弥补。这是具身导航和纯软件任务最大的不同模型不是跑在服务器上而是跑在真实物理环境里所以“可靠性”和“可诊断性”比“单次性能”更重要。10. 总结与下一步回到标题的问题具身导航大模型白训了吗我的结论是没有白训但“只用大模型包办一切”的训练理念确实需要调整。coding-agent 裸接机器人能够取得 78% 这类结果真正说明的是语义理解、工具调用、失败恢复这些能力在导航任务中的价值被此前低估了而那些传统导航算法已经解决得很好的底层问题端到端模型未必能做得更好。对读者来说下一步可以按这样的路径实践先搞清你的导航任务里瓶颈在语义层、感知层还是控制层。最简单的做法是拿现有传统规划器跑一遍如果表现很好那瓶颈就不在控制层。如果瓶颈在语义层接一个标准大模型 API写一个工具调用层先跑仿真回归。如果瓶颈在感知层比如目标检测、语义分割不稳定那应该优化检测模型而不是指望大模型“看图”解决问题。构建多维评测体系把成功率、碰撞率、路径效率、恢复成功率都记录下来建立回归基线。这个领域的变化速度很快但工程判断力不会过时用什么模型取决于你的任务在哪一层有瓶颈。大模型擅长把复杂语义转化为行动传统算法擅长在真实物理约束下稳定执行把它们组合起来才是当下具身导航最务实的路线。