机器人的决定是怎么冒出来的
系列：人形机器人大脑体系 · 架构篇 3/3
字数：约 3000 字

获取与部署
⚠️ 重要说明：软件包托管于我方阿里云 ECS 静态服务节点，链接为配套文章专属访问地址。
服务仅用于本次文稿配套评估试用，链接会按需维护，我方有权随时关停访问。
文件禁止二次分发、转存商用；如需商用正式包与持续技术支持，请联系我方商务对接获取正式发布渠道。

下载地址
http://47.119.135.145:8080/lumina_pmd_v3.1.2_so_publish.tar.gz
部署四步

1. 下载并校验总包 MD5
   md5sum lumina_pmd_v3.1.2_so_publish.tar.gz

   期望值：eab169edc7a6d31ee636c8edc0f6c99c

2. 解压
   tar -xzf lumina_pmd_v3.1.2_so_publish.tar.gz
3. 执行安装脚本配置环境
   bash install.sh
   如提示 /etc/profile.d 权限不足，改用用户级 PYTHONPATH 方案：
   echo ‘export PYTHONPATH=$PWD/cor{e}_{m}odules:$PWD/adapter:$PWD/vtl{a}_{h}al:$PYTHONPATH’ >> ~/.bashrc
   source ~/.bashrc
4. 执行冒烟测试，验证模块导入与全链路功能
   cd lumina_pmd_v3.1.2_so_publish
   bash install.sh
   install.sh 已内置核心模块导入自检，全部通过时输出 OK: core modules loaded。
   环境要求：Ubuntu 22.04 LTS · Python 3.10 · x86_64 · 内存 8GB 起（推荐 16GB）
   文件级验真：包内附 md5_manifest.txt（251 条文件级指纹），可执行以下命令逐文件复核：
   md5sum -c md5_manifest.txt --quiet
   全部条目无输出即代表一致；若出现 FAILED，请核对 Python 版本是否为 3.10（编译产物与解释器版本绑定）。

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

一、两条路的对比
1.1 集中式：一个大脑说了算
感知 ──► 规划器 ──► 一条动作序列 ──► 执行
优点是简单、可预测、容易调试。缺点是：
死结 说明
单点失效 规划器的判断错了，整条链路全错，没有任何内部纠错
场景泛化差 没见过的组合要人工补规则；规则越补越多，最后互相冲突
感知假设硬 默认感知输入是完整的；一旦某个视角被遮挡，规划器只能"猜"

1.2 分布式协商：多个小判断合起来
感知分片 ──► 单元1 ┐
单元2 ├──► 协商 ──► 一条动作序列 ──► 执行
单元3 │
… ┘
每个单元只负责自己那一小块（前方、身侧、脚下、目标物体、手臂可达域……），各自给出一个"倾向"。协商层把这些倾向合成为一个决定。
这不是"把规划器拆碎"，而是换了一种决策模型：从"算出答案"变成"让答案收敛"。

图：感知切成若干片，每片由一个只看局部的小单元判断，协商层把这些倾向收敛成一条动作序列。

二、协商必须有约束，否则就是混乱
多单元并行，最容易出的事是：议论半天出不了结论，或者结论来回摆动。
所以协商不是自由讨论，是带约束的收敛。我们只用三条约束：
约束一：每个单元只跟直接相邻的单元交换意见
不允许"全局广播"。理由是：
· 全局广播的通信量随单元数平方增长，8 个单元还能扛，32 个就崩了；
· 全局广播会把所有人的判断平均掉，等于又退回了一个大脑；局部交换才能保留差异。
局部交换的额外好处：某条链路断了，影响的只是局部，整体还能降级运行。
约束二：冲突到一定比例就直接淘汰，不做折中
当某两个倾向在同一处冲突达到一定比例，直接判为不可行，退出候选池，而不是各让一步。
为什么不做折中？因为物理世界没有折中。要么撞上，要么不撞。一个"70% 往前走、30% 往左"的决定，执行出来是撞。折中在语义层是妥协，在物理层是事故。
约束三：连续多轮稳定才算达成共识
一次交换就定结论是不行的——那等于第一个说话的单元说了算。
规则是：同一结论连续保持若干轮不变，才允许入池。轮数不需要多，三轮就够。这条约束的作用是过滤掉瞬时抖动，比如某个感知帧恰好有噪声，单帧会让它误判，三轮下来噪声自己会被稀释。
三条约束的工程参数
光讲"有三条约束"是不够的，得能报出数字。我们把可公开的参数列出来：
参数 取值 含义
决策单元数 8 并行判断的单元个数
凝聚权重 0.6 向邻近单元的平均倾向靠拢的强度
对齐权重 0.3 与邻近单元的方向一致程度
分离权重 0.4 与邻近单元保持最小间隔的强度
分离半径 0.35 低于此距离触发分离（归一化单位）
吸引系数 0.9 向目标收敛的强度
迭代轮数 24 单次协商的最大轮数
时间步长 0.1 每轮推进的归一化时间
最大速度 0.5 单元单轮可移动的上限
保守阈值 0.45 协商置信度低于此值转入保守模式

