1. 从"写代码"到"动手做"：EmbodiedSWE到底在解决什么难题

大多数人对编程智能体的印象还停留在"给个需求，它吐出一段代码"的阶段。你让它写个排序算法、搭个REST接口、修个空指针异常，它干得挺漂亮。但如果你把场景换一下——让一个带机械臂的机器人去完成"把散落在桌上的零件按颜色分拣到对应料盒，过程中如果遇到卡料要自己调整抓取角度"这种任务，传统编程智能体就彻底歇菜了。

原因不复杂。传统智能体的输出空间是文本符号，它生成的代码在虚拟环境里执行，错了大不了重跑。而具身智能体（Embodied Agent）的输出空间是物理动作，每一个关节角度、每一次夹爪开合都直接作用于真实世界，错了可能撞坏设备、损坏工件，甚至造成安全事故。更麻烦的是，物理世界有摩擦、有形变、有传感器噪声，同一个动作在不同时刻执行结果可能不一样。这就引出了EmbodiedSWE这个方向的核心命题：如何让编程智能体具备在物理世界中长时程执行灵巧操作的能力。

"长时程"三个字是关键词。短时程任务比如"抓取一个方块放到指定位置"，用传统的运动规划或者简单的模仿学习就能搞定。但长时程任务意味着任务链条长、中间状态多、失败恢复复杂。举个例子，一个完整的装配任务可能包含：识别零件位姿→规划抓取路径→执行抓取→检测抓取是否成功→移动到装配点→调整姿态→插入→检测插入深度→如果卡住则微调角度重试→拧紧→检测扭矩→记录结果。这中间任何一步出问题，后续步骤全部受影响。而且长时程任务往往需要多模态感知（视觉、力觉、触觉）和在线决策（根据实时反馈调整策略），这对智能体的架构设计提出了远高于纯软件编程的要求。

EmbodiedSWE的定位，就是在这个背景下，把"编程"这个动作从写代码扩展到生成可执行的物理操作策略。它不是一个单纯的机器人控制库，也不是一个纯粹的代码生成模型，而是一个面向具身任务的编程框架——智能体需要理解任务语义、分解任务步骤、生成每一步的控制代码、在仿真或真实环境中执行、根据执行结果反思并修正策略。这个循环跑通了，才叫真正的EmbodiedSWE。

适合读这篇内容的人：做机器人算法工程的、搞具身智能研究的、想从纯软件AI转向具身方向的开发者，以及那些手里有机械臂但苦于任务泛化能力太差的团队。如果你只是想让机械臂重复执行固定轨迹，那传统的示教编程就够了，EmbodiedSWE这套东西对你来说属于杀鸡用牛刀。但如果你面对的是多品种、小批量、任务经常变的场景，那这套思路就值得仔细琢磨了。

2. 拆解EmbodiedSWE的架构骨架：它凭什么能跑长时程任务

2.1 任务分解层：把"人话"翻译成可执行的子目标序列

EmbodiedSWE的第一道关卡是任务理解。用户给的输入往往是一句自然语言，比如"把工作台上所有红色齿轮装到减速箱的对应轴上，装完检查每个齿轮能否手动转动"。这句话对人来说很直观，但对机器来说，它需要被拆解成一系列可验证的子目标。

我见过不少团队在这一步偷懒，直接用一个LLM把任务拆成步骤列表就完事了。结果到了执行阶段发现，拆出来的步骤要么粒度太粗（"装配齿轮"这种步骤根本没法直接执行），要么缺少成功判据（怎么算"装好了"？扭矩达到多少？位置误差小于多少？）。EmbodiedSWE在这块的做法是引入结构化任务表示，每个子目标必须包含四个要素：操作对象、目标状态、约束条件、失败恢复策略。

举个例子，"抓取红色齿轮"这个子目标，结构化之后是这样的：

