开源代码：GitHub - Open-RUA/uni-robot-agent

论文： “Democratizing Robot-Use Agents: A Unified Harness with Open Models”，清华和加州伯克利分校， 26年11月。

它的工程设计扎实，最值得借鉴的是“把机器人的物理不确定性封装进工具层”。但“开源模型超过 GPT-6 Astra”的标题要打折扣：同一 Harness 下，Astra 仍以 51.90 比 31.39 明显领先，真机部分也还没开源。

系统概览如图所示：

1. 它是什么

它不重写 Agent 循环，而是直接复用 Codex / Claude Code 作为运行时，自己提供机器人工具、调度和模型网关。Python 代码约 2.76 万行，MIT 许可，当前版本 v0.1.1。

如图其5个逻辑层：

层	职责	代码量（行）
Agent	运行时、上下文策略、模型协议转换	agents 3020，provider 3482，context 887
编排	后台任务、资源队列、取消	execution 884
工具	move/grasp、capture_scene/locate、技能库、finish	tools 2980
服务	环境、动作模型、感知（快照、回执、批处理）	services 5247
后端	RoboDojo、RoboUse、RoboLab 适配，π0.5，SAM3	integrations 5480（不含 π0.5、SAM3 后端，它们在 services 内）

共享工具加适配器，把 N×M 份工具实现降为 N 个工具加 M 个适配器。接入新环境时，主要写适配器和配置。

2. 核心设计

如图所示核心设计选择：

流水线执行（效率）

• 动作在后台执行时，模型可以继续推理；占用同一资源的动作仍按提交顺序执行。
• 5 个任务的耗时缩短 4.8%–73.7%，动作时间中有 84.5%–93.8% 与模型请求重叠。
• 代码默认就是这个模式：tool_return_mode="background"、resource_scheduling="per-resource"。

受监控的 move（可靠性）

• 每一步都从实测位姿重新生成路点，并按原因停止：到达、发散、停滞、不安全运动、规划被拒或超出步数预算。
• 单次 move 最多 24 步。默认档步长 4 cm、位置容差 3 cm；精密档步长 1 cm、容差 5 mm。
• 我抽查了发散判据和异常运动阈值（0.2 m/0.8 rad，0.05 m/0.25 rad），都与附录 D 一致。

其他设计

• 一致性： 图像、标定和机器人状态绑定到同一个不可变快照，避免“旧图配新位姿”。
• 防重复动作： 响应丢失时查回执，绝不自动重发。这是物理世界与普通 Agent 工具调用的关键区别。
• 可诊断反馈： 工具返回误差和停止原因并附图，并明确“到达位姿不等于任务成功”。
• 上下文管理： 旧图批量换成文字占位符，以保持提示前缀稳定、提高缓存命中。

3. 论文结果

场景	组合	分数
RoboDojo 仿真	Astra + uni-robot-agent	51.90
	Qwen3.8-Flash-Next + uni-robot-agent	31.39
	Astra + RoboProbe	28.97
	DeepSeek-V4.1-Flash + uni-robot-agent	27.11
	Qwen + RoboProbe	1.90
真机 19 任务	Astra + uni-robot-agent	75.50
	Qwen + uni-robot-agent	49.50
	π0.5（微调）	47.75
	Dream-1	35.50

• Harness 的作用： 换用它后，Qwen 提升 29.49 分，Astra 提升 22.93 分。
• 成本： Qwen 每集约 $1.09，Astra 约 $21.29，相差约 20 倍。
• 能力归因： 失败主要来自视觉理解、空间定位、几何编程和具身推理四类能力。

4. 需要打折扣的地方

1. 标题比较跨了 Harness。 31.39 对 28.97 的差距只有 2.42 分，而 Astra 仅因评测批次不同，就有 55.04 和 51.90 两个分数（种子和布局数不同）。
2. “不需要深度”只在总分上成立。
   • Qwen 在精密任务上的成功率从 18.75% 掉到 2.08%，分数从 26.35 掉到 10.21。
   • 正文说 Astra 保留了 98.6% 的分数，但那是单种子批次；按表 1 的 3×2 批次算约 91.4%。

