大模型生成代码驱动机械臂：具身智能抓取实战

之前在业务迭代中接触具身智能时，最大的感受是：论文里讲得很高，动辄“世界模型”“具身大模型”，但真正想动手复现一个“机器人听指令抓物体”的效果时，往往被一层又一层概念挡在门外。很多材料只给架构图，不给代码路径；只讲模型能力，不讲物理边界。这篇文章想把这条路走通——从具身智能最核心的“感知-决策-执行闭环”出发，重点拆解一个关键思路：让大模型输出可执行代码，而不是直接输出抽象的指令，再由代码去调用机械臂、底盘、夹爪等真实或仿真控制接口，最终完成物理世界里的具体任务。

文章会包含完整的环境准备、场景分析、可运行的示例代码、常见坑点和工程落地建议。不管你是想了解具身智能论文里反复提到的“可执行代码到底是什么意思”，还是准备在自己的机器人项目里接一个大模型做决策控制，都适合读下去。读完你不仅能明白具身智能机械臂背后的技术栈，还能跟着实战章节，把一条“自然语言指令 → 感知结果 → 策略代码 → 执行动作”的链路完整跑通。

1. 具身智能：让 AI 从“对话”走向“动手”

1.1 什么是具身智能

具身智能（Embodied AI）研究的是：一个拥有物理身体的智能体，如何通过与真实世界互动，来学习、感知和完成复杂任务。这句话听起来抽象，拆开看就清楚了。

传统意义上的 AI，比如聊天机器人、图像分类模型，处理的是“信息空间”里的数据。你输入一句话，它输出一句话；你输入一张图，它输出一个标签。整个过程停留在数字世界里，不产生物理变化。

具身智能则不一样。它要求智能体必须有“身体”——机械臂、四足机器人、轮式底盘，甚至只是一只仿真环境里的虚拟夹爪。智能体通过摄像头、触觉传感器、关节编码器去感知物体的位置、形状、材质，然后决策下一步该做什么，最后把决策变成真实的物理运动。AI 从“会说”变成了“会做”。

这也是为什么“机器人 AI”和“具身智能”这两个词经常被放在一起讨论。一个只会写代码的 AI 不是机器人，一个只会按固定轨迹运动的机械臂也不是智能体。只有当感知、决策、执行三个环节形成闭环，并且具备泛化到新场景的能力，才算真正进入具身智能的范畴。

1.2 具身智能与传统 AI、机器人控制的区别

要理解具身智能，必须先分清它和传统方案之间的边界。

先看传统机器人控制。工业机械臂抓取一个固定位置、固定高度的工件时，工程师会事先规划好轨迹，把运动学方程、PID 控制器参数写死在程序里。这套方案非常稳定，但通用性很差。只要工件位置偏移一厘米，或者换一个抓取对象，往往就得重新调试参数，甚至重新标定坐标。

再看传统 AI。近年来的大语言模型确实能理解自然语言、生成代码、规划任务，但模型本身没有机械臂，没有传感器，也没有执行器。模型知道“西红柿放在操作台上”，但它不知道自己的夹爪现在在什么位置，也不知道伸手过去需要多大力矩。这种缺乏环境状态反馈的模型，只能做高层规划，无法独立完成物理世界里的闭环操作。

具身智能要做的事情，就是把这两条线缝合起来：

• 用视觉、触觉、关节反馈等传感信息替代纯人工标定；
• 用大模型或强化学习策略替代手工规则和状态机；
• 用运动规划与底层控制把决策结果转化为真实的物理位移；
• 用“执行结果是否成功”作为反馈信号，驱动智能体不断调整策略。

简单说，传统机器人控制强调“精确执行人类预设的程序”，传统 AI 强调“在信息空间里生成内容”，而具身智能强调“在一个物理闭环中自主决策、行动和验证”。

1.3 为什么“可执行代码”是关键路径

近两年具身智能论文里频繁出现一个词：可执行代码（executable code）。很多刚接触这个概念的同学会疑惑：大模型明明可以直接输出文字指令，为什么非要输出代码？

因为文字指令和信息密度、可组合性都不够。