• 操作对象：工作台上位姿为(x, y, z, rx, ry, rz)的红色齿轮
• 目标状态：齿轮被夹爪稳定夹持，夹持力在2N到5N之间
• 约束条件：抓取过程中夹爪不能与周围零件碰撞，接近方向需避开障碍
• 失败恢复：如果抓取后力觉传感器读数低于2N，判定为滑脱，重新执行抓取，最多重试3次

这种结构化表示的好处是，它把"做什么"和"怎么判断做成了"绑定在一起，后续的执行层和反思层都有明确的依据。没有这个结构，长时程任务跑到一半你都不知道当前是在正常执行还是已经跑偏了。

2.2 代码生成层：为什么不是直接输出动作，而是输出代码

这是EmbodiedSWE和端到端模仿学习最大的区别。端到端方法直接学一个从感知到动作的映射网络，输入图像输出关节角度。这种方式在短时程、单一任务上表现不错，但一旦任务变长、环境变复杂，泛化能力就急剧下降。因为神经网络学到的是一种隐式的、纠缠的表示，你很难在里面插入先验知识，也很难调试。

EmbodiedSWE选择让智能体生成可执行的代码，比如Python函数调用机器人API。这样做有几个实实在在的好处。第一，代码是可读的，工程师能看懂智能体打算怎么干，出了问题能定位。第二，代码是可组合的，抓取函数、移动函数、检测函数可以像搭积木一样拼装，新任务只需要重新组合已有技能。第三，代码可以嵌入经典控制算法，比如在接近阶段用阻抗控制，在插入阶段用力位混合控制，这些算法经过几十年验证，比神经网络瞎试靠谱得多。

当然，代码生成也有代价。它要求智能体对机器人API有准确的理解，生成的代码语法要正确，参数要合理。EmbodiedSWE在这块的策略是分层生成：高层生成任务级的伪代码，低层把伪代码翻译成具体的API调用。中间加一层参数校验，比如检查生成的目标位姿是否在工作空间内、速度参数是否超过安全阈值。这层校验看起来不起眼，但实际跑起来能挡掉大量低级错误。

2.3 执行与监控层：长时程任务的"仪表盘"

长时程任务最怕的是什么？是静默失败。机器人以为自己抓到了零件，实际上夹爪是空的，然后它带着空夹爪继续往下走，走到装配点发现装不进去，又不知道问题出在哪。EmbodiedSWE在执行层设计了多层级监控机制。

底层是实时安全监控，跑在控制频率上（通常500Hz到1kHz），检查关节力矩是否超限、是否接近奇异位形、是否进入禁飞区。这一层不依赖智能体决策，是硬性的安全兜底。

中层是技能级监控，每个技能执行完后检查成功判据。比如抓取技能执行后，读力觉传感器和视觉检测结果，判断是否真的抓到了。这一层是智能体反思的主要依据。

上层是任务级监控，跟踪整个任务链条的进度，检测是否出现循环重试、是否偏离预期时间太多。如果发现某个子任务反复失败，任务级监控会触发策略切换，比如从"直接抓取"切换到"先调整零件位姿再抓取"。

这三层监控的数据会汇总到一个执行日志里，包含时间戳、状态、传感器读数、决策依据。这个日志是后续反思和优化的金矿。我自己的经验是，长时程任务调试时，80%的时间花在看日志上，而不是改代码。日志设计得好，问题定位快十倍。

2.4 反思与修正层：让失败变成下一次成功的养料

EmbodiedSWE的反思层不是简单的"失败了就重试"。它要回答三个问题：为什么失败、怎么改、改了之后怎么验证。

为什么失败：根据执行日志和监控数据，判断失败类型。是感知错误（零件位姿估计偏了）、规划错误（路径撞了）、控制错误（力控参数不对）、还是任务分解错误（子目标顺序不合理）。不同类型的失败，修正策略完全不同。

怎么改：如果是感知错误，可能需要切换检测算法或增加多视角确认；如果是控制错误，可能需要调整阻抗参数或降低接近速度；如果是任务分解错误，可能需要重新生成子目标序列。EmbodiedSWE在这块通常会维护一个失败模式库，记录历史失败案例和对应的修正措施，新问题先匹配库里的模式，匹配不上再让LLM生成新方案。

