3小时前 DexHoldem：让机器人打德州扑克，真正难的不是赢牌，而是别把桌子搞乱

出品：具身释界

让机器人去打德州扑克，听起来像是一个有点好玩的 demo。

但这篇论文真正想研究的，并不是机器人会不会算牌，也不是它能不能像人类玩家一样 bluff。论文关心的是一个更底层、更真实的具身智能问题：

机器人能不能在真实桌面环境中，看懂当前状态，选择合适动作，用灵巧手完成操作，并且让桌面状态还能继续用于下一步任务？

这就是论文 DexHoldem: Playing Texas Hold'em with Dexterous Embodied System 想做的事情。

简单来说，DexHoldem 把德州扑克桌面变成了一个真实世界的灵巧操作 benchmark。机器人需要操作扑克牌和筹码，需要理解当前牌局状态，还需要在真实物理环境中持续感知、决策和执行。

它不是让机器人完成一次“抓起物体”的短任务，而是要让机器人在一个不断变化的桌面环境里持续做事。

论文 Figure 1 很适合作为开篇图。它展示了 DexHoldem 的完整设定：真实硬件是 ShadowHand + UR 机械臂，输入来自俯视相机、第三人称相机和腕部相机；系统需要先感知桌面状态，再进行路由决策，最后调用低层 policy 执行具体动作。Figure 1 也展示了 policy benchmark 和 agent benchmark 的整体结果，可以让读者一眼看出：这不是一个单纯的扑克游戏，而是一个真实灵巧操作系统 benchmark。

为什么选择德州扑克？

德州扑克这个任务看起来很轻松：桌面上无非就是扑克牌和筹码。

但对机器人来说，这其实是一个非常“刁钻”的场景。

首先，扑克牌很薄。机器人要把一张牌从桌面上拿起来，再放回指定位置，这比普通夹爪抓一个方块要难得多。灵巧手需要处理手指接触、摩擦、角度、力度和微小误差。

其次，筹码也不好操作。机器人要推筹码、拉筹码，还要根据不同面额移动筹码。动作稍微偏一点，就可能把旁边的牌或筹码撞乱。

更关键的是，德州扑克不是一个静态任务。牌桌状态会随着每一步动作变化。机器人要知道现在轮到谁、公共牌是什么、下注是多少、自己还有多少筹码、对手还有多少筹码，以及当前应该看牌、下注、跟注、亮牌，还是等待。

所以，这篇论文选择德州扑克，并不是因为“扑克”本身重要，而是因为它把很多真实具身系统的难点压缩到了一个可控桌面场景里：

精细操作、视觉理解、状态记忆、动作选择、闭环执行。

这也是 DexHoldem 和很多传统机器人 benchmark 不一样的地方。很多 benchmark 只问机器人能不能完成一个动作，而 DexHoldem 进一步追问：

机器人完成这个动作之后，桌面还能不能继续用？

DexHoldem 评测的不是一个模型，而是一整套系统

DexHoldem 可以分成三个层次来看。

第一层是 Dexterous Hand Policy Bench，评测低层灵巧操作能力。

第二层是 Agentic Perception Bench，评测 agent 是否能看懂牌桌状态。

第三层是 System-Level Evaluation，评测完整闭环系统能不能真的跑起来。

这三个层次刚好对应一个真实具身系统里的三个关键问题：

手能不能做？眼睛能不能看懂？大脑能不能把流程串起来？

第一层：低层 policy，灵巧手能不能完成原子动作？

DexHoldem 设计了 14 个德州扑克相关的原子操作 primitive。

这些动作包括：

拿起左边或右边的手牌；

放下左边或右边的手牌；

展示左边或右边的手牌；

推不同面额的筹码；

拉回不同面额的筹码。

论文一共采集了 1,470 条真实世界遥操作 demonstration。每个 primitive 有 105 条演示，其中 100 条用于训练，5 条用于验证。

机器人硬件是 UR10e 机械臂 + Shadow Dexterous Hand。也就是说，它不是普通的二指夹爪，而是一个多自由度灵巧手系统。

