城市级AI服务从试点到常态化，机器人入口如何流转？

当一家公司不再只展示机器人“能跑起来”，而是开始公布真实运营里程、落地城市数量、任务场景和盈利能力时，行业关注点就会发生变化。对 App 开发者、产品经理和增长负责人来说，这条新闻真正值得盯住的，不只是具身智能又进了一步，而是城市服务中的任务、系统和终端正在进入新的【多端流转】阶段。

新闻与环境拆解

酷哇把“机器人能力”讲成了“城市运营能力”

在 2026AI Partner·北京亦庄 AI+ 产业大会上，酷哇科技联合创始人、COO 李柯宏围绕“城市级AI服务：从试点到常态化，机器人的实景作战与规模化落地”做了公开分享，核心主题并不是单个产品发布，而是如何在全时空城市场景中实现机器人的规模化部署。据 36氪对该场演讲的整理，酷哇将自己的定位描述为“以统一世界模型驱动的具身智能企业”，并提出依靠真实运营数据推动模型持续进化的路径。城市级AI服务：从试点到常态化，机器人的实景作战与规模化落地 - 36氪

这一定义很关键。过去机器人公司更容易从“硬件能力”“自动驾驶级别”或“算法亮点”切入，但酷哇这次更强调“世界模型 + 一脑多形 + 多场景部署”的体系化叙事。换句话说，它不只是想证明某一类机器人已经可用，而是试图证明一套面向物理世界的统一能力，已经可以在环卫、出行、即时配送、物业、家庭等场景中持续复制。

从 2023 年开始，具身智能的讨论重心已经变了

在演讲中，李柯宏提到，2023 年是大语言模型和具身智能演进的一个关键分水岭。此前行业里更常见的是分模块架构或端到端机器人架构，而 2023 年之后，基于生成式 AI 的世界模型开始成为新方向，其能力不只在于看见环境，还在于基于观测生成未来动作预测，并把物理因果关系嵌入决策链条。

这一变化与行业整体趋势是吻合的。过去两年，中美头部 AI 公司持续把世界模型、物理世界推理和实体任务执行作为重点议题，场景覆盖机器人、智能驾驶和视频生成。换句话说，行业主轴已经从“模型会不会说”转向“模型能不能在现实世界持续完成任务”，而城市服务恰恰是这种能力最容易被验证、也最容易被放大的地方。

酷哇的核心打法，是“以战养战”

在这次分享中，酷哇给出的最核心表达，是“以战养战”。简单说，酷哇并没有把训练和运营割裂开来，而是让机器人先进入真实任务，再用任务数据回流模型。公开信息显示，酷哇构建了 CooWAIM（World-Action Interactive Model）通用世界模型，以“一脑多形”的架构驱动不同机器人本体，覆盖环卫、出行、即时配送、物业、家庭五大核心场景，其中前三个已进入规模化或快速 POC 阶段。

这个路径背后的现实逻辑也很清楚：具身智能最大瓶颈之一是数据，而数据的前提是量产和运营。没有足够多真实终端，就没有足够多真实动作数据；没有真实动作数据，模型就难以持续迭代。酷哇给出的回答不是先等终极模型成熟，而是先让机器人在真实工作里“干起来”，再把作业过程变成训练资产。

双系统架构背后，不只是算法结构，更是任务结构

从演讲内容看，酷哇的模型采用双系统架构：一套是直觉行动系统，负责端侧视觉推理和当下安全效率；另一套是长程任务推理系统，负责更高层的语义理解和全局规划。两者叠加后，对外映射为两类具身能力域：Drive 和 Work，也就是全域移动与多关节协作操作。

这个拆法很适合从产品视角理解。以前很多团队把机器人看成“会移动的设备”，但在城市服务里，移动只是任务的一部分。真正复杂的是移动、识别、执行、交互、通知和回传同时发生。比如环卫机器人需要在复杂人行道环境下贴边清扫、识别垃圾、调度风机模组；配送机器狗需要在末端履约里完成路径识别、楼栋寻址、电梯识别和到达通知。这些动作不是孤立功能，而是一条连续任务链。

规模化的关键数据，已经不是概念演示能解释的了

酷哇在这次分享中给出了一组很有代表性的规模数据：全系列产品已经在全国 50 余个地区落地，累计真实里程达到 5500 万公里，并收集到 1000 万条视频—语义—动作对齐 clips。相关整理稿还提到，基于“以战养战”的经营策略和万台级机器人的部署，公司目前每年能够实现大几个亿的利润流入。