改了之后怎么验证：修正后的策略不能直接上真机，先在仿真里跑一批测试用例，通过率达标了再部署。这个仿真验证环节是EmbodiedSWE区别于纯LLM编程的关键。物理世界的试错成本太高，仿真里跑一千次和真机上跑一次，代价差了几个数量级。

3. 实操落地：从零搭建一个EmbodiedSWE原型系统

3.1 环境准备：仿真平台和机器人接口的选择

如果你要自己搭一套EmbodiedSWE的原型，第一步是选仿真平台。目前主流的选择有PyBullet、MuJoCo、Isaac Sim这几个。PyBullet轻量、开源、Python接口友好，适合快速验证算法逻辑，但物理精度一般，接触力模拟比较粗糙。MuJoCo物理精度高，适合做力控和接触密集型任务，但渲染效果一般，视觉感知的仿真逼真度不够。Isaac Sim渲染和物理都强，但吃显卡、上手门槛高。

我的建议是分阶段选型：算法逻辑验证阶段用PyBullet，快速迭代；力控和接触策略验证阶段切MuJoCo；如果需要大规模视觉感知训练，再上Isaac Sim。不要一上来就追求"全都要"，环境配置的时间成本会把你拖垮。

机器人接口方面，EmbodiedSWE需要一套统一的技能API。不管你底层用的是UR、Franka还是自定义的机械臂，上层智能体看到的应该是一组标准化的函数，比如move_to_pose()、grasp()、insert()、detect_object()。这层抽象很关键，它让智能体生成的代码不依赖具体硬件，换机器人只需要重新实现底层驱动，上层策略不用动。

# 技能API的抽象接口示例 class RobotSkillAPI: def move_to_pose(self, pose, velocity=0.1, acceleration=0.1): """移动到指定位姿，pose为[x,y,z,rx,ry,rz]""" pass def grasp(self, force=3.0, width=0.05): """执行抓取，force为期望夹持力(N)，width为夹爪开口(m)""" pass def insert(self, target_pose, force_threshold=10.0, max_depth=0.02): """执行插入，force_threshold为最大允许接触力""" pass def detect_object(self, color=None, shape=None): """检测指定属性的物体，返回位姿列表""" pass

这套接口设计有个细节要注意：每个函数的参数都要有安全默认值。智能体生成的代码可能漏传参数，或者传了不合理的值。默认值要保证即使参数缺失，机器人也不会做出危险动作。比如move_to_pose的默认速度设成0.1m/s，而不是最大速度，这样即使智能体忘了限速，也不会撞得太狠。

3.2 任务描述的结构化模板

前面说了任务分解层需要结构化表示，具体怎么落地？我建议定义一个任务描述模板，用YAML或JSON格式，让智能体按模板填充。这样做的好处是格式统一，后续的解析和校验都好做。

task: name: "齿轮装配" description: "将工作台上所有红色齿轮装配到减速箱对应轴上" objects: - id: "gear_red_1" type: "gear" color: "red" target_position: "shaft_1" - id: "gear_red_2" type: "gear" color: "red" target_position: "shaft_2" subtasks: - name: "定位齿轮" skill: "detect_object" params: {color: "red", shape: "gear"} success_criteria: "检测到至少2个红色齿轮" - name: "抓取齿轮" skill: "grasp" params: {force: 3.0} success_criteria: "力觉读数在2N-5N之间" failure_recovery: "重试3次，每次调整抓取角度5度" - name: "装配齿轮" skill: "insert" params: {force_threshold: 10.0} success_criteria: "插入深度达到15mm，接触力低于10N" failure_recovery: "如果卡住，旋转齿轮±10度重试" post_conditions: - "所有齿轮装配到位" - "手动转动齿轮无卡涩"

这个模板的关键在于success_criteria和failure_recovery必须成对出现。没有成功判据，你不知道什么时候算做完；没有失败恢复，遇到问题就卡死。很多团队做具身任务时只写前者不写后者，结果机器人一遇到异常就停在那里等人来救，完全谈不上自主。

