Serve Robotics 开放配送 API：先用沙盒测试，真实车队访问仍需批准

Serve Robotics 开放了开发者门户，让应用和 AI 助手通过接口请求人行道机器人配送。开发者可以先进行模拟配送，但沙盒集成成功，并不意味着获准调度公司的真实车队。

Serve 的正式发布公告日期为 2026 年 11 月 11 日；作为本文线索来源的 The Verge 报道发表于 11 月 10 日。这一变化为既有运营网络开放了软件接入方式，此前该网络通过第三方配送合作伙伴提供服务。Serve 仍负责调度、路线规划、导航和监督。

Serve Delivery API 指南描述了三个步骤：获取报价、据此创建任务，以及跟踪任务直至完成。沙盒使用模拟机器人，无法派出真实配送机器人。因此，团队可以在业务依赖服务之前，检查故障处理方式。

指南给出了一项明确的时间限制：报价五分钟后失效，而且只能使用一次。应用不应将用户刚打开购物车时取得的报价，当作之后结账时仍长期有效的承诺。文档还将 couriers_busy 列为正常的运力不足响应，因此团队需要主动决定是重试、排队，还是改用其他配送方式。

进入生产环境需要支持的服务区域、单独的生产密钥，以及授予该账户的车队访问权限。指南称，合作伙伴注册暂不支持自助开通。公司公告还将配送限定在运营区域和时段内，物品必须装得进货舱。开发门户开放，不等于任何地址和包裹都符合条件。

对商家而言，有用的试点应从获批取货点跟踪一笔真实订单，直至符合条件的目的地，并检查没有可用配送机器人时员工和顾客分别会看到什么。将机器人配送列为结账选项前，应确认当前服务条款及真实访问权限。仅凭发布公告，无法确定某条路线的配送成本或可靠性。

如果 AI 助手可以发起订单，应先规定它有权批准哪些动作，以及何时需要人工确认。TechKili 关于 Railway 与 Primcloud 代理争议的报道提供了自动执行前界定权限的背景；那是另一个案例，并非 Serve 存在问题的证据。

这一门户也不同于 11 月 5 日发布的 Physical AI Services，后者向机器人开发企业提供技术和数据服务。新的配送接口面向使用 Serve 运营车队的团队。明确这一区别，团队就能分别评估接入现成运营服务的集成项目与开发自有机器人的项目。

相关文章