即便把公开表述中带有企业视角的乐观成分考虑进去，这组信息仍然足够说明一个趋势：城市级机器人正在从“试点、参观、展示”走向“持续运行、真实履约、反哺模型”。相比之下，酷哇官网此前披露的口径是“在全球超过 50 座核心城市及地区实现规模化常态运营，累计运行超 4500 万公里”，这也从侧面说明其最近一次对外分享中的数据是沿着同一轨迹继续增长的。酷哇科技官网关于我们

为什么环卫、出行、配送会先跑出来

如果只看想象空间，家庭机器人和通用家务助手更容易成为舆论焦点；但如果看商业化节奏，先跑出来的往往是环卫、出行和配送。原因并不神秘：这些场景的任务边界更清晰、价值更容易量化、需求频次更稳定，而且可以在大规模真实环境下持续采集数据。

酷哇的案例也在验证这一点。环卫场景里，机器人在高峰时段过路口时需要实时处理大量动态特征，并根据未来轨迹预测来生成自适应通行策略；配送场景里，真正耗时的不一定是主路骑行，而是进小区、找门牌、识别电梯和完成最后一百米履约；无人小巴则在特定城市和区域内承担接驳任务。每一个场景的共同点都是：价值来自连续任务执行，而不是单次演示动作。

“从试点到常态化”最重要的，不是更多机器人，而是更稳定的系统

很多报道喜欢把“50 多个城市”“5500 万公里”“1000 万 clips”当作规模化证明，但真正更值得关注的是另一层变化：系统正在从围绕设备运转，变成围绕任务运转。机器人只是承担执行的载体，背后真正被拉长的是任务链路、数据链路和系统链路。

一旦进入常态化阶段，机器人业务就不再是简单的“设备上岗”，而会变成“任务发起—系统分发—终端执行—结果回传—数据训练”的长期闭环。也正因为如此，这条新闻看起来是机器人产业动态，实际上已经和 App 产业里的入口管理、参数透传、全链路归因和渠道辨识发生了直接关联。

从新闻到用户路径的归因问题

普通人看到的是机器人，开发团队看到的应该是链路

大众看这类新闻，首先会被“无人小巴”“机器狗送货”“环卫机器人上岗”吸引，这是典型的技术落地叙事。但如果站在开发者和增长团队的视角，最值得追问的问题不是机器人炫不炫，而是这些任务到底从哪儿发起、经过哪些系统、在哪个终端被接住、如何回传到上游平台。

这就是【多端流转】真正复杂的地方。城市级 AI 服务不只涉及机器人本体，还会连接商户系统、调度平台、物业平台、履约引擎、短信与电话通知、用户侧 App 或小程序，甚至是后台运营端。用户看到的是一个结果，系统内部经历的却是多个入口、多类身份、多段调用和多次状态切换。

用户路径不再是“点击—安装—打开”这么简单

传统移动增长路径里，最经典的模型是：曝光、点击、下载、安装、首启、注册、转化。但在城市级 AI 服务场景里，这套路径明显不够用了。比如一笔配送任务，可能先由商家系统发起，再经由配送编排系统路由给机器人，随后通过物业系统完成楼宇通行，再通过短信或电话通知用户，最后把履约结果回传给上游平台。

这意味着很多原来被归为“用户路径”的动作，已经变成了“任务路径”。在这种结构里，人物流量仍然存在，但更值得关注的是任务流量：谁发起了任务，任务在哪个入口进入系统，任务中途是否换端，哪些节点会丢上下文，哪些状态对结果影响最大。xinstall 在相关文章中也反复强调，AI 场景下需要把单纯的人物流量分析扩展到任务链分析，例如引入 task_id、workflow_id、agent_platform、channelCode、scene 等字段，才能在复杂链路中保留来源与上下文。亚马逊AI 战略升级？多云多Agent 时代App 该怎么认清流量真身

现有归因报表，最容易漏掉三类关键断点

第一类断点是入口断点。任务可能来自物业系统、商家后台、开放接口、合作平台或机器人运维控制台，但很多团队在埋点时只记录“任务已创建”，没有记录任务究竟由哪个入口触发，也没有把入口身份统一映射到可分析编号中。这样一来，量是看到了，来源却丢了。

第二类断点是终端断点。城市级服务天然跨端：后台、机器人端、运营端、用户手机端、短信与电话系统都可能参与同一笔任务。一旦系统之间字段不统一，某个状态变化就会只在单一系统里可见，无法回挂到同一条链路上。第三类断点是上下文断点，也就是参数丢失：任务的场景、意图、来源、优先级和风险等级只保留在源头，而没有随着链路往下传，最终让后续分析只能看到“任务完成了”，却不知道它为何被发起、为何以这种方式完成。