3.3 代码生成提示词的设计要点

EmbodiedSWE的代码生成质量，很大程度上取决于提示词设计。我试过几种不同的提示词结构，最后稳定下来的方案是四段式：角色设定、API文档、任务描述、输出格式约束。

角色设定要明确告诉模型它是什么："你是一个机器人编程助手，负责将装配任务分解为可执行的Python代码，调用提供的RobotSkillAPI。"这句话看似废话，但能显著减少模型生成无关内容。

API文档要完整且精确，包括函数签名、参数含义、返回值格式、异常情况。我习惯把API文档写成docstring的形式，模型对这种格式的理解最准确。

任务描述就是前面结构化好的YAML，直接贴进去。

输出格式约束要明确要求生成可执行的Python函数，并且包含异常处理。比如要求"每个技能调用必须包裹在try-except中，捕获异常后记录日志并返回失败状态"。

# 期望模型生成的代码结构 def execute_gear_assembly(api): results = [] try: # 子任务1：定位齿轮 gears = api.detect_object(color="red", shape="gear") if len(gears) < 2: return {"status": "failed", "reason": "未检测到足够的红色齿轮"} for gear in gears: # 子任务2：抓取齿轮 grasp_success = False for attempt in range(3): try: api.grasp(force=3.0) force_reading = api.get_grasp_force() if 2.0 <= force_reading <= 5.0: grasp_success = True break else: api.rotate_gripper(5.0) # 调整角度重试 except Exception as e: log_error(f"抓取失败: {e}") if not grasp_success: results.append({"gear": gear.id, "status": "grasp_failed"}) continue # 子任务3：装配齿轮 try: api.insert(target_pose=gear.target_position, force_threshold=10.0) results.append({"gear": gear.id, "status": "success"}) except InsertionError: # 卡住时旋转重试 api.rotate_gripper(10.0) api.insert(target_pose=gear.target_position, force_threshold=10.0) results.append({"gear": gear.id, "status": "retry_success"}) except Exception as e: return {"status": "error", "reason": str(e)} return {"status": "completed", "results": results}

这段代码不是让模型一次生成的，而是分步生成+人工校验。先让模型生成骨架，再逐个填充子任务，每填一个跑一次语法检查和仿真测试。一次性生成完整代码，出错概率太高，调试成本反而更大。

3.4 仿真环境中的闭环测试流程

代码生成完了，不能直接上真机。仿真环境里的闭环测试分三步走。

第一步是单元测试，每个技能函数单独测。比如grasp()函数，在仿真里放一个已知位姿的零件，调用抓取，检查力觉读数是否在预期范围。这一步能发现参数错误和API误用。

第二步是集成测试，把子任务串起来跑。这时候重点看状态传递是否正确，比如抓取后的零件位姿是否准确传递给了插入函数。集成测试最容易暴露的问题是坐标系不一致，抓取时用的是相机坐标系，插入时用的是机器人基坐标系，中间没转换，结果位置全错。

第三步是扰动测试，在仿真里加入随机扰动，比如零件位姿加噪声、抓取时施加侧向力、插入时孔位有偏差。看智能体生成的代码能否通过失败恢复机制处理这些扰动。这一步是检验长时程鲁棒性的关键。我通常会在仿真里跑100次扰动测试，统计成功率。成功率低于80%的策略，不上真机。

注意：仿真测试通过不代表真机就能跑通。仿真里的接触模型、摩擦系数、传感器噪声和真实世界有差距。真机部署时，建议先用低速、低力运行，确认基本流程没问题后再逐步提速。

4. 踩过的坑与实战经验：那些文档里不会写的东西

4.1 坐标系混乱：具身任务的第一大杀手

我敢说，做具身智能的团队，没有一个没被坐标系坑过。相机坐标系、机器人基坐标系、工具坐标系、工件坐标系，四个坐标系之间的变换关系，错一个就全盘皆输。更麻烦的是，有些变换是动态的，比如工具坐标系随夹爪开合变化，工件坐标系随零件移动变化。

