A 组的《机器人的决定是怎么冒出来的》讲了协商结构的三条约束。本文往下挖一层：跟随一次真实的抓取决策，从输入进来到动作序列出去，逐步看每个环节发生了什么。 全部数据来自实机运行记录，不是设计稿。

传统机器人做决策是"一个人拍板"：一个规划器读完场景，输出一条指令。这条路能走通，但有两个死结——单点失效，以及面对没见过的场景时无从下手。Lumina PMD 用的是另一种结构：多个各自只看得见一小块的决策单元并行判断，靠少数几条极简的协商规则，让一个谁都没想到的解决方案自己长出来。 本文讲这套协商机制的三个约束条件，以及为什么"少规则"比"多规则"更难做、也更可靠。

机器人行业最危险的一句话是"应该没问题"。传感器抖了、某个视角被挡住了、力矩读数丢了，系统往往会用一个"合理的默认值"把缺口填上，然后继续执行。绝大多数撞机、误抓、摔倒事故，根子都在这里。Lumina PMD 在决策入口设了一道很硬的门：主感知链路缺一个必需物理量，整条决策直接拒绝执行，不猜、不补、不降级硬跑。 本文讲这道门怎么设、为什么必须这么硬、以及它给客户带来了什么。

具身智能最常见的失败不是"算不出来"，而是"算出来的东西落不下去"。上层规划输出的是一串语义动作（往前走、抓住它、放桌上），下层电机要的是角度、力矩、速度，两者之间隔着一道翻译层。绝大多数机器人系统的复杂度，都堆在这道翻译层里。本文讲 Lumina PMD 的一个选择：把这道翻译层做成一个独立的、封闭的、可验证的物理智能核心模块，让上层智能只看见语义动作，永远看不见电机。本系列的边界声明：这一系列

具身智能领域有一种默认假设：机器人的智能来自云端大模型。这个假设在实验室成立，在工厂车间、地下车库、偏远厂区往往不成立——没网、网差、或者客户根本不允许数据出内网。本文讲 Lumina PMD 的端侧闭环方案：什么能力必须放在端侧，端侧能做什么、不能做什么，以及资源边界有多宽。

具身智能领域有一种默认假设：机器人的智能来自云端大模型。这个假设在实验室成立，在工厂车间、地下车库、偏远厂区往往不成立——没网、网差、或者客户根本不允许数据出内网。本文讲 Lumina PMD 的端侧闭环方案：什么能力必须放在端侧，端侧能做什么、不能做什么，以及资源边界有多宽。

人形机器人行业有一个长期的痛点：算法和硬件绑死。换一个本体，大脑代码要重写大半。这个问题在单机研发阶段还不明显，一旦要面对多个客户、多种机型，就变成了灾难。本文讲 Lumina PMD 的分层可插拔设计——不是讲某个模块怎么实现，而是讲为什么这样分层、接缝开在哪里、集成商要改多少代码才能接一个新本体。

V1.3 是这条路线的第一块公开拼图：先把仿真的事情做到"开箱即用"，再让同一套大脑走进真机。如果你在做机器人运动开发，欢迎下载体验、留言反馈——Issue 与评论区都会看。下载链接见上文表格。我们 V1.4 见。