城市服务，成为了具身智能的新考场？

具身智能，在城市服务里补上了“全栈”这块硬骨头。

同样一台机器人，如果把它放在工厂车间和城市马路上，它面对的实际上是两个世界。

在结构化场景（比如工厂车间）内，机器人落地已经十分成熟，但一进入开放环境（比如城市马路），难度就完全不一样了。尤其是在城市户外环境中，机器人需要7×24小时不断电地干活，这就要求它必须经得住风吹日晒和人来车往。

中国信息通信研究院的《具身智能发展报告》把现状概括成了一句话：数据、模型、本体、场景难闭环。但毫无疑问的是，2026年的具身智能已经开始从技术验证期迈向场景落地期，而城市服务，正在成为检验一切落地能力的重要考场。

面对这一现状，以“具身智能服务城市开放场景”为目标的库萨科技做了一个清晰的选择：把数据采集、模型训练、机器人部署的全栈工程一并打通，让机器人在真实世界里先跑起来，并且保证能够跑得稳。在库萨的判断里，填平规模化落地的鸿沟，研发和工程化能力必须同时过硬。

库萨成立于2023年，核心团队来自清华、上海交大等高校，核心成员拥有15年的整车、机器人与自动驾驶研发与管理经验，核心产品是面向城市开放场景的服务机器人，产品已经在超过40座城市落地运营。

在今年7月中旬，库萨科技发布了一套具身智能开发平台Kusa Robo Platform。平台定位很明确，即一套专为城市级具身智能部署打造的工程化平台，从数据采集、模型训练到多端部署、远程运维，形成了全栈闭环。作为少数真正走进这个考场的公司，库萨想要以此回答一个行业里没人能说清的问题：

为什么具身智能规模化落地，做好专用平台才是关键？

01. 城市级具身，为什么难？

自动驾驶团队转型做机器人，几乎一开始都以为只是需要把二维问题升到三维。

库萨的团队一开始也这么想。从平面提到空间，难度好像不大，但真正扎进场景才发现，基准实际上完全变了。

最本质的区别在于评价方法的变化。同一个场景下，一台乘用车的任务是从A到B，不撞、体感好就算成功。而一台城市环卫机器人可能是反过来，它要主动去跟各种东西发生接触，做出判断。

比如，马路上一个鼓鼓囊囊的黑色塑料袋，里面到底是砖头、装满水的矿泉水瓶，还是空瓶子？实际需要的处理方式天差地别。对于自动驾驶来说，碾过去或者绕开就行，环卫机器人得尝试去扫，扫不动再决定怎么办。因为环卫的硬指标是把垃圾扫干净，看到东西就绕开等于根本没干活。

评价方法变了，背后藏着一个被低估的维度和难点：物理交互。

库萨科技联合创始人兼CTO陶圣告诉36氪，自动驾驶不太关心接触力学，是因为汽车行业已经有多年积累，底盘“早就做好了”，城市服务机器人却必须得做到，把末端清扫结构的力矩反馈、旋转控制跟整车控制完全耦合。从“车”到“机器人”的跨越，区别就在于这里。而要处理好物理交互，光靠传感器不够，还得让模型理解物理世界本身。

02. 为什么偏偏选城市场景？

陶圣表示，核心判断在于看到了真实且迫切的需求：

城市空间复杂度高、技术壁垒强，同时能直接产生可落地的商业化价值，是验证具身智能工程化能力最合适的土壤。更关键的是，城市服务机器人行业的市场渗透率很低，还不足1%，是一个尚待开发的蓝海。

做起来很难，但回报却很明确的生意，也是一件值得长线技术投入的“难而正确的事”。这种门槛，决定了城市级具身智能需要一套专用的工程平台，库萨的回答就是Kusa Robo Platform，这需要先从三块核心技术说起。

03. 底座、燃料和大脑

这次发布的三块核心技术，各自分工明确。

Kusa OS是面向城市级具身智能的专用操作系统，管机器人的稳定运行和实时调度；Corner Factory是数据工厂，负责从数据里自动挖掘、清洗、标注长尾场景；Kusa Omni-CTS是全模态具身模型，负责从场景感知、认知理解到动作输出的完整链路。三块技术回答的是同一个问题：机器人怎么在城市里跑得稳、学得快、懂场景。

Kusa OS首先解决的问题是“跑得稳”，这套操作系统的起点要追溯到2018年，库萨核心团队当时还在做码头无人驾驶。