EmbodiedSWE的代码生成层如果不处理坐标系，生成的代码就是一堆废纸。我的做法是在API层强制统一坐标系。所有detect_object()返回的位姿，统一转换到机器人基坐标系。所有move_to_pose()接受的位姿，也统一要求是基坐标系。转换工作在API内部完成，智能体不需要关心。

但这里有个坑：转换矩阵的标定误差。手眼标定做得不好，转换后的位姿偏差可能达到几毫米甚至几厘米。对于精密装配任务，这个偏差是致命的。我的经验是，手眼标定后一定要做验证：让机器人移动到几个已知点，用相机检测实际位置，对比偏差。偏差超过0.5mm就重新标定，别凑合。

4.2 力控参数：调到你怀疑人生

长时程任务里，力控参数是最难调的部分。阻抗控制的刚度、阻尼、惯性参数，抓取力的上限、下限，插入时的力阈值，这些参数相互耦合，改一个影响一片。

我踩过的最大的坑是抓取力设得太大。当时想着"抓得牢一点总没错"，把夹持力设到了10N。结果抓金属零件没问题，抓塑料零件直接夹变形了。更隐蔽的问题是，大力抓取会导致零件在夹爪里发生微小位移，这个位移在抓取时看不出来，但到了装配环节，累积误差导致插不进去。

后来我把抓取力改成自适应的：先以2N的力闭合夹爪，检测接触后逐步增加到刚好不打滑的力。这个"刚好不打滑"的力通过一个小实验确定：抓住零件后，让机器人以0.01m/s的速度做微小圆周运动，同时监测零件是否相对夹爪滑动。滑动就加力，不滑动就保持。这样确定的抓取力，既不会夹坏零件，也不会滑脱。

插入力的阈值设定也有讲究。设得太低，稍微碰到就报错停止，任务效率极低；设得太高，零件已经卡死了还在硬怼，可能损坏设备。我的经验值是：插入力阈值设为零件重量的5到10倍。比如一个50g的齿轮，插入力阈值设2.5N到5N之间。这个范围既能检测到真正的卡死，又不会因为正常接触力波动而误报。

4.3 失败恢复的逻辑陷阱：无限重试和错误恢复

失败恢复机制设计不好，会引入新的问题。最常见的是无限重试：抓取失败→重试→又失败→再重试，循环到天荒地老。EmbodiedSWE的反思层必须设置重试上限和策略切换条件。同一个策略重试3次还失败，就必须换策略，不能死磕。

另一个陷阱是错误恢复。比如插入失败后，智能体决定"旋转零件10度再试"。但如果失败原因是孔位偏了，旋转零件根本没用，应该调整位置而不是角度。错误恢复的根源是失败原因判断错误。EmbodiedSWE在这块需要结合力觉和视觉数据做多模态失败诊断：力觉曲线显示接触力突然增大然后恒定，通常是位置偏差；力觉曲线显示周期性波动，通常是角度偏差；视觉显示零件根本没对准孔，那是感知或规划问题。

我自己的做法是维护一个失败诊断决策树，把常见的失败模式和对应的诊断依据、修正措施整理成规则。新问题先过决策树，匹配不上再让LLM分析。决策树覆盖不了的case，记录下来，定期更新树。这样跑一段时间后，大部分常见失败都能自动处理。

4.4 长时程任务的"状态漂移"问题

长时程任务跑久了，会出现一种隐蔽的失败：状态漂移。每一步的误差都很小，但累积起来，跑到后面就偏得离谱。比如抓取时零件在夹爪里偏了0.1mm，装配时又偏了0.1mm，到了第十个零件，偏差可能就到了1mm，直接导致装配失败。