举个例子。你让大模型“帮我把桌上的绿色方块放到左侧篮子里”。如果模型输出一段自然语言：“先移动到桌子附近，然后伸出机械臂，夹住绿色方块，移动到篮子位置，松手。”看起来没问题，但这段文字无法被机械臂控制器直接执行。你需要一个人去读这段文字，再翻译成运动指令，整个过程又回到了人工编程的老路。

但如果模型直接输出一段 Python 代码，情况就不同了：

python复制move_to("table")
pick("green_block")
move_to("left_box")
place("green_block")

这段代码里的每个函数，比如 move_to、pick、place，都是事先封装好的底层控制接口。代码本身就可以被解释执行，生成的动作指令直接驱动仿真器或真机。大模型在这种情况下做的是“组合”而不是“翻译”：它从已有的动作函数库中挑选合适的函数，并传参调用。

这种方案有几个非常实际的优势：

• 泛化性更强：只要函数库覆盖了足够多的原子能力，模型就能组合出多样化的行为，而不必针对每个任务单独训练；
• 可审计性更好：代码是人类可读的，工程师能在执行前检查和修改策略；
• 调试成本低：某一步失败了，直接看代码就知道模型规划的逻辑对不对，而不是盯着黑盒网络发呆；
• 工具生态可复用：现代大模型在代码生成上已经相当成熟，借助代码生成能力去控制机器人，比直接从模型输出关节角度要简单得多，也不需要大量机器人轨迹数据。

这也是“机器人自主进化”在这个时代能够落地的一个重要原因。模型不一定要从一开始就学会所有的精细操控，它能通过生成代码组装已有的技能库，并且利用视觉反馈迭代试错。下面我们从技术栈层面展开，看看这样一套系统到底包含哪些模块。

2. 具身智能系统的技术栈与工作闭环

2.1 感知层：读物理世界

感知层负责回答一个问题：环境当前是什么样的？

在具身智能系统里，感知不是简单地识别“图片里有一只杯子”，而是要输出与机器人行为直接相关的结构化信息，比如：

• 目标物体的类别和语义属性（这是什么、能不能抓）；
• 位置与姿态（物体在相机坐标系、机器人基座坐标系或世界坐标系下的坐标）；
• 形状和大致尺寸（决定夹爪开口宽度和抓取方向）；
• 障碍物分布（决定机械臂运动路径是否安全）。

常用传感器包括 RGB 摄像头、深度相机、激光雷达、触觉传感器和关节里的编码器。其中 RGB-D 深度相机是最主流的方案，因为它在硬件便宜和数据处理效率之间取得了较好的平衡。

感知层的输出，通常不是一张图，而是一份场景描述（Scene Description），比如 JSON 形式的物体列表：

json复制{
  "objects": [
    {"name": "green_block", "x": 0.40, "y": 0.22, "z": 0.05, "w": 0.04, "h": 0.04},
    {"name": "red_block",   "x": 0.21, "y": 0.51, "z": 0.05, "w": 0.04, "h": 0.04}
  ],
  "gripper": {"x": 0.60, "y": 0.70, "z": 0.20}
}

这份描述会作为上下文，传给决策模型。后续生成代码时，模型就能基于真实坐标调用控制函数，而不是凭空猜测物体在哪里。

2.2 决策层：从指令到任务拆解

决策层负责回答两个问题：要完成什么目标？分成哪些动作序列？

传统机器人任务规划常用 PDDL（Planning Domain Definition Language），把任务拆成“先执行 A，再执行 B，最后执行 C”的逻辑。PDDL 的问题在于，用户需要手工编写领域定义，而且规划器并不擅长处理视觉感知中的不确定性和模糊语义。

引入大语言模型后，决策层发生了一个重要转变：任务拆解不再依赖人工写死，而是由模型根据自然语言指令和当前感知结果直接生成。模型完成三件事：

1. 理解指令：“把绿色方块放到左侧篮子”；
2. 结合感知结果：绿色方块当前在坐标 (0.40, 0.22, 0.05)；
3. 生成动作序列：调用 navigate、pick、move_to、place，并填上正确的参数。

这里最有意思的环节，是“生成动作序列”的具体形式。早期论文倾向于让模型输出 JSON 动作列表，比如：

json复制[
  {"action": "pick", "target": "green_block"}
]