ROS2是机器人圈最主流的开源软件框架，设计上重视灵活性和易用性，方便研究者快速跑通新算法，但代价是硬实时性不够，会有不可预期的延迟和抖动，在长期稳定性和实时性要求非常高的城市服务场景中有潜在风险。

这也是库萨从底层自研Kusa OS的核心原因。

与城市服务一样，码头场景也需要7×24小时不断电运行，对长期稳定性和实时性要求非常高。库萨从场景真实需求出发，基于数据分发技术从头自研了一套系统，核心思路是让系统更加精简，每个模块都严格可控。系统更小，就能更稳定。

在长期迭代的过程中，它为行业解决了三件事：长期稳定性、确定性调度，以及时延抖动压缩。

不过，过去几年里自研OS的代价也是实打实的。

“到现在我都依然在纠结”，陶圣这么形容。最大的挑战是工具链不完备，ROS2社区原本有大量开源贡献，覆盖了从实时可视化监测，到机器人动力学仿真，再到世界场景重建的全链路，但自研就全都要自己建。库萨的解法是另起炉灶，做一套编程工具链，用描述性语言自动生成初始化代码，让迁移成本尽量低。

自研支付的代价，终于换来了底层的自由度和实时稳定度。

如果说OS是底座，那么Corner Factory就是燃料，因为它解决了“持续学”的问题。

库萨的数据飞轮“跑通”体现在，公司第一个量产产品落地的时候，整套管线就已经打通了，现在自动标注的占比也从早期的80%提升到了90%以上。

根据陶圣的介绍，一条完整的数据链路是这样运转的：机器人在作业中遇到异常触发停车，自动保存前后若干秒的多传感器数据，回到作业站点后由专门的数据采集器传回数据工厂。先完成人脸、车牌等脱敏，进入自动标注，从早期的2D分割分类，升级到3D占用网格和三维重建。人工做最后的修补和确认，再由专用模型筛选哪些是真正值得学习的长尾场景，入库后喂给模型训练。

在Corner Factory中，Kusa Omni-CTS基于单帧真实场景输入生成时序视频流，并从中同步派生3D点云及OCC语义占用。Kusa Omni-CTS将OCC/3D点云确立为核心中间表征，在二维观测与三维结构间构建物理级空间约束，确保空间理解的准确性，支撑数据闭环的高效运转与模型周级迭代。

但陶圣也直言：“数据飞轮或者管线并不是壁垒，数据才是真正的壁垒。因为数据跟场景极相关，没见过就是没见过，不可能靠工程师脑补。数据飞轮带来的先发优势，本质上需要用时间乘以量。”

最上层的Omni-CTS作为大脑，解决的是让机器人“懂场景”的工程化难题。

陶圣解释，库萨模型的“第一性原理”是：难点不在某个具体技术，在思维方法的转变。他甚至自嘲：“我们就是个缝合怪”。但缝合不是拼凑，是把视频生成、时空编码、3D Gaussian等不同领域的前沿思路，拼成一套原创的解法。

工程化领域有个更准确的说法，这是模型结构的创新——它突破了模型异步输入的难点。

核心问题也很具体。在真实的机器人上，多个传感器天生就对不齐。比如激光雷达10赫兹、相机30赫兹、IMU可能1000赫兹，数据来的节奏完全不同。强制同步要么等待卡顿，要么产生矛盾，模型性能就会直接大幅往下掉。

Kusa Omni-CTS要解决的就是这个问题，它的解法分了两层：

第一层，是跨模态异步特征对齐。摒弃传统离散帧对齐，在高维隐空间构建连续时空曲线，视觉、激光、IMU、力矩反馈各按各的节奏采集，进入模型后自动“对表”，让数据自然流动，不再依赖昂贵的硬件同步。

第二层，则是物理一致性预测——这正是对“物理交互”难题的回应。在高维空间构建符合物理动力学的连续轨迹，模型不仅能理解当前发生了什么，还能基于物理规律和环境变化，提前推测接下来可能发生的种种状况，再选择最合理的执行方式。

Kusa Omni-CTS模型结构图：基于连续时空预测的全模态模型

从硬件角度来说，这套设计的硬件变更其实不多，但它解决了时间抖动时模型能力大幅下降的问题。在具身领域，多模态融合才是最终的解决方案，既有上限，也能兜底。

