把机器人当作一台可调用的服务器，这个想法在纸面上存在很久了。11 月 11 日，Serve Robotics 把它变成了一个开发者门户。
开放了什么
公司上线 AV Delivery Developer Portal，让开发者、企业、爱好者乃至 AI 助理，可以通过公开 API 以编程方式调用其人行道配送机器人。同时提供一个沙盒环境，供任何人在接入真机之前构建与测试应用。
接入方式被刻意做成「像调任何 API 一样」：应用或 AI 助理发起取件与送达请求、确认细节、跟踪机器人直到配送完成。调度、路径规划、导航与远程监管由 Serve 负责——开发者不必理解机器人怎么过马路。
限制也很明确：配送范围限于 Serve 的活跃服务区域与营业时间，物品必须能装进机器人的货舱。
为什么这件事不寻常
机器人行业的开放历来停在 SDK 层：给你一套控制接口，你自己造场景、自己运维。真正开放「机队」的很少，因为机器人是有物理实体的资产，一次事故的代价远高于一次接口超时。
Serve 的做法是把风险留在自己这边：调度与远程监管由它承担，开发者只负责发起任务。这个分工让「用机器人」的门槛降到了「会写几行代码」。
公司 CEO Ali Kashani 的说法是：你不应该为了用机器人做点有用的事，就去创办一家机器人公司；他们已经花了几年解决机器人如何在社区里导航，而住在那里的人有他们没想到的需求。
家底
Serve 2021 年从 Uber 分拆，总部在加州红木城，设计并运营在人本环境中自主导航的机器人。公开数据：在美国与澳大利亚部署超过 2000 台机器人，触达约 300 万人口，服务 4000 多家餐厅；系统已在 20 个美国城市、150 多个社区完成数十万次配送。
今年早些时候，它收购了医院服务机器人公司 Diligent Robotics。上周还推出了 Serve Physical AI Services，把支撑自有车队的技朮开放给做新型机器人的公司。
关键转折：从「平台专供」到「任何人可调」
过去，Serve 的机器人只能通过第三方配送平台调用——用户在外卖 App 下单，平台派单给机器人。这意味着机器人是平台的运力，Serve 拿到的是订单，不是开发者。
现在开放 API，等于把自己变成一层基础设施：任何本地商家、任何应用、任何 AI 助理，都可以直接调度机器人。这与其说是技术服务，不如说是渠道革命——从「给平台打工」变成「给所有人供水」。
对 AI 助理来说，这是个有象征意义的接口。过去代理只能在数字世界里操作（订票、发邮件、查资料），现在可以发起一次物理世界的配送。这也是「物理 AI」从概念走向接口的一步。
沙盒的意义
沙盒是这项服务里最务实的设计。开发者可以模拟机器人、跑配送流程、演练边界情况（比如收件人不在、地址错误、货舱超限），确认逻辑没问题再申请接入真机。真机访问需要 Serve 审批。
这个「先沙盒、后真机」的两段式，与云服务商的思路一致：把试错成本降到零，把物理风险留到最后一步。对机器人行业来说，这是必要的谨慎——软件崩溃可以重启，机器人撞人可以上新闻。
商业模型与隐忧
收入模型目前没公开细节，但可以推测三层：按次配送的服务费、面向企业的平台接入费、以及数据与调度能力的增值服务。
隐忧有三。一是密度经济：机器人配送的成本优势依赖单区域的高订单密度，开放 API 会带来分散的、低频的请求，可能拉低效率。二是责任归属：第三方开发者发起的任务出了问题（比如送错、延误、货损），责任在平台还是开发者，需要合同厘清。三是安全边界：机器人进入更多场景，意味着更多不可预见的交互，远程监管的人力成本会上升。
对行业的启示
过去两年，具身智能的叙事集中在「机器人什么时候能干活」。Serve 这条路径给出了另一个答案：先不追求通用，把一件小事（人行道短途配送）做到可规模化，再把能力做成接口卖出去。
这与云计算的历史相似：最早的基础设施不是通用计算机，而是标准化的、边界清晰的算力单元。机器人要变成基础设施，也得先找到那个「边界清晰的小事」。
对国内做配送机器人的公司，这套模式值得研究。国内在末端配送的落地规模更大，但开放程度更低——多数厂商仍以整机销售或项目制交付为主。谁能先把「机队即服务」的接口做成标准，谁就可能拿到下一层的位置。