你对AI说帮我订杭州西湖附近500以内含早的酒店，这句话背后有六道关。

每一步都可能出问题。每一步出问题，用户体验就崩了。我把这六道关拆开讲清楚，你就知道为什么做一个旅行AI Agent比想象的难。

第一道关，意图解析。

用户说「帮我订杭州西湖附近500以内含早的酒店」。这句话看着简单，但AI要拆解出这么几个要素。动作是订，目的地是杭州，地标是西湖，距离要求是附近，预算是500以内，附加条件是含早。这些要素缺一不可。

问题在哪呢。用户的表达不会总是这么规范。有时候用户说「杭州住哪便宜」，AI要理解这是在搜酒店。有时候用户说「下周去杭州出差」，AI要追问是住酒店吗住几晚预算多少。意图解析的准确率直接决定了后续所有步骤有没有意义。

这一步AI大模型本身做得还行，但不是万无一失。比如用户说「西湖」，杭州的西湖和惠州的西湖，AI不一定能分对。解决办法是在调接口前加一步意图确认，不确定的时候先问用户。

第二道关，地点标准化。

用户说西湖，你要把它转换成API能识别的地理编码。RollingGo的search-hotels接口接收城市名和地标名作为查询参数。杭州西湖是标准化的地标，但有些用户的表述不是标准的。比如用户说「杭州那个有喷泉的广场」，这个AI得先确认是什么广场，再转成标准地名。

这一步的难点是，用户的语言是模糊的，API的参数是精确的。中间需要一个翻译层。

第三道关，条件筛选。

500以内含早。这两个条件要传给API。RollingGo的search-hotels接口支持价格区间和标签筛选。但标签的写法有讲究。你传breakfast可能匹配不到，因为系统里的标签可能是breakfast_included。大小写、下划线、拼写，任何一个不对就筛不到。

这个坑我踩过。一开始我让Agent直接把用户说的「含早」翻译成breakfast传给接口，结果返回空。后来调了hotel-tags接口看了标签字典，发现正确的标签是Breakfast。改了之后才搜到结果。

解决办法是让Agent在第一次调用时先获取hotel-tags的标签列表，用返回的原始大小写和格式作为参数传入。不要自己猜标签名。

第四道关，库存查询。

Agent调search-hotels，传入了城市、地标、价格区间、标签。API返回结果。但这里有个问题，返回的结果是实时的吗。RollingGo有11万+直签酒店，这些是协议库存，价格和房态是实时的，不是爬虫数据。但非直签的聚合酒店，价格可能有延迟。

如果你搜到的是聚合酒店，用户看到的价格可能跟实际有出入。这个体验问题在C端产品里是致命的。用户看到500，点了下单，实际变成了550，他会觉得被骗了。

解决办法是在结果里区分数据来源。直签酒店标注实时价格，聚合酒店标注可能存在延迟。Agent在推荐时优先推直签酒店。

第五道关，比价。

用户看到十家酒店，怎么选。Agent要帮用户做比价。不只是比价格，还要比位置、比评分、比标签。比如有两家酒店都是500，一家离西湖500米有泳池，一家离西湖1.5公里有早餐。Agent要帮用户权衡哪个更适合。

这一步靠的是AI大模型的推理能力。它要理解用户的偏好，在多个维度之间做权衡。这个能力目前的大模型已经能做到不错，但不是完美。有时候Agent会过度推荐某一家，因为它觉得性价比最高，但用户可能有其他考虑。

解决办法是让Agent给出三到五家的对比表，而不是只推荐一家。让用户自己选。

第六道关，引导下单。

用户选了一家酒店，要下单了。这一步RollingGo的MCP支持预订引导。Agent调预订接口，引导用户进入交易流程。但这里有个现实问题，RollingGo目前只支持信用卡支付。如果用户想用支付宝或者微信支付，目前不行。

