从“能跑通”到“能一直跑”是 Grok 机器人计划落地时最难过的一关。我这里说的不是某一台指定硬件而是把 Grok 这类大语言模型接到机器人任务规划链路的通用情况。Grok 擅长把自然语言指令拆成动作序列所以很多开发者的第一反应是让模型直接告诉机器人“下一步做什么”。单次任务这样跑没问题一旦任务变长、状态变多计划就非常容易卡住、复位、甚至让机器人停在原地不动。整理了一下这段时间的调试经验我认为最核心的问题是链路结构不是模型本身。下面 6 个实用技巧专治“计划跑不持久”。1. 把模型规划和机器人执行拆成两层1.1 为什么不能把 Grok 的输出直接当控制指令Grok 这类模型有一个非常明显的特征输出有延迟也有随机性。同样是“把箱子放到货架”这句话它今天可能给出三步明天可能给出四步今天返回的是合法 JSON明天可能夹带一段解释文字。如果你让模型直接控制电机、直接下发导航目标那么一次响应超时机器人就会一直停在原地等。很多人在调试时看到的现象是机器人任务执行到一半停住了日志里最后一行停在“正在请求 Grok”。过一会儿模型返回了但机器人已经在原地空转了好几秒。更麻烦的是如果模型返回的动作和当前机器人真实位姿不匹配继续执行只会让任务更乱。所以想让计划持续运行第一步不是提高模型能力而是把模型放回“决策层”不要让它直接碰实时控制。1.2 最小可落地的两层结构我一般会这样设计让 Grok 接收当前任务和机器人状态输出一个高层任务列表。执行层拿到任务列表后按步骤逐个执行每个步骤都调用底层接口。执行层完成一个步骤后更新状态再决定是否需要让模型生成下一步。比如模型输出的计划可能是这样的{ plan_id: P001, steps: [ {index: 1, action: move_to, target: A, timeout: 30}, {index: 2, action: grab, target: box, timeout: 10} ] }这里的move_to、grab不能由模型直接控制电机而是由执行层调用 ROS2 的 action、机械臂接口或 PLC 指令。Grok 只负责告诉执行层“这一步要去哪、做什么”真正控制硬件的是执行层。这样一旦 Grok 超时或返回异常执行层至少可以把当前动作安全收尾而不是死等。1.3 状态机和行为树怎么选新手建议先用状态机。任务阶段无非是 idle、planning、moving、executing、recovering、finished。状态机切换逻辑写死在执行层Grok 只负责给出阶段内的具体目标。状态机的好处是直观一条线走下来出错时很容易定位是哪个状态卡住了。任务分支超过 8 个以后状态机会变得很难维护。这时候改用行为树更合适。行为树可以组合顺序、选择、重试这些逻辑适合机器人导航和机械臂协作同时出现的场景。但不管用哪种都不要让模型直接决定状态迁移。模型的输出只能作为任务目标状态怎么切换由执行层控制。否则就会出现“模型说下一步切换到失败但机器人还在运动过程中”这种互相踩脚的场景。2. 给每个计划节点加上超时、重试和失败恢复2.1 缺超时的系统卡住只是时间问题长期运行最容易出现的现象就是“条件等待卡顿”。比如 ABB 机器人等待一个寄存器信号信号一直没到机器人就在 wait 指令上一直卡着。再比如导航目标在仿真环境下暂时无解机器人就一直停在路径规划器里看起来像完全失去响应。这些问题的共同点就是系统里没有任何一个环节负责“等到什么时候为止”。在给 Grok 生成计划时我会要求每个动作节点都带timeout字段并且由执行层来做硬性计时。超时时间不能只靠模型计算而是执行层根据实际动作类型自动兜底。一般单个动作的timeout设为正常执行时长的 1.5 到 2 倍。如果正常走完需要 10 秒超时就设 15 到 20 秒。整个任务级超时可以设为所有单步超时之和再额外放 30% 的余量。这个数值不是固定的要结合导航距离、机械臂速度、传感器采样周期去调。2.2 重试策略要分三层我给执行层配置重试策略时会分三层动作失败后立即重试一次主要应对通信抖动、socket 断开、ROS2 话题偶发丢消息。等待 1 到 3 秒后再重试主要应对传感器信号未稳定、路径临时堵塞、夹爪没有完全到位。重试超过 2 次后不再重试同一个动作而是把状态置为“需要恢复”然后通知看门狗或人工介入。这里最容易犯的错是把重试逻辑也交给模型。让模型说“请重试”听起来很智能但模型响应慢而且失败时可能连续给出同一条错误指令。重试必须是执行层自动完成的不能依赖模型。尤其是工业机器人场景PLC 和机械臂之间的联锁条件一旦卡住靠外部模型去判断会非常危险。2.3 失败恢复的优先级高于任务继续很多计划跑不持久不是因为任务难度高而是失败后没有恢复路径。我一般会这样设计恢复逻辑停止当前动作。记录当前状态和失败原因。把机器人切换回安全位置或预先定义好的 home 点。如果任务允许跳过该步骤就跳过否则请求 Grok 重新生成新的计划。不要试图从失败点继续硬跑。比如夹爪没抓到箱子原地反复重试只会让情况更糟。正确的做法是先退到安全点重新规划。ABB 机器人“条件等待卡顿”的优化思路也一样就是在等待条件之外加一个时间上限并且给定超时后跳到异常分支。PLC 机器人程序里也必须有类似的联锁和超时判断不能只靠外部脚本轮询。3. 控制上下文长度让长时任务保持清醒3.1 上下文膨胀是计划跑持久的最大隐患Grok 的上下文窗口是有限的。长时间运行的时候如果把每一条传感器数据、每一次状态切换、每一次模型回复都塞进上下文很快 token 就会爆炸。后果有两个一是模型响应越来越慢二是模型开始“忘记”前面真正关键的信息甚至自己造出冲突计划。实测中最常见的情况是机器人跑了 20 分钟以后开始原地打转。表面上看像是导航规划出错但把日志拉出来一看上下文里堆满了无关状态模型已经分不清当前到底在哪个任务阶段。所以想让计划运行持久必须对上下文做主动管理不能放任它一直增长。3.2 三层记忆设计我会把记忆拆成三层短期记忆只保留最近 10 到 30 条关键状态变化。超过就丢弃或者合并为一条摘要。比如“正在前往 A 点”这种中间状态没必要一直留着。长期记忆把地图锚点、常用目标点、之前失败过的位置放进向量库按需检索。比如 Grok 需要知道“仓库里有哪些货架”不要每次都传全量地图而是先按任务关键字检索出相关锚点。这里尤其针对“机器人导航”场景给模型的应该是一张轻量拓扑图而不是巨大的高精栅格地图。地图越大token 消耗越高模型也越容易混乱。固定规则安全边界、禁区、最大速度、急停优先级这些永远不放在模型上下文里而是放在执行层。即使模型忘了执行层也不会越界。这样模型可以自由规划但真正触碰安全规则时底层会拦下来。3.3 上下文压缩的触发时机我建议在下面三个时机做压缩每次模型调用前先估算要发的状态长度超过预估值就压缩。任务切换时清掉上一个任务的细节只保留结果摘要。每 50 步或每 5 分钟做一次全局摘要写入长期记忆。这个逻辑在 ROS2 里可以做成独立节点。节点订阅状态话题维护自己的记忆池Grok 每次只拿最近状态和检索到的知识而不是全部聊天历史。这样能明显减少长时运行时的 token 膨胀也能降低模型响应延迟。4. 引入看门狗和健康检查卡住能自动恢复4.1 先学会判断“没反应”和“正在执行”计划卡住时最忌讳的是直接重启节点。先看三类指标日志最近一条日志是否还在刷新。心跳状态节点是否按固定周期上报 alive 信号。资源CPU、内存、磁盘 I/O 是否异常。如果日志还在刷但机器人不动可能是执行层在等一个永远不来的条件如果心跳都没了可能是节点死锁或崩溃。这两种情况恢复方式完全不同。前者可能是超时配置问题后者可能是内存泄漏或依赖服务挂了。直接重启只会掩盖真实原因。4.2 看门狗怎么设计我一般会在机器人控制器或工控机上跑一个独立进程每 500 毫秒检查一次主节点的心跳文件或话题消息。如果连续 3 到 5 个周期没有心跳就触发恢复。伪代码可以这样写import time MAX_MISSING 3 missing 0 while True: time.sleep(0.5) if heartbeat_file_exists(heartbeat.json): missing 0 else: missing 1 if missing MAX_MISSING: trig_recovery()这里要注意心跳文件必须带时间戳否则程序重启后仍可能读到上一次留下的旧文件导致看门狗误判。如果机器人的计算资源很紧张尤其是“资源受限机器人”场景不要高频写文件可以改用共享内存或订阅 ROS2 话题。更老派的方案是在硬件上开一个硬件看门狗定时器比任何软件实现都可靠。工业 PLC 场景就直接用 PLC 的定时中断没必要再搭额外服务器。4.3 恢复动作要分层恢复动作不能上来就重启系统。我常用的分层是自动清除异常任务回到 safe state。如果主节点无响应拉起重启脚本。重启仍失败机器人进入保持状态等待人工介入。对于带机械臂和移动底盘的复合机器人安全状态不一定是停机很多时候是先停到最近的安全点位再等待进一步指令。如果一异常就断电急停虽然安全但任务中断率会非常高反而跑不持久。4.4 看门狗触发后第一件事是保存现场触发后先把触发前后的日志、状态机状态、模型最近一次输出、执行层当前动作完整保存下来。很多问题只有在现场日志里能看出来。没有这些现场信息下次复现只能靠猜反复试错成本很高。后续无论调超时还是改重试策略都要基于现场记录做判断。5. 严格限制计划输出格式解析环节不能松散5.1 模型输出再准也要先过解析和校验Grok 这类模型即使提示词写得再严格也可能输出多余的说明文字、忘了加逗号、把布尔值写成字符串。如果你在解析层不做校验一个格式错误就能让整条计划中断。所以“Grok 能生成计划”不等于“计划能落地”中间必须有一道闸门。这道闸门不是可选项。长时运行会调用很多次模型哪怕格式稳定率有 99%跑 1000 次也会出现 10 次异常。如果异常直接打断执行计划怎么可能持久。5.2 定义统一计划格式我用的格式是 JSON字段固定为 action、params、timeout、retry、fallback。所有执行步骤都在这套结构里。示例{ steps: [ {action: move_to, params: {target: dock}, timeout: 30, retry: 1, fallback: move_to_safe} ] }如果模型输出不是合法 JSON或者字段缺失解析层直接返回“无法解析”不向下执行。更重要的是action 字段必须做白名单校验。只允许出现系统里已经实现的动作比如 move_to、grab、release、wait_for_io、notify。不在白名单内的动作直接丢弃并提示“不支持的动作类型”。这样即使模型想出奇奇怪怪的动作执行层也不会当真。5.3 校验函数该怎么写一个简单的 Python 伪代码可以这样ALLOWED {move_to, grab, release, wait_for_io, notify} def validate_plan(data): if not isinstance(data, dict) or steps not in data: return False for step in data[steps]: if step.get(action) not in ALLOWED: return False if timeout not in step or step[timeout] 0: return False return True校验通过后再把计划发给执行层。校验失败时可以让 Grok 重新生成一次但重试次数不要超过 1 到 2 次。否则模型一卡系统又回到“一直等模型返回”的老问题。校验逻辑能在计划执行之前把大部分格式异常和非法动作拦截掉显著提升长时间运行的稳定性。5.4 提示词辅助但别依赖提示词在给 Grok 的提示词里我会写得很明确“只返回 JSON不要注释不要 markdown 代码块”然后放 2 到 3 个 few-shot 示例。这样确实能提高格式稳定率但并不能做到 100%。校验层仍然必须有。另外一个细节是解析错误日志也要保留模型原始输出方便回头分析是提示词不够还是模型最近行为变了。6. 先上仿真平台跑 24 小时压力测试再上真机6.1 真机排障成本高仿真压测能提前暴露问题把一套 Grok 机器人计划直接放到真机上跑 24 小时风险很高。机械磨损、环境光线、网络波动、现场 IO 干扰都会影响问题定位。而且真机上跑一次复现路径很慢改一个参数又要重新跑很久时间成本完全撑不住。更合理的做法是先上仿真平台把这些与任务相关的逻辑先在虚拟环境里连续跑把“计划会不会死锁、上下文会不会涨爆、看门狗会不会误触发”这些问题提前暴露出来。6.2 机器人仿真平台怎么选很多人在选机器人仿真平台时很纠结我建议先看三件事是否支持你用的机器人模型和驱动方式。是否能模拟传感器、IO 信号和通信延时。是否能方便注入故障比如断网、堵路径、信号不返回。支持 ROS2 的通用仿真平台是常见选择但也要看你手头机器人是否提供对应的仿真模型。如果机器人和 PLC 来自不同厂商仿真平台还要能模拟 PLC 交互否则你只能测算法测不了完整联调。仿真平台名气再大不支持自己的机器人模型落地都是空谈。另外要关注低配置环境下的表现有的平台动效丰富但对资源要求很高跑 24 小时压测时反而因为图形渲染拖慢仿真速度。6.3 压测期间到底看什么我一般会在仿真里连续跑 24 小时记录 4 类指标单步决策延迟Grok 从收到状态到输出计划的时间看趋势是否持续增大。看门狗触发次数触发多说明上位环节不稳定先查上下文和超时配置。日志丢失率高频状态下消息是不是有掉帧。内存和 CPU 增长曲线正常应该平稳不能一路往上走。判断标准可以设得很简单连续 24 小时里因格式错误导致计划中断的次数为 0看门狗误触发少于 2 次重启次数为 0。如果达不到不要上真机。上真机之后第一周也建议继续盯着这几个指标确认仿真结果和真机结果是否一致。6.4 压测里的一个典型场景我最常用的压测场景是仿真导航时给机器人设置一个无法到达的目标点或者把路径中间放一堵墙。Grok 生成的计划如果一直被路径规划器卡住执行层会显示“等待规划完成”。此时如果超时和重试配置合理系统应该自动标记失败并生成替代计划如果配置不合理程序就会一直等下去。通过这个场景能非常清楚地看出“计划是否持久”。这类场景比单纯跑一条成功路径有用得多。因为成功路径只会验证“功能正常”而持续运行最大的敌人是异常情况下的恢复速度。仿真里把该挂的环节都挂过一遍真机上的稳定性才会真正接近你的预期。说实话我踩过几次坑之后再看这些连续运行问题多数不是 Grok 本身能力不行而是周边链路没有按长时运行的标准来搭。模型是决策层不是实时控制层执行层得有超时、重试、状态机记忆层要控制上下文不能让模型一直背历史监控层要有看门狗卡住能自动恢复输出解析层要把模型偶尔的坏格式挡在门外最后用仿真压测把这些环节一起验证一遍。按这个顺序做Grok 机器人计划从“能跑通”到“能一直跑”才真正有性价比。