后来很多工作发现，直接让模型生成可执行代码比输出 JSON 更灵活。代码里可以有条件判断、循环、异常处理，能表达更复杂的控制流。比如模型可以生成：“如果第一次抓取失败，就调整夹爪角度重试一次”的逻辑。这种表达能力，在纯 JSON 列表里很难实现。

当然，让模型自由生成代码也引入了风险和不确定性，因此必须给模型约束一个可控的“函数库”和“语法范围”。这一点我们在实战中会具体处理。

2.3 执行层：控制函数与运动规划

执行层负责把代码里的函数调用变成实际物理运动。这一层通常由运动规划器和底层控制器构成。

当决策层生成了 pick("green_block")，执行层首先要把目标物体的三维坐标换算到机械臂基座坐标系下，再由逆运动学（Inverse Kinematics，IK）求解出机械臂各关节的角度。如果目标点有多个可选解，还要选择一条平滑且不碰撞的轨迹。最后，底层控制器会按照规划好的轨迹输出力矩或位置指令，驱动电机转动。

这里需要特别区分两个概念：

• 运动规划：负责“路径怎么走”。比如从当前位姿到抓取点之间，机械臂肘部要怎么弯，才能不碰到周围的障碍物；
• 底层控制：负责“跟随路径”。比如按照多少速度、多大加速度驱动每个关节，让机械臂实际执行轨迹。

在仿真环境里，很多仿真器已经帮你把运动规划和动力学都算好了，你只要调用 setJointMotorPosition 之类的接口就能让机械臂动起来。而在真实机器人上，这一层通常要对接 ROS（Robot Operating System）的运动规划框架。这也是“仿真容易、真机难”最集中的体现。

2.4 感知-决策-执行的闭环设计

上面三个模块不是单向串联，而是一个闭环。执行动作后，感知模块需要再次观察环境，确认“绿色方块是否真的被夹住了”“是否被放到了目标位置”。如果操作失败，系统要把失败信息反馈给决策层，让模型重新生成策略。

闭环逻辑用伪代码描述就是：

text复制while not task_finished:
    scene = perceive()
    plan_code = generate_code(instruction, scene, action_library)
    result = sandbox_execute(plan_code)
    task_finished = check_result(result)

为什么闭环如此重要？因为物理世界充满不确定性。模型在生成代码时，视觉给出的物体坐标可能有误差，夹爪执行时也可能打滑，物体材质可能和预期不一样。一次性的“生成→执行”没有容错能力，只有闭环反馈，系统才能在失败后调整策略，进而展现出“自主进化”的特征。

3. 环境准备与工具选型

3.1 仿真环境与真实机器人的选择

学习具身智能时，第一步要先决定在仿真环境里跑，还是在真实机器人上跑。

真实机器人的优势是数据真实、物理效果直接。但硬件成本高，调试周期长，还存在很大的安全风险。初学者在没掌握运动规划和感知标定之前，直接上手真机，很容易损坏设备。

仿真环境的优势是便宜、安全、可复现。你可以随时重置场景，批量测试不同任务，还能用仿真数据训练模型。常见仿真器包括：

• PyBullet：轻量、纯 Python API，适合学习机械臂控制和抓取；
• MuJoCo：物理仿真精度高，很多具身智能论文都用它做实验；
• Isaac Sim / Isaac Lab：适合大规模并行仿真和数据生成，但依赖较重；
• Coppeliasim：自带可视化底盘和机械臂模型，适合做完整系统演示。

这里特别提一下 MuJoCo 和 PyBullet。MuJoCo 在机器人运动和接触仿真方面非常出色，许多具身智能论文的机械臂抓取实验都基于它；PyBullet 则因为 API 简单、文档丰富，是入门时的好朋友。你可以先选一个仿真器，把“感知 → 决策 → 执行”链路跑通，再迁移到真实机器人上。迁移过程中注意真实传感器噪声和电机延迟问题，这部分我在第 6 节会展开。

3.2 工具清单与版本注意

为了避免无意义的版本纠纷，本文不强行规定严格版本号，而是给出一个“以常见环境为例”的选型清单。实际搭建时，请根据你的系统环境和依赖兼容性进行调整。

