AI搜索走向任务执行：Google AI Mode的机票追踪与酒店预订

从出行场景说起很多人的订票习惯是“反复刷新同一个航班页面等它降价”。传统搜索引擎在这件事上能做的很有限——它把几十次查询拆成几十条链接本质上还是让用户自己盯。如果 AI 搜索想真正变成智能助手它就必须改变这种交互把“搜索”变成“持续追踪”把“浏览详情”变成“预订完成”。Google AI Mode 新增机票价格追踪与酒店预订功能恰好卡在这个转变点上。这篇文章的判断很简单这不是 AI 搜索多加了两个卡片而是搜索产品第一次从“信息检索”完整走向“任务执行”。对普通用户来说可能意味着少刷十次页面对开发者来说意味着技术栈、数据结构、信任边界都在悄悄发生变化。文章会先拆解这次更新的本质再以一个小型价格追踪系统为例演示从自然语言解析、报价获取、历史价格记录到降价提醒的完整工程路径。即使你没有接入 Google 官方接口这套代码也能在你自己的产品里跑通。1. AI Mode 这次新增的两项能力本质是什么先把背景交代清楚。按目前的公开信息Google 搜索中的 AI Mode核心变化是把传统的“输入关键词→返回链接列表”升级成“输入需求→返回可执行答案”。它不只是把搜索结果做摘要而是把多个来源的信息整合成一份答案并且开始承担任务型操作比如查询实时价格、对比酒店、追踪机票价格变化、辅助预订。这次新增的两个能力值得分开看机票价格追踪本质是“持续观察”。它不是在你搜索那一刻返回一个价格而是允许系统记住你关注的航线、日期和价格基线在后续价格波动时提醒你。酒店预订功能本质是“闭环交易”。过去搜索酒店页面给你的是列表、评分、地图、链接现在 AI Mode 试图在对话里完成从选酒店到预订的更完整路径。这两件事放在一起信息量比表面大得多。传统搜索和 AI Mode 的差异可以整理成一张表维度传统搜索AI Mode 的机票/酒店能力交互方式输入关键词返回链接输入自然语言返回答案与操作入口时间维度一次性查询结果即时过期持续追踪价格变化主动提醒决策路径用户自己筛选、比较、跳转AI 整合数据给出推荐和预订路径状态管理无状态每次搜索独立有状态需要保存用户关注的任务技术核心检索排序、索引、摘要意图解析、工具调用、数据实时获取、交易接口风险边界点错链接最多浪费几分钟订错票、订错酒店会产生真实损失“能搜到票”和“能帮你盯住票”是完全不同的两种系统。前者是一个无状态函数输入查询输出结果结束。后者是一个有状态的持续进程它要记住“你在关注哪条航线”定义什么是“降价”判断什么时机提醒还要在提醒之后给你一条可执行的预订路径。这正是 AI Agent 的典型特征——不再只是一次回答而是一段需要维护目标的连续过程。所以这篇更新真正值得开发者关注的不是搜索结果变漂亮了而是搜索引擎的产品形态正在从“连接用户与信息”变成“连接用户与服务”。它是趋势信号不是简单功能更新。2. 从“给链接”到“帮下单”任务执行背后的四个技术环节如果要在自己的产品里复刻类似能力拆开看至少有四个技术环节是绕不开的意图解析把“帮我查下个月上海飞北京最便宜的航班”变成结构化参数比如出发地 SHA、目的地 PEK、日期、舱位偏好。实时数据获取从航班报价系统、酒店库存系统、价格策略接口里拿到当前价格、余票、可订状态。价格追踪与状态管理保存历史价格计算价格走势设定提醒阈值。这里的难点是数据一致性、过期判断和通知频率控制。交易闭环当用户真的要预订时要把选定的航班、酒店、价格、用户身份、支付方式组合成一个合法订单并处理确认、取消、退款、异常。有一个常用的类比搜索是“问路”追踪是“导航”预订是“叫车”。问路只需要一张地图导航需要实时路况和路线规划叫车则需要一套完整的交易系统。三者对基础设施的要求差别很大。传统搜索引擎解决得最好的是第一环和第二环的前半段。它擅长把“上海到北京”识别成一次查询然后展示一堆结果。但后面两环传统搜索架构基本不参与。价格追踪为什么难因为它不是一次性的计算。系统需要维护一张“关注表”每一项都包含航线、日期、目标价格、当前价格、最近一次变更时间。每一次新报价进来都要做一次比较看是否达到提醒阈值。这些看起来简单一旦用户量上来问题就变得非常现实同一航班多少人关注、报价接口被调用多少次、缓存策略怎么做、价格数据过期了怎么办。酒店预订更难。因为它涉及真实的商品库存和资金流转。酒店价格有淡旺季有取消政策有余房约束。AI 推荐了酒店、用户下了单结果酒店回来说房型已满这中间的信任损失谁来承担所以交易闭环要求系统必须保持幂等、可重试、可核对这些都属于工程化问题而不是“大模型够不够聪明”的问题。还有一个被忽略的点搜索界面和交易界面的信任度完全不同。用户对“搜索”的容忍度很高搜错了可以重搜用户对“预订”的容忍度很低订错了就是真实损失。所以 AI Mode 做酒店预订就必须在界面、确认环节、支付链路里设计足够的二次确认。这也是为什么“AI 搜索”的竞争重点正在从模型能力转向工程责任边界。3. 本地复刻一个价格追踪原型环境准备与目录结构如果你希望在自己的产品里复刻“机票价格追踪”这类能力不需要一开始就接复杂的交易系统。更合理的路径是先跑通一个最小原型验证四个环节能否串起来解析意图、获取报价、记录价格、触发提醒。先说明边界下面的示例使用模拟报价数据源生产环境请替换为已获得授权的机票或酒店报价接口。不要对任何第三方平台做未经授权的高频抓取也不要绕过平台的安全限制。这既是合规要求也是工程上避免自己被封禁的基本前提。环境要求很简单不需要外部依赖Python 3.10标准库sqlite3、random、datetime、time、re一个文本编辑器或 IDE系统版本、Python 版本以你本机为准本文重点演示通用思路。示例使用的 SQLite 是 Python 内置模块不需要额外安装。建议的目录结构如下ai-travel-demo/ ├── demo/ │ ├── intent_parser.py # 自然语言解析 │ ├── quote_client.py # 模拟报价客户端 │ ├── price_tracker.py # 价格追踪与历史记录 │ └── main.py # 主程序入口 └── scripts/ └── track_daily.sh # 定时触发脚本示例这个拆分方式对应前面说的四个环节解析、获取、追踪、执行。目录拆得清晰后续替换数据源、接入真实接口时只需要改 quote_client.py 和 transaction 相关模块其他部分基本不动。4. 核心代码实现解析、报价、追踪、提醒4.1 自然语言解析把“上海到北京”变成结构化参数第一段代码解决意图解析。生产环境一般用 LLM 或 NLP 服务实现能处理更复杂的表达下面的演示版本用规则和正则表达式目的是让你看清输入输出结构。# 文件路径ai-travel-demo/demo/intent_parser.py import re AIRPORTS { 上海: SHA, 北京: PEK, 广州: CAN, 深圳: SZX, 成都: CTU, 杭州: HGH, } def parse_intent(text: str) - dict: 从自然语言中提取行程参数。 演示版本使用规则匹配生产环境建议替换为 LLM 结构化输出。 origin None destination None for alias, code in AIRPORTS.items(): if alias in text: if origin is None: origin code else: destination code date_match re.search(r(\d{4}-\d{2}-\d{2}), text) depart_date date_match.group(1) if date_match else None return { origin: origin, destination: destination, depart_date: depart_date, }这段代码的逻辑很直接在文本里找城市名第一个出现的记为出发地第二个记为目的地。同时用正则表达式提取日期。如果用户说“后天”规则版本无法处理需要交给 LLM 或更完整的日期解析库。实际项目中建议让 LLM 输出固定的 JSON 结构例如{origin: SHA, destination: PEK, depart_date: 2025-06-20}这样做的好处是下游模块拿到的永远是同一个结构不管用户说的是“上海到北京”还是“从上海飞北京6月20号”。自然语言处理可以不断升级但接口契约保持稳定。4.2 报价客户端构造可替换的数据源第二段代码负责获取报价。真实项目中这里会调用航司、GDS 或 OTA 的官方接口。演示版本用随机数模拟价格波动目的是模拟“同一航线不同时刻价格会变”的真实情况。# 文件路径ai-travel-demo/demo/quote_client.py import random from datetime import datetime def fetch_quote(origin: str, destination: str, depart_date: str) - dict: 模拟报价接口返回。 生产环境请替换为已获得授权的数据源并做好限流、缓存、超时处理。 返回结构尽量贴近真实报价通用字段。 price random.randint(600, 2200) return { origin: origin, destination: destination, depart_date: depart_date, price: price, currency: CNY, is_available: True, fetched_at: datetime.now().isoformat(timespecseconds), }这段代码最关键的设计点是所有字段都是稳定的字符串或数字。真实接口很可能返回更复杂的嵌套结构但建议在上游就把它“摊平”成统一结构再交给下游使用。这么做的好处有两个第一记录历史价格时字段简单减少数据库设计成本第二如果后续切换数据源只需要在这个模块里做适配价格追踪逻辑完全不用改。这就是“面向接口编程”的最小实践。4.3 价格追踪器用 SQLite 记录历史价格并判断降幅第三段代码是整个示例的核心价格存储和降幅判断。这里使用的是 SQLite理由是零配置、单文件、Python 内置支持非常适合作原型验证。# 文件路径ai-travel-demo/demo/price_tracker.py import sqlite3 DB_PATH price_history.db ALERT_THRESHOLD 0.1 # 价格降幅超过 10% 时提醒 class PriceTracker: def __init__(self, db_path: str DB_PATH): self.conn sqlite3.connect(db_path) self._init_table() def _init_table(self): with self.conn: self.conn.execute( CREATE TABLE IF NOT EXISTS quote_history ( id INTEGER PRIMARY KEY AUTOINCREMENT, route TEXT NOT NULL, depart_date TEXT NOT NULL, price REAL NOT NULL, fetched_at TEXT NOT NULL ) ) def record(self, quote: dict): route f{quote[origin]}-{quote[destination]} with self.conn: self.conn.execute( INSERT INTO quote_history (route, depart_date, price, fetched_at) VALUES (?, ?, ?, ?) , (route, quote[depart_date], quote[price], quote[fetched_at]), ) def last_price(self, route: str, depart_date: str): cur self.conn.execute( SELECT price FROM quote_history WHERE route? AND depart_date? ORDER BY id DESC LIMIT 1 , (route, depart_date), ) row cur.fetchone() return row[0] if row else None def should_alert(self, quote: dict): route f{quote[origin]}-{quote[destination]} last self.last_price(route, quote[depart_date]) current quote[price] if last is None: return None drop_ratio (last - current) / last if drop_ratio ALERT_THRESHOLD: return { route: route, depart_date: quote[depart_date], old_price: last, new_price: current, drop_ratio: round(drop_ratio * 100, 2), } return None这段代码有几个值得注意的细节quote_history 表以 route depart_date 作为查询维度这是价格追踪的核心粒度。同一个航线、同一天的价格才有比较意义。record 和 should_alert 是分开的两个操作。先判断、后记录避免把“当前价格”自己跟自己比较。ALERT_THRESHOLD 是 0.1表示降幅超过 10% 就提醒。实际产品中这个阈值最好由用户自定义因为不同航线的价格波动幅度差异很大。短途航线一两百元的变动可能就是大降价长途航线 10% 可能还很常见。表结构里没有用户 ID因为这是单机演示。真实系统中还需要记录“这是谁关注的路线”并把提醒状态、已读状态一并保存。4.4 主程序入口把流程串起来最后把上面三个模块串成主程序。主程序做的事情是解析自然语言 → 循环获取报价 → 判断降幅 → 记录价格 → 输出提醒。# 文件路径ai-travel-demo/demo/main.py import time from intent_parser import parse_intent from quote_client import fetch_quote from price_tracker import PriceTracker def main(query: str, run_times: int 5, interval: int 2): tracker PriceTracker() intent parse_intent(query) if not intent[origin] or not intent[destination] or not intent[depart_date]: print(无法解析完整行程参数请检查输入格式。示例上海到北京2025-06-20) return print(f解析出的行程{intent}) for _ in range(run_times): quote fetch_quote( originintent[origin], destinationintent[destination], depart_dateintent[depart_date], ) alert tracker.should_alert(quote) tracker.record(quote) if alert: print( f[ALERT] 航线 {alert[route]} 日期 {alert[depart_date]} f从 {alert[old_price]} 元降到 {alert[new_price]} 元降幅 {alert[drop_ratio]}% ) else: print(f[INFO] 当前价格{quote[price]} 元未触发降幅提醒。) time.sleep(interval) if __name__ __main__: main(帮我查上海到北京的机票日期是2025-06-20, run_times5, interval2)运行方式cd ai-travel-demo python demo/main.py如果所有逻辑正确你会看到类似下面的输出解析出的行程{origin: SHA, destination: PEK, depart_date: 2025-06-20} [INFO] 当前价格1832 元未触发降幅提醒。 [INFO] 当前价格1210 元未触发降幅提醒。 [ALERT] 航线 SHA-PEK 日期 2025-06-20 从 1210 元降到 880 元降幅 27.27%因为报价是随机的实际数字会不同但逻辑是稳定的只有当新价格比上一次价格低 10% 以上时才会触发提醒。这个最小原型已经具备了一个价格追踪系统最核心的部分。5. 用 JSON-LD 结构化数据理解酒店与航班页面价格追踪系统解决的是“价格变化”但 AI Mode 要做的还有“酒店预订”这意味着它必须理解页面上有哪些房型、什么价格、是否可订。现实中的酒店和航班页面很多会嵌入 JSON-LD 结构化数据它就像网页里的“机器可以读的菜单”AI 系统可以靠它快速提取关键字段。以下是一个模拟酒店页面的 JSON-LD 数据// 文件路径ai-travel-demo/demo/hotel_page.jsonld { context: https://schema.org, graph: [ { type: Hotel, name: 示例未来酒店, address: { type: PostalAddress, addressLocality: 北京, streetAddress: 中关村大街 1 号 }, priceRange: ¥600 - ¥1800, checkinTime: 14:00 }, { type: Offer, name: 标准大床房, price: 780.00, priceCurrency: CNY, availability: https://schema.org/InStock, url: https://example.com/hotel/room-101 }, { type: Offer, name: 行政双床房, price: 1280.00, priceCurrency: CNY, availability: https://schema.org/SoldOut, url: https://example.com/hotel/room-202 } ] }用 Python 解析这段数据很简单# 文件路径ai-travel-demo/demo/parse_jsonld.py import json def load_jsonld(file_path: str): with open(file_path, r, encodingutf-8) as f: data json.load(f) nodes data.get(graph, [data]) hotel next((node for node in nodes if node.get(type) Hotel), None) offers [node for node in nodes if node.get(type) Offer] return hotel, offers def main(): hotel, offers load_jsonld(demo/hotel_page.jsonld) print(酒店名称, hotel.get(name)) print(价格区间, hotel.get(priceRange)) for offer in offers: status 可预订 if InStock in offer.get(availability, ) else 不可预订 print( f房型{offer.get(name)} f价格{offer.get(price)} {offer.get(priceCurrency)} f库存状态{status} ) if __name__ __main__: main()运行结果酒店名称 示例未来酒店 价格区间 ¥600 - ¥1800 房型标准大床房价格780.00 CNY库存状态可预订 房型行政双床房价格1280.00 CNY库存状态不可预订理解 JSON-LD 的价值在于AI 系统不需要像人一样“看懂”整个网页只需要解析结构化字段就能拿到房型、价格、地址、库存状态。这也是搜索 Agent 实现酒店预订的底层能力之一机器可读数据 意图解析 交易接口三者缺一不可。如果你的产品需要接入真实预订系统建议在页面中同样输出标准 JSON-LD让搜索引擎和 AI Agent 能低成本理解你的库存和价格。这既有利于搜索收录也有利于被 AI 搜索推荐。6. 运行结果与效果验证本地原型跑通之后你可以用三种方式来验证效果。第一种直接运行主程序cd ai-travel-demo python demo/main.py 帮我查上海到北京的机票日期是2025-06-20 --run-times 3 --interval 1注意我们 main.py 目前没有支持命令行参数传入只支持硬编码 query。你可以手动修改 main.py 中的 query或者在 main.py 里扩展 sys.argv 解析。原型阶段直接改代码是最快的验证方式。第二种验证数据库是否写入历史cd ai-travel-demo python -c import sqlite3; conn sqlite3.connect(price_history.db); print(conn.execute(select * from quote_history).fetchall())你应该能看到多条价格记录并且每次运行后同一航线、同一日期会追加新记录。这说明价格追踪的数据链路是通的。第三种验证提醒逻辑。由于报价是随机的不一定每次都能触发提醒。你可以手动把 ALERT_THRESHOLD 调成 0.01也就是降幅超过 1% 就提醒。这样在随机价格波动下几乎每次都会触发用来验证提醒输出是否正常。如果运行失败第一步看哪里看 Python 解释器版本是否满足 3.10语法不支持会导致运行直接报错。看当前目录是否为 ai-travel-demo如果路径不对sqlite3 会在子目录下创建数据库可能造成“数据没写入”的错觉。看 import 语句是否报错尤其是直接运行 main.py 时要保证它和 intent_parser.py 在同一目录。7. 常见问题与排查思路问题现象可能原因排查方式解决方案导入模块报错 ModuleNotFoundError运行目录不对或者模块路径缺失查看当前目录和报错信息在 demo 目录下运行或用 python -m demo.main没有触发任何提醒ALERT_THRESHOLD 设置过高或模拟价格变动不够打印每次价格和上一次价格临时调低阈值确认 should_alert 逻辑数据库文件找不到SQLite 连接的是相对路径运行目录变化搜索 price_history.db 文件位置在 PriceTracker 中使用绝对路径或基于项目根目录的路径日期解析失败用户输入格式和正则不匹配打印 intent 字典统一日期格式或改用 LLM 做意图解析重复调用正式报价接口被限流生产环境没有做缓存和限流查看接口返回的 429 或限流错误码添加本地缓存、异步刷新、降低轮询频率搜索结果页面推荐了已下架房型结构化数据与实际库存不同步检查页面 JSON-LD 和真实库存接口将availability字段实时对接库存系统而不是硬编码用户重复预订同一天同一房型缺少幂等性校验查看订单表是否有重复记录用外部订单号或用户日期房型做唯一约束8. 最佳实践与工程建议8.1 对普通用户的建议如果你开始使用 AI Mode 规划出行有几点值得注意把 AI 当“助手”而不是“决策者”。AI 推荐航班和酒店基于的是历史数据和实时报价但它不知道你对“太早”“太晚”的接受程度也不会替你判断转机风险。看到降价提醒后先确认退改政策、行李额、航班是否真实可订再进入预订流程。提醒触发的是“价格变化”不代表“一定合适”。涉及支付时务必走官方平台和受信任的支付通道不要在第三方对话页面里直接泄露卡号、证件号等敏感信息。8.2 对开发者的建议从工程角度看如果你要在自己的产品里做类似的价格追踪和预订能力建议把下面几点当成基础约束数据源必须合法合规。使用已授权的报价接口做好限流、超时、重试。不要抓取第三方页面更不要用代理池绕过限制。短期能跑长期会被封禁而且有法律风险。价格追踪要设计成“可恢复”的任务。用户可能隔一天再打开页面系统需要有能力从之前关注的位置继续追踪而不是从头再来。提醒要设置频率上限。频繁推送会消耗用户信任建议同一航线一天最多提醒一次除非出现大幅异常降价。交易环节一定要做幂等设计。用户点击“预订”后网络超时他可能会再点一次。系统要保证两次点击不会生成两笔订单。常见做法是在前端生成一个唯一请求 ID由后端判断重复。状态变化要留日志。价格追踪系统最难排查的问题是“用户为什么没收到提醒”。任何一次价格获取、阈值判断、提醒发送都应该有日志。8.3 对产品设计者的建议搜索产品做“任务执行”最容易忽视的是失败处理推荐失败了可以换个结果但预订失败不能假装成功。产品上至少要设计三条路径成功路径、失败重试路径、放弃路径。放弃路径尤其重要。用户通过 AI 找到合适的酒店后可能仍希望自己在官方页面下单。产品要允许用户“带着上下文跳转”而不是强迫用户在 AI 界面里完成所有操作。这不只是体验问题也是信任问题——用户需要感到自己始终可以控制最终决策。另外价格追踪类的产品要让用户清楚知道“系统在帮你做什么”。收到降价提醒时用户应该能一眼看到这是哪条航线、之前价格是多少、现在价格是多少、价格是否包含税费。模糊的提醒比不提醒更容易让用户流失。9. 总结与后续学习方向Google AI Mode 这次新增的机票价格追踪与酒店预订功能把搜索的边界从“返回信息”推到了“执行任务”。拆到技术层面它背后是意图解析、实时报价、价格追踪、交易闭环四个环节的协同放到产品层面它意味着搜索想真正成为用户的出行助理而不是一个更聪明的链接列表。对于开发者来说最有价值的不是追逐某一个具体功能而是理解这套逻辑搜索正在变成有状态、可执行、有责任边界的系统。价格追踪系统用 SQLite 记录历史、计算降幅、触发提醒虽然是最小实现但它是很多 AI Agent 产品的地基。下一步你可以继续深入几个方向自然语言意图解析升级为 LLM 工具调用、报价数据源切换为真实授权接口、提醒通道接入邮件或消息推送、交易模块加入幂等和退款处理。这套能力看起来离普通开发很远其实每一步都可以从一个小原型开始。先把“查询→报价→记录→提醒”这个最小闭环跑通再逐步补上交易和合规能力你也就真正理解了 AI Mode 这次更新背后的工程分量。