policy 的输入包括三个 RGB-D 视角：俯视视角、第三人称视角和腕部相机视角，再加上机器人自己的关节状态。输出则是机器人接下来要执行的关节位置 action chunk。

论文 Figure 4 很适合放在这里。它展示了 view cards、show cards、push chip、pull chip 等操作的成功和失败案例。这里可以重点讲一个直观感受：这些动作在人看来很简单，但对灵巧手来说并不简单。拿牌、亮牌、推筹码、拉筹码，都涉及非常细的接触控制。机器人不是“碰到物体”就算完成任务，而是要在不破坏桌面状态的情况下完成动作。

一个非常关键的指标：成功了，但桌面还能继续用吗？

这篇论文最有意思的地方之一，是它没有只用普通的 success rate。

作者把每次物理执行结果分成四类：

SP：Scene-Preserving Success 任务完成了，而且桌面状态仍然干净，可以继续后续操作。

DC：Disruptive Completion 任务完成了，但桌面被扰乱了，后续流程可能无法继续。

TF：Task Failure 任务没有完成，但桌面状态还比较稳定，可以重试。

DF：Disruptive Failure 任务失败，而且环境被破坏，需要重置。

这个划分非常重要。

因为在真实机器人系统里，完成当前动作并不等于真正成功。

比如机器人成功把筹码推到了下注区，但同时把手牌撞翻了，或者把其他筹码撞乱了。从单步目标看，它好像完成了任务；但从完整系统看，它已经让后续流程无法继续。

所以 DexHoldem 引入了两个指标：

一个是 TCR，也就是 task completion rate。只要任务完成，就算完成。

另一个是 SPSR，也就是 scene-preserving success rate。只有任务完成，并且桌面状态仍然可继续使用，才算真正干净的成功。

这个指标其实比普通 success rate 更接近真实部署需求。

因为真实机器人不是为了拍一个成功视频，而是要连续、稳定、可恢复地完成任务。

实验结果：最好的 policy 也远远不稳

在低层 policy benchmark 中，论文比较了多个模型，包括 π0.5、π0、RDT、DP、ACT、BAKU 等。

结果显示，π0.5 的 TCR 最高，达到 61.2%。也就是说，如果只看任务有没有完成，π0.5 是表现最好的。

但如果看更严格的 SPSR，也就是既完成任务又不破坏桌面状态，π0.5 和 π0 都是 47.5%。

这里建议插入论文 Table 1。这个表非常关键，因为它清楚展示了不同 policy 的 SP、DC、TF、DF，以及最终的 SPSR 和 TCR。

可以看到，π0.5 的 TCR 是 61.2%，但 SPSR 只有 47.5%。这说明有不少动作虽然完成了，但会扰乱桌面状态。RDT 也是类似，TCR 是 46.2%，但 SPSR 只有 30.0%。

这正是 DexHoldem 想强调的问题：

机器人不是只要“做到了”就行，还要“做得干净”。

对于长程任务来说，一次不干净的动作，可能会让后面的感知、决策和执行全部变难。

预训练有帮助，但不能直接解决灵巧操作

论文还进一步分析了一个问题：

大规模预训练 policy 对 DexHoldem 这种真实灵巧手任务到底有多大帮助？

从结果看，π0.5 和 π0 这类预训练 VLA policy 确实明显领先于很多从零训练或较小规模的 imitation policy。这说明大规模机器人预训练对真实桌面操作是有帮助的。

论文 Figure 5 很适合用来讲这个结论。横轴是 policy pretraining data scale，纵轴是 task completion rate，点的大小表示 policy 参数量。可以看到，π0 和 π0.5 位于右上区域，说明大规模预训练和更大的模型规模确实带来了更好的物理执行效果。

但这个图也说明了另一个问题：

预训练不是万能的。

即使是表现最好的 π0.5，TCR 也只有 61.2%，SPSR 只有 47.5%。也就是说，大规模预训练能把性能往上推，但还没有让真实灵巧手操作达到稳定部署水平。