这十个数字合起来，就是第一节说的"三条约束"的落地形态——凝聚/对齐/分离三组权重对应局部交换，迭代 24 轮对应多轮稳定，分离半径与保守阈值对应冲突处理。
有个细节值得说：分离权重（0.4）大于对齐权重（0.3）。 这个关系是刻意的——让单元"别挤在一起"比让单元"想法一致"更重要。如果反过来，八个单元会很快收敛到同一个倾向，等于退化成一个单元，协商就失去意义了。
这条不等式是整个参数集里最关键的一处。 调参调到最后，真正决定系统有没有多样性的，往往就是这一处权重的高低关系。
三条约束合起来的效果
单一约束 单独用会怎样
只做局部交换 意见永远合不拢，无法收敛
只做冲突淘汰 有效选项被过早杀死，退化成保守不动作
只做多轮稳定 抖动过滤了，但没有结构，决定依旧是乱的

三条必须同时在，才构成一个能收敛、又不失多样性的协商机制。 这是这套结构的核心，也是最难调的地方——调松了决议不出来，调紧了所有单元给出同一个答案，等于没有协商。

三、这套结构解决什么集中式解决不了的问题
3.1 没见过的新场景
集中式的行为可以概括成：见到过的场景有规则，没见过的场景没规则。
协商式的行为不一样：没见过的场景，单元们各自凭局部规则给出倾向，合起来仍然能产出一条动作序列。
举一个实测例子。给系统一个此前不在任何规则表里的场景，它输出的决策过程记录是这样的：
判定：全新场景（未命中任何历史决策）
动作序列：抓取 → 缓慢趋近目标 → 安全优先
协商置信度：0.09 —— 低于保守阈值，自动转入保守模式（降速 + 力上限收紧）

转成结构化输出后是这样的：
步骤 参数 说明
APPROACH（趋近） 增益 0.786，速度系数 1.0 先靠近，正常速度
TOUCH（触碰） 接触力 6.0 N，速度系数 1.0 轻触确认，力控制在 6 牛
GRASP（抓取） 抓取力 12.0 N，置信 0.586 确认后施力，力值取自上一阶段实测

注意这条序列不是任何一条预写规则的内容。它是几个单元各自判断后收敛出来的：
· 目标单元说"要抓"；
· 路径单元说"前方不确定，速度降下来"；
· 安全单元说"优先级压过速度"；
· 三条倾向合成，就是"慢慢靠过去、轻碰确认、再施力抓"。
这就是"决定自己长出来"的意思——不是随机生成，是局部判断在约束下收敛出的唯一合理路径。
3.1.1 置信度低的时候会怎样
这是这套机制里我最想强调的一处诚实设计。
上面那次实测，协商置信度只有 0.09。系统的处理不是"照样输出"，而是：
低置信，转入保守模式（降速 + 力上限收紧）

这意味着两件事：

1. 系统知道自己拿不准。 置信度不是一个用来炫耀的数字，是一个内部判据；
2. 拿不准时它不硬来。 降速、收紧力上限——动作还是那套动作，但变得更谨慎。
   这比"永远输出高置信度"要有价值得多。 一个永远自信的系统，在真出问题时不会告诉你它没把握。
   3.2 部分感知缺失
   多单元天生对缺失有容忍度：某个单元的输入丢了，它的倾向会被标为弱，协商时权重自然下降，其余单元照常工作。
   集中式没有这个能力——输入不完整，规划器要么报错要么瞎猜。
   3.3 决策的可解释性
   协商式天然留下决策痕迹。当前版本记录到这一层：
   记录项 内容
   决策次数 累计进入协商的次数
   记忆复用次数 命中历史决策的次数
   保守模式次数 协商置信度低、转入降速收紧的次数
   拒绝次数 输入不齐备被拦下的次数
   单次结果 动作序列、协商置信度、模式（探索/保守）、单元离散度、是否复用记忆

