从工具调用到具身执行：AI-Agent如何驱动机械臂完成物理任务

上周在实验室里盯着一台六轴机械臂反复尝试把一颗M3螺丝插进工件孔里旁边屏幕上的Agent日志一行行刷着“抓取失败、重试”“角度偏移0.8度、补偿”。那一刻我突然意识到AI-Agent这一脚跨得比很多人想象的要大——短短两年前我们还在为Agent能正确调用一个天气API而兴奋现在已经在为它接入毫米级力控和视觉伺服了。这个领域的热度也在快速升温AI-Agent、工具调用、具身执行这几个关键词几乎每周都会出现在新的技术讨论里。如果你也想搞清楚Agent是怎么从“只会说话”走到“真的动手”的这篇文章应该能帮你把整条技术路径捋清楚。这篇文章不是概念科普而是我这一路做Agent工具接入、再做机械臂真机部署的经验复盘重点拆三件事工具调用阶段的核心机制和工程坑、从工具调用跃迁到具身执行需要补哪些技术栈、以及一条可以直接参考的“LLM控制机械臂”实操路线。适合正在做Agent应用开发的工程师、准备切入具身智能方向的算法同学以及想评估“Agent到底能在物理世界干多少活”的技术决策者。1. 从工具调用到具身执行Agent演化背后的技术逻辑1.1 Agent的“手”是怎么长出来的回顾AI-Agent这两年多的演进可以清晰看到三个阶段。第一阶段是“会说话”的Agent大模型能理解意图、生成文本但说完就完了没有后续动作。第二阶段是“会调用”的Agent2023年年中开始Function Calling机制让模型可以输出结构化指令去调用外部函数、API和数据库Agent第一次能对数字世界产生真实影响——帮你查天气、订机票、改表格、发消息。第三阶段就是我们现在正处的“会执行”的Agent模型输出的不是JSON请求而是目标位置、关节角度、运动轨迹、力控参数真正驱动机械臂、移动底盘、灵巧手在物理世界干活。这三次跨越的本质是Agent的“输出通道”在变宽。纯文本时代模型的输出只能被人阅读工具调用时代模型的输出可以被程序解析和执行于是它能操作所有“长着API接口”的系统到了具身执行时代模型的输出可以直接映射到执行器的底层控制指令于是它能操作真实的物理设备。你把这几个阶段放在一起看工具调用其实就是“具身执行”的数字预演——先在软件层面验证了“决策→行动→反馈→修正”的闭环然后才让这个闭环真正接触到物理世界的噪声、延迟和不确定性。1.2 为什么Agent一定要走向物理世界有人会问数字世界的工具调用还不够吗答案是不够因为大量真实任务本质上不是“信息处理”而是“物理操作”。产线上的分拣、装配仓储里的搬运、码垛家庭场景中的整理、清洁这些任务没有办法通过调用API完成必须有人把“物理动作”做出来。数字世界解决的是“知道该做什么”物理世界解决的是“真的把它做完”。我个人的判断是这个走向还有三个驱动力。第一是数据瓶颈大模型训练所依赖的互联网文本数据差不多被用尽了而物理交互能产生海量高价值的高维数据这些数据是下一轮模型能力提升的重要燃料。第二是商业闭环单纯卖API的市场空间有限一旦Agent能操作设备、替代流水线上的重复劳动付费意愿和客单价会完全不同。第三是模型能力的溢出当模型已经能够理解复杂指令、进行长程规划顺理成章的下一个变现方向就是把这种“大脑”接到“身体”上。这并不是科幻而是技术能力和商业需求共同推着行业往前走。2. 工具调用数字世界的“动手能力”从何而来2.1 Function Calling的核心机制与关键参数工具调用听起来简单但工程实现上有不少讲究。以最常用的Function Calling为例它的工作流程是这样的开发者在请求里用JSON Schema描述一批可用函数包括函数名、功能描述、参数结构模型看到用户消息后会自己判断需不需要调用函数如果需要就返回一个结构化的“函数调用请求”包含函数名和参数程序收到请求后执行对应的真实函数把结果返回给模型模型把结果组织成自然语言回复给用户。整个过程就是“模型出脑、程序出手”模型负责决策程序负责执行。这里有一个非常容易被忽视的细节函数描述的“写法”直接影响模型调用的准确率。如果你写的是一个模糊的description比如“获取数据”模型很可能在应该调用A函数的时候去调B函数。描述里要写清楚这个函数是干什么的、适合在什么场景用、参数的单位和取值范围是什么。举个例子我之前做一个设备远程控制Agent某个函数是“set_temperature”最初只写了“设置温度”模型在用户说“把温度调到28度”时会传一个字符串“28度”进去后来把参数描述改成“目标温度数值单位为摄氏度类型为整数允许范围16-30”错误率肉眼可见地降了下去。另外temperature参数建议调低工具调用是“精准任务”不是“创意任务”我在工具调用场景基本是0到0.3之间太高会导致模型输出不稳定甚至一本正经地编造不存在的函数名。2.2 MCP与工具生态的协议化工具调用做多了以后你会发现一个痛点每个Agent都要单独写工具接入逻辑十个Agent接十遍换个平台又要重来。这个痛点的解法方向是“协议化”目前最有代表性的是MCPModel Context Protocol。我习惯把它类比成Agent世界的USB-C接口——过去每个设备都要专门配一根线现在统一标准一个接口到处插。MCP定义了一套Client-Server架构模型通过客户端连接各个MCP Server每个Server负责暴露自己的工具、资源或提示词。Agent接入一个新工具不再是写一大堆胶水代码而是启动一个MCP Server再连上就行。这套体系对具身执行特别有价值。想象一下一个Agent需要同时操作机械臂、调用视觉识别服务、查询MES系统里的工单数据如果没有统一协议每个设备的SDK、认证方式、数据格式都不一样整合成本极高。用MCP的框架做可以把“机械臂控制”封装成一个Server把“视觉定位”封装成另一个ServerAgent只需按照协议去发现和调用这些工具。我在做机械臂Agent原型时就是把抓取、放置、位姿识别、路径规划都封装成了MCP工具调试效率比之前直接调SDK高了很多。2.3 工具调用工程化中容易翻车的几个细节工具调用看着简单实际投产时有不少坑。我总结几个最常踩的回填给模型的结果要精炼。很多初次接触的人会把工具返回的十万行日志直接塞回模型上下文紧接着就遇到“上下文爆炸”和“模型被噪声干扰”的问题。正确的做法是在执行函数内部对结果做摘要只把关键状态、关键数值、错误码回填给模型。给工具调用设置超时和降级策略。外部服务不稳定很常见如果工具连续失败Agent不能一直干等。我通常会给核心工具配两级降级路径第一级换备用API第二级直接向用户说明“当前能力不可用”而不是让模型硬编一个假结果。注意级联调用带来的token成本。一个任务拆成五六步工具调用每步都要把中间结果回填给模型token消耗增长很快。基于我的经验需要根据任务复杂度动态决定“要不要多轮调用”简单的任务尽量一步到位。工具的审计与权限分级不能省。工具能执行的动作越重权限管控就越要严格。读操作可以放开写操作要鉴权涉及物理设备的操作必须双重确认。这里的教训是权限问题不要等项目大了再补最好在接入第一个高危工具时就定好规范。3. 具身执行的技术栈与指令链路3.1 具身Agent系统的模块划分从工具调用跳到具身执行技术栈的复杂度是数量级提升。为了说得清楚我把具身Agent拆成五个模块每个模块负责一个环节模块职责常用技术方向感知模块获取环境信息识别物体、检测状态RGB-D相机、激光雷达、YOLO系列目标检测、6D位姿估计决策模块理解任务、拆解步骤、选择策略大语言模型、视觉语言模型VLM、VLA模型、任务规划器运动规划生成无碰撞、可执行的轨迹MoveIt、OMPL、RRT系列、CHOMP、轨迹优化执行控制把轨迹变成电机动作处理力/位控制ROS2、PD/PID控制、阻抗控制、导纳控制、伺服驱动反馈闭环确认动作是否生效修正误差力传感器、视觉伺服、状态机、重试逻辑很多人以为具身Agent的核心就是“一个大模型包打天下”真正做过以后才知道每个模块都可能是木桶的一块短板。决策模块再聪明如果视觉定位误差超过一厘米机械臂照样抓不住东西运动规划再顺滑如果底层控制不稳定照样会有抖动和过冲。做具身执行本质上是在做系统集成工程要把感知、规划、控制的误差一层层消化掉。3.2 从一句话到一次抓取指令是怎么变成电机转动的用一个最简单的任务“把桌上的杯子拿起来放到盘子里”完整走一遍指令链路你就能理解具身执行和工具调用的区别。第一步是任务拆解大模型把自然语言指令解析成有序子任务找到杯子、移动机械臂到抓取位置、闭合夹爪、抬起、移动到盘子上方、释放。这个阶段输出的还不是物理量而是语义级别的行动序列。第二步是语义锚定视觉语言模型把“杯子”这个语义概念映射到图像中的具体区域再结合深度图计算出它在机械臂基座坐标系下的三维位姿输出的是一个包含x、y、z坐标和姿态的四乘四变换矩阵。第三步是运动规划规划器负责在机械臂当前构型和目标位姿之间找出一条满足关节限位、不碰撞环境、轨迹平滑的路径输出的是机器人各个关节角度的时序序列。第四步是底层执行控制器把规划好的轨迹转变成每个关节电机的目标位置、速度、力矩指令伺服驱动器驱动电机转动机械臂在物理世界画出真实轨迹。第五步是反馈闭环手臂到位后视觉系统做二次确认力传感器判断夹爪是否夹到了杯子如果没夹到或者夹偏了系统会触发修正或重试。这一整套下来你会发现大模型在其中的角色更多是“战略决策者”真正的战术动作由感知、规划、控制模块来完成。我在实际部署时也体验到Agent层的价值在于把脏活累活不确定环境、口语化指令、异常状态转换成多个专业模块能够处理的标准化输入你可以把整个系统看成一家公司——大模型是CEO视觉、规划、控制是各个部门CEO不需要亲自拧螺丝但要知道该叫哪个部门来干活。3.3 Sim2Real跨越仿真与现实的鸿沟具身执行绕不开的一个话题是Sim2Real。在真实机械臂上调试一次抓取成本高、周期长、还有安全风险所以主流做法是在仿真环境里先把算法验证好再迁移到真机。常用仿真器包括Isaac Sim、MuJoCo、Gazebo各有侧重Isaac Sim的渲染效果好适合视觉相关任务MuJoCo快适合做强化学习Gazebo配ROS生态方便适合做整机验证。但仿真和现实之间永远存在一道“鸿沟”也就是所谓的Sim2Real gap。仿真器里没有真实的光照变化、没有传感器噪声、没有机械臂的动力学误差在仿真里跑得好好的策略一上真机可能完全失灵。业界常用做法是domain randomization也就是在仿真里随机化物体的纹理、光照、物理参数、相机位姿让策略见过足够多的“世界变体”从而提高在真实世界的泛化能力。我个人的建议是不要把仿真结果当成真机效果的承诺仿真能帮你验证流程逻辑、排除明显bug但最终的调优一定要回到真机上尤其涉及力控、柔顺操作的场景仿真和真实世界的差距更难拉平。4. 实操案例LLM控制机械臂完成“识别-抓取-放置”4.1 硬件选型与系统搭建说一个我最近跑通的完整案例方便你直接参考。硬件方面我用的是一台六轴协作机械臂比工业机械臂更轻、有更好的力矩感知能力适合做研究原型末端执行器用的电动平行夹爪视觉传感器用了一个RGB-D深度相机负责检测物体和输出深度信息算力平台是一台带RTX系列GPU的工控机既要跑视觉模型又要跑机械臂控制显存尽量不要小于8G我实际用下来12G左右比较舒服。软件栈方面系统选用Ubuntu 22.04和ROS2 Humble机器人操作系统负责各模块间通信运动规划用的是MoveIt2这是ROS生态里最成熟的机械臂规划框架视觉部分用的YOLOv8做目标检测配合深度图计算三维坐标Agent调度层用Python写了一个简单的循环负责和LLM交互、调用上述视觉和运动规划工具。整套系统的基本信息流是自然语言指令进入LLMLLM拆解出子任务后依次调用视觉工具和运动工具底层模块执行后反馈结果LLM根据反馈决定下一步动作。4.2 标定、感知与Agent调度实现部署的第一步不是跑模型而是标定。相机看到的是一堆像素机械臂执行的是空间坐标这两者之间的桥梁就是相机标定和手眼标定。相机内参标定解决的是“像素坐标怎么变成相机坐标系下的物理坐标”手眼标定解决的是“相机坐标系和机械臂基座坐标系之间的变换关系”。手眼标定有两种模式眼在手上即相机装在机械臂末端标定的是相机到末端的固定变换眼在手外即相机固定安装标定的是相机到机械臂基座的变换。我做的是眼在手外用标定板拍了十几组不同位姿的数据通过ROS2的easy_handeye2工具计算变换矩阵最后重投影误差在2到3个像素以内这个精度对抓取常规物体够用了。标定完成后感知侧就相对直接了。相机拿到RGB图目标检测模型输出杯子的边框和类别深度图提取边框中心点的深度值再结合相机内参和手眼标定结果就可以算出杯子的三维位置。为了让抓取更稳我还会对目标点做一次“下降试探”先用检测结果驱动机械臂移动到目标正上方再用深度相机的局部数据修正高度这样可以抵消一部分标定残差。下面是Agent调度层的一个简化代码框架你可以看到它和Tool Use阶段的核心模式是相通的TOOLS [ { type: function, function: { name: detect_object_3d_position, description: 检测目标物体在机械臂基座坐标系下的三维位置, parameters: { type: object, properties: { object_name: {type: string, description: 目标物体名称} }, required: [object_name] } } }, { type: function, function: { name: move_to_pose, description: 控制机械臂末端运动到指定三维位置, parameters: { type: object, properties: { x: {type: number}, y: {type: number}, z: {type: number} }, required: [x, y, z] } } } ] def run_agent(task: str): messages [{role: user, content: task}] while True: response llm.chat(messages, toolsTOOLS) if response.tool_calls: for call in response.tool_calls: result execute_tool(call.function.name, call.function.arguments) messages.extend([ {role: assistant, content: None, tool_calls: [call]}, {role: tool, tool_call_id: call.id, content: str(result)} ]) else: return response.content这段代码的核心逻辑就是“模型决策、程序执行、结果回填”的循环。在具身场景里唯一的区别是工具函数从“查数据库”变成了“感知三维坐标”“控制机械臂运动”同时底层执行变得慢得多一个动作可能要几秒钟到十几秒所以整个循环的节奏要慢下来每一步都要有足够的超时和重试机制。4.3 运动规划与执行反馈运动轨迹规划是让机械臂“安全到达”的关键我用的是MoveIt2结合OMPL的RRT-Connect算法。它做的事情就是在机械臂的关节空间里找一条从当前位置到目标位姿、满足关节限位和碰撞约束的无碰撞路径。实际使用时有几个参数需要重点调规划时间上限、路径平滑程度和末端允许误差。我的经验是不要把目标设得太激进末端速度控制在0.2m/s左右、加速度0.5m/s²虽然动作看起来稍微“木”一点但稳定性和安全性好很多后期再逐步提速。执行完动作后一定要有反馈闭环否则机械臂就是“盲飞”。我在夹爪和视觉两个层面都加了反馈夹爪闭合时读取电流值判断是否夹到了物体夹空了就重新调整角度再来一次放置完成后用深度相机拍一张图验证物体是否在目标区域。这套机制把一个端到端任务的成功率从70%级别拉到了90%以上剩下的失败大多源于极端光照和物体形状特殊。整个调试过程中我最深的感受是具身执行项目里80%的精力都花在“让系统稳定地做简单的事”上而不是“让模型变聪明”。5. 常见问题与排查技巧实录5.1 高频故障速查表具身Agent调试过程中的问题往往不是模型不够聪明而是系统某一环掉链子。我把高频问题整理成一张表方便你对照排查现象可能原因排查建议LLM返回的坐标参数明显越界工具描述没写参数范围在JSON Schema里加上minimum/maximum约束调度层再做一次参数合法性校验机械臂运动过程中抖动明显速度增益过高或路径不平滑降低TCP速度和加速度开启轨迹平滑检查规划器输出夹爪经常抓空或夹偏视觉定位精度不足或夹持策略不当增加高度修正步骤检查标定误差调整夹爪开合宽度仿真里正常、真机上位置全偏相机标定或动力学参数差异重新标定检查机械臂DH参数先做单点重复精度测试Agent调用工具超时底层动作太慢超过Agent等待上限把工具的等待时间改为异步轮询或加大超时值深度相机在强光下测距不准红外结构光/ToF受环境光干扰加滤光片、换遮光环境或用多视角融合数据模型在长程任务中突然“忘了”目标上下文太长导致注意力衰减用结构化状态记录器管理任务状态不全部依赖上下文5.2 安全设计不可妥协系统运行在物理世界出了问题的后果和数字世界完全不在一个量级所以安全设计必须放在最高优先级。我的经验是至少做三层保护第一层是硬件急停机械臂控制柜上要有独立急停按钮按下后直接断电锁轴不经过任何软件第二层是软件限位在控制器里设置关节角度软限位、末端速度限制、力/力矩限制接近边界时自动减速停止第三层是Agent层面的行为约束在LLM的System Prompt里明确规定禁止的动作同时在工具层做参数白名单比如移动范围限定在工作空间内。还有一个容易被忽视的点Agent在异常情况下可能会连续执行同样的错误动作。我在调度代码里专门加了“连续失败熔断”机制同一子任务连续失败三次就停止自动重试并请求人工介入。这个设计思路来自工业自动化领域的报警管理在具身Agent上同样适用。毕竟物理系统不能无限试错每一次错误动作都有成本甚至可能损坏设备。5.3 具身Agent好不好要看哪些指标评估一个具身Agent表现如何我建议关注五个核心指标单步成功率、端到端任务完成率、平均执行时间、平均重试次数、人机干预率。单步成功率反映底层模块的稳定性端到端完成率体现Agent整体能力平均执行时间是商业落地的关键直接决定产出效率重试次数能帮你定位系统瓶颈——到底是感知问题、规划问题还是控制问题人机干预率则是衡量系统成熟度最真实的指标一个成熟的具身Agent应该能连续运行很长时间不需要人帮忙。我在项目汇报时通常会把“干预率”放在最核心的位置因为它最能说明系统是否真的可用而不只是在demo里能用。6. 落地场景与影响范围物理世界正在被重新编程6.1 最可能被重塑的行业AI-Agent从工具调用走到具身执行受影响最大的肯定是那些“重复性强、环境相对结构化”的行业。工业制造排第一位产线上的上下料、分拣、装配、质检都是结构化环境下的重复操作非常适合具身Agent切入而且制造企业本身就有自动化基础和改造预算。仓储物流同样热门移动底盘加机械臂的组合可以在仓库里完成取货、搬运、盘点、包装等任务能有效缓解旺季人力不足的问题。家庭服务是大家最期待的领域家务场景极其非结构化技术难度最高但一旦在安全性和可靠性上取得突破市场容量不可估量。还有一个容易被忽略的方向是危险环境作业比如配电站巡检、有毒有害空间操作人类本来就不愿意去机器替代的意愿很强是具身Agent能较早商业化的场景。这一波变革对行业的影响不在于“替代人”这个判断本身而在于重新定义“哪些岗位需要人”。基础的重复劳动会被Agent逐渐消化但设备的维护、复杂异常的决策、系统之间的协调仍然需要人的经验和判断。对从业者来说我的建议是不要焦虑被替代而是主动学习“如何指挥Agent干活”从“自己执行”转向“定义执行标准和验收标准”这个技能在接下来几年会越来越值钱。6.2 对开发者能力结构的新要求原来做AI-Agent开发核心能力是自然语言处理、提示词工程、后端API集成。到了具身执行能力模型明显变宽了你要看得懂坐标变换知道四元数、旋转矩阵你要理解ROS2的通信机制会配置话题、服务和Action你要懂一点控制理论至少得知道P控制和阻抗控制的区别你还要有硬件安全意识知道什么动作是危险的、怎么设计急停链路。这些知识在传统AI课程里学不到都要靠现场实践一点点积累。我的习惯是“仿真先行、真机分步验证”。每引进一个新模块先在仿真环境里把参数调顺再回到真机做单点验证确认无误后再做系统集成。这样可以把变量控制在最小范围出了问题也能快速定位。这套方法论让我避免了很多大改推倒重来的痛苦也推荐给刚开始做具身方向的开发者。说实话这个领域还在非常早期的阶段没有太多成熟标准可参考反而给了大家很大的探索空间。最后再分享一个我在实际项目中反复验证的经验越是看起来“智能”的系统越要保证底层每个环节的确定性。Agent的创新在决策层但稳定性的地基在感知、规划、控制这些“不性感”的模块里。把标定做准、把超时机制设好、把安全链路测透比换一个更聪明的模型更有用。AI-Agent走向物理世界的路还很长但每一步踏实的工程实践都会让它走得更稳一点。