论文还用 RDT 做了一个 fine-tuning data scaling study，比较随机初始化和 gripper-pretrained initialization 在不同数据量下的表现。

Figure 3 展示了一个很有意思的结果：随着 DexHoldem-specific 数据量增加，validation loss 会下降；但 gripper-pretrained 初始化并没有在低数据量下带来质变。也就是说，gripper 场景的预训练对 ShadowHand 这种灵巧手任务有一定初始化帮助，但并不能直接解决少样本灵巧操作问题。

这也很符合直觉。

二指夹爪和多指灵巧手虽然都属于机器人操作，但它们的接触模式、动作空间和控制难度差异很大。把 gripper 上学到的能力迁移到 ShadowHand 上，并不是一件自然发生的事情。

第二层：agent 看得懂牌桌吗？

低层 policy 解决的是“手怎么动”的问题。

但一个完整的 embodied agent 还需要解决另一个问题：

它能不能看懂当前牌桌状态？

DexHoldem 设计了一个 agentic perception benchmark，一共有 36 个真实部署过程中的牌桌状态问题。模型需要根据当前图像和前面的历史状态，恢复出结构化的游戏状态。

这些状态字段包括：

当前流程阶段；

现在轮到谁；

大小盲位置；

公共牌；

当前下注；

机器人筹码状态；

对手筹码状态；

摊牌结果。

这部分和普通 VQA 不太一样。

普通 VQA 可能会问：“图中有几张牌？”或者“筹码是什么颜色？”

但 DexHoldem 更关心的是：模型能不能把视觉信息转成后续机器人决策真正需要的状态变量。

比如，如果模型看错当前下注金额，agent 就可能选择错误的 call 或 raise。

如果模型看错对手筹码状态，系统就可能一直等待，或者错误判断游戏阶段。

如果模型看错当前轮到谁，机器人可能在不该行动的时候乱动。

所以这里考察的不是“看图说话”，而是 视觉状态恢复能不能支撑后续动作路由。

Frontier VLM 也会在完整状态恢复上出错

论文测试了多个前沿多模态模型。

结果很有意思：GPT 5.5 的平均 field-wise accuracy 最高，达到 66.8%；但如果要求一个问题中所有相关字段都完全正确，Opus 4.7 的 strict problem-level accuracy 最高，也只有 34.3%。

这里建议插入论文 Table 2。这个表很适合讲“单字段准确”和“完整状态恢复”之间的差距。

可以看到，模型在某些字段上表现还不错，比如 blind information 这种相对显眼的信息，很多模型都能达到很高准确率。但在 current bet chips、robot chip inventory、opponent chip inventory 这些细粒度筹码状态上，模型表现明显更差。

这说明当前 VLM 并不是完全看不懂牌桌，而是很容易在某个关键字段上出错。

对于普通图像问答来说，一个字段错了可能只是答案不够完美；但对于真实机器人闭环系统来说，一个字段错了，就可能导致后续动作选择错误。

这也是 DexHoldem 很有价值的地方：

它不是停留在“模型能不能描述图片”，而是进一步问：

这个视觉理解结果，能不能支撑机器人继续做事？

第三层：完整系统怎么闭环运行？

有了低层 policy 和高层感知之后，DexHoldem 还搭建了一个完整的系统级闭环。

这个系统可以简单理解为：

拍摄当前桌面 → 解析结构化状态 → 更新游戏记忆 → router 判断当前应该做什么 → 调用对应低层 policy → 机器人执行 → 再次观察桌面。

论文 Figure 2 是理解系统闭环的关键图。

它展示了 agent 在一次决策中如何工作：先感知桌面状态，然后加载和更新 game-state memory，再通过 reasoning checks 判断当前状态，最后在场景稳定且需要执行 primitive 时，调用 dexterous policy。

Figure 2 中的例子是 view left card。系统发现左边手牌未知、机器人处于 idle 状态、桌面稳定，于是选择 “View Left Card”。这个高层动作会被翻译成低层动作序列：

pick_up_left → perceive → put_down_left