如果你的环境受限，比如公司电脑不允许装仿真器，或者缺乏 GPU，也可以用一个“最小模拟版本”来学习核心链路。本文第 4 节的实战代码，会侧重于“可执行代码决策闭环”的逻辑，通过纯 Python 标准库和少量 NumPy 就能运行，这样你可以先掌握思想，再去替换成真正的仿真器接口。

3.3 示例项目目录结构

我建议把具身智能示例项目拆成几个独立模块，方便后续替换和测试。整体目录如下：

text复制embodied_demo/
├── perception/
│   ├── __init__.py
│   └── scene_parser.py       # 视觉感知 + 物体定位
├── action/
│   ├── __init__.py
│   └── primitives.py         # 动作函数库
├── planner/
│   ├── __init__.py
│   ├── prompt_builder.py     # 生成提示词
│   └── sandbox_executor.py   # 沙箱化执行生成代码
├── main_pipeline.py          # 主流程
├── requirements.txt
└── README.md

模块边界很清晰：perception 负责把视觉信息变成结构化场景描述；action 负责暴露可供模型调用的动作接口；planner 负责和 LLM 交互并对生成代码做安全检查；main_pipeline 串联整个闭环。这样即使以后更换视觉模型或仿真器，也只需要修改对应模块的接口实现，不影响整体架构。

4. 实战：用可执行代码驱动机械臂完成抓取

这一节我们做一个简化但完整的实操案例：让机器人根据自然语言指令，者在仿真环境中抓取一个彩色方块并移动到目标位置。为了让你能直接运行，我会把真实传感和仿真器接口抽象成“模拟数据”，重点演示可执行代码决策链路。

4.1 需求拆解与整体流程

先看需求：

• 用户指令：“把绿色方块放到左侧蓝色区域”
• 机器人有一个简单的吸盘/夹爪，可以在二维平面内移动
• 感知模块输出环境中各个物体的坐标和颜色
• 决策模型输出可执行代码，代码调用动作函数库
• 执行模块运行代码并输出“每一步操作日志”

整体流程是：感知模块从相机/仿真器拿到物体位置列表 → 构造自然语言指令和场景上下文 → 大语言模型生成 Python 代码 → 沙箱执行器运行代码 → 每一步动作打印输出 → 最后检查抓取结果。

这个流程看起来很复杂，但核心就是：模型负责决策“调用哪个动作函数、传入什么参数”，执行层负责把动作函数变成物理行为。我们把这个思路用代码写出来。

4.2 第一步：编写感知模块

首先模拟一个感知模块。为了演示，我直接构造一份场景数据，对应真实系统中“深度相机 + 目标检测模型”的输出。实际项目中，你需要用 OpenCV 读取图像、用目标检测模型识别类别、用深度图计算坐标，这里先不展开。

文件路径：perception/scene_parser.py

python复制# 感知模块简化版本：模拟真实视觉系统输出的结构化场景描述
import json


class Scene:
    def __init__(self, data):
        self.objects = data.get("objects", [])
        self.gripper = data.get("gripper", {})

    def find_by_name(self, name):
        for obj in self.objects:
            if obj["name"] == name:
                return obj
        return None

    def to_prompt_text(self):
        # 把场景信息压缩成模型易读的文本
        lines = ["当前场景中观察到的物体："]
        for obj in self.objects:
            pos = obj["position"]
            lines.append(
                f"- {obj['name']}: 颜色 {obj['color']}, "
                f"坐标 ({pos['x']:.2f}, {pos['y']:.2f}, {pos['z']:.2f})"
            )
        gripper = self.gripper.get("position")
        if gripper:
            lines.append(
                f"机器手当前坐标 ({gripper['x']:.2f}, {gripper['y']:.2f})"
            )
        return "\n".join(lines)


def observe_from_camera():
    # 真实项目中，这里应该做图像检测 + 深度投影
    # 此处用固定数据模拟单次观测结果
    demo_scene = {
        "objects": [
            {
                "name": "green_block",
                "color": "green",
                "position": {"x": 0.40, "y": 0.22, "z": 0.05}
            },
            {
                "name": "red_block",
                "color": "red",
                "position": {"x": 0.21, "y": 0.51, "z": 0.05}
            }
        ],
        "gripper": {
            "position": {"x": 0.60, "y": 0.70}
        }
    }
    return Scene(demo_scene)

