1. 从写代码的Agent到动手干活的Agent这个演进到底在说什么Coding Agent 这两年几乎成了 AI 工程圈的标配词汇。从最早的代码补全到能自主读写文件、跑测试、提 PR 的智能体整个行业在短短两三年里把让模型写代码这件事推到了一个相当成熟的阶段。但如果你最近在关注 Agent 领域的前沿讨论会发现一个越来越明显的信号只会在屏幕里敲代码的 Agent天花板已经看得见了。真正让人兴奋的方向是让 Agent 走出纯文本世界去感知物理环境、做出物理动作——也就是 Physical Agent。这个演进不是简单的加个机械臂那么粗暴。它背后是一整套技术范式的迁移从纯语言空间的推理转向语言加视觉加动作的联合建模从单一大模型包打天下转向大脑负责高层规划、小脑负责底层控制的协同架构。关键词里的 VLAVision-Language-Action模型、LLM 作为推理内核、多智能体编排这些概念拼在一起勾勒出的正是下一代 Agent 的轮廓。我写这篇东西不是要给你一份学术综述。我想做的是把这条演进路径拆开讲清楚 Coding Agent 和 Physical Agent 在架构上到底差在哪、VLA 模型是怎么训练的、大脑和小脑怎么分工、以及如果你是一个开发者现在应该怎么理解这套范式、从哪里切入。不管你是做 Agent 应用开发的工程师还是在研究具身智能方向的学生或者只是对AI 怎么从屏幕里走出来这件事好奇这篇内容都值得你花时间读完。先说一个我自己的判断Coding Agent 是 Physical Agent 的预演。为什么这么说因为写代码这件事本身就是一个感知-规划-执行-验证的闭环——读需求是感知拆任务是规划写代码是执行跑测试是验证。这个闭环结构和机器人在物理世界里抓取物体的闭环在抽象层面是同构的。理解了 Coding Agent 的架构演进你就能更快理解 Physical Agent 的设计逻辑。这也是为什么我把这两个概念放在一起讲而不是分开谈。2. Coding Agent 的能力边界它已经做到了什么又卡在哪里2.1 一个成熟 Coding Agent 的典型工作流要理解演进方向得先看清楚现在的 Coding Agent 到底是怎么工作的。我拿一个比较典型的场景来拆你给 Agent 一个任务——给这个项目加一个用户登录接口包含 JWT 鉴权。一个成熟的 Coding Agent 会这样跑环境感知扫描项目目录结构读取相关文件路由配置、数据库模型、中间件理解现有代码风格和依赖。任务规划把加登录接口拆成子任务——定义数据模型、写路由处理函数、实现 JWT 签发与校验、加中间件、写测试。执行逐个生成或修改文件调用工具文件读写、终端命令、测试运行器。验证与修复跑测试如果失败读取错误信息定位问题修改代码再跑直到通过。交付生成 diff 或直接提交。这个流程里工具调用tool use是核心能力。Agent 不是单纯生成文本而是通过调用外部工具来改变环境状态。文件系统、终端、Git、测试框架这些都是它的手。2.2 为什么纯文本 Agent 会遇到天花板问题出在几个地方。第一感知通道太窄。Coding Agent 的输入基本是文本——代码、日志、报错信息。它能看到的世界就是文本化的。一旦任务涉及视觉信息比如这个 UI 布局有问题帮我修一下它就得依赖别人把视觉信息转成文字描述信息损耗极大。第二动作空间是离散的符号操作。写代码、改文件、跑命令这些都是离散的、符号化的动作。但物理世界的动作是连续的——关节角度、力矩、速度都是连续量。这两者的控制逻辑完全不同。第三验证闭环依赖确定性反馈。代码跑测试通过就是通过失败就是失败反馈是确定的。但物理世界里抓取成功这件事本身就有模糊性——物体滑了算不算成功抓歪了但没掉算不算反馈信号是噪声大、延迟高的。第四泛化靠的是语言先验。Coding Agent 之所以能处理没见过的代码库很大程度上是因为海量代码训练让模型学到了编程语言的通用模式。但物理世界的通用模式要难学得多——不同机器人本体、不同传感器配置、不同环境光照都会让同一个任务的表现天差地别。这里有个常见的误解很多人以为 Physical Agent 就是给 Coding Agent 加个机器人身体。实际上从离散符号操作到连续物理控制中间隔着的是一整套建模范式的切换不是简单的能力叠加。2.3 从 Coding Agent 继承下来的三个关键遗产虽然天花板存在但 Coding Agent 这几年的发展给 Physical Agent 留下了三样非常值钱的东西。一是 LLM 作为推理内核的范式。用大语言模型做高层任务分解和规划这个思路已经被验证有效。Physical Agent 同样可以用 LLM 做我该先做什么、后做什么的决策而不需要为每个任务单独写规划器。二是工具调用与函数调用的工程框架。Agent 怎么调工具、怎么处理工具返回、怎么在失败时重试这套工程实践可以直接迁移。只不过 Physical Agent 调的工具从文件读写变成了运动原语。三是多智能体编排的经验。Coding Agent 领域已经摸索出不少多 Agent 协作的模式——一个负责规划、一个负责执行、一个负责审查。这套分工思路在 Physical Agent 里同样适用而且更必要因为物理任务对实时性和可靠性的要求更高。3. VLA 模型把视觉、语言、动作塞进同一个网络3.1 VLA 到底是个什么东西VLA 是 Vision-Language-Action 的缩写。顾名思义它是一个同时处理视觉输入、语言指令、并输出动作的模型。你可以把它理解成给多模态大模型接了一个动作头。传统的机器人控制是分层的上层用规划算法决定去哪里下层用控制器决定每个关节怎么动。VLA 的思路是把这两层打通用一个端到端的大模型直接从看到什么 听到什么指令映射到该输出什么动作。一个典型的 VLA 模型结构大致是这样视觉编码器把摄像头图像编码成特征向量。常见的选择是 ViT 或预训练的视觉 backbone。语言编码器把指令文本编码成特征。通常直接复用 LLM 的 tokenizer 和 embedding。融合层把视觉和语言特征对齐、融合。这一步是关键决定了模型能不能理解把红色的杯子拿起来里红色对应图像里哪个区域。动作解码器输出动作。可以是离散的动作 token也可以是连续的轨迹参数。3.2 VLA 是怎么训练的从模仿学习到大规模预训练VLA 的训练路径目前主流是两条腿走路。第一条腿是模仿学习Imitation Learning。收集大量人类遥操作机器人的数据——人戴着动捕设备或手柄操作机器人完成任务同时记录摄像头画面、指令文本、关节动作序列。然后用这些数据做监督学习让模型学会看到这样的画面、听到这样的指令应该输出这样的动作。这条路径的代表工作是各种开源机器人数据集上的训练。数据量从几万条轨迹到几十万条轨迹不等。训练目标通常是最小化预测动作和真实动作之间的差异用 MSE 或者动作 token 的交叉熵。第二条腿是大规模预训练加微调。先用海量互联网视频、图文对做预训练让模型学到通用的视觉和语言理解能力再在机器人数据上微调动作头。这条路径的好处是能利用互联网规模的先验知识泛化性更好。具体训练时有几个工程细节特别关键动作表示的选择是预测关节角度、末端执行器位姿还是预测动作 token不同表示对训练稳定性和泛化性影响很大。目前比较流行的是把连续动作离散化成 token用类似语言模型的方式预测。时间对齐视觉帧率、语言指令、动作频率往往不一致需要做时间对齐。常见做法是把动作序列按固定时间窗口切片每个窗口对应一帧或几帧视觉输入。数据增强光照变化、视角扰动、物体位置随机化这些增强对泛化至关重要。物理世界的变化比文本世界大得多。3.3 在 LIBERO 这类基准上测试 VLA 意味着什么关键词里提到了vla如何在libero上进行测试。LIBERO 是一个机器人操作任务的基准测试集专门用来评估 VLA 模型在长序列操作任务上的表现。它包含多个任务套件从简单的抓取放置到复杂的多步骤操作。在 LIBERO 上测试 VLA核心看几个指标指标含义为什么重要成功率任务完成的比例最直接的性能衡量泛化能力在新物体、新场景下的表现决定模型能不能走出实验室长序列能力多步骤任务中每一步的正确率考验规划和执行的协同样本效率达到某成功率需要多少演示数据决定部署成本测试流程一般是加载预训练的 VLA 模型在仿真环境里跑标准任务套件记录每个任务的完成情况。仿真环境的好处是可以大规模并行、可复现但 sim-to-real 的差距始终是个问题。我个人的经验是在 LIBERO 上刷到高分的模型放到真实机器人上往往会打不少折扣。仿真里的物理引擎再精细也模拟不出真实世界的摩擦、形变、传感器噪声。所以看 benchmark 分数要理性别把它当成真实能力的等价物。4. 大脑与小脑为什么 Physical Agent 必须做分工4.1 一个模型包打天下为什么不现实最直觉的想法是既然 VLA 能直接从视觉和语言映射到动作那是不是一个大模型就够了理论上可以但工程上不现实。原因在于控制频率和推理频率的矛盾。物理世界的控制需要高频——机械臂的关节控制通常在 100Hz 到 1000Hz意味着每 1 到 10 毫秒就要输出一次动作。但大模型的推理速度即使是优化过的也很难稳定跑到这个频率。一个几十亿参数的 VLA 模型单次前向推理可能要几十毫秒甚至上百毫秒。如果强行让大模型做高频控制要么降频导致动作不流畅、不稳定要么用大算力硬堆成本和功耗都受不了。另一个原因是任务的时间尺度差异。把桌子收拾干净这个任务可能持续几分钟需要高层规划但手指施加多大的力这个决策是毫秒级的。用一个模型同时处理这两个时间尺度效率极低。4.2 大脑层LLM 做规划与决策大脑层的职责是慢思考。它处理的是理解高层指令把厨房收拾干净任务分解先收碗筷再擦桌子最后倒垃圾环境推理碗筷在洗碗机旁边垃圾袋在柜子下面异常处理如果洗碗机满了就先放水槽调用工具和子 Agent把子任务分发给执行层这一层用 LLM 或者多模态 LLM 来做推理频率可以是秒级甚至更慢。它不需要实时性但需要强推理能力和世界知识。大脑层的输出通常是结构化的子任务描述或者运动原语序列比如移动到坐标 (x, y, z)、抓取、放置到目标位置。这些输出是符号化的、离散的正好是 LLM 擅长的。4.3 小脑层VLA 或专用控制器做实时执行小脑层的职责是快执行。它接收大脑层下发的子任务把它翻译成具体的、连续的控制信号。这一层可以用 VLA 模型也可以用传统的运动规划加控制器。选择取决于任务复杂度和对泛化的要求简单、结构化任务传统运动规划如 RRT、轨迹优化加 PID 或阻抗控制稳定可靠计算量小。复杂、非结构化任务VLA 模型能处理视觉变化和指令多样性但需要更多算力和数据。混合方案VLA 输出高层动作意图底层用传统控制器做精细执行。这是目前比较务实的做法。小脑层的控制频率要高通常在 100Hz 以上。它需要处理传感器噪声、执行器延迟、外部扰动这些是纯符号推理处理不了的。4.4 大脑和小脑之间怎么通信这是整个架构里最容易被忽视、但工程上最要命的部分。大脑和小脑的接口设计直接决定了系统的响应性和鲁棒性。常见的通信模式有几种请求-响应模式大脑下发一个子任务小脑执行完返回结果大脑再下发下一个。简单但延迟高大脑得等小脑做完才能决策。流式模式大脑持续输出子任务序列小脑边接收边执行中间有缓冲。响应快但需要处理子任务之间的衔接和冲突。共享状态模式大脑和小脑共享一个世界状态表示大脑基于状态做决策小脑基于状态做控制。灵活但状态同步和一致性问题复杂。我见过不少项目在这块翻车——大脑规划得挺好小脑执行得也不错但两者之间的接口没设计好导致整个系统要么反应迟钝要么动作抖动要么在异常情况下直接卡死。一个实用的经验大脑和小脑之间的接口最好定义成带时间戳和优先级的结构化消息。时间戳让双方能对齐时间优先级让系统在冲突时知道该听谁的。别用裸的字符串或 JSON 传后期维护会哭。5. 多智能体协同Physical Agent 的编排难题5.1 为什么单个 Agent 不够用物理任务往往需要多种能力导航、抓取、操作、检测。把这些能力塞进一个 Agent模型会变得臃肿训练和调试都困难。更合理的做法是拆成多个专职 Agent各司其职。比如一个家庭服务场景导航 Agent负责在房间里移动避开障碍。抓取 Agent负责识别和抓取物体。操作 Agent负责开关门、按按钮这类精细操作。协调 Agent负责分配任务、解决冲突、监控全局。这种拆分和 Coding Agent 领域的多 Agent 协作规划 Agent、编码 Agent、审查 Agent在思路上是一致的。5.2 编排的核心挑战时序、冲突与容错多 Agent 协同在物理世界里比在软件世界里难得多主要难在三点。时序问题多个 Agent 的动作有先后依赖。导航 Agent 没到位抓取 Agent 就抓不到。如果时序没协调好会出现抢跑或空等。冲突问题两个 Agent 可能同时想操作同一个物体或者路径交叉。物理世界的冲突不像软件里加个锁那么简单因为动作一旦发出就收不回来。容错问题某个 Agent 失败了其他 Agent 得知道并调整。比如抓取失败了协调 Agent 得决定是重试、换策略还是放弃这个子任务。解决这些问题目前比较有效的做法是中心化协调加去中心化执行。协调 Agent 维护全局状态和任务队列执行 Agent 只关心自己的子任务通过标准接口和协调 Agent 通信。这样既保证了全局一致性又避免了执行层的过度耦合。5.3 从 Coding Agent 的多智能体实践里能抄什么作业Coding Agent 领域已经积累了不少多 Agent 编排的经验有些可以直接迁移角色定义要清晰每个 Agent 的职责边界、输入输出格式、失败处理方式都要明确定义。模糊的角色定义是多 Agent 系统混乱的根源。通信协议要标准化用统一的消息格式包含发送者、接收者、任务 ID、时间戳、优先级、载荷。别每个 Agent 自己定一套。要有全局监控和日志多 Agent 系统的调试难度是单 Agent 的好几倍。没有完善的日志和可视化出了问题根本不知道是哪个环节。失败要能传播和恢复一个 Agent 失败要能通知相关 Agent触发重试或降级策略。别让失败静默地吞掉。6. 如果你现在想切入这个方向该怎么下手6.1 先搞清楚你是在做大脑还是小脑这是最重要的一步。Physical Agent 的技术栈很宽从 LLM 推理到电机控制一个人不可能全吃透。你得先定位自己。偏大脑方向需要 LLM 应用开发能力、任务规划、多 Agent 编排、工具调用框架。技术栈偏软件和做 Coding Agent 的技能重合度高。偏小脑方向需要机器人学基础、控制理论、运动规划、VLA 模型训练。技术栈偏硬件和算法门槛更高但壁垒也更深。偏系统集成需要理解两边的接口设计通信协议做性能优化和容错。这个方向最缺人因为既要懂软件又要懂硬件。我的建议是如果你已经有 Coding Agent 的开发经验从大脑方向切入最自然。先把 LLM 做规划、多 Agent 编排这套东西玩熟再逐步往小脑方向延伸。6.2 最小可跑通的实验路径如果你想动手试试我建议按这个顺序来仿真环境起步别一上来就碰真机。用 MuJoCo、Isaac Sim 这类仿真环境成本低、可复现、不怕搞坏。跑通一个 VLA 的推理找一个开源的 VLA 模型比如基于 LIBERO 训练的那些在仿真里跑通推理理解输入输出格式。加一个 LLM 规划层用 LLM 把高层指令拆成子任务序列喂给 VLA 执行。这一步能让你理解大脑和小脑的接口设计。加多 Agent 协同把导航、抓取拆成不同 Agent加一个协调层处理时序和冲突。做 sim-to-real 的尝试如果条件允许把仿真里跑通的流程往真机上迁感受一下真实世界的噪声和不确定性。每一步都会踩坑但每一步的坑都是值得的。我见过太多人一上来就想搞端到端的大系统结果卡在某个底层细节上出不来。6.3 几个容易踩的坑坑一低估数据的重要性。VLA 模型的性能高度依赖训练数据的质量和多样性。仿真数据便宜但 sim-to-real 差距大真实数据贵但难规模化。怎么平衡是个需要认真想的问题。坑二忽视实时性约束。在仿真里跑得挺好上真机就卡顿多半是实时性没考虑。控制频率、通信延迟、计算资源这些在仿真里往往被忽略。坑三把 LLM 的输出当成可靠指令。LLM 会幻觉会输出格式不对的内容会给出物理上不可行的指令。大脑层和小脑层之间必须有校验和过滤机制不能盲目信任 LLM 的输出。坑四多 Agent 系统过早复杂化。一开始就搞五六个 Agent 协同调试起来会崩溃。先从单 Agent 加简单工具调用开始跑通了再逐步拆分。7. 这套范式接下来会往哪走我不想做空泛的展望就说几个我观察到的、正在发生的趋势。第一VLA 和 LLM 的边界在模糊。现在很多工作在做统一模型——一个模型既能做语言推理又能输出动作。虽然工程上还有实时性的坎但方向是明确的。未来可能不再有明确的大脑和小脑之分而是按任务动态分配计算资源。第二数据飞轮会成为核心竞争力。谁的机器人部署得多、收集的真实数据多谁的模型就迭代得快。这和自动驾驶早期的竞争逻辑很像。数据闭环的搭建能力会比单点算法能力更重要。第三仿真和真实的融合会加速。纯仿真训练加真机微调或者用世界模型做数据增强这些方向都在快速进展。sim-to-real 的差距在缩小但不会消失。第四Agent 的评估体系会越来越重要。现在 Physical Agent 的评估还很粗糙主要看任务成功率。未来需要更细的指标——泛化性、鲁棒性、样本效率、安全性、可解释性。评估体系不成熟整个领域的发展就会缺乏方向感。最后分享一个我自己的体会从 Coding Agent 到 Physical Agent变的是动作空间和感知通道不变的是感知-规划-执行-验证这个闭环。你在 Coding Agent 领域积累的架构思维、工程经验、调试方法大部分都能迁移过来。真正需要重新学的是物理世界的连续控制、噪声处理和实时性约束。把这两块补上你就能在这波演进里找到自己的位置。