平台越来越强，黑盒也越来越厚

另一个现实问题是，平台化程度越高，黑盒就越厚。机器人企业、物业系统、城市服务平台、合作商户和用户侧应用之间，往往不是一个团队维护一整条链，而是多个团队、多个供应商、多个系统共同参与。每一个系统都能出报表，但这些报表未必能拼成一张完整的图。

这和多云多 Agent 场景的难题非常相似。xinstall 的相关分析提到，在复杂入口环境下，开发团队需要把“渠道”从传统广告位扩展到 Agent、工作流、平台入口和任务模板，因为如果不先定义统一入口身份，后续所有转化解释都会失真。亚马逊AI 战略升级？多云多Agent 时代App 该怎么认清流量真身 放到机器人场景里，这条原则同样成立：系统越来越聪明，并不意味着链路天然透明，反而意味着更需要主动重建可观测性。

工程实践：重构安装归因与全链路归因

渠道编号 ChannelCode：先把入口身份统一起来

问题在于，很多团队并不缺日志，而是缺一个统一的入口语言。物业系统用物业自己的编号，商户后台用订单来源字段，机器人平台用调度策略标签，短信系统又用自己的一套模板 ID。最后每个环节都能说明自己做了什么，但没人能回答“这一类任务到底从哪儿来、哪类入口质量更高”。

做法上，可以优先建立一套统一入口标识体系，把所有任务发起源抽象为可分析的渠道编号。例如把物业系统入口、商家系统入口、机器人运营后台入口、合作平台入口拆成不同 channelCode，再叠加 scene、task_type、entry_type 等字段。这样做的价值不是为了多一张报表，而是为了把不同系统里的任务收束到同一套口径中。xinstall 一直把渠道编号 ChannelCode视作多来源流量统一治理的基础能力，这套思路放到城市级机器人服务中同样成立。

带来的好处很直接：首先可以重新看清入口质量，不再把所有任务混成“自然流量”或“平台流量”；其次可以把城市、楼宇、合作方和任务类型拆开分析，找到高价值但被淹没的入口；最后还能为后续的策略调度打基础，例如不同 channelCode 对应不同 SLA、优先级或运营策略。

智能传参安装：把场景和意图跟着任务一起走

问题在于，很多任务的失败并不出在执行端，而出在上下文没有被完整带过去。上游知道这是哪类任务、服务哪个楼宇、优先级多高、是否需要人工兜底；可到了中间系统或终端系统，这些信息只剩下一串普通任务 ID，后续动作就失去了语义。

更合理的做法，是把参数透传视为任务链的基础设施。无论任务最终落在 App、机器人端还是运营后台，都需要让场景参数、来源参数和意图参数一起进入下游系统。xinstall 在《智能体分发时代App 安装传参逻辑的底层重构》相关讨论里强调的，本质就是“链接携参—安装—首启—参数还原”的连续性思维；放到机器人和城市服务里，同样可以迁移成“入口携参—任务分发—终端执行—结果回传”的结构。在能力层面，这与智能传参安装的思路是一致的。

带来的好处在于，团队不再只知道任务“发生了”，而能知道任务“为什么会这样发生”。比如同样是送货到楼，来自高客单价品牌专送与来自普通即时零售的履约策略可能不同；同样是物业任务，来自高密度小区与园区办公楼的调度逻辑也不同。参数不丢，分析才有意义。

参数还原与事件模型：把多端日志拼成一张任务图

问题在于，即便入口和参数有了，如果事件模型仍然沿用旧式移动增长口径，很多核心信息还是会丢。传统事件体系关注的是页面浏览、注册、登录、付费，但城市级 AI 服务更应该记录的是任务创建、任务分发、机器人接单、到达关键点、执行失败、人工介入、完成回传等状态。

做法上，建议把事件体系从“只围绕用户”扩展到“用户 + 设备 + 任务”三元结构。至少可以考虑把 task_id、workflow_id、channelCode、scene、risk_level、device_type、callback_result 作为基础字段，并让关键状态节点都能回挂到同一任务链上。这样一来，数据仓里看到的就不再是一堆碎片日志，而是一张可回放、可分析、可比较的任务事件图。