这段代码里，Scene 负责保存结构化场景数据，observe_from_camera 模拟了一次感知观测。在真实项目里，你需要用目标检测模型识别物体类别，然后通过深度相机的内参把像素坐标转换到相机坐标系或机械臂基座坐标系。坐标变换是坑非常多的地方，后面会专门说明。

4.3 第二步：沉淀动作函数库

动作函数库是整个系统里最值得花时间设计的部分。模型生成的代码，本质上就是在调用这些函数。函数设计得合理，模型生成代码就越不容易出错；函数设计得太大，模型难以灵活组合；设计得太小，生成代码会很冗长，也更容易超长被截断。

文件路径：action/primitives.py

python复制# 动作函数库：供决策模型调用的底层原子能力
class RobotActionExecutor:
    def __init__(self):
        self.action_log = []
        self.carried_object = None

    def move_to(self, x, y):
        """移动到目标二维坐标"""
        log_msg = f"MOVE_TO ({x:.2f}, {y:.2f})"
        self.action_log.append(log_msg)
        print(log_msg)

    def pick_up(self, object_name):
        """抓取指定物体"""
        log_msg = f"PICK_UP {object_name}"
        self.action_log.append(log_msg)
        print(log_msg)
        self.carried_object = object_name

    def place_at(self, x, y):
        """把当前携带的物体放到目标坐标"""
        log_msg = f"PLACE_AT ({x:.2f}, {y:.2f})"
        self.action_log.append(log_msg)
        print(log_msg)
        if self.carried_object:
            print(f"成功放置 {self.carried_object}")
            self.carried_object = None
        else:
            print("警告：手爪为空，无法放置")

这个函数库只实现了三个动作：移动、抓取、放置。你可能会问，为什么真实机械臂还需要逆运动学、轨迹规划，这里怎么只有 move_to？答案是：move_to 在高层代码里是“移动到目标坐标”，而真正执行时，这个函数内部会调用运动规划器计算路径，再调用底层控制器把每个关节转过去。在简化示例中，我们只关注高层控制逻辑。

实际具身智能项目里，动作函数库的设计要考虑以下几点：

• 每个函数尽量对世界产生“可验证”的影响，比如 pick_up 之后可以检查 self.carried_object 是否非空；
• 函数参数类型要简单、明确，坐标优先用浮点数，物体名称用字符串；
• 函数内部要做超限保护，比如坐标超出机械臂工作空间时要拒绝执行并返回错误；
• 函数尽量幂等，避免同一个动作执行两次造成破坏。

4.4 第三步：让模型生成可执行代码

接下来是决策模块。我们要构建一段提示词，把用户指令、场景文本、函数签名一起发给大模型，让模型输出一段 Python 代码。

文件路径：planner/prompt_builder.py

python复制import json

SYSTEM_PROMPT = """你是一个具身智能机器人控制器。\
根据用户指令和场景信息，输出一段可执行的 Python 代码，\
控制机器人完成操作。

你可以使用的函数如下：
- move_to(x: float, y: float): 移动到目标位置
- pick_up(object_name: str): 抓取指定物体
- place_at(x: float, y: float): 把携带物体放到目标位置

要求：
1. 只调用上面给出的函数。
2. 代码中禁止使用 import、open、exec、eval 等危险操作。
3. 坐标必须从场景信息中读取，不要猜测。
4. 输出格式为 ```python 代码块```，不要输出多余解释。
"""


def build_user_prompt(instruction, scene_text):
    return (
        f"用户指令：{instruction}\n\n"
        f"场景信息：\n{scene_text}\n\n"
        "请输出控制代码："
    )


def extract_python_code(raw_response):
    """从模型输出中提取纯 Python 代码"""
    if "```python" in raw_response:
        start = raw_response.index("```python") + len("```python")
        end = raw_response.index("```", start)
        return raw_response[start:end].strip()
    # 如果没有代码块，就假设整个输出就是代码
    return raw_response.strip()

这里的核心是把函数签名和规则明确告诉模型，并要求模型只调用白名单内的函数。实际调用大模型时，不同模型对提示词格式的敏感度不同，你可能需要根据模型能力调整提示词。关键原则就一条：让模型做选择题，而不是开放创作题。模型组合函数库里的函数，比让它凭空设计行为要安全得多。

