Swiggy开放MCP接口，允许外部AI代理直接下单订座

Swiggy正致力于将其商业服务向外部AI代理开放，使用户能够透过AI助手，在Swiggy应用之外完成美食发现、购物车构建、下单及餐厅预订等操作。

在Inc42首届“2026 CTO峰会”上，Swiggy首席技术官Madhusudhan Rao阐述了这一策略的核心：不再假设每位用户的购物旅程都始于应用内，而是让服务对AI代理原生开放。

目前，Swiggy已部署四个模型上下文协议（MCP）服务器，作为AI工具与其服务交互的连接件。这些服务器包含66种工具，覆盖食品外卖、Instamart即时零售、Dineout餐饮预订及Scenes业务，功能涵盖发现、菜单浏览、购物车管理、下单、预订及订单追踪。

该策略允许外部AI助手处理用户请求，并直接调用Swiggy的商业基础设施执行操作。Rao举例表示，用户可将Swiggy的MCP连接至任意大型语言模型（LLM），询问如何根据饮食计划规划膳食。“今天，你可以使用你选择的任何LLM配合我们的MCP来实现这一点，”他说。

此举旨在满足那些通过应用内固定功能难以覆盖的个人偏好。Swiggy不再为每种用例构建独立界面，转而提供易于被其他服务、人类或代理调用的核心能力。

在向外部开放的同时，Swiggy也在重构内部AI系统，以降低对单一模型的依赖。Rao透露，公司此前曾围绕某一特定模型构建客服代理，当该提供商出现容量限制时，迁移耗时近一个月。

这一经历促使Swiggy投资于模型评估与实验系统，确保在不重建整个工作流的情况下轻松更换模型。“将模型视为可替换项，重点投资于工作流和评估体系，”Rao指出。

目前，Swiggy利用LLM网关将任务分发至不同模型，并在实时运营中测试替代方案。系统跨云提供商运行，并根据可用性、响应时间和成本动态选择模型，旨在保留AI任务系统架构的同时，允许执行模型灵活变更。

针对AI代理开放带来的安全疑虑，Swiggy采取了严格的隔离措施。代理被部署在具有受限访问权限的独立环境中，而非与核心生产服务并列。

“我们实际上是将它们部署到类似生产的独立架构中，但设有非常严格的入站和出站规则，”Rao表示。这些控制措施限制了代理运行环境中数据的进出，公司也在同步处理代理身份、权限和信任等问题。

在内部应用方面，Swiggy利用AI辅助新配送合作伙伴入职。内置助手以当地语言引导骑手完成全流程。Rao称，该助手提升了骑手的净推荐值（NPS）和入职漏斗效率，但未披露具体数据。