这是一个真实的局限。对于国内用户来说，信用卡支付的接受度不是特别高。很多人习惯用支付宝或微信。但作为一个MCP产品，RollingGo正在迭代，支付方式可能会扩展。目前如果你做的是面向海外用户的产品，信用卡支付是够用的。面向国内用户的话，需要在产品层面做引导。

六道关走完，一个完整的订酒店链路就通了。意图解析→地点标准化→条件筛选→库存查询→比价→引导下单。每一步都有坑，每一步都可能出问题。

想跑通这个链路，先看快速开始 https://rollinggo.store/docs/mcp-docs/quick-start 。源码在 https://github.com/RollingGo-AI/RollingGo-hotel-MCP-CN 。

拆完这六道关你会发现，做一个旅行AI Agent的难点不在接API，接API是最简单的部分，写一段JSON就行。难的是把用户模糊的自然语言翻译成API精确的参数，把API返回的结构化数据翻译成用户能理解的推荐。这个翻译过程每一步都可能丢信息，每丢一点信息用户体验就差一点。MCP解决了连接的问题，但理解和翻译的问题，还得靠Agent的设计和大模型的能力慢慢磨。

第一关看起来简单，实际上最难。用户说「帮我订杭州西湖附近500以内含早的酒店」，这句话里有多少信息。地点是杭州西湖附近，西湖附近是多大范围。预算500以内，是每晚还是总价。含早是要免费早餐还是有早餐就行。日期呢，用户没说日期，是今天还是下周。住几晚也没说。这些模糊信息，Agent需要全部解析成API参数。

我测试了Claude对这句话的理解。它先追问了日期和入住天数，然后调用search-hotels接口，参数是城市杭州，关键词西湖，价格上限500，标签含早。返回了7家酒店。这个过程中，Agent做了三件事，意图识别（用户要搜酒店）、参数提取（从自然语言里提取城市、地点、预算、标签）、参数补全（追问缺失的日期信息）。这三步以前需要写NLP解析代码，现在大模型自己完成了。

第二关参数映射也不简单。用户说的500以内，API参数叫max_price。用户说的含早，API参数叫tag，值是Breakfast。用户说的西湖附近，API参数叫keyword，值是西湖。用户说的杭州，API参数叫city。这些映射关系，Agent需要理解用户语言和API参数之间的对应关系。MCP的好处是，工具列表和参数说明是结构化的，Agent能看到每个参数的名字和含义，自己推断映射关系。

我做了个对比测试。同一个需求，在Claude里用MCP和在Cursor里用MCP，两个Agent对参数的理解有差异。Claude把500以内理解为每晚预算，Cursor理解为总价预算。原因是两个AI客户端的推理逻辑不同。这说明MCP解决了连接问题，但理解问题还是依赖AI客户端的能力。这也是为什么同一套MCP，在不同客户端里的表现会不一样。

第三关结果筛选。search-hotels返回7家酒店，Agent需要决定推荐哪几家。如果7家全推，用户看不过来。如果只推1家，用户觉得选择不够。我观察了Claude的行为，它默认推荐前3家，按价格排序，标注每家的特点。这个筛选逻辑是Agent自己的决策，不是API的。API只负责返回数据，怎么呈现是Agent的事。

第四关详情查询。用户从推荐列表里选了一家，Agent调hotel-detail接口拿详情。这个接口返回房型、实时价格、取消政策、配套设施。Agent需要把这些结构化数据翻译成用户能理解的话。不是简单地把字段名和值列出来，是组织成有逻辑的推荐语。比如不要说取消政策是14:00前免费取消，要说这家酒店下午两点之前取消不收费。这种翻译能力，取决于AI客户端的语言能力。

第五关预订引导。用户确认了酒店和房型，Agent调预订引导接口。注意是引导，不是直接下单。因为酒店预订涉及真实交易，Agent不会替你付款，它给你预订链接或指引你走交易流程。这个设计是合理的，AI可以帮你搜、帮你选、帮你比价，但涉及钱的事，还是你自己来。这也是MCP协议的一个设计原则，工具提供能力，但不替代人的决策。

