MCP（Model Context Protocol）解决了AI Agent与外部工具的"连接"问题，但在旅游行业，“交易闭环"远未完成。Amadeus CTO Sylvain Roy 2026年5月明确指出：“MCP只是第一步”。当行业从"hype"转向"reality check”，开发者必须正视MCP的结构性边界，以及UCP（Universal Commerce Protocol）、行业Know-How与人工兜底在闭环中的不可替代作用。

一、从MCP hype到MCP reality check
过去半年，旅游科技行业经历了一次集体认知刷新。MCP在2025年被广泛包装为"AI Agent连接真实世界的USB接口"，酒店、机票、邮轮等垂直领域的MCP服务器如雨后春笋般涌现。但到了2026年5月，全球GDS巨头Amadeus的首席技术官Sylvain Roy在公开演讲中给出了一记清醒的冷水：
“MCP是AI互操作性的重要第一步，但单独采用MCP并不够。它无法处理复杂的零售工作流——shopping、booking、servicing——也无法提供旅客期望的端到端体验。基础API也必须具备AI-ready特性：结构化、上下文丰富、支持Agent驱动的交互。此外，延迟、使用量和运营成本仍是不可忽视的挑战。”

这段表态撕开了MCP光环下的真实图景。MCP定义了"Agent如何调用工具"的协议语法，但它没有规定"Agent如何完成一笔交易"。在零售场景中，"加入购物车→结算→发货→退货"的链路已经相对标准化；可一旦进入旅游，航班报价的3秒有效期、酒店取消政策的多层嵌套、改签时涉及的航空公司与GDS双重结算规则，都让MCP定义的"工具调用"显得过于单薄。

本文的核心判断是：MCP是必要条件，不是充分条件。旅游Agentic Commerce的真正落地，需要MCP+UCP+行业Know-How+人工兜底的组合方案，任何单一协议都无法独立撑起闭环。

二、MCP能做什么——已被验证的价值
在进入批判之前，必须公允地承认MCP在三个维度上已经创造了实际价值。
第一，标准化了AI Agent连接外部工具的接口规范。在MCP出现之前，每一个AI Agent若想调用外部数据源，都需要为该数据源单独编写适配层，集成成本随供应商数量线性增长。MCP通过定义统一的工具描述格式（tools、resources、prompts），让开发者只需实现一次Server端，即可被所有兼容MCP的Client调用。

第二，降低了集成的边际成本。对于旅游开发者而言，这意味着接入一家新酒店供应链的时间从数周压缩到数天。国内DIDA道旅、1Stay、WinWin等酒店MCP，以及TravelCode这类覆盖航班+酒店的复合MCP，都是这一红利的直接受益者。

第三，让结构化旅游数据可被AI实时查询。房型名称、价格计划、取消政策、是否含早、是否有窗——这些过去需要人工反复比对的信息，现在可以通过MCP tool call在秒级返回给Agent。用户在ChatBot中问一句"这房能免费取消吗"，Agent即可直接拉取结构化字段作答。
根据2026年7月的行业盘点，目前旅游MCP的落地大致呈现以下分布：大多数服务器仍停留在"搜索/发现"阶段，能完成预订的仅有1Stay、DIDA、WinWin、TravelCode等少数几家，能处理取消/修改等售后场景的更少，1Stay的cancel_booking工具和TravelCode是其中代表。完全端到端（搜索→预订→支付→售后）闭环的旅游MCP，仍属凤毛麟角。
这一分布本身就是对"MCP万能论"最直接的反驳。