下面模拟一次模型输出。假设模型接收到“把绿色方块放到左侧蓝色区域”的指令后，生成如下代码：

python复制move_to(0.40, 0.22)
pick_up("green_block")
move_to(0.10, 0.60)
place_at(0.10, 0.60)

注意，pick_up 是不带坐标的，它通过物体名称从场景中查找位置；而 move_to 直接传坐标。这种分工有利于减少模型输出参数的负担。

4.5 第四步：沙箱化执行

生成代码直接 exec 是很危险的。模型可能被引导生成恶意代码或错误代码，所以执行前必须做沙箱化处理。

文件路径：planner/sandbox_executor.py

python复制import ast
from action.primitives import RobotActionExecutor


class SandboxExecutor:
    def __init__(self):
        self.allowed_names = {
            "move_to", "pick_up", "place_at", "True", "False", "None"
        }

    def check_code(self, code):
        """静态检查：只允许调用白名单函数"""
        tree = ast.parse(code)
        for node in ast.walk(tree):
            if isinstance(node, ast.Call):
                func = node.func
                if isinstance(func, ast.Name):
                    if func.id not in self.allowed_names:
                        raise ValueError(f"禁止调用函数: {func.id}")
                else:
                    raise ValueError("不支持复杂函数调用表达式")
            if isinstance(node, ast.Import):
                raise ValueError("禁止使用 import")
            if isinstance(node, ast.Attribute):
                raise ValueError("禁止访问对象属性")
        return code

    def execute(self, code, executor):
        self.check_code(code)
        # 只向 exec 暴露白名单函数
        safe_globals = {
            "move_to": executor.move_to,
            "pick_up": executor.pick_up,
            "place_at": executor.place_at,
        }
        exec(code, safe_globals)

这里做了几层防护：

• ast.parse 解析代码，只允许白名单里的函数名；
• 禁止 import 和属性访问，避免 __builtins__ 逃逸；
• exec 时传入的 safe_globals 里只包含三个动作函数。

你要注意，这个沙箱仅供学习参考。Python 的 exec 沙箱化在安全等级上并不高，生产环境里更稳妥的方案是单独放到容器或子进程中执行，并通过系统级权限控制来兜底。模型代码生成永远存在不可控风险，必须在行动前有“人机审核”或“动作置信度门槛”。

4.6 第五步：主流程串联与运行结果

把上面的模块串起来，写一个主流程。

文件路径：main_pipeline.py

python复制from perception.scene_parser import observe_from_camera
from action.primitives import RobotActionExecutor
from planner.prompt_builder import (
    SYSTEM_PROMPT, build_user_prompt, extract_python_code
)
from planner.sandbox_executor import SandboxExecutor


def main(instruction):
    # 1. 感知
    scene = observe_from_camera()
    scene_text = scene.to_prompt_text()

    # 2. 决策（这里用预置代码模拟模型输出）
    # 真实项目请调用大模型接口，把 SYSTEM_PROMPT + build_user_prompt
    # 传给模型，再使用 extract_python_code 提取代码。
    generated_code = (
        "move_to(0.40, 0.22)\n"
        "pick_up('green_block')\n"
        "move_to(0.10, 0.60)\n"
        "place_at(0.10, 0.60)\n"
    )

    print("场景信息：")
    print(scene_text)
    print("\n模型生成的可执行代码：")
    print(generated_code)

    # 3. 沙箱执行
    executor = RobotActionExecutor()
    sandbox = SandboxExecutor()
    print("\n执行日志：")
    sandbox.execute(generated_code, executor)

    # 4. 检查最终状态
    print("\n最终状态：")
    if executor.carried_object is None:
        print("抓取-放置流程完成，机械手为空。")
    else:
        print(f"警告：机械手仍携带 {executor.carried_object}")


if __name__ == "__main__":
    main("把绿色方块放到左侧蓝色区域")

运行结果大致如下：

text复制场景信息：
当前场景中观察到的物体：
- green_block: 颜色 green, 坐标 (0.40, 0.22, 0.05)
- red_block: 颜色 red, 坐标 (0.21, 0.51, 0.05)
机器手当前坐标 (0.60, 0.70)