也就是说，agent 的一个高层决策，实际会被拆成多个低层灵巧操作。

这个设计很重要，因为 DexHoldem 并不是让一个大模型端到端直接输出机器人关节动作，而是采用了模块化闭环：

高层 agent 负责理解和决策；

router 负责流程控制和安全判断；

低层 policy 负责真实物理执行。

这种系统设计很接近真实机器人部署。真实世界里，机器人不仅要知道“应该做什么”，还要知道什么时候不该动，什么时候应该等待，什么时候应该重试，什么时候应该请求人类帮助。

系统级评估：真正的困难来自错误累积

论文还做了三个完整的 hand-level case study，也就是让系统在真实牌桌上跑完整流程。

需要注意的是，作者也说明这些是 case study，不是大规模统计意义上的完整成功率评估。它们的价值主要在于展示真实闭环部署中会出现什么问题。

这里可以插入论文 Table 3。这个表统计了三个系统级轨迹中的 captured states、agent primitives、dexterous-policy primitives、wait-branch events、human-help requests 和 recovery dispatches。

这些数字说明了一个很真实的问题：

完整系统不是“做一个动作就结束”，而是在不断等待、验证、继续、恢复和重试。

比如某个轨迹中，系统可能需要多次等待场景稳定；某些动作可能需要继续执行后续 primitive；如果识别或操作不确定，系统还可能进入 recovery，甚至请求人工帮助。

这比单步 success rate 更接近真实部署。

在真实机器人系统里，失败往往不是突然发生的，而是慢慢累积的：

感知错一点，router 可能选择错误分支；

policy 执行不稳定，桌面状态会被扰乱；

桌面状态一乱，下一轮感知又更难；

如果系统无法确认状态，就只能等待、重试，甚至请求人工介入。

所以 DexHoldem 展示的不是一个漂亮 demo，而是一个更真实的问题：

机器人系统的难点，不只在某个模块是否足够强，而在多个模块组合起来之后，错误会不会不断放大。

这篇论文真正重要的地方

我觉得这篇论文最重要的地方，不是“机器人会打德州扑克了”。

它真正重要的地方是提出了一种更接近真实部署的具身智能评测方式。

过去很多机器人 benchmark 更关注单步任务，比如抓起一个物体、放到某个位置、按下一个按钮。这些任务当然重要，但它们很难反映真实机器人系统的完整难度。

真实机器人需要面对的是：

它能不能持续理解环境？

它能不能在状态变化后做出正确选择？

它能不能执行动作后不破坏环境？

它能不能在失败后恢复？

它能不能在不确定时等待，而不是乱动？

DexHoldem 通过德州扑克桌面，把这些问题压缩到了一个结构化但足够复杂的真实物理场景中。

这对工业机器人也很有启发。

比如在产线上，机器人不是只要拿起一个零件就行。它不能把旁边零件撞乱，不能影响后续工序，不能在状态不确定时继续乱动。它需要知道什么时候等待、什么时候重试、什么时候请求人工处理。

所以，DexHoldem 评测的其实不是“扑克机器人”，而是一个具身智能系统最基础的问题：

机器人能不能在真实世界里持续、干净、可恢复地完成任务？

小结

DexHoldem 这篇论文可以用一句话概括：

它把灵巧手操作、视觉状态理解和闭环决策放进同一个真实桌面任务里，评测机器人是否真的具备持续做事的能力。

这篇工作的结果也很清楚：

最好的 policy 仍然只有 61.2% 的任务完成率；

更严格的干净成功率只有 47.5%；

最强感知模型在完整状态恢复上的准确率也并不高；

系统级 case study 中，等待、验证、恢复和人工帮助仍然非常重要。

这些结果说明，当前 VLA、VLM 和灵巧手系统距离真正稳定部署，还有很长一段路要走。

但也正是这些“不完美”，让 DexHoldem 变得有意义。

因为真实机器人研究最需要的，可能不是一个看起来很漂亮的成功视频，而是一个能暴露问题、能量化失败、能推动系统进步的 benchmark。

DexHoldem 想做的，就是这件事。