三、MCP不能做什么——结构性缺口的诚实盘点
MCP的设计目标是"让Agent能调用工具"，它没有解决Agent商业化中最棘手的几个问题。
3.1 无法处理完整的零售工作流
Sylvain Roy的批评直指核心：MCP擅长"工具调用"，但不擅长"工作流编排"。一个真实的旅游交易涉及报价获取、库存锁定、价格校验、身份验证、支付授权、订单生成、确认书下发等多个环节，每一步都可能失败、可能回滚、可能需要人工介入。MCP没有内置状态机来管理这种长链路的失败恢复。
3.2 无法解决易腐库存的实时定价问题
旅游产品的本质是"易腐库存+动态报价"。一条航班报价的有效期可能只有3秒，一个酒店房型在旺季的价格每分钟都在波动。MCP的tools/call接口可以拉取一次报价，但没有任何机制强制Agent检查"这条报价现在还活着吗"。
第三方基准测试平台UCP Checker对5个前沿大模型（包括Claude、GPT、Gemini等）进行了标准化测试，结果令人警醒：
在模拟的旅游预订场景中，没有一个模型在调用预订接口之前主动检查报价的存活时间（quote validity check）；当报价设置3秒过期窗口时，5个模型中只有1个能在窗口关闭前完成下单；没有一个模型会主动向用户标记价格变化，除非被用户明确追问。
这意味着，在当前的Agent实现中，"AI帮你订到便宜机票"在很多时候只是Demo级别的演示，而非生产环境中的可靠能力。

3.3 无法处理售后场景
改签、取消、中断处理（disruption handling）是旅游服务中最复杂的环节。当一班航班被取消时，旅客需要的是：自动识别替代航班、计算差价、执行退改签、与酒店联动调整入住时间、向保险公司报案、向差旅公司报备。每一个环节都涉及不同的供应商、不同的API、不同的政策版本号。
MCP可以提供"调用改签接口"的能力，但谁来编排这条链路？当航空公司返回"该航班已无可改签座位"时，Agent下一步该做什么？这些问题不在MCP的协议范围内。
Sylvain Roy对此的结论相当务实：
“并非所有用例都需要MCP。在基础工作流中，一个设计良好的REST API往往就足够了。”
这句话翻译成开发者语言就是：不要为了"上MCP而上MCP"。如果你的业务只是"查一个酒店有没有空房"，一个干净的REST endpoint可能比MCP Server更高效、更易调试。
四、UCP登场——交易层的补位协议
MCP的边界清晰之后，行业的下一步走向也愈发明确。2026年，Google联合Shopify、Target、Walmart，以及American Express、Mastercard、Stripe、Visa等支付与金融基础设施方，共同推出了UCP（Universal Commerce Protocol）。
UCP的目标被明确定义为：让消费者（或其Agent）完成从发现、购买到售后支持的完整流程。如果说MCP解决的是"Agent如何说话"，UCP要解决的是"这笔交易如何成立、如何被信任、如何被追溯"。

在Google Marketing Live 2026上，UCP for Lodging正式启动，首批参与方涵盖了全球旅游分销的几乎所有核心节点：Accor、Amadeus、Booking.com、Choice Hotels、Expedia Group、Hilton、IHG、Marriott、Trip.com、Wyndham。这一名单本身就是一个信号——酒店集团、OTA、GDS三大势力同时入场，说明UCP在旅游领域的潜力已经被产业链上游认可。
UCP与MCP的关系是兼容而非替代。在协议栈中，MCP位于"连接层"（让Agent能调用工具），UCP位于"交易层"（让调用结果能被结算、被审计、被服务）。两者协同工作：MCP负责把报价数据拉出来，UCP负责把报价变成可被支付、被履约、被退款的订单。UCP官方也明确支持MCP、Agent2Agent（A2A）以及Agent Payments Protocol（AP2）等既有协议。
一个对酒店业尤其重要的设计原则被写入了UCP规范：酒店保持"记录商户"（merchant of record）地位，保留客户数据和关系。这意味着即使交易由Agent发起，酒店仍然是数据主权方和法律责任主体。这一安排在GDPR、CCPA等数据保护法规日趋严格的背景下，是产业链上游能够接受UCP的关键前提。
但UCP也并非没有短板。UCP Checker在其评估报告中给出了一个克制的提醒：
“UCP目前’largely retail-native’（本质上是零售原生的），在适配旅游的复杂性方面仍有大量工作要做。”
这意味着UCP的协议规范本身还在演进，旅游行业的特殊规则——多币种结算、动态报价失效、跨境税务、签证前置条件等——需要通过扩展机制（extension）逐步纳入。开发者不应期待UCP for Lodging在2026年下半年就能提供开箱即用的完整方案。