模型生成的可执行代码：
move_to(0.40, 0.22)
pick_up('green_block')
move_to(0.10, 0.60)
place_at(0.10, 0.60)

执行日志：
MOVE_TO (0.40, 0.22)
PICK_UP green_block
MOVE_TO (0.10, 0.60)
PLACE_AT (0.10, 0.60)
成功放置 green_block

最终状态：
抓取-放置流程完成，机械手为空。

到这里，一个最小闭环就工作起来了。你可以看到，决策逻辑完全以“可执行代码”的形式存在，感知结果和动作函数库之间通过代码粘合。真实系统里，你只需要把 observe_from_camera 换成仿真器观察接口，把 RobotActionExecutor 里的函数实现替换为机械臂控制 API，整个链路依然是成立的。

5. 常见问题与排查思路

在跑具身智能项目时，下面这些问题出现频率非常高，这里整理成一个排查清单。

这些问题的共性是：具身智能项目里，错误往往不是单纯出在某一个模型或某一个函数，而是出在模块衔接处。排查时不要只盯着一端，要一层一层验证感知数据是否准确、决策代码是否符合规则、执行层是否真正完成了运动，最后再检查反馈机制有没有把失败信息传回决策模块。

6. 最佳实践与工程建议

6.1 安全边界：机器人操作不是文件读写

写普通后端代码时，遇到 Bug，最多是服务报错，改完重新部署。但机器人控制代码一旦出错，轻则夹爪撞坏工件，重则危及现场人员安全。因此在具身智能项目中，“安全”必须作为系统架构的一部分来设计，而不是事后补救。

建议在所有动作函数内部都加上边界检查。比如机械臂的每个关节都有角度限制，运动速度有上限，夹爪的力矩不能超过某个阈值。底层函数必须拒绝执行超出安全范围的指令，而不是盲目执行高层生成的动作。同时，真实机器人的运行环境应该设置物理急停开关，并始终保证工程师可以随时接管控制权。

6.2 沙箱与可控执行

大模型生成代码的能力越强，Code 沙箱就越重要。在真实项目中，我建议使用比“白名单 exec”更严格的方式：

• 把生成代码放到独立的 Python 子进程或容器里执行，只在子进程里暴露极小权限；
• 禁用网络、文件写入系统目录等高风险能力；
• 对生成代码做静态扫描，除了函数白名单，还要检查循环次数、递归深度，防止死循环消耗算力；
• 保留执行前后的状态快照，一旦发生异常，可以回滚机械臂到安全位置；
• 在执行关键动作前，加入人工确认闸口，尤其是第一次在真机运行某个新策略时。

即使是全自动系统，也要有“置信度阈值”的概念。模型生成的代码在历史上成功率较低时，系统应该主动降级为请求人工干预，而不是继续执行。

6.3 从仿真到真机：域随机化与延迟补偿

仿真和真机之间存在一条巨大的“现实鸿沟”。即使仿真器在物理上已经做得很接近真实，也永远无法完全复现真实世界的摩擦力、电机延迟、相机曝光差异。

常见的解决办法是域随机化（Domain Randomization）：在仿真训练阶段，随机化物体的位置、颜色、光照、摩擦系数、机械臂末端负载等参数，让策略见过足够多样的环境，从而在真实世界里表现出一定的泛化能力。另一个关键点是延迟补偿。真机系统中，从相机采集图像到执行动作之间存在几十毫秒甚至更高的延迟，感知结果在到达执行层时已经“过期”。你可以通过卡尔曼滤波对物体运动轨迹做预测，或者在控制循环中定期刷新目标位姿，减少延迟带来的位置误差。

6.4 日志回放与评估指标

具身智能程序会涉及非常长的运行链：自然语言指令、感知帧、模型生成的代码、沙箱执行日志、底层运动轨迹、每一步的反馈结果。调试时，如果这几个环节的信息不能对得上，问题定位会非常痛苦。

我建议在项目一开始就设计统一的任务日志格式。每轮尝试都用同一个任务 ID 关联所有日志，记录：

• 用户原始指令；
• 感知模块输出的场景 JSON；
• 大模型返回的原始输出和提取后的代码；
• 沙箱执行时每步动作的入参与返回值；
• 抓取结果的视觉反馈结论；
• 失败时系统自动生成的错误描述。