对库萨来说，研发和工程化从来不是两件事。单有研发，落不了地；单有工程化，守不住技术门槛。库萨选择把这两件事放在同一张桌上做。Kusa Omni-CTS的结构创新、自研OS的底层重构，背后都是实打实的研发功底；而OS、数据飞轮、全模态融合的耦合，又把研发成果变成了跑得稳、学得快的工程系统。可以说，研发是库萨的基本功，而工程化则是它的杀手锏。

三块技术合起来，形成了一个认知进化的闭环。往深一层看，每一个单点技术都有可能在短期内被复制，但OS、数据飞轮、全模态融合的耦合深度，再乘以城市场景的时间积累，形成了全栈协同的系统性优势，为库萨这家公司构筑了独特的护城河。

04. 跑通了吗？

既然上文提到这是一场考试，那么更重要的是成绩如何。

目前，库萨的具身智能产品已经部署到了40多个城市里。从增速看，三年的时间从0起步，交付规模连续以数倍甚至数十倍的速度扩张，如此陡峭的爬坡曲线，在这个细分赛道里还没有第二家。

在中大型开放道路场景，库萨已经进入跑通商业模型、产生实际作业价值的常态化运营阶段。但陶圣紧接着就开始“降温”：

从存量看，规模化问题还没有完美解决。场景泛化能力还要增强，硬件还没经过极端天气考验，产能从单线500台爬到5000台的里程碑，也还在进行中。

他的原话很直白，对于行业来说分量也很重：“没有验证之前，都还是打嘴炮。”

这是因为量产爬坡从0到1是突破，1到100是突破，100到10000也是突破，每个阶段面对的问题都不一样，很多时候说不清哪个阶段“更难”。

唯一可以确定的是，在这条坡道上，技术迭代一定是被真实需求推着走的——真实世界里的长尾场景，永远比预设的多。

第一个有说服力的场景，是一根“不起眼”的鱼竿。

库萨从市政道路往公园、园区、景区等更靠近人的场景走，有时候会碰到钓鱼的人把鱼竿支在那儿，一两厘米粗、孤零零一根。团队以前做的是地面分割，检测水管电线，从没想过空中会有这么细的东西，只能重新采数据训练。

陶圣从中收获了一个感悟：在规模化落地之前，大部分技术迭代都是为了针对突然发现的场景，团队不可能一开始就预设到所有问题，这是一个慢慢发现的过程。

第二个案例则是“书包旁的纸与铅笔”。

傍晚，机器人看到书包、纸笔，旁边有学生在跑。靠这幅画面的语义理解，它能判断前方奔跑的学生可能是文具的主人，书包和文具都属于临时存放，选择不清扫；第二天，书包和人都不在了，同样的一张纸，就会被判定为遗留垃圾。这个场景判断的实现，靠的是大模型对整张图片的语义理解能力，能把人、物、时间、空间关联起来。

无论是识别一根鱼竿，还是理解一个放学场景，这些迭代之所以能快速发生、快速部署到机器人体内，背后靠的是Corner Factory的数据飞轮，和Kusa Robo Platform的通用型。

长尾场景之外，平台还要跨得住形态的切换。平台通用性最硬的证据，是一脑管理多形。同一套栈，短期内就从轮式机器人切到了双轮足式，机械臂控制也从一个轮式车型上的2到3个自由度，平滑扩展到多自由度。换句话说，平台不会被某一种机器人形态锁死。

跨形态适配的难点在本体动力学差异和控制矩阵差异，库萨的解法是硬件抽象层，把力矩、角度、圈数统一抽象成上层算法看不见的量，再由底层运动学模型转换成可执行的指令。

陶圣打了个比方，就像人游泳时不会刻意去想手怎么打水，动作会慢慢变成肌肉记忆；一脑管理多形的奥秘也在于此，大模型管顶层思维，底层小模型负责具体的执行和“肌肉记忆”。

未来平台进化最大的空间在哪？

陶圣给出的回答很明确：还是在大模型。

OS底层枯燥、迭代慢、目前已经基本够用，而大模型正在回归数学本质，开始引入物理和数学的硬约束，比如用流体力学描述物理概念嵌入世界模型，让3D空间理解成为共识。

具身智能的OS不会像手机那样一家独大，机器人场景的碎片化程度远超手机和PC，最后大概率是“多家分天下”。

而在行业终局到来之前，库萨要做的，就是让城市服务机器人在更多纵深的场景里开箱即用，成为可靠、持续、可规模化的生产力伙伴，让城市的智慧运转变得更加高效、有韧性。