对抗状态漂移，我的经验是定期重定位。每完成3到5个子任务，就让机器人回到一个已知的参考位置，用视觉重新检测关键物体的位姿，校正内部状态估计。这个操作会增加任务时间，但能显著提升长时程成功率。另一个技巧是在线标定：利用任务中的自然接触点（比如零件放到料盒底部时），检测实际位置和预期位置的偏差，实时更新坐标系变换。

提示：状态漂移在仿真里往往不明显，因为仿真没有传感器漂移和机械间隙。真机部署时，一定要留出重定位的时间预算，别把任务节拍卡得太死。

5. 从原型到生产：EmbodiedSWE的工程化考量

5.1 技能库的版本管理与回归测试

EmbodiedSWE跑起来之后，技能库会不断增长。今天加一个"拧螺丝"技能，明天加一个"插线缆"技能。技能多了之后，版本管理就成了问题。新加的技能可能和旧技能冲突，修改一个技能的参数可能影响其他任务的执行。

我的做法是给技能库上语义化版本，每个技能有独立的版本号。任务描述里指定依赖的技能版本，比如grasp@2.1.0。技能升级时，跑一遍回归测试集，确保已有任务的仿真通过率不下降。回归测试集不需要很大，覆盖典型任务场景就行，但必须每次升级都跑。

# 技能依赖声明示例 skills: - name: "grasp" version: "2.1.0" params: force_range: [2.0, 5.0] approach_speed: 0.05 - name: "insert" version: "1.3.2" params: force_threshold: 10.0 max_retries: 3

5.2 真机部署的安全边界设置

仿真里跑得再好，真机上也可能出意外。EmbodiedSWE的真机部署必须设置多层安全边界。

第一层是硬件急停，物理按钮，任何人发现异常都能立即切断动力。这一层不依赖软件，是最可靠的兜底。

第二层是软件安全监控，独立于智能体决策循环，以固定频率检查关节力矩、速度、位置是否在安全范围内。超限立即触发软急停。

第三层是任务级安全约束，在任务描述里显式声明禁止区域和禁止动作。比如"夹爪不得进入料盒上方5cm以内的区域"、"插入力不得超过15N"。智能体生成的代码必须通过安全约束校验才能执行。

这三层安全边界，缺一不可。我见过只靠软件监控的团队，软件一卡死，机器人就失控了。也见过只靠硬件急停的，操作员反应不过来，还是撞了。多层防护，每层独立工作，才能把风险降到最低。

5.3 数据回流与持续优化

EmbodiedSWE系统跑起来后，会产生大量执行数据：成功案例、失败案例、传感器读数、决策日志。这些数据是持续优化的燃料。

我的做法是建一个数据回流管道：每次任务执行完，自动把日志上传到数据中心，按成功/失败分类存储。每周跑一次分析，统计失败模式分布，找出高频失败原因。针对高频失败，要么优化技能参数，要么补充失败恢复策略，要么调整任务分解逻辑。

这个闭环跑起来后，系统的成功率会逐步提升。我自己的项目里，第一个月成功率从60%提升到了85%，第三个月稳定在92%以上。提升主要来自失败恢复策略的完善，而不是底层控制算法的改进。这说明长时程任务的瓶颈往往在异常处理，而不在正常流程。

5.4 多任务泛化的现实预期

最后说一个容易被过度宣传的点：多任务泛化。很多Demo展示一个模型搞定几十种任务，看起来很厉害。但实际部署时你会发现，这些任务往往在同一个仿真环境、同一套物体、同一种机器人上采集的。换一个环境、换一批物体、换一个机器人，性能就大幅下降。

EmbodiedSWE的泛化能力，目前阶段还是有限泛化：在相似任务之间迁移效果不错，比如从"装配红色齿轮"迁移到"装配蓝色齿轮"；在差异较大的任务之间迁移，比如从"齿轮装配"迁移到"线缆插接"，还是需要重新采集数据、重新调参。

我的建议是不要追求通用具身智能体，而是针对你的具体场景，构建领域专用的EmbodiedSWE。把场景内的任务做深做透，成功率做到95%以上，比做一个什么都能干但什么都干不精的通用系统有价值得多。工程落地看的是稳定性和可靠性，不是Demo的炫酷程度。

