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

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

在结构化场景（比如工厂车间）内，机器人落地已经十分成熟，但一进入开放环境（比如城市马路），难度就完全不一样了。尤其是在城市户外环境中，机器人需要






7×24小时不断电地干活，这就要求它必须经得住风吹日晒和人来车往。

中国信息通信研究院的《具身智能发展报告》把现状概括成了一句话：数据、模型、本体、场景难闭环。但毫无疑问的是，





2026





年的具身智能已经开始从技术验证期迈向场景落地期，






而城市服务，正在成为检验一切落地能力的重要考场。

面对这一现状，以






“具身智能服务






城市






开放场景






”为目标的库萨科技做了一个清晰的选择：把数据采集、模型训练、机器人部署的全栈工程一并打通，让机器人在真实世界里先跑起来，并且保证能够跑得稳。在库萨的判断里，填平规模化落地的鸿沟，研发和工程化






能力






必须同时过硬。

库萨成立于





2023





年，核心团队来自清华、上海交大






等高校，核心成员拥有






15年的整车、机器人与自动驾驶研发与管理经验






，






核心产品是面向






城市开放






场景






的服务机器人，产品已经在超过





40





座城市落地运营。

在今年





7





月中旬，库萨科技发布了一套具身智能开发平台






Kusa Robo Platform






。平台定位很明确，






即






一套专为城市级具身智能部署打造的工程化平台，从数据采集、模型训练到多端部署、远程运维，形成了全栈闭环。






作为少数真正走进这个考场的公司，






库萨想要以此回答一个行业里没人能说清的问题：

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

城市级具身，为什么难？

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

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

最本质的区别






在于






评价方法的变化。同一个场景下，一台乘用车的任务是从





A





到






B






，不撞、体感好就算成功。而一台城市环卫机器人可能是反过来，它要主动去跟各种东西发生接触，做出判断。

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

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

库萨科技联合创始人兼






CTO






陶圣告诉






36






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

为什么偏偏选城市场景？

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

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





1%





，是一个尚待开发的蓝海。

做起来很难






，






但回报






却






很明确的生意，也是一件值得长线技术投入的






“






难而正确的事






”






。这种门槛，决定了城市级具身智能需要一套专用的工程平台






，






库萨的回答就是






Kusa Robo Platform，这需要先从三块核心技术说起。

底座、燃料和大脑

这次发布






的三块核心技术，各自分工明确。

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





、数据飞轮、全模态融合的耦合深度，再乘以城市场景的时间积累，形成了全栈协同的系统性优势，为库萨这家公司构筑了独特的护城河。

跑通了吗？

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

目前，库萨的具身智能产品已经部署到了





40





多个城市里。从增速看，三年的时间从






0






起步，交付规模连续以数倍甚至数十倍的速度扩张，如此陡峭的爬坡曲线，在这个细分赛道里还没有第二家。

在中大型开放道路场景，库萨已经






进入






跑通商业模型、产生实际作业价值的常态化运营阶段。但陶圣紧接着就开始






“






降温






”






：

从存量看，规模化问题






还






没有






完美解决






。场景泛化能力还要






增强






，硬件还没经过






极端天气






考验，产能从单线





500





台爬到






5000






台的里程碑，也还






在






进行中






。

他的原话很直白，对于行业来说分量也很重：






“






没有验证之前，都还是打嘴炮。






”

这是






因为量产爬坡从





0





到






1






是突破，






1






到






100






是突破，






100






到






10000






也是突破，每个阶段面对的问题都不一样，很多时候说不清哪个阶段






“






更难






”






。

唯一可以确定的是，在这条坡道上，技术迭代一定是被真实需求推着走的






——真实世界里的长尾场景，永远比预设的多






。

第一个有说服力的场景，是一根






“






不起眼






”






的鱼竿。

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

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

第二个案例则是






“






书包旁的纸与铅笔






”






。

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

无论是识别一根鱼竿，还是理解一个放学场景，这些迭代之所以能快速发生、快速部署到机器人体内，背后靠的






是






Corner Factory的数据飞轮，和





Kusa Robo Platform





的通用型。

长尾场景之外，平台还要跨得住形态的切换。






平台通用性最硬的证据，是一脑管理多形。同一套栈，短期内就从轮式机器人切到了双轮足式，机械臂控制也从一个轮式车型上的





2





到






3






个自由度，平滑扩展到多自由度。换句话说，平台不会被某一种机器人形态锁死。

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

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






“






肌肉记忆






”






。

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

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

OS





底层枯燥、迭代慢、目前已经基本够用，






而






大模型正在回归数学本质，开始引入物理和数学的硬约束，比如用流体力学描述物理概念嵌入世界模型，让





3D





空间理解成为共识。

具身智能的





OS





不会像手机那样一家独大，机器人场景的碎片化程度远超手机和






PC






，最后大概率是






“






多家分天下






”






。

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

（来源：智能涌现）