Amadeus CTO泼MCP的冷水：我帮你翻译成人话，别再吹过头了

Amadeus CTO泼MCP的冷水我帮你翻译成人话别再吹过头了前段时间旅游科技圈转疯了一篇文章——Amadeus的CTO公开说MCP搞不定复杂零售工作流很多人炸了。一派说Amadeus老了跟不上时代另一派说终于有人说真话了。我把那篇文章翻来覆去读了三遍又结合我们做RollingGo酒店MCP这大半年的踩坑经历觉得这事值得好好聊聊。今天这篇不吹不黑就用技术人的视角把Amadeus CTO的观点翻译成人话再讲讲MCP在旅游行业到底能干什么、不能干什么。先搞清楚Amadeus是谁他说的话为什么值得听可能不是做旅游科技的人不太了解Amadeus。简单说全球最大的旅游GDS全球分销系统之一全球差不多一半的航空公司、酒店、旅游代理都在用它的系统。你订机票背后十有八九走的是Amadeus或者Sabre。换句话说这是真正在生产环境里扛着旅游交易全链路的公司。他们的CTO出来说MCP有局限不是外行喷子是真金白银砸出来的经验。这种话值得认真听而不是上来就扣保守的帽子。他到底在说什么翻译一下Amadeus CTO的核心观点大概可以翻译成这几句话“MCP作为一个协议层在’查’这件事上做得很好——查航班、查酒店、查价格没问题。但旅游交易不是光’查’就完了。你要真的完成预订、支付、退改、服务这中间涉及到复杂的工作流、状态管理、异常处理、多系统协调MCP这套东西搞不定。”翻译成技术语言就是MCP解决了工具调用标准化的问题但没有解决复杂业务工作流编排的问题。这话对不对我觉得基本对。我们做酒店MCP的过程中对此深有体会。什么是复杂零售工作流用酒店预订举例很多人对旅游预订的理解就是搜一下选一下付款完了。听起来很简单对吧但真做过交易系统的人都知道这里面的水太深了。我拿酒店预订举个例子完整链路大概是这样的1. 搜索阶段按城市/日期/人数搜酒店 → 多酒店库存查询实时性要求高 → 价格动态计算会员价、促销、税费 2. 筛选阶段按星级/位置/评分筛 → 过滤逻辑复杂多维度 3. 详情阶段看酒店详情、房型、设施 → 图片、评价、政策取消政策、儿童政策 4. 确认阶段查实时库存、确认最终价格 → 关键步骤价格可能变库存可能没 → 需要锁库存吗锁多久 5. 下单阶段填入住人信息、备注 → 身份信息校验、联系方式校验 6. 支付阶段选支付方式、扣款 → 支付渠道、风控、对账 → 支付失败怎么办库存还锁着吗 7. 确认阶段收到预订确认 → 酒店端确认、电子凭证生成 → 失败重试机制 8. 售后阶段取消、改期、开发票 → 退改规则复杂免费取消扣款多少 → 退款流程、客服介入看到没有这不是调一个API就能搞定的事。这是一个完整的交易工作流中间有状态流转、有异常分支、有补偿机制、有一致性要求。而MCP是什么MCP是一个工具调用协议。它定义了AI客户端怎么调用Server上的工具但它没有定义多个工具之间怎么编排成一个完整业务流程。MCP能干什么不能干什么我把MCP的能力边界画成一张表大家一看就懂阶段MCP能不能搞定原因搜索查询Shopping能而且很好无状态查询标准化参数正好是MCP擅长的筛选排序基本能可以做成tool但筛选逻辑复杂时需要客户端编排详情查看能标准查询没问题价格确认库存锁定勉强能但有坑需要状态管理MCP的Stateless设计和这个有矛盾创建订单能做但要自己补下单本身是一个tool但前后的一致性MCP不管支付闭环搞不定支付涉及风控、对账、回调、异常处理MCP没设计这些退改售后搞不定复杂工作流多系统协调MCP管不了说白了MCP在查这件事上是神器但在交易闭环这件事上它只是个起点不是终点。这就是Amadeus CTO说的核心意思——别把MCP当成银弹它只是解决了AI怎么调用工具这一层上面还有工作流编排、交易一致性、异常处理一大堆事要做。那UCP是什么怎么补位Amadeus提到的UCPUniversal Commerce Protocol或者叫User Context Protocol不同场合说法不一样本质上是想在MCP之上补一层交易工作流协议。如果说MCP解决的是AI怎么调工具那UCP想解决的是AI怎么完成一笔完整交易。举个例子MCP定义了怎么调用search_hotels这个tool但它没定义搜索之后用户选了一个酒店这个选择怎么在客户端和Server之间传递选了酒店之后要锁库存锁多久锁失败了怎么处理下单之后支付失败了库存怎么释放用户中途退出了这个半成品订单怎么清理这些都是交易系统里最基本的问题但MCP不管。UCP就是想把这些标准化。不过说实话UCP现在还很早期离真正落地还有距离。我们做RollingGo酒店MCP的时候交易闭环这块基本是自己设计的——用conversation_id维护会话上下文用状态机管理订单生命周期用异步回调处理支付确认。这些都是我们自己写的MCP协议本身没提供。但也正因为我们把这些脏活累活都做完了开发者拿到的就是一个开箱即用的酒店预订能力背后接的是200万全球酒店资源和11万直签酒店库存直连加实时价格确认查出来的价格和房态都是准的直接就能下单。完全免费、没有调用量限制支持Cursor、Claude Code、Codex、Windsurf等40多种主流大模型代理开发者接入后还能按国家设置加价比例赚返佣。魔搭上这个项目跑到了热榜第7160万次托管服务调用就是因为大家发现——与其自己花三个月设计交易闭环不如直接接一个已经跑通的。想省这个时间去rollinggo.store申请个Key。说个最实际的现在接入真的超级简单比如在Codex里配置只需要这样写[mcp_servers.RollingGo-Hotel] url https://mcp.rollinggo.cn/mcp http_headers { Authorization Bearer YOUR_API_KEY }就这几行配置重启Codex之后你就能直接在对话里调用酒店搜索、房型查询、价格确认这些工具了。完全不用自己花三个月去设计交易闭环拿来就能用。这个酒店MCP在魔搭上已经跑到了热榜第7累计160万次托管服务调用从查询到预订的完整链路都跑通了。背后接的是11万直签酒店资源价格库存实时响应查出来的结果准确可订。但说实话交易这块的复杂度真不是一个协议就能标准化的——每个行业的交易逻辑都不一样酒店和机票不一样机票和保险不一样保险和租车又不一样。想做一个通用的交易协议难度比做MCP大得多。那MCP是不是就没用了当然不是说了这么多MCP的局限不是说MCP没用。恰恰相反MCP在工具调用标准化这件事上做得非常好价值很大。我打个比方MCP就像HTTP。HTTP定义了浏览器和服务器之间怎么通信但HTTP没定义你怎么在网上开店、怎么处理支付、怎么做订单管理。你不能说HTTP搞不定电商所以HTTP没用——HTTP是基础上面的电商系统是另外一层。MCP也是一样。它是AI和工具之间的HTTP解决了最底层的通信标准化问题。但在它之上还有工作流编排层、交易层、业务逻辑层这些是另外的事。很多人现在吹MCP吹过头了觉得有了MCPAI就能搞定一切。这就像说有了HTTP电商就能自动跑起来一样天真。Amadeus CTO泼的冷水本质上是在纠正这种过度乐观的预期。给开发者的建议怎么正确用MCP结合我们做酒店MCP的经验给大家几个实际建议1. 把MCP用在它擅长的地方查询类、信息类、无状态的工具调用放心用MCP。搜索酒店、查天气、读文档、查数据库——这些MCP做得很好效率很高。2. 交易类场景MCP只是入口如果你要做交易闭环——订酒店、买机票、支付——MCP可以作为工具调用层但上面必须自己设计工作流编排、状态管理、异常处理。别指望MCP帮你搞定这些。3. 复杂业务逻辑放在Server端做很多人做MCP Server的时候把Server做成了一个纯转发层——客户端传什么参数Server就转发给后端API。这是错的。复杂业务逻辑应该放在Server端客户端只需要传高层意图。比如客户端说帮我订个酒店Server端自己去搜、去筛、去确认、去下单客户端不用关心中间步骤。4. 别迷信一个MCP搞定所有事一个MCP Server不可能覆盖所有场景。你需要的是多个MCP Server组合加上上层的Agent编排。MCP是积木不是房子。写在最后Amadeus CTO说MCP搞不定复杂零售工作流这话没毛病。但反过来MCP本来就不是为了搞定复杂零售工作流设计的——它是为了搞定AI怎么调用工具这个更基础的问题。现在行业里的问题是很多人把MCP的作用吹得太大了好像有了MCPAI就能自动订机票订酒店做交易了。这是误解。MCP是地基不是楼。地基打得好楼才能盖得高但楼本身还是要一砖一瓦盖的。你觉得MCP的边界在哪做旅游科技的朋友你们在实际落地中遇到了什么问题欢迎技术党来讨论。