企业官网建设流程全解析

最近 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 会在后台持续跟踪这条航线的价格变化，并在合适的时间给出提醒。

从技术角度拆解，这个功能至少包含四层逻辑：

1. 航线意图提取：从自然语言中提取出发城市、到达城市、出行日期、舱位类型、目标价格等参数。
2. 数据源接入：对接航班报价数据接口，获取实时或准实时的机票价格快照。
3. 定时对比任务：按照一定频率抓取最新价格，并与历史价格做对比，判断是否出现明显波动。
4. 触发通知：当价格降到用户设定的阈值，或者出现比历史均值低一定比例时，生成提醒。

这里面最容易被忽视的是“价格波动”的判断标准。机票价格受淡旺季、节假日、航空公司调价策略影响很大，简单地和昨天的价格比较没有意义，必须结合历史价格分布和未来出行日期进行综合判断。

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 做机票追踪、里程查询、酒店预订，本质上是在大模型的能力之上，增加了对第三方工具和服务的调用能力。模型负责理解“用户想干什么”，工具负责“把事办成”。

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(default=None, description="出发日期，格式 YYYY-MM-DD") return_date: Optional[str] = Field(default=None, description="返程日期，格式 YYYY-MM-DD") target_price: Optional[int] = Field(default=None, description="用户期望的目标价格（人民币）") cabin_class: str = Field(default="economy", description="舱位：economy/premium/business/first") class MileageQueryParams(BaseModel): airline_code: Optional[str] = Field(default=None, description="航司二字码，例如 CA/MU/CZ") query_type: str = Field(description="查询类型：balance(余额)/award(兑换试算)") route: Optional[str] = Field(default=None, 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(default=2, description="入住人数") budget: Optional[int] = Field(default=None, description="预算上限（人民币/晚）") keywords: Optional[str] = Field(default=None, 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 能力对比表

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 节的原型代码跑通，再用真实数据源替换模拟数据，最后补上授权、日志和监控。一步步来，比一开始就追求“大而全”要稳妥得多。