注意：领域专用不代表封闭。技能库的设计要留好扩展接口，新任务可以通过组合已有技能快速实现。这样既保证了当前场景的稳定性，又为未来扩展留了空间。

6. 一个完整的调试案例：齿轮装配任务从失败到稳定

6.1 初始版本的问题表现

前面讲的都是方法论，这里用一个实际调试案例把流程串起来。任务背景是"将工作台上散落的红色齿轮装配到减速箱的对应轴上"，初始版本的EmbodiedSWE系统在仿真里跑100次，成功率只有45%。失败模式主要有三种：抓取滑脱（占失败案例的60%）、插入卡死（占30%）、检测不到齿轮（占10%）。

6.2 抓取滑脱的排查与修复

抓取滑脱是最大问题。我先把抓取过程的力觉数据导出来看，发现力觉读数在抓取后迅速从3N掉到0.5N，说明零件在夹爪里滑了。但夹持力设的是3N，按理说不应该滑。

进一步排查发现，夹爪的接触面是金属，齿轮表面有油膜，摩擦系数比预期低很多。仿真里默认的摩擦系数是0.5，实际接触的等效摩擦系数可能只有0.2。3N的夹持力，产生的摩擦力只有0.6N，而齿轮重量是0.5N，稍微一动就滑。

修复方案有两个：一是增大夹持力到5N，二是换用带橡胶垫的夹爪增加摩擦。我选了后者，因为增大夹持力可能导致齿轮变形。换夹爪后在仿真里重新标定摩擦系数，抓取滑脱率从60%降到了5%以下。

6.3 插入卡死的力觉曲线分析

插入卡死的问题，通过力觉曲线定位到了根因。正常的插入力觉曲线应该是：接触后力缓慢上升，到达插入深度后力稳定。但失败案例的曲线是：接触后力突然跳到8N，然后持续上升直到触发10N阈值停止。

这个曲线说明零件在孔口就卡住了，根本没进去。原因是齿轮的键槽和轴上的键没有对齐。初始版本的代码只做了位置对齐，没有做角度对齐。修复方案是在插入前增加一个角度搜索步骤：夹爪夹持齿轮，以低速旋转，同时监测力觉，当力觉出现微小周期性波动时，说明键槽和键接触了，记录此时的角度，然后在这个角度下执行插入。

这个角度搜索逻辑加进去后，插入卡死率从30%降到了8%。剩下的8%是孔内有毛刺或异物，这种情况通过增加插入前的吹气清洁步骤解决。

6.4 检测失败的视觉参数调整

检测不到齿轮的问题相对简单，是视觉检测的颜色阈值设得太窄。仿真环境的光照有变化，红色齿轮在不同光照下RGB值波动较大，固定阈值经常漏检。改成HSV色彩空间+自适应阈值后，检测率从90%提升到了99%。

6.5 修复后的整体效果与剩余风险

三个问题修复后，仿真成功率从45%提升到了88%。剩下的12%失败主要是多齿轮场景下的遮挡问题：两个齿轮挨得太近，夹爪抓一个的时候碰到了另一个，导致被碰的齿轮移位，后续抓取时位姿估计错误。

这个问题目前还没有完全解决，我的临时方案是抓取顺序优化：先抓取边缘的齿轮，再抓取中间的，减少碰撞概率。同时增加了抓取后的二次检测：抓完一个齿轮后，重新检测剩余齿轮的位姿，更新内部状态。这个方案把成功率提升到了92%，但还没有根治。根治需要更精细的碰撞检测和路径规划，这是下一步的优化方向。

这个案例说明，EmbodiedSWE的调试是一个迭代逼近的过程。不要指望一次设计就完美，而是要通过执行数据不断发现问题、修复问题、验证效果。每修复一个失败模式，成功率就上一个台阶。最终的目标不是100%成功，而是把失败模式收敛到可接受的范围，并且对剩余失败有明确的恢复策略。