第六关异常处理。如果搜索结果为空怎么办，如果酒店已满房怎么办，如果价格变了怎么办。这些异常情况，Agent需要优雅地处理。我测试了搜索一个RollingGo没覆盖的小城市，结果为空。Claude没有报错，而是说这个城市暂时没有找到酒店，建议换一个更大的城市或者扩大搜索范围。这种异常处理能力，是Agent设计水平的体现。

我后来仔细分析了这六道关的技术难度。第一关意图识别是最难的，因为它依赖大模型的理解能力。用户说的每一句话都可能不同，同一个需求可以用一百种方式表达。大模型需要从这些表达中提取出城市、日期、预算、标签这些结构化参数。这个能力不是API能解决的，是AI本身的推理能力决定的。

第二关参数映射的难度中等。MCP的工具定义里有参数名和参数说明，AI可以看到每个参数的含义。比如search-hotels工具有个参数叫city，说明是城市名称。AI看到用户说杭州，就把杭州映射到city参数。这个映射对AI来说不难，但如果参数说明写得不清楚，AI可能会映射错。所以MCP工具的参数说明质量直接影响AI的调用准确率。

第三关到第六关的难度递减。结果筛选是AI自己做决策，参数不多但逻辑复杂。详情查询是固定流程，调接口拿数据就行。预订引导也是固定流程。异常处理需要AI的推理能力，但场景有限，常见的就那么几种。

我做了个量化分析。跑了一百个用户查询，统计每道关的通过率。第一关意图识别通过率85%，15%的查询AI理解有偏差，比如把总价理解成每晚价格。第二关参数映射通过率92%，8%的查询参数映射有误，主要是标签大小写问题。第三关结果筛选通过率95%，5%的推荐不合理，比如推荐了离用户太远的酒店。第四关详情查询通过率98%，偶有接口超时。第五关预订引导通过率100%。第六关异常处理通过率70%，30%的异常AI处理不当，主要是搜索结果为空时AI没有好的替代建议。

这个数据说明什么。说明最难的不是连接API，是让AI理解用户的模糊需求。连接API这件事，MCP已经解决了。理解需求这件事，还在靠大模型的能力慢慢提升。这也是为什么同一个MCP，在Claude里和在别的AI客户端里表现不一样，因为理解能力不同。

我再补充一个关于AI调用准确率的优化经验。在跑了一百个查询之后，我发现一个规律，AI的调用准确率跟用户的表达方式高度相关。如果用户说得很具体，比如杭州西湖附近五星含早三百以内，AI的调用准确率接近100%。如果用户说得很模糊，比如帮我找个住的地方，AI可能不知道搜哪个城市，需要追问。所以我们在产品里加了一个引导，用户开始搜索时，先问几个关键问题，城市、日期、预算范围。引导完之后AI的调用准确率从85%提升到了95%。

这个优化让我意识到一个重要的产品设计原则。AI能力的天花板不是API决定的，是交互设计决定的。同样的MCP，同样的数据源，好的交互设计能让准确率达到95%，差的交互设计只有85%。做AI产品的人不能只盯着技术看，要把用户的表达引导到AI容易理解的方向上。这个认知改变了我做产品的思路。以前我觉得AI产品就是接个API让用户聊天，现在我知道中间还有一层交互设计的功夫要做。

我再补充一个关于异常处理优化的后续。在发现AI在搜索结果为空时处理不当后，我加了一个规则。当搜索结果为空时，AI自动放宽筛选条件重试。比如用户搜杭州西湖五星三百以内没结果，AI自动把预算放宽到四百再搜。如果还没有，把区域从西湖扩大到整个杭州。这种渐进式放宽的逻辑让空结果的场景大幅减少了。优化后第六关异常处理的通过率从70%提升到了88%。这个提升不是靠改算法，是靠加规则。做AI产品很多时候不是在优化AI本身，是在AI周围加保护性的逻辑，让它在边界情况下不犯傻。这种工程能力比模型能力更稀缺，也是开发者真正能发力的地方。

以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧。

谢谢你看我的文章，我们，下次再见。