WebMCP实战：MakeMyTrip如何用它重塑旅行预订体验

引言：AI Agent与Web应用的"标准接口"

当AI Agent逐渐从概念走向落地，一个核心难题浮出水面：智能体如何可靠地与现有Web应用交互？印度最大在线旅游平台MakeMyTrip的工程副总裁Dhananjay Kumar，在一次深度分享中给出了他们的答案——WebMCP。

在这次分享中，Dhananjay将WebMCP定义为"一个适配器（adapter），它让AI Agent能够以标准化的方式与任何Web应用进行交互"。这个定义看似简单，但背后指向的是当前AI Agent工程化中最棘手的痛点之一：交互的"猜测性"。

值得注意的是，WebMCP的设计灵感直接来源于MCP（Model Context Protocol）——由Anthropic于2024年底提出的开放标准协议。MCP借鉴了编程语言中LSP（Language Server Protocol）的设计理念：通过定义一套标准通信协议，让任何兼容的客户端（AI Agent）都能与任何兼容的服务端（工具/数据提供方）即插即用地协作。LSP最初由微软于2016年为VS Code开发，解决了编程语言工具与编辑器之间M×N的集成问题——在LSP出现之前，每种编辑器都需要为每种语言单独开发语法高亮、自动补全、错误检查等功能；LSP通过定义标准化的JSON-RPC通信协议，将问题简化为M+N。MCP将这一思想迁移到AI领域：每个数据源/工具只需实现一个MCP Server，每个AI应用只需实现一个MCP Client，即可实现普遍互操作。截至2025年初，已有数百个开源MCP Server实现，覆盖数据库、文件系统、API服务等多种场景。MCP定义了工具（Tools）、资源（Resources）和提示（Prompts）三类核心原语，让AI模型能够以结构化方式发现可用能力、理解调用参数并获取执行结果。WebMCP正是将这套设计哲学从后端API层延伸到前端Web应用层的一种实现，让网页本身成为Agent可编程的"能力提供者"。

告别"猜测式"交互：WebMCP解决了什么问题

DOM抓取的困境

Dhananjay直言，在没有WebMCP之前，让AI Agent操作网页更像是一场猜谜游戏。开发者不得不依赖DOM抓取（DOM scraping）和用户流程模拟（user flow simulations）——这些方法本质上是让Agent"猜"页面上哪个元素该点、哪个流程该走。

要理解这个困境的严重性，需要了解DOM的技术背景。DOM（Document Object Model）是浏览器将HTML文档解析后生成的树状结构，每个HTML标签都对应一个DOM节点。传统的网页自动化工具（如Selenium、Puppeteer）通过CSS选择器或XPath定位特定DOM节点来执行点击、输入等操作。然而，现代Web应用大量使用动态渲染框架（React、Vue、Angular等），这些框架采用虚拟DOM和组件化架构，页面元素的渲染由状态驱动而非静态HTML定义。CSS-in-JS方案（如styled-components、Emotion）会在构建时生成哈希化的class名称（如.sc-bdfBwQ），Shadow DOM封装使得外部选择器无法穿透组件边界，而Single Page Application的路由机制意味着页面切换不产生完整的HTTP请求。更复杂的是，A/B测试框架会动态改变页面结构，懒加载和虚拟滚动使得DOM节点随时创建和销毁。这意味着一个看似稳定的选择器（如.btn-primary-v2 > span:nth-child(3)）可能在下一次前端发布后完全失效，其生命周期可能短于一个sprint周期。对于拥有数百个页面、频繁迭代的大型平台而言，维护这些选择器的成本几乎与开发新功能相当。

这种方式脆弱且难以维护。网页结构一旦变动，基于DOM选择器的自动化逻辑就可能全面失效。WebMCP的价值，正是"把这种猜测彻底拿掉"（takes away that guesswork）。

工具注册机制：三步完成能力暴露

WebMCP的核心工作方式，是让开发者通过"模型上下文接口（model context interface）"来注册工具。据Dhananjay介绍，注册过程相当轻量，开发者只需要指定三个要素：

• 工具名称（tool name）
• 描述（description）
• 模式（schema）

