一套脑子带五种身体：「一脑多态」真正缺的不是模型，是一张按本体重标的安全表
四足、三轮、配送狗，都要跑同一套模型。跨任务的成功率衰减已经有公开数字（91% 掉到 70%），跨本体的衰减还没人报过——这恰恰是「一脑多态」最该被追问的那一格。
- 事实：2026 年 11 月 8 日，酷哇科技首次亮相第九届进博会，展出 D0 重载四足机器人与 X1 城市作业服务机器人，两者搭载同一套 COOWAM 双层智能体世界模型。
- 模型分层：上层 Urban VLM 负责「慢思考」——理解行业 SOP、做长程任务规划；下层 CooWAIM 负责「快思考」——在隐空间完成毫秒级动作推演与执行。整套模型原生部署在端侧，弱网与断网环境下保持本地闭环。
- 本体谱系：D0 基于「Aether 以太」重载四足平台，可换装适配市政环卫、末端配送、安防巡检；X1 基于「Glide 驰航」1 吨级三轮线控底盘，面向人行道与辅道，做沿边清扫、障碍绕行、窄道脱困。社区配送机器狗 D2 计划 2027 年正式发布。
- 对照数字：本号 11-07 写过的苹果 HALO，在同一批场景里单任务成功率 91%，串成组合任务后掉到 70%——衰减 21 个百分点，相对下降约 23%。这是「跨任务」的衰减，而「跨本体」的衰减，目前没有任何一家公布过。
- 判断：「一脑多态」的瓶颈不在模型层，在安全边界层。模型可以复用，安全阈值必须按本体重算——一台 30 公斤的四足和一台 1 吨的三轮，撞上同一个人的后果完全不同。
- 判断：端侧部署的真实价值不是省流量，是让「断网可用」变成可承诺的交付条款。这一条对市政与园区客户，比成功率多五个点更有用。
先把「一脑多态」这四个字拆开。
「一脑」= 一套模型；「多态」= 多种身体形态。酷哇在进博会上展出的两台机器，是这句话目前最具体的一次落地：一台是重载四足 D0，一台是 1 吨级三轮底盘的 X1，两者共用同一套 COOWAM 世界模型。
这套模型分两层：上层 Urban VLM 做「慢思考」，读行业 SOP、拆长程任务；下层 CooWAIM 做「快思考」，在隐空间里做毫秒级动作推演。整套东西跑在端侧，断网也能闭环。
这个架构本身不新鲜——「慢规划 + 快执行」是过去两年 VLA 与分层控制的主流写法。真正值得讨论的是它想证明的那件事：同一套模型，能不能同时驱动一台 30 公斤级的四足和一台吨级的三轮？
先给一个已知的坐标。
11 月 7 日，苹果 HALO 的论文数据里有一组对照：在六个未建图的真实场景中，360 次单项任务测试平均成功率 91%；把动作串起来做组合任务，每种各测 10 次，平均成功率掉到 70%。
这是同一个模型、同一批场景、同一台机器人，只是任务变复杂了，就掉了 21 个百分点。
现在把问题换成：同一个模型、同一类任务、换一台机器人，会掉多少？
没有答案。翻遍公开材料，没有一家公司报过这个数。
| 复用维度 | 有没有公开衰减数据 | 典型数字 | 为什么难 |
|---|---|---|---|
| 同一本体 · 跨任务 | 有 | 91% → 70%（苹果 HALO） | 长程误差累积 |
| 同一本体 · 跨场景 | 部分有 | 多为 5–15 个点 | 光照、布局、材质变化 |
| 跨本体 · 同类任务 | 基本没有 | 未披露 | 运动学、动力学、传感器配置全变 |
| 跨本体 · 跨任务 | 没有 | 未披露 | 两个衰减叠加，且相互耦合 |
判断：「一脑多态」的可行性，取决于第三行那一格能不能填出来。填不出来，它就只是一个架构图；填得出来，它才是一门生意。
为什么跨本体比跨任务更难？因为任务的差异主要在「做什么」，本体的差异在「怎么动」。同一句「把垃圾捡起来」，四足要蹲、三轮要停稳伸臂；四足的落足点约束和三轮的转弯半径约束完全不是一套数学。模型的输出层如果按本体分化，那「一脑」就退化成了「一脑 + 多个身体适配层」——这也没问题，但宣传口径就该改成「一套底座 + 五个适配」。
这是本文最想说的部分。
模型可以复用，数据可以复用，代码可以复用。但有一样东西一旦换本体就必须重算：安全边界。
一台 30 公斤的四足机器人以 1.5 米/秒撞到人，动能约 34 焦耳；一台吨级的三轮底盘以同样速度撞到人，动能约 1125 焦耳——差 33 倍。同样一条「检测到人 → 减速停车」的策略，在四足上可能是合规的，在三轮上就是事故。
这张图说明一件事：「多态」这个词把差异说小了。四足、三轮、配送狗、无人小巴、人形，这五种形态在人机共处的场景里，属于完全不同的风险等级。把它们放在同一个模型底座上没问题，放在同一套安全策略上就是灾难。
这条判断对做租赁和场景交付的团队更直接。给园区、给市政、给商演场地报价时，客户问的第一句从来不是「成功率多少」，是「撞到人怎么办」。答案不能是「我们的模型很聪明」，只能是「这台设备的急停距离是 X 米、限速是 Y、责任划分是 Z」。这三样，每换一个本体就要重写一遍。
这篇稿子里最实的一句是「原生部署于端侧，弱网、断网环境下仍能保持本地闭环」。
为什么这句比「毫秒级」重要？因为市政环卫、园区巡检、地下车库、老小区这些场景，网络覆盖本来就不稳。云端推理的方案在这些地方，一断网就停摆——而停摆的机器人在马路上是个障碍物。
端侧还有一个隐性好处：数据不出场。市政与物业客户对「摄像头画面传到哪里」这件事越来越敏感，本地闭环等于把这条风险切掉。这一点对签合同的影响，往往比技术指标大。
代价也很清楚：端侧算力有限，模型必须压缩，压缩就要掉点。判断：端侧方案的真实水平，不看实验室成功率，看「压缩后掉了几个点、掉的是哪一类任务」。这一点厂家从不会主动说，采购时要问。
酷哇给这套东西起了个名字：RoboCity，机器人城市。说法是不同形态的机器人共享「物理—社会」统一世界模型，成为一张 Physical Agent 网络。
这个愿景在逻辑上成立：城市服务本来就是多形态分工——人行道要小的、辅道要窄的、主干道要快的、楼宇里要能上台阶的。一个底座统一调度，理论上能减少重复建设。
但城市服务的采购单位不是「网络」，是「街区」。
一个街道办买的是「这条路上每天扫两遍」，不是「接入一个智能体网络」。判断：RoboCity 这类叙事在资本市场上好用，在招标文件里没用。招标文件里只会写：作业面积、作业频次、验收标准、故障响应时间、单价。
所以这类公司的真实考验不在发布会，在两件事上：一是单条街区的单位经济能不能算正（人机配比、充电点位、故障率），二是跨街区复制时，模型要不要重新标数据。
第二件事就是本文开头那个问题的商业版本：如果每进一个新城市都要重采一轮数据，那「一脑」的规模效应就不成立，它只是一套更好用的工具。
最后说一句公道话。这家公司选择「端侧 + 多形态 + 城市服务」这个组合，本身是有判断力的：城市服务是少数几个「任务重复、路线固定、客户是政府或物业、付费能力稳定」的场景，比家庭场景现实得多，也比工厂场景更容忍慢一点的速度。
D2 定在 2027 年发布，说明它自己也知道配送这条线还没到能卖的时候。判断：一家公司愿意把一条产品线的上市时间推到两年后，通常说明它对当前这条线的现金流有信心。这比任何参数都更像一个成熟团队的做法。