评估指标也不要只看“任务是否完成”。建议记录：

• 任务成功率：连续运行 N 次任务的成功比例；
• 平均完成时间：包含感知、决策、执行全过程；
• 平均重试次数：一个任务失败多少次后才成功；
• 安全事件次数：发生碰撞、越界、急停的次数；
• 代码生成合法率：模型生成代码通过沙箱静态检查的比例。

只有把指标拆细，你才知道系统到底是卡在“模型决策不对”还是“动作执行断链”。这比笼统的“成功率 80%”更有指导意义。

7. 总结与具身智能学习路线

7.1 本文核心要点回顾

这篇文章围绕“可执行代码 + 具身智能机械臂”展开，核心结论可以概括成三点：

• 具身智能是一个感知-决策-执行-反馈的物理闭环，不是单纯的语言模型或视觉模型；
• 大模型在具身智能中更适合做“代码生成器”，利用函数库组合出任务策略，而不是直接输出运动参数；
• 工程落地时必须重视函数库设计、代码沙箱、安全边界、日志回放和仿真验证，否则再强的模型也无法安全地运行在真实机器人上。

通过第 4 节的实战案例，你应该已经看到，一套具身智能系统的最小闭环并不复杂：感知模块输出场景描述，模型生成可执行代码，沙箱执行器调用动作函数，最终用状态检查判断任务是否完成。这套思想可以扩展到更复杂的三维机械臂控制，只要你把感知换成真实验测、把动作函数换成真实控制接口即可。

7.2 具身智能学习路线建议

如果你刚从零开始接触具身智能，我建议按下面这个路线推进，不用急着直接去看复杂模型。

第一步，补数学和编程基础。线性代数中的坐标变换、矩阵旋转，是理解机械臂运动学的前提；Python 和 NumPy 是你操作数据和调用仿真器的基础。

第二步，学习和操作仿真器。先跑通 PyBullet 或 MuJoCo 自带的机械臂样例，理解运动学、碰撞检测、关节控制的基本概念。你不需要在一周内成为仿真器专家，但必须有能力写出“控制机械臂去抓取仿真中一个固定位置物体”的程序。

第三步，搭建感知链路。从 RGB 图像中检测目标物体，计算中心点像素坐标，再通过深度相机和相机参数得到物体的三维坐标。这一步会帮助你理解坐标系转换，也是很多开发者最容易卡住的地方。

第四步，接大语言模型。用提示词让模型根据场景文本生成可执行代码，加上本文学到的沙箱执行和状态检查，把决策闭环搭起来。建议先用简单的二维平面任务，等完全理解后再扩展三维机械臂。

第五步，关注社区和开源项目。具身智能学习资料很多，算法更新也快，建议你多关注具身智能相关的开源社区，比如 xbotics 具身智能开源社区，这类社区通常会提供从机械臂模型、仿真教程到任务环境的一整套学习资源，比自己从头造轮子快得多。

7.3 开源社区、仿真环境与下一步实践

最后说一点实操层面的建议。我认为在具身智能方向，动手跑通一个小项目，比读十篇论文对新人的帮助更大。可以先给自己定一个具体的小目标：在仿真环境中完成“抓起随机位置的方块，放到指定区域”的任务。过程中记录问题清单：相机标定怎么做的、运动规划怎么调的、模型代码生成偶发了哪些幻觉、失败重试逻辑是怎么写的。

等这个小目标跑通后，再逐步增加难度：换更复杂的物体形状，增加障碍物，引入多步任务指令，甚至尝试让同一个系统完成“先整理桌面，再归还指定物品”这样的组合式任务。每一次扩展，都会迫使你重新审视感知、决策、执行、反馈四个模块的边界。这种“由小到大、不断加约束”的迭代方法，也符合“让机器人自主进化”的内核，因为真正让能力涌现的，并不是某一个超级模型，而是智能体在不断试错中形成的闭环反馈机制。

如果你现在手边没有实体机械臂，不需要犹豫，直接从仿真环境开始。上面的代码可以直接复制运行，改造成 PyBullet 或 MuJoCo 仿真器接入，也只是替换接口的问题。希望这篇文章能让你少走一些弯路，尽快跑通自己的第一条具身智能闭环链路。