这里的"模式（schema）"通常指JSON Schema——一种描述数据结构和验证规则的声明式规范，是IETF标准草案（截至2024年为Draft 2020-12）。JSON Schema提供了一种与编程语言无关的方式来描述JSON数据的结构：通过type、properties、required、enum、minimum/maximum等关键字，可以精确表达参数约束。在WebMCP的语境中，schema定义了一个工具的输入参数类型、必填项、取值范围等元信息。例如，一个"搜索航班"工具的schema可能声明需要出发城市（字符串）、到达城市（字符串）、出发日期（ISO日期格式）、乘客数（整数，最小值1）等参数。值得注意的是，OpenAI的Function Calling、Anthropic的Tool Use、以及Google的Gemini API都采用JSON Schema作为工具参数的描述格式——这种统一性意味着，一旦工具通过JSON Schema声明了接口契约，理论上任何支持该格式的LLM都能正确生成调用参数，无需额外的格式适配。这种声明式描述让AI Agent无需阅读文档或源码，就能通过解析schema自动生成正确的调用请求。这与OpenAPI/Swagger规范描述REST API的方式异曲同工，但面向的是Web应用的前端交互能力而非后端接口。

完成注册后，AI Agent就能够在需要时主动发现（discover）并调用这些工具。这意味着Web应用从被动等待被"抓取"，转变为主动向Agent暴露结构化的能力接口——这是一种范式上的转变。

测试自动化：从脆弱选择器到自然语言驱动

UI选择器的长期痛点

Dhananjay特别强调了WebMCP在测试模拟上的价值，这是一个容易被忽视但极具实用性的应用场景。

他坦言，MakeMyTrip长期依赖UI选择器来做测试，而这些选择器"时常不稳定（flaky at times）"。任何做过端到端UI自动化测试的工程师都能感同身受：测试用例经常因为界面微调而报错，维护成本居高不下。

用自然语言定义测试用例

WebMCP带来的转变是：Dhananjay可以"用自然语言定义测试用例"，从而让维护变得容易得多（maintenance much more easier）。

这一点意义深远，它代表了UI自动化测试的第三代范式演进。第一代是录制回放（如早期的QTP/UFT，Mercury Interactive于2001年推出），完全依赖坐标或对象属性；第二代是Page Object Model等设计模式配合Selenium等框架，提升了可维护性但仍与DOM耦合；2017年Cypress和2020年Playwright的出现引入了更智能的等待机制和网络拦截能力，但选择器脆弱性问题依然存在。近年来出现的AI驱动测试工具（如Testim、Mabl、Heal）尝试通过机器学习自动修复失效的选择器，但仍属于"修补"而非"重构"思路。第三代则是基于意图的测试——用业务语言描述期望行为，由AI理解语义并映射到实际操作，完全绕过了选择器问题。这与BDD（行为驱动开发）中Gherkin语法（Given-When-Then）的思想一脉相承，但更进一步：BDD仍需人工编写步骤定义（step definitions）来绑定具体操作，而基于WebMCP的方案让AI Agent自行通过已注册工具完成映射，从根本上解耦了测试描述与实现细节。

当测试逻辑不再绑定在具体的DOM选择器上，而是描述业务意图（比如"预订一张从德里到孟买的经济舱机票"），测试的健壮性和可读性都会显著提升。对于MakeMyTrip这样交易流程复杂的平台，这可能大幅降低QA团队的重复劳动。

复杂预订场景：让国际航班预订变得简单

旅行预订的复杂性挑战

Dhananjay用一个极具代表性的例子说明WebMCP的业务价值——国际航班预订。

他指出，一次国际航班预订可能牵涉到：

• 签证（visa）
• 中转（transit）
• 行李规则（baggage rules）

"让Agent自己搞清楚这一切本身就是一项任务（a task in itself）。"这句话精准道出了旅行行业数字化的难点：业务规则错综复杂，任何一个环节的疏漏都会影响用户体验。

要理解这种复杂度的量级，需要了解OTA行业的背景。OTA（Online Travel Agency，在线旅游代理）是全球数字经济中交易复杂度最高的垂直领域之一。MakeMyTrip成立于2000年，是印度市场份额最大的OTA平台，2010年在纳斯达克上市，2017年与ibibo集团合并后覆盖了印度约60%的在线旅行预订市场。平台每天处理数百万次搜索请求，涉及航班、酒店、火车票、巴士、度假套餐等多品类，其中80%以上流量来自移动设备。一次国际航班预订涉及的系统交互极为复杂：需要查询GDS（全球分销系统，如Amadeus、Sabre、Travelport）的实时库存，对接NDC（New Distribution Capability）新零售标准的航司直连接口，处理多币种支付结算，查询各国实时签证政策（各国签证规则每年变更数百次，如申根区过境签、英国TWOV规则等），检索IATA行李规则数据库中不同航司和舱位的差异化政策（廉航与全服务航司差异显著），以及验证各机场的最低转机时间（MCT，Minimum Connecting Time）规则。印度出境游市场年增长率超过15%，这些规则的组合爆炸使得端到端自动化预订成为行业性技术难题。

