最近 Google 搜索的 AI Mode 又更新了一波实用能力这次把方向对准了旅行规划机票价格追踪、积分里程查询、酒店预订。对于经常出差、喜欢比价、或者正在做 AI Agent 产品的人来说这不只是一条产品新闻更是一个值得拆解的 AI 应用落地样本。这篇文章我会先讲清楚 AI Mode 到底在做什么、这三个旅行规划能力分别解决什么问题然后从开发者视角分析这类“AI 搜索 工具调用 交易闭环”背后可能的技术链路最后给出一套可以照着改的旅行助手原型代码以及做同类功能时必须注意的安全与工程问题。无论你是关注 AI 搜索的产品经理、后端开发者还是准备把 AI Agent 落地到垂直行业的工程师这篇文章都值得看完。1. 事件背景AI Mode 为什么盯上旅行规划1.1 AI Mode 是什么AI Mode 是 Google 搜索里基于 Gemini 模型实现的交互式搜索模式。它和传统搜索最大的区别是传统搜索返回的是“一组蓝色链接”由用户在多个网页之间跳转、对比、筛选而 AI Mode 会在一轮对话中完成理解意图、拆解任务、检索信息、综合推理最后输出一份可以直接使用的答案。你可以把它理解成一个“能自己干活的搜索框”。用户不再需要搜完“北京到东京机票”再搜“东京酒店推荐”再搜“成田机场到市区交通”而是直接说“帮我规划下周去东京的行程预算八千以内包含机票和前三晚住宿。”AI Mode 会尝试把这一整条需求拆开分头查找再整合成完整方案。1.2 旅行规划为什么是 AI 搜索的“黄金场景”旅行规划天然适合 AI Agent 来做原因有三第一信息源极度分散。机票要查航司官网、OTA 平台、比价网站酒店要比较位置、评分、价格、取消政策里程兑换规则更是各家航司一套。用户需要同时打开十几个页面才能做一次完整决策这恰恰是 AI 擅长的事情。第二决策链路长。有别于“苹果手机多少钱”这种单点查询旅行规划是“查询 → 比价 → 决策 → 预订 → 行程管理”的多步流程每一步都涉及不同系统和数据源非常适合用 Agent 的多工具调用能力串联。第三结果可以直接落地。搜索机票不只是为了看价格最终目的是买票查里程是为了兑换看酒店是为了预订。当 AI 搜索能从“信息检索”延伸到“交易完成”它就不再只是流量入口而是变成了服务闭环本身。1.3 这次更新的核心意义从产品形态看Google 这次把 AI Mode 的三个能力分别对应到旅行决策中最常用的三个动作机票价格追踪解决“什么时候买最划算”的问题。积分里程查询解决“我有多少里程能用、怎么用”的问题。酒店预订解决“选哪家、怎么订”的问题。这三个能力合在一起已经覆盖了一次完整旅行规划的主干流程。对开发者来说更值得关注的是当一个拥有亿级用户量的搜索产品开始认真做 AI Agent 和工具调用时说明“AI 搜索 下一个超级入口”这个判断正在变成现实而我们自己写代码时同样可以借鉴这套思路。2. 三种旅行规划能力逐一拆解2.1 机票价格追踪从“查价格”到“盯价格”过去我们查机票通常是打开 OTA 平台输入日期和目的地看到当前价格后自己判断“贵不贵”。如果觉得贵只能过几天再查一次反复刷新效率很低。AI Mode 的机票价格追踪核心变化是把“单次查询”变成了“持续监控”。你可以直接提出类似“帮我关注北京到新加坡的往返机票价格低于三千时提醒我”这样的需求AI Mode 会在后台持续跟踪这条航线的价格变化并在合适的时间给出提醒。从技术角度拆解这个功能至少包含四层逻辑航线意图提取从自然语言中提取出发城市、到达城市、出行日期、舱位类型、目标价格等参数。数据源接入对接航班报价数据接口获取实时或准实时的机票价格快照。定时对比任务按照一定频率抓取最新价格并与历史价格做对比判断是否出现明显波动。触发通知当价格降到用户设定的阈值或者出现比历史均值低一定比例时生成提醒。这里面最容易被忽视的是“价格波动”的判断标准。机票价格受淡旺季、节假日、航空公司调价策略影响很大简单地和昨天的价格比较没有意义必须结合历史价格分布和未来出行日期进行综合判断。2.2 积分里程查询打通账号与联盟规则第二个能力是积分里程查询。很多旅行达人手里会同时持有几家航空公司的会员卡里程散落在不同账户里到期时间不同、兑换规则不同、可以兑换的航线也不同。想搞清楚“我能不能用里程换这张机票”通常得登录好几个航司 App 分别查询非常麻烦。AI Mode 的积分里程查询理想状态下应该能做到用户授权自己的航司会员账户后AI 直接把所有账户里的里程余额、有效期、可兑换航线汇总到一次对话中甚至可以回答“用哪家的里程换这张票最划算”。但这里必须强调积分里程查询是所有旅行功能里最敏感的一项因为它涉及用户账号授权用户必须明确授权 AI Mode 访问自己的航空公司账户。里程是一种有价值的数字资产查询和兑换必须区分权限。不同航司的里程联盟规则差异很大星空联盟、天合联盟、寰宇一家的兑换逻辑各不相同。里程兑换存在动态定价同一个航班的兑换所需里程可能随时变化。对开发者来说这条功能线最重要的启示是涉及用户账号数据的 AI 功能不能光把“能查”做好还必须把“授权”“审计”“最小权限”做好。没有明确授权就没有数据访问没有操作留痕就不应该执行兑换动作。2.3 酒店预订从推荐到完成交易酒店预订是三个能力里离“交易闭环”最近的一环。用户在 AI Mode 里输入目的地、入住日期、预算、偏好比如“离地铁站近”“有健身房”“含早餐”AI 会筛选出符合条件的酒店给出推荐理由并且可以继续追问“这家和那家有什么区别”“能不能取消”“有没有免费停车”。在信息推荐之上酒店预订最大的难点是“完成交易”。一次完整的酒店预订要经过搜索与比价从多个酒店分销渠道获取房型和价格。库存校验用户选中的房型在当前日期是否还有房。价格锁定从用户点击到提交订单价格是否变化。支付与确认支付成功后是否能拿到确认号。售后保障取消、改期、入住纠纷如何处理。这些环节单拎出来每一个都不难难的是在一个对话式界面里让用户不用跳转到酒店平台就能顺畅完成。这对 AI 模型的工具调用稳定性、订单状态一致性、异常兜底能力都提出了很高要求。3. 从“找链接”到“完成任务”AI Mode 的工作方式变化3.1 传统搜索 vs AI Mode为了更清楚地理解这次更新的价值我们可以做一张对比对比维度传统搜索引擎AI Mode用户输入关键词组合自然语言完整需求输出形式链接列表整合后的答案或操作结果多步任务支持不支持需要用户自己跳转支持拆解为多步执行实时数据依赖网页抓取和索引可调用实时数据接口交易行为跳转到第三方网站完成部分场景可直接在对话内完成连续性每次搜索相互独立支持上下文连续对话这里的关键词是“工具调用”。AI Mode 做机票追踪、里程查询、酒店预订本质上是在大模型的能力之上增加了对第三方工具和服务的调用能力。模型负责理解“用户想干什么”工具负责“把事办成”。3.2 Agent 式处理链路如果用一句话描述这种工作方式它就是一个精简版的 AI Agent 处理链路用户输入 ↓ 意图理解与任务拆解 ↓ 调用对应工具机票 API / 里程 API / 酒店 API ↓ 汇总结果并推理生成回复 ↓ 必要时执行后续动作持续追踪、发起预订 ↓ 结果确认与用户反馈这套链路里最核心的变化是“模型不再只是生成文本而是生成动作”。AI 必须知道什么时候调用哪个工具、传什么参数、拿到返回结果后怎么判断、结果异常时怎么处理。这也是为什么大模型厂商都在争相发布“函数调用”“工具使用”能力因为这才是 AI 从聊天走向生产力的分水岭。3.3 实时数据与静态索引的差异传统搜索引擎的本质是网页索引索引更新再快也有滞后。但机票价格、酒店房态是典型的实时数据一个价格可能在几分钟内变化。AI Mode 要做旅行规划就必须依赖实时数据接口而不是网页快照。这给技术架构带来的直接改变是AI 搜索产品必须具有“按需拉取数据”的能力。模型输出一个查询条件后台访问实时数据源获取结果再把结果带回给模型生成回复。整个流程中数据准确性和时效性由数据源保障模型负责理解和表达。4. 开发者视角实现一个“AI 旅行助手”的技术链路猜想需要提前说明Google 内部的工程实现细节并没有完整公开下面的内容是基于 AI Agent 通用架构的合理推断目的是帮大家理解这类产品的实现思路也可以直接作为自己开发同类功能的参考。4.1 意图识别与槽位填充无论用大模型还是传统 NLP 方法第一步都是把用户的话转成结构化参数。比如“帮我关注从上海到首尔的机票低于两千块告诉我”这句话要提取出出发城市上海到达城市首尔任务类型机票价格追踪目标价格2000 元触发条件价格下降至阈值这类结构化抽取可以由大模型直接完成也可以由大模型生成 JSON 后交给后端代码做参数校验。下面是一个简化示例展示如何用函数定义让模型输出结构化结果# 文件路径demo/agent/schema.py from typing import Optional from pydantic import BaseModel, Field class FlightTrackParams(BaseModel): origin: str Field(description出发城市中文名例如上海) destination: str Field(description到达城市中文名例如首尔) depart_date: Optional[str] Field(defaultNone, description出发日期格式 YYYY-MM-DD) return_date: Optional[str] Field(defaultNone, description返程日期格式 YYYY-MM-DD) target_price: Optional[int] Field(defaultNone, description用户期望的目标价格人民币) cabin_class: str Field(defaulteconomy, description舱位economy/premium/business/first) class MileageQueryParams(BaseModel): airline_code: Optional[str] Field(defaultNone, description航司二字码例如 CA/MU/CZ) query_type: str Field(description查询类型balance(余额)/award(兑换试算)) route: Optional[str] Field(defaultNone, description要查询的航线例如成都-巴黎) class HotelSearchParams(BaseModel): city: str Field(description目的地城市) check_in: str Field(description入住日期格式 YYYY-MM-DD) check_out: str Field(description离店日期格式 YYYY-MM-DD) guests: int Field(default2, description入住人数) budget: Optional[int] Field(defaultNone, description预算上限人民币/晚) keywords: Optional[str] Field(defaultNone, description偏好关键词例如地铁站附近 含早餐)实际落地时这组 Pydantic 结构可以直接作为大模型函数调用的入参 schema让模型从用户对话里抽取参数并返回 JSON再通过校验后进入业务逻辑。4.2 工具调用后端函数注册与执行有了参数下一步就是执行工具。这里用一个简化的 FastAPI 接口做演示重点不是代码本身而是展示“参数解析后调用外部接口并返回统一格式”的过程。# 文件路径demo/agent/tools.py import time import random from typing import Dict, Any from demo.agent.schema import FlightTrackParams, HotelSearchParams def search_flight_price(params: FlightTrackParams) - Dict[str, Any]: 模拟查询机票价格。 真实项目中这里会调用 OTA 或航司 GDS 接口。 # 模拟网络请求耗时 time.sleep(0.2) # 模拟查询价格真实场景应来自外部数据源 base_price random.randint(1800, 4200) return { origin: params.origin, destination: params.destination, price: base_price, currency: CNY, price_timestamp: time.strftime(%Y-%m-%d %H:%M:%S), source: demo-data-provider, } def search_hotel(params: HotelSearchParams) - Dict[str, Any]: 模拟查询酒店房态与价格。 真实项目中这里会调用酒店聚合供应商接口。 time.sleep(0.3) hotels [ {hotel_name: 示例酒店A, price_per_night: random.randint(380, 780), rating: 4.5, cancellable: True}, {hotel_name: 示例酒店B, price_per_night: random.randint(650, 1200), rating: 4.8, cancellable: False}, {hotel_name: 示例酒店C, price_per_night: random.randint(280, 520), rating: 4.1, cancellable: True}, ] return {city: params.city, check_in: params.check_in, check_out: params.check_out, hotels: hotels, query_time: time.strftime(%Y-%m-%d %H:%M:%S)}真实项目中search_flight_price 里面应该是对接真实机票供应数据的 HTTP 请求search_hotel 同理。这里用随机数模拟是为了把注意力放在 Agent 调用结构和数据格式设计上。4.3 价格追踪与定时任务机票价格追踪比单次查询多了一个“定时”维度。常见做法是把追踪任务持久化到数据库然后由定时调度器周期性执行。# 文件路径demo/tasks/price_tracker.py import sqlite3 import time from datetime import datetime DB_PATH tracker.db def init_db(): conn sqlite3.connect(DB_PATH) conn.execute( CREATE TABLE IF NOT EXISTS track_rules ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT, origin TEXT, destination TEXT, depart_date TEXT, target_price INTEGER, created_at TEXT ) ) conn.execute( CREATE TABLE IF NOT EXISTS price_snapshots ( id INTEGER PRIMARY KEY AUTOINCREMENT, rule_id INTEGER, price INTEGER, captured_at TEXT ) ) conn.commit() conn.close() def add_track_rule(user_id: str, origin: str, destination: str, depart_date: str, target_price: int): 新增一条价格追踪规则。 conn sqlite3.connect(DB_PATH) cur conn.cursor() cur.execute( INSERT INTO track_rules(user_id, origin, destination, depart_date, target_price, created_at) VALUES (?, ?, ?, ?, ?, ?), (user_id, origin, destination, depart_date, target_price, datetime.now().isoformat()), ) conn.commit() conn.close() def snapshot_all_rules(): 定时任务对每一条追踪规则抓取最新价格并判断是否触发提醒。 conn sqlite3.connect(DB_PATH) rules conn.execute(SELECT id, user_id, origin, destination, depart_date, target_price FROM track_rules).fetchall() for rule in rules: rule_id, user_id, origin, destination, depart_date, target_price rule # 调用外部机票查询接口这里以模拟价格代替 latest_price int(time.time()) % 3000 1500 conn.execute( INSERT INTO price_snapshots(rule_id, price, captured_at) VALUES (?, ?, ?), (rule_id, latest_price, datetime.now().isoformat()), ) if latest_price target_price: send_notification(user_id, f{origin}→{destination} 价格降至 {latest_price} 元) conn.commit() conn.close() def send_notification(user_id: str, message: str): 发送提醒真实项目中可对接邮件、推送或消息队列。 print(f[NOTIFY] user{user_id}, message{message})这里有几个工程细节值得注意追踪规则必须去重同一个用户对同一条航线重复创建规则时要合并。价格快照表建议按月或按规则归档避免数据无限膨胀。定时任务要设置合理的执行频率高频抓取会被数据源限流低频抓取会错过价格变化窗口。提醒触发后要记录已通知状态避免同一个价格反复提醒用户。实际生产环境中调度器可以用 Celery Beat、APScheduler 或者云平台的定时任务服务这里用 sqlite 和顺序执行只是为了演示核心逻辑。4.4 安全边界授权、交易与最小权限如果你要开发类似功能这三条安全底线一定要守住第一账号数据访问必须走显式授权。查询用户里程积分之前必须让用户明确登录并同意授权。不要在对话里直接要求用户提供航司账号密码更不要把账号凭据保存在日志里。规范做法是让用户跳转到航司官方 OAuth 授权页拿到 access token并且 token 要加密存储、定期过期。第二交易类操作必须二次确认。AI 推荐的酒店用户点了“预订”不代表用户已经决定支付。系统必须在提交订单前展示完整订单信息酒店名称、入住日期、房型、总价、取消政策、支付方式并让用户点击“确认预订”后才真正发起扣款。第三最小权限原则。一个查询里程的功能不应该拥有兑换里程的权限一个查询机票的功能不应该拥有免密支付的能力。权限拆分得越细单个漏洞造成的影响就越小。5. 与主流旅行平台和传统方式对比5.1 能力对比表能力分类传统 OTA 平台人工多平台比价Google AI Mode本次更新方向自然语言描述需求不支持或很弱不支持支持多数据源整合平台内有限比价依赖用户手动切换模型聚合多源信息价格持续追踪部分平台有降价提醒无支持跨航司里程查询很少支持依赖逐个登录方向已明确能力依赖授权酒店预订闭环支持跳转各平台逐步支持上下文连续追问无无支持5.2 各自的优劣传统 OTA 平台的优势是交易链路成熟支付、售后、客服体系完善库存数据准确。缺点是用户需要在结构化表单里反复操作价格对比维度受限难以处理复杂的组合需求。人工多平台比价的优势是灵活用户可以结合自己的经验做判断缺点是耗时、容易遗漏信息过载严重。AI Mode 这类产品的优势是交互自然、能整合多源信息、具备持续追踪能力。但目前也存在明显短板交易闭环还在完善中数据源覆盖范围不等于全覆盖模型偶尔会给出不准确的推荐。因此现实中的合理用法是让 AI 完成信息整合和决策辅助再在关键交易环节人工确认。6. 常见问题与注意事项6.1 机票价格追踪一定能买到最低价吗不能。价格追踪只能做“在你设定的条件下有低价时提醒你”并不保证追踪到的是全网最低价。机票价格受库存、舱位、航司策略影响同一个航班可能同时存在多个价格档位。建议把追踪功能定位为“价格监测工具”而不是“最低价保证”。6.2 积分里程查询涉及哪些风险主要是授权和数据安全风险。用户在授权 AI 查询里程时应该确认授权范围只包含“查询余额和兑换试算”不包含“直接兑换”。开发者在设计这一功能时也必须对兑换操作做单独的、更高等级的授权验证。6.3 AI 推荐的酒店一定能在线预订吗不一定。AI 推荐的酒店可能来自多个数据源其中部分数据源只有展示数据、没有下单接口。遇到这种情况AI 应该明确告知用户“这家暂不支持在线预订请跳转官网”而不是强行完成一个无法履约的订单。6.4 AI 搜索给出的价格信息可信吗可信度取决于数据源的实时性。机票酒店价格是动态数据如果 AI 使用缓存结果价格可能已经过期。开发者在设计回复时最好带上“价格快照时间”和“数据来源”让用户自行判断时效性。6.5 这个功能什么时候能全面用上功能覆盖范围和上线节奏会因地区、语言、用户群体不同而有差异。这类依赖第三方数据和账号授权的功能通常采用逐步灰度策略。对用户来说如果当前账号没有对应功能入口可以等待逐步放开无需尝试任何非官方途径。7. 开发者做同类功能时的工程建议7.1 数据结构设计所有外部数据源返回的价格、房态、时间戳都要保留原始来源字段方便排查问题。追踪规则、价格快照、通知记录要分开建表避免一张表承担多种职责。日期时间统一存储为 UTC展示时再按用户时区转换避免时区导致的价格追踪误判。7.2 异常处理调用外部数据接口一定会遇到超时、限流、返回异常数据的情况。处理原则是外部数据异常时AI 必须能感知并降级回复而不是把错误信息原样抛给用户。建议在工具调用层做统一异常包装返回类似“当前数据源暂时不可用请稍后再试”的提示并记录日志便于排查。7.3 交易安全所有涉及扣款、兑换、下单的接口必须做用户身份二次校验。前端要展示完整的订单摘要后端要记录完整的订单变更日志。对异常高频的下单请求要做风控拦截。涉及退款、改签时保留客服介入通道不能完全依赖自动流程。7.4 缓存与限流价格数据可以短时间缓存但不要长期缓存。酒店房态建议实时校验。同时要对外部接口的调用频率做统一控制防止触发供应商的限流策略。价格追踪任务要采用分布式锁避免多个 worker 重复执行同一条追踪规则。7.5 用户体验AI 搜索的优势是对话式交互但对话不能替代关键信息展示。涉及金额、日期、取消政策时建议用结构化卡片展示方便用户核对。用户确认前不要替用户做任何不可逆的操作。8. 总结与下一步学习方向Google 搜索 AI Mode 新增机票价格追踪、积分里程查询和酒店预订传递的信号很明确AI 搜索正在从“更聪明的搜索框”转变成“能完成任务的智能助手”。对产品经理来说要关注的是用户交互方式和商业模式的演变对开发者和技术决策者来说更值得思考的是自己的产品能否借鉴这套“意图识别 工具调用 交易闭环”的架构。如果你接下来想深入研究可以从这几个方向入手大模型的函数调用机制以及如何定义清晰、稳定的工具参数 Schema。旅行类数据源的接入方式比如机票 GDS 接口、酒店分销接口的通用数据格式。定时任务调度与消息通知体系的工程实现。账号授权体系的设计尤其是第三方 OAuth 接入和 token 安全管理。AI 返回结果的可信度评估如何用数据来源、时间戳、置信度等信息提高用户信任。做这类 AI 应用最忌讳的是把模型当成“万能执行器”。模型负责理解和表达工程系统负责数据准确、流程可靠、操作安全。先把这层边界想清楚你设计的 AI 旅行助手才能既聪明又靠谱。如果你正准备在自己的项目里实现类似的 AI 工具调用功能建议先把本文第 4 节的原型代码跑通再用真实数据源替换模拟数据最后补上授权、日志和监控。一步步来比一开始就追求“大而全”要稳妥得多。