五、旅游为什么是Agentic Commerce最难的垂直
UCP Checker的批评背后，是一个更根本的结构性事实：旅游是Agentic Commerce所有垂直领域中最复杂的一个。这种复杂性体现在五个维度。
第一，动态报价，非固定SKU。 一条航班报价、一个酒店房型，本质上是供应商系统实时生成的Offer ID（甚至没有稳定ID），它无法被"加入购物车"后保持不变。零售商品有EAN/UPC码，Agent可以放心地让用户在购物车里躺三天；但旅游报价的半衰期以分钟甚至秒计。
第二，易腐库存与实时定价。 库存具有强时效性，价格随供需、舱位、提前期、汇率实时波动。任何"先看价格稍后再订"的策略都意味着价格漂移风险。这对Agent的实时数据获取能力提出了远超零售的要求。
第三，复杂售后服务。 改签、取消、中断处理的stakes远高于退回一件T恤。一次错误的酒店取消可能导致旅客深夜无房可住，一次错误的航班改签可能让旅客错过重要会议。供应商、酒店、航司、GDS、保险、支付通道、差旅管理公司（TMC）——每一个利益相关方都有自己的规则引擎。
第四，身份、结算和监管。 多方履约、旅客身份验证、跨境签证、税务合规义务伴随每一次预订。在企业差旅场景下，还涉及差旅政策执行、预算控制、审计追踪。Agent不能像在零售场景中那样"先用用户的钱垫付再说"。
第五，数据质量与控制权。 个性化推荐需要跨供应商共享旅客上下文（历史行程、偏好、忠诚度等级），但供应商必须保持对自身数据的可见性和控制权。这种"既要共享又要主权"的张力，是旅游分销二十年未解的难题，在Agent时代依然成立。
这五个维度的叠加，决定了旅游Agentic Commerce不可能"搭便车"零售方案——它需要独立的协议设计、独立的合规框架、独立的失败恢复机制。
六、支付与责任的灰色地带
即使MCP和UCP都在协议层日趋完善，支付层和责任归属仍然是两个悬而未决的灰色地带。
6.1 支付层的工程化挑战
旅游交易涉及PCI DSS合规（信用卡数据安全标准）、多币种实时结算、外汇风险、退款与改签的逆向资金流。这些都不是"调用支付API"能解决的问题。2025年下半年，行业已经开始尝试：

• OpenAI × Stripe 在2025年9月推出Agentic Commerce Protocol，试图把支付授权嵌入Agent对话流。
• Google × PayPal 在2025年10月推出Agentic Commerce解决方案，主打"Agent代付+商户收款"。
  但截至2026年中，人类在循环（human-in-the-loop） 仍是完成最终支付确认的标配。没有任何主流监管机构允许AI Agent在无用户明确确认的情况下自主扣款，尤其是在涉及大额、跨境、不可逆交易的旅游场景中。
  6.2 责任归属的悬而未决
  以下三个问题在法律层面尚无定论：
• 当AI Agent错误地推荐了一个不符合用户需求的酒店，损失由谁承担？
• 当Agent告诉用户"这间房可以免费取消"但实际不可取消，平台、Agent供应商、酒店三方各负多少责任？
• 当Agent为用户预订了一张错误日期的机票，谁来承担改签费？
  当前的行业惯例是"Agent平台免责，最终责任落在供应商或用户"，但这一惯例在监管层面非常脆弱。欧盟AI Act、美国各州的AI透明度法案都在推动"AI决策可追溯、可申诉"的要求，旅游Agent必须为此做好准备。
  七、企业差旅的特殊约束——UCP.travel的实践
  在所有旅游Agent场景中，企业差旅对协议层的合规要求最高，因为它叠加了企业治理需求。UCP.travel（Governed AI Travel Booking）是这一方向的代表案例，其工作流被设计为四层校验：