化繁为简的用户体验

借助WebMCP，MakeMyTrip得以"把所有这些复杂性抽离，让流程变得自然、简单"。最终目标很明确——为用户提供"更有影响力、更简单的预订体验（impactful, simpler booking experience）"。

从技术视角看，这背后的逻辑是：WebMCP把业务能力封装为标准化工具，AI Agent通过组合这些工具来处理复杂决策链，而无需硬编码每一条业务规则。例如，Agent可以先调用"查询签证要求"工具确认目的地签证政策，再调用"搜索航班"工具筛选符合转机时间要求的航线，最后调用"计算行李额度"工具确保旅客了解不同航段的行李限制——整个过程由Agent自主编排，而每个工具通过WebMCP的标准接口被发现和调用。这种Agent自主编排工具链的能力，在AI领域被称为"工具组合（tool composition）"或"任务规划（task planning）"，是当前大语言模型从单轮问答走向复杂任务执行的关键能力之一。ReAct（Reasoning + Acting）框架、LangChain的Agent模块、以及AutoGPT等项目都在探索让AI自主决定工具调用顺序和参数的技术路径。WebMCP通过提供标准化的工具发现和调用接口，为这种自主编排提供了基础设施层的支撑。这正是Agent化应用的理想形态。

分析与展望：WebMCP释放的行业信号

作为印度最大OTA平台的技术负责人，Dhananjay的实践给出了几个值得关注的行业信号。

第一，Web应用正在为Agent时代做准备。 正如MCP（Model Context Protocol）标准化了大模型与工具/数据源的连接，WebMCP试图将这套思路延伸到浏览器与Web应用层，让网页本身成为Agent可编程的"能力提供者"。这一趋势与当年从静态网页到RESTful API的演进逻辑一致——Web应用需要为新一代"消费者"（从人类用户到AI Agent）提供结构化的交互方式。回顾Web技术演进史，我们可以看到类似的模式反复出现：1990年代的CGI让Web从静态文档变为动态应用；2000年代的SOAP/XML-RPC和后来的REST让Web应用之间能够互相调用；2010年代的GraphQL让客户端能够精确声明数据需求。每一次演进的本质都是为新的"消费者类型"提供更高效的交互协议。WebMCP代表的是为AI Agent这一新消费者类型量身定制交互协议的尝试。

第二，测试自动化可能是最快见效的场景。 相比面向终端用户的AI功能，用自然语言重构脆弱的UI测试，是一个ROI清晰、风险可控的切入点。企业完全可以从内部工具链开始尝试。测试领域的特点是——即使Agent偶尔犯错，后果也仅限于测试失败需要人工排查，而不会直接影响生产用户，这使其成为验证WebMCP可行性的理想沙盒。从投资回报的角度看，大型互联网公司的UI自动化测试维护成本通常占QA总工时的30%-50%，其中相当一部分是修复因前端变更导致的选择器失效。如果WebMCP能将这部分成本降低一个数量级，其经济价值不言而喻。

第三，复杂业务领域受益最明显。 旅行、金融、保险等规则密集型行业，恰恰是传统自动化最头疼的地方，也是WebMCP这类标准化交互协议最能发挥价值的战场。这些行业的共同特征是：业务规则数量庞大（一家大型保险公司可能有数万条核保规则）、变动频繁（金融合规要求可能每季度更新）、存在大量跨系统依赖（一次保险理赔可能涉及核心系统、影像系统、反欺诈系统、支付系统等多个环节），传统的硬编码集成方式在面对规则组合爆炸时几乎不可持续。WebMCP的工具化封装思路——将每条业务规则或每个系统能力暴露为可独立调用的标准化工具——为AI Agent提供了一种优雅的方式来应对这种复杂性，让规则的变更只需要更新对应工具的实现，而不影响Agent的编排逻辑。

需要说明的是，本文基于MakeMyTrip单一来源的分享，WebMCP的具体技术规格、生态成熟度以及在生产环境的规模化表现，仍有待更多公开案例验证。但至少可以确定：让AI Agent以标准化、可发现的方式操作Web应用，正在从理论走向真实的商业实践。

核心要点

核心要点