1. 从代码世界走向物理世界为什么 Agent 需要“大脑”与“小脑”协同过去两年绝大多数人对 Agent 的认知都停留在“能写代码、能调 API、能查资料”这个层面。Coding Agent 确实火从自动补全到整仓库重构从单测生成到 PR 自动提交工具链已经相当成熟。但如果你真正做过机器人、自动驾驶或者任何需要和物理世界打交道的项目就会立刻意识到一个问题代码写得再漂亮也拧不开一瓶矿泉水。这就是 Physical Agent 要解决的核心矛盾。它不是一个新概念包装而是 Agent 技术栈从纯数字空间向物理空间延伸时必然遇到的一整套新问题。Coding Agent 的输入是文本、输出是文本最多加个工具调用Physical Agent 的输入是摄像头图像、激光雷达点云、关节编码器读数输出是电机扭矩、末端执行器位姿、移动底盘速度。这两者的差异不是换个模型就能抹平的。我过去一年在多个机器人操作和具身智能项目中反复踩坑最大的体会是把 LLM 直接接到机器人上效果往往惨不忍睹。原因很简单LLM 擅长的是高层语义推理和任务规划它不知道“抓取”这个动作需要多大的夹爪力也不知道“走过去”这个指令在轮式底盘上对应多少线速度。你需要一个“小脑”来负责实时控制、运动规划和反射式响应而“大脑”负责理解意图、拆解任务、调用工具。两者协同才是 Physical Agent 的完整形态。这篇文章适合三类人正在做 Coding Agent 想往具身方向扩展的开发者、做机器人控制想引入大模型能力的工程师、以及想理解 Agent 技术全景的产品和技术管理者。我会从架构设计、核心模块、实操要点、常见坑四个维度把“大脑与小脑协同”这件事讲透。2. 大脑与小脑的分工逻辑为什么不能用一个模型全包2.1 大脑的职责边界语义理解与任务编排大脑的核心是LLM 或 VLM它负责的是“做什么”和“为什么做”。具体来说大脑要完成以下几件事意图理解把人类的自然语言指令比如“把桌上的红色杯子拿给我”解析成结构化的任务描述。任务拆解把高层任务分解成可执行的子任务序列比如“定位杯子 → 规划抓取位姿 → 移动机械臂 → 闭合夹爪 → 抬起 → 移动到目标位置 → 释放”。工具调用决定在每一步调用哪个技能函数或 API比如detect_object、plan_grasp、move_to_pose。异常推理当小脑反馈“抓取失败”时大脑要判断是位姿不对、力度不够还是物体滑动并决定重试策略。这里的关键是大脑不需要知道电机怎么转但它必须知道每一步的语义状态和成功条件。我见过很多项目把大脑做得太“重”试图让 LLM 直接输出关节角度结果就是推理延迟高、精度差、泛化能力弱。正确的做法是让大脑输出“目标位姿”或“技能调用”而不是底层控制量。2.2 小脑的职责边界实时控制与反射响应小脑对应的是传统的机器人控制栈包括运动规划、逆运动学、力控、视觉伺服等。它的核心要求是实时性和鲁棒性。大脑的推理延迟可能在几百毫秒到几秒但小脑的控制循环必须在毫秒级完成。小脑要处理的事情包括轨迹规划根据大脑给出的目标位姿规划出无碰撞的运动轨迹。力位混合控制在接触任务中比如插拔、拧螺丝同时控制位置和力。反射式响应遇到突发情况比如碰撞、物体滑落时立即执行保护动作而不是等大脑决策。状态反馈把小脑的执行结果和传感器状态反馈给大脑供其推理。我通常会把小脑设计成一个技能库的形式每个技能是一个封装好的控制原语比如grasp(object_id)、place(position)、push(direction, distance)。大脑只需要调用这些技能不需要关心底层实现。这样做的好处是大脑的推理空间被大幅压缩LLM 的 prompt 可以更简洁推理速度更快而且技能库可以独立测试和优化。2.3 协同机制事件驱动的双向通信大脑和小脑之间的通信不是简单的“请求-响应”而是事件驱动的双向流。大脑下发任务后小脑会持续反馈执行状态大脑根据状态决定下一步动作。这里有几个关键设计点状态抽象小脑反馈给大脑的状态必须是语义化的比如grasp_success、object_slipped、collision_detected而不是原始的关节角度或力矩值。超时与重试每个技能调用都要有超时机制超时后大脑要决定是重试、换策略还是放弃。优先级抢占当安全相关的反射触发时小脑可以抢占当前任务直接执行保护动作同时通知大脑。注意大脑和小脑的通信频率不要太高。我见过有人把控制循环的每一帧都发给 LLM结果 token 消耗爆炸推理延迟也完全不可接受。正确的做法是只在状态发生语义级变化时才通知大脑。3. 核心技术点拆解VLA、LLM 规划与技能原语3.1 VLA 模型把视觉、语言和动作对齐VLAVision-Language-Action是 Physical Agent 领域最热的方向之一。它的核心思想是用一个统一的模型把视觉观测、语言指令和动作输出映射到同一个表示空间。这样模型就能直接从图像和指令生成动作而不需要显式的任务拆解。VLA 的训练通常分两阶段预训练在大规模视觉-语言数据上训练让模型理解物体、场景和指令的对应关系。微调在机器人操作数据上微调让模型学会把语言指令映射到具体的动作序列。我实测下来VLA 在短程、高频、视觉主导的任务上表现很好比如抓取、放置、推拉。但在长程、多步骤、需要推理的任务上纯 VLA 就不够用了。这时候就需要大脑LLM来做任务拆解VLA 作为小脑的一部分来执行具体动作。一个常见的架构是LLM 负责把“把桌子收拾干净”拆解成“拿起杯子 → 放到架子上 → 拿起盘子 → 放到水槽里”每个子任务再交给 VLA 或传统规划器执行。这样既利用了 LLM 的推理能力又利用了 VLA 的视觉-动作对齐能力。3.2 LLM 作为任务规划器Prompt 设计与约束用 LLM 做任务规划最大的坑是幻觉和不可执行。LLM 可能会输出一个看起来合理但实际无法执行的计划比如“用夹爪拧开瓶盖”——如果夹爪没有旋转自由度这个计划就是废的。我的做法是给 LLM 加上技能签名约束。在 prompt 里明确列出所有可用的技能及其参数类型要求 LLM 只能输出这些技能的调用序列。比如available_skills [ {name: move_to, params: {target: pose}}, {name: grasp, params: {object_id: str, force: float}}, {name: release, params: {}}, {name: detect, params: {object_name: str}}, ]然后在 prompt 里加上“你只能使用上述技能输出格式为 JSON 数组每个元素包含 skill 和 params 字段。” 这样 LLM 的输出就被约束在可执行空间内幻觉大幅减少。另外few-shot 示例非常关键。我会在 prompt 里放 3-5 个完整的任务拆解示例覆盖常见场景。实测下来这比单纯用文字描述规则有效得多。3.3 技能原语设计从抽象到具体的桥梁技能原语是大脑和小脑之间的接口。设计得好整个系统就流畅设计得不好大脑和小脑就会互相甩锅。我设计技能原语的原则是语义清晰技能名要能直接反映意图比如pick_up比execute_trajectory好。参数简洁参数不要超过 3 个且类型要明确。复杂参数用对象 ID 或预定义配置来替代。状态可观测每个技能执行后要返回明确的状态比如success、failed、timeout。可组合技能之间要能组合成更复杂的技能比如pick_and_place可以由pick_up和place组合而成。一个典型的技能定义如下class Skill: name: str params: dict precondition: callable postcondition: callable execute: callable timeout: float其中precondition和postcondition用于检查技能是否可执行以及是否成功。比如grasp的 precondition 是“物体在夹爪可达范围内”postcondition 是“夹爪力传感器读数超过阈值”。提示技能原语的数量不要太多一般 10-20 个就够了。太多会导致 LLM 选择困难太少又无法覆盖任务空间。我通常会根据具体应用场景来裁剪技能集。4. 实操过程从零搭建一个大脑-小脑协同的 Agent4.1 环境准备与工具选型搭建 Physical Agent 的第一步是选型。我的建议是大脑用支持 function calling 的 LLM比如 GPT-4 系列、Claude 系列或开源的 Llama 3。如果涉及视觉输入用 VLM 比如 GPT-4V 或 Qwen-VL。小脑用 ROS 2 或 ROS 1 作为中间件配合 MoveIt 做运动规划或者用更轻量的 PyBullet、MuJoCo 做仿真。VLA如果要做端到端操作可以用 OpenVLA、RT-2 或自己微调。仿真环境推荐 LIBERO 或 RoboSuite。通信用 gRPC 或 ROS 2 的 action 机制保证大脑和小脑之间的异步通信。我自己的项目里大脑用 GPT-4o小脑用 ROS 2 MoveItVLA 用 OpenVLA 微调。整个系统跑在一台带 RTX 4090 的工作站上仿真环境用 MuJoCo。4.2 大脑侧Prompt 工程与任务规划实现大脑侧的核心是一个任务规划循环。伪代码如下def plan_and_execute(instruction, scene_state): prompt build_prompt(instruction, scene_state, available_skills) plan llm.generate(prompt) for step in plan: skill get_skill(step[skill]) result skill.execute(**step[params]) if result.status ! success: # 触发重规划 new_plan replan(instruction, scene_state, result) return plan_and_execute(instruction, scene_state) return task_completed这里的关键是build_prompt函数。它要把当前场景状态物体列表、位置、机器人状态和可用技能列表都塞进 prompt同时加上 few-shot 示例和输出格式约束。我实测下来prompt 的长度控制在 2000 token 以内效果最好。太短了信息不够太长了 LLM 会忽略中间部分。4.3 小脑侧技能实现与状态反馈小脑侧的核心是技能执行器。每个技能是一个独立的模块负责把大脑的语义指令转换成具体的控制指令。以grasp技能为例class GraspSkill(Skill): def execute(self, object_id, force10.0): # 1. 获取物体位姿 pose self.perception.get_object_pose(object_id) if pose is None: return SkillResult(statusfailed, reasonobject_not_found) # 2. 规划抓取轨迹 trajectory self.planner.plan_grasp(pose) if trajectory is None: return SkillResult(statusfailed, reasonno_valid_trajectory) # 3. 执行轨迹 self.controller.execute(trajectory) # 4. 闭合夹爪并检测力 self.gripper.close(forceforce) if self.gripper.force force * 0.8: return SkillResult(statussuccess) else: return SkillResult(statusfailed, reasongrasp_unstable)这里有几个细节物体位姿获取可以用视觉检测加深度估计也可以用 AprilTag 等标记。轨迹规划要考虑碰撞检测和关节限位。力检测要用夹爪的力传感器或电流反馈。状态反馈方面小脑要定期把关键状态推送给大脑比如object_detected、grasp_success、collision_detected。这些状态是大脑做决策的依据。4.4 仿真验证在 LIBERO 上测试 VLA 与 LLM 协同LIBERO 是一个常用的机器人操作 benchmark包含多个任务套件比如libero_spatial、libero_object、libero_goal。我通常用它来验证 VLA 和 LLM 协同的效果。测试流程如下环境初始化加载 LIBERO 环境设置任务和初始状态。VLA 推理把当前观测图像 指令输入 VLA得到动作序列。LLM 规划对于长程任务先用 LLM 拆解成子任务每个子任务再调用 VLA。执行与评估执行动作记录成功率和执行时间。我实测下来纯 VLA 在短程任务上成功率能到 80% 以上但在长程任务上掉到 30% 以下。加上 LLM 规划后长程任务成功率能提升到 60% 左右。这个提升是显著的但也说明还有很大优化空间。注意LIBERO 的测试结果和真实机器人差距很大。仿真里成功的策略到真机上可能完全失效。所以仿真验证只是第一步真机测试必不可少。5. 常见问题与排查技巧实录5.1 大脑输出不可执行技能签名约束与格式校验问题LLM 输出的计划包含不存在的技能或参数类型错误。排查检查 prompt 里的技能列表是否完整输出格式约束是否明确。我通常会在 LLM 输出后加一层格式校验用 JSON Schema 验证输出是否符合预期。如果不符合直接重试或返回错误。解决用 function calling 替代纯文本输出。function calling 会强制 LLM 按照预定义的 schema 输出格式错误率大幅降低。5.2 小脑执行失败状态反馈与重规划策略问题技能执行失败但大脑不知道失败原因导致重复调用同一个技能。排查检查小脑返回的状态是否足够语义化。如果只返回failed大脑无法判断是物体没找到、轨迹规划失败还是抓取不稳定。解决让小脑返回详细的失败原因比如object_not_found、no_valid_trajectory、grasp_unstable。大脑根据失败原因选择不同的重试策略。比如object_not_found就重新检测grasp_unstable就调整抓取位姿或增加力度。5.3 通信延迟与超时异步设计与优先级抢占问题大脑推理延迟高导致小脑等待时间过长任务执行卡顿。排查测量大脑推理时间和小脑执行时间找出瓶颈。如果大脑推理是瓶颈考虑用更小的模型或缓存常见任务的规划结果。解决用异步通信大脑下发任务后不阻塞等待而是通过回调或事件机制接收小脑的状态更新。同时设置超时超时后大脑可以决定是否取消任务或重试。5.4 常见问题速查表问题现象可能原因排查方法解决方案LLM 输出格式错误prompt 约束不明确检查输出是否符合 schema用 function calling 或加格式校验技能执行超时轨迹规划失败或控制器卡死查看小脑日志和状态反馈设置超时超时后重规划抓取不稳定力度不够或位姿偏差检查力传感器和视觉检测调整力度或重新检测位姿任务规划不合理LLM 幻觉或技能集不匹配检查 prompt 和技能列表加 few-shot 示例裁剪技能集通信延迟高大脑推理慢或网络问题测量各环节耗时用异步通信缓存规划结果5.5 独家避坑技巧技能原语要可测试每个技能都要有独立的单元测试确保在给定输入下能正确执行。不要等到集成测试才发现问题。大脑输出要可解释让 LLM 在输出计划时附带推理过程方便调试。比如“我选择先抓杯子是因为它在盘子前面不会挡住盘子”。小脑状态要可追溯记录每个技能的执行日志包括输入参数、执行时间、返回状态。出问题时可以快速定位。仿真和真机要一致仿真里的物体尺寸、摩擦系数、传感器噪声要尽量接近真机否则迁移效果会很差。安全第一真机测试时一定要有急停按钮和力矩限制防止 Agent 做出危险动作。6. 未来演进从专用技能到通用具身智能6.1 技能库的自动扩展与组合现在的技能库大多是手工设计的扩展性有限。未来的方向是让 Agent 能自动发现和组合技能。比如通过强化学习或模仿学习从演示数据中提取新的技能原语或者把已有技能组合成更复杂的技能。我最近在尝试用 LLM 来生成技能代码。给定一个任务描述和可用的底层 API让 LLM 写出技能实现然后在小脑上执行和验证。这个方法在简单任务上已经能跑通但复杂任务还需要人工干预。6.2 多智能体协同多个 Physical Agent 的分工与通信单个 Agent 的能力有限多个 Agent 协同可以完成更复杂的任务。比如一个 Agent 负责搬运一个负责装配一个负责质检。这里的关键是任务分配和通信协议。我设想的架构是一个中央大脑LLM负责任务分配和全局规划每个 Agent 有自己的小脑和局部大脑。中央大脑通过消息队列下发任务Agent 之间通过共享内存或 ROS 2 topic 交换状态。这个方向还在早期但已经有一些研究在做了。比如多机器人协作搬运、多机械臂协同装配。6.3 从仿真到真机的 Sim-to-Real 迁移Sim-to-Real 是 Physical Agent 落地的最大障碍。仿真里训练好的策略到真机上往往因为传感器噪声、动力学差异、光照变化而失效。常用的迁移方法包括域随机化在仿真里随机化物体纹理、光照、摩擦系数等参数让策略更鲁棒。系统辨识用真机数据校准仿真参数缩小仿真和真机的差距。在线适应在真机上用少量数据微调策略适应真实环境。我自己的经验是域随机化效果最明显但需要仔细设计随机化范围。范围太小迁移效果差范围太大策略学不到有用技能。6.4 LLM 与 VLA 的融合趋势未来 LLM 和 VLA 可能会融合成一个统一的模型。这个模型既能做高层推理又能直接输出动作。这样就不需要显式的任务拆解和技能调用了。但这条路还很长。当前的 LLM 和 VLA 在训练数据、模型架构、推理速度上都有很大差异。融合需要新的训练方法和架构设计。我个人的判断是未来 2-3 年内大脑和小脑协同仍然是主流架构但两者之间的边界会越来越模糊。提示如果你现在开始做 Physical Agent建议从简单的抓取放置任务入手先把大脑-小脑协同的框架跑通再逐步增加任务复杂度。不要一上来就做长程多步骤任务那样很容易卡住。最后分享一个我在实际项目中总结的小技巧把大脑的规划结果缓存起来。很多任务在相似场景下会重复出现比如“把杯子放到架子上”这个任务在不同时间可能只是杯子位置不同。如果场景状态相似可以直接复用之前的规划结果只需要重新执行技能即可。这样能大幅减少 LLM 调用次数提升响应速度。我实测下来缓存命中率能到 40% 左右效果相当可观。