1. 验证旅客身份——确认操作者确实是该企业员工，且差旅请求在其权限范围内。
2. 执行差旅政策——根据舱位等级、提前预订天数、供应商偏好等规则自动筛选合规选项。
3. 最终价格确认——在交易前再次校验报价有效性，并锁定预算占用。
4. 审计追踪——完整记录Agent的每一步决策、每一次工具调用、每一次用户确认，用于事后审计与合规报送。
   在资源覆盖上，UCP.travel接入了300+航空公司网络，并通过30+直接NDC（New Distribution Capability）连接绕开传统GDS中介。NDC是国际航协（IATA）推动的航空数据标准（可以理解为航空公司的"数据语言"），GDS是渠道中介（Amadeus、Sabre、Travelport），MCP是AI连接协议——三者位于不同层级，互为补充而非竞争关系。
   产品形态上，UCP.travel提供了白标旅行应用、可被外部AI工具调用的接口、以及给企业差旅经理使用的运营仪表盘。这一三层结构实际上预示了未来旅游Agent的成熟形态：面向C端的对话入口、面向B端的治理后盾、面向供应链的标准化连接，三者缺一不可。
   八、对开发者的务实建议
   回到开发者视角，面对MCP的边界与UCP的补位，务实的策略应当包含以下几条。
   第一，不要迷信MCP万能论。 在动手做一个旅游MCP之前，先问自己：用户最痛的点是什么？如果是"查一个信息"，MCP是合适的工具；如果是"完成一笔交易"，你需要的是MCP+UCP+行业Know-How的组合。
   第二，能完成交易闭环的MCP才有商业价值。 当前大多数旅游MCP仍停留在"展示信息"阶段，真正的护城河是"从搜索到售后的全链路能力"。这意味着开发者不能只调通search和book两个接口，还必须把cancel、modify、refund、dispute等售后工具纳入产品规划。
   第三，售后能力是差异化竞争的关键壁垒。 搜索和预订是"门槛"，售后是"利润"。一个能帮用户在航班取消时自动改签到下一班、并联动调整酒店和接机的Agent，其用户粘性和付费意愿将远超只会"帮你订票"的Agent。
   第四，human-in-the-loop不是过渡方案，而是长期必需品。 在支付确认、敏感个人信息提交、政策边界判断等关键节点，引入人工确认不仅是合规要求，也是产品体验的必要环节。把"人工兜底"设计成产品的一部分，而不是一个"未来要消除的缺陷"。
   第五，积累行业Know-How。 旅游分销有20年的历史积累，每一个供应商都有自己的规则引擎、每一个GDS都有自己的术语体系、每一种舱位都有自己的退改签规则。这些知识无法从通用大模型中蒸馏出来，必须由开发者自己在供应链中沉淀。这也是为什么最懂旅游的AI团队往往来自旅游业内部，而非纯技术背景的初创公司。
   结语
   MCP是AI Agent时代的TCP/IP协议之一，但它不是旅游交易闭环的银弹。Amadeus CTO已经公开承认MCP的局限，Google用UCP补上了交易层，UCP Checker用基准测试指出了当前模型的真实表现。在这场基础设施迭代中，清醒比热情更重要。
   对旅游Agent的开发者而言，2026年是一个"祛魅与重建"的年份：祛魅的是"MCP万能"的神话，重建的是"MCP+UCP+行业Know-How+人工兜底"的新共识。那些能在祛魅中保持耐心、在重建中积累深度的团队，将在2027-2028年Agentic Commerce真正成熟时占据有利位置。

在这个方向上，DIDA道旅旗下的RollingGo MCP系列提供了一个值得关注的实践样本。RollingGo MCP系列已覆盖全球200万+酒店资源，其中11万+直签酒店实现价格库存实时响应，接入500+全球供应商网络。与多数仍停留在"搜索/发现"阶段的旅游MCP不同，RollingGo MCP系列已将能力延伸至在线预订、订单管理、取消退款等售后环节，试图在MCP连接层之上构建完整的交易闭环——正是本文所讨论的"从搜索到售后全链路能力"的一次具体落地。