3.相机标定才是硬依赖。 去掉标定后，Qwen 下降 71%（到 9.13），Astra 下降 43%（到 31.29），论文却称后者“moderate”。

4. 无深度设定没有上真机验证。 真机实验中 Agent 用了 D405 深度，而 π0.5 和 Dream-1 只用 RGB。所以 49.50 对 47.75 不是同等输入下的比较，差距也只有 1.75 分，且未报告置信区间。

5. “不依赖技能库”掩盖了结构性差异。

• • 总分几乎不变（30.31 对 31.39）。
  • 去掉技能后，精密和长程任务的成功率反而上升（2.1%→8.3%，6.3%→16.7%），记忆和开放词表任务则下降。
  • 误差棒多有重叠，但值得追查技能是否误导了模型。

6. 统计依据偏弱。

• • 流水线对比每个任务只跑 1 集，也没有报告成功率是否受影响。
  • 图 8 的相关系数只基于 6 个模型。
  • 图 6 混用了设置不同的批次。
  • 各模型的推理强度也不同：Astra 用 medium，Qwen 用 xhigh，DeepSeek 用 max。

5. 代码与论文的差异

问题	我看到的情况	影响
真机未开源	README 中 ARX One 和 Franka 都标注 “Coming soon”	真机结果目前无法复现
默认开启深度	RoboDojo 默认有深度，要加 --no-depth	不加这个参数，跑的就不是论文主设定
术语不一致	README 的 “RGB-only” 含标定，论文的 “RGB only” 不含	容易配错实验
任务补充说明	默认追加 instruction_supplements.json，其来源包含 env/reward_manager/	见下方说明
灵巧手	代码里有 dexterous-1 接口，但发布校验脚本列出了相关名称，看起来被排除在发布包之外	图 1 列出的 Sharpa 暂时不能指望
公开测试	贡献指南提到 tests/，仓库里却没有这个目录	改动核心代码时缺少回归保护

任务补充说明是最值得追问的一点：

• 它会告诉模型“不要抬起方块”“结束时双臂回到初始位姿”这类要求，文件声明不含评分细节和容差。
• 这不算验证器的实时反馈，但确实是对原始指令的增强，而论文的输入清单只写了 “task instructions”。
• 更详细的 task_requirements.json 含具体容差，默认不加载。
• 论文跑分时用的是哪一版，我无法确认。

复现配置： 我也没有找到能复现 31.39 的完整配置。快速开始示例用的是 --no-sam3，而论文架构含 SAM3，上下文策略默认是 identity，不是论文描述的滑动窗口。

6. 上真机前的风险

• 排队动作不会自动取消： 提示词明确写着，前置动作失败后，已排队的后续动作不会自动取消，要靠模型主动调用 flush_queue。运行中的动作也不能强制停止。
• 流水线收益可能被高估： 代码和技能文档显示，仿真看起来是按步推进的，模型思考时世界可能不动。这一点我没有完全验证。如果属实，真机上动态任务的表现不能直接类推。
• 控制频率低： 运动循环在客户端按步走 HTTP，不是实时控制，文档也写明实时伺服要放在硬件侧。
• 感知模态受限： 判断结果主要靠位姿误差和图像，所以接触丰富的精密任务仍是短板，论文也承认这一点。

7. 怎么用它

• 适合借鉴： 回执机制、快照绑定、带停止原因的动作工具、N+M 适配器和资源队列。这些不依赖具体模型，也是我认为最持久的价值。
• 适合做研究底座： 统一的交互记录便于采集训练数据；不过 artifacts/sft/ 目前只有一个 59 字节的 __init__.py，训练管线似乎还没放出来。
• 暂不适合： 直接拿去部署真机。接入时至少要补上硬件急停和中断、失败后自动清空队列，以及独立于模型的安全层。
• 自己评测时： 用 --no-depth，固定补充说明的版本，并把分数按维度拆开看，不要只看总分。

来源

• 论文 arXiv:2611.01560
• GitHub 仓库
• 架构文档
• motion.py
• scheduler.py