其中"模式"这一项最有用：它直接告诉你这次决策是"有把握"还是"将就着做"。 现场运维拿到这一项，就能判断哪些动作需要重点盯。
需要说明边界：当前版本记录的是收敛结果与宏观状态，不含逐单元每一轮的完整投票明细。这意味着你能知道"这次决策收敛得好不好、走的哪条路"，但不能回放"第三个单元在第 17 轮改了什么主意"。
为什么不做完整回放？因为八个单元、24 轮迭代、每轮几十维状态的完整快照，量级会超出端侧存储的合理预算。我们选择记"决策结论 + 可信度 + 离散度"这三个最有诊断价值的量，而不是全量留痕。这是一个取舍，不是能力缺失。

集中式只有最终输出，出了问题只能反推；协商式至少能告诉你这次它有多确定。

四、为什么"规则少"反而更难
这一段是本文的核心论点，值得展开。
规则多不难，规则少才难。
规则多的时候，每加一条就解决一个具体问题，效果立刻可见，工程师会有明确的成就感。但规则会互相冲突，到某个量级之后，加规则带来的收益小于它制造的冲突，系统开始"改一处坏一处"。
规则少的时候，每条规则都必须在大量场景下同时成立。这需要把规则提到一个更高的抽象层——不是"遇到 X 就做 Y"，而是"任何情况下都得满足 Z"。
我们这三条约束，全都是后一种形式：
· 局部交换，是"任何情况下通信不得超过邻接"；
· 冲突淘汰，是"任何情况下不得用折中规避冲突"；
· 多轮稳定，是"任何情况下不得以单次判断定案"。
它们不告诉你该做什么，只告诉你不许做什么。剩下的空间留给场景自己填。这就是为什么它能覆盖规则表覆盖不了的场景。

五、这套机制在系统里的位置
它不是一个独立模块，而是决策层的组织形式。它与上下层的关系：
层 它做什么 与本机制的关系
语义层 解析指令，给出任务目标 提供协商的初始目标
协商层（本机制） 多单元判断，收敛出一条动作序列 本体
物理层 把动作序列变成关节物理量 消费协商结果

值得强调的是：协商层的输出是语义动作，不是物理量。 它不知道电机怎么转，也不需要知道。这条边界由物理智能核心模块守住，两个模块各管一段，互不越界。

六、小结
· 集中式规划有两个死结：单点失效、新场景无从下手。
· 协商式的代价是"需要约束"，收益是"能自我收敛出新解"。
· 三条约束必须同时成立，少一条就退化。
· 约束全是"不许做什么"的形式，这是它能泛化的原因。
· 协商层的输出止步于语义动作，不下探到物理量。

架构篇回顾
篇目 主题
1/3 让上层智能彻底不知道电机的存在 翻译层为什么独立、边界怎么划
2/3 缺一个物理量，它就拒绝执行 物理校验门：缺件为什么必须拒绝
3/3 机器人的决定是怎么冒出来的（本篇） 多单元协商，新场景怎么自己长出解

本系列架构篇到此结束。下一篇为压轴独立稿：不靠遥控、不靠预写脚本，机器人如何自主完成作业。

获取与部署
⚠️ 重要说明：软件包托管于我方阿里云 ECS 静态服务节点，链接为配套文章专属访问地址。
服务仅用于本次文稿配套评估试用，链接会按需维护，我方有权随时关停访问。
文件禁止二次分发、转存商用；如需商用正式包与持续技术支持，请联系我方商务对接获取正式发布渠道。

下载地址
http://47.119.135.145:8080/lumina_pmd_v3.1.2_so_publish.tar.gz
部署四步

1. 下载并校验总包 MD5
   md5sum lumina_pmd_v3.1.2_so_publish.tar.gz

   期望值：eab169edc7a6d31ee636c8edc0f6c99c

2. 解压
   tar -xzf lumina_pmd_v3.1.2_so_publish.tar.gz
3. 执行安装脚本配置环境
   bash install.sh
   如提示 /etc/profile.d 权限不足，改用用户级 PYTHONPATH 方案：
   echo ‘export PYTHONPATH=$PWD/cor{e}_{m}odules:$PWD/adapter:$PWD/vtl{a}_{h}al:$PYTHONPATH’ >> ~/.bashrc
   source ~/.bashrc
4. 执行冒烟测试，验证模块导入与全链路功能
   cd lumina_pmd_v3.1.2_so_publish
   bash install.sh
   install.sh 已内置核心模块导入自检，全部通过时输出 OK: core modules loaded。
   环境要求：Ubuntu 22.04 LTS · Python 3.10 · x86_64 · 内存 8GB 起（推荐 16GB）
   文件级验真：包内附 md5_manifest.txt（251 条文件级指纹），可执行以下命令逐文件复核：
   md5sum -c md5_manifest.txt --quiet
   全部条目无输出即代表一致；若出现 FAILED，请核对 Python 版本是否为 3.10（编译产物与解释器版本绑定）。