带来的好处，是开发、产品和增长终于可以用同一张图说话。开发能看接口状态和失败节点，产品能看任务路径和交互断点，增长能看不同入口与任务类型的转化质量。
注：本文探讨的部分复杂链路，属于对未来分发趋势的前瞻性技术延展与思考，例如跨平台任务编排、跨系统上下文回传和更精细的机器人任务归因。目前这类高度定制化链路未必全部对应现成标准化功能，若存在高阶业务需求，更适合结合具体系统架构做专项技术设计与验证。

这件事和开发 / 增长团队的关系

对开发和架构团队，优先做三件事

• 先把任务对象提升为一等公民，至少预留 task_id、channelCode、scene、entry_type、risk_level 这些字段，让不同系统能围绕同一任务说同一种语言。
• 重新设计埋点边界，不要只埋页面和用户动作，还要埋任务创建、任务分发、终端接收、状态变更、人工兜底和结果回传。
• 规划多终端 ID 策略，把用户 ID、设备 ID、机器人 ID、任务 ID 的关系理顺，避免后续出现“每个系统都能证明自己完成了工作，但无法证明这是同一笔任务”的情况。

对产品团队，重点是拿回入口定义权

• 不要只从“设备能做什么”定义产品，而要从“任务从哪里来、由谁触发、在哪个终端完成”来定义产品。
• 重新梳理所有入口，把物业、商户、运营后台、API、消息触达等入口拆分成明确类型，否则后续再精细分析也只是把混合流量分得更花。
• 在需求评审时提前要求“来源保留”和“参数透传”，别等链路跑通之后再补埋点，那时往往已经补不全了。

对增长和数据团队，重点是从人物流量切到任务流量

• 先区分两类流量：用户主动打开 App 形成的人物流量，与外部系统、调度平台或自动化工作流触发的任务流量。
• 报表上不要只看订单量、完成率和留存，还要看不同入口的任务质量、跨端成功率、参数还原率和回传完整率。
• 在策略层面，优先找到高价值任务源，而不是一味追求更多任务量。城市级服务的瓶颈常常不是“没任务”，而是“不知道哪些任务最值得做”。

常见问题（FAQ）

世界模型和过去的机器人架构，差别到底在哪？

从这次公开分享的表述看，世界模型的关键差别在于，它不只是对当前环境做识别，还会基于观测去预测未来动作，并把物理因果关系纳入决策链。简单理解，过去很多系统更像“看见后反应”，而世界模型更强调“理解环境后预判并行动”。

为什么酷哇反复强调“以战养战”？

因为具身智能要进化，需要大量真实数据，而这些数据很难靠纯仿真获得。酷哇强调“以战养战”，本质是让机器人先进入真实运营，再在清扫、接驳、配送、物业等任务中不断采集视频、语义和动作数据，用运营反哺模型。

50 多个城市、5500 万公里、1000 万 clips，意味着什么？

这组数字说明具身智能已经不只是展示层面的样板项目，而是开始进入持续运营阶段。真实里程和 clips 数量的增长，代表企业不只在卖设备，而是在通过持续任务执行积累训练资产、验证经济性和优化系统效率。

为什么即时配送里的最后一百米这么重要？

因为在末端配送中，真正消耗时间的往往不是主路运输，而是进楼、找门牌、识别电梯、完成到家通知这些高非结构化环节。酷哇在分享中提到，机器狗正是尝试解决这种“地图上没有、但履约里必须解决”的细碎难题，这些环节往往也是城市级服务最难标准化的地方。

行业动态观察

从行业位置来看，这条新闻的意义不在于又多了一家做机器人业务的公司，而在于城市级 AI 服务开始证明：真实任务可以成为模型训练、业务收入和系统优化的共同来源。过去大家把自动驾驶、机器人和城市服务看成不同赛道，但随着世界模型、任务编排和持续运营能力成熟，它们正在逐渐汇成同一条基础设施赛道。

对 App 和 B 端团队的中长期影响也已经很清晰。未来很多增长不再只来自页面、投放和应用商店，而是来自任务是被谁触发、在哪个系统被分发、在哪个终端被完成。只要业务开始穿过多个系统和多个设备，团队就不能再依赖单点报表解释全局，而必须重建入口、上下文和结果之间的关系。

真正的窗口期，恰恰出现在“规模开始形成、链路还没完全固化”的阶段。现在布局，团队还有机会统一字段、重构事件模型、建立入口编号和参数透传机制；等机器人、Agent 和自动化工作流全面接管更多任务之后，再回头补链路，成本会高得多。对很多开发和增长团队来说，这条新闻最现实的提醒就是：城市级 AI 服务的竞争，表面看是模型和机器人，底层拼的却是任务可观测性，而这背后绕不开【多端流转】。