近段时间AI 搜索类产品密集迭代Google AI Mode 在整合航班与酒店信息时不再是简单给出链接列表而是把“机票价格追踪”和“酒店预订”直接做进了对话流程里。对一个长期做后端和搜索技术的人来说这个变化值得拆开看AI Mode 背后的查询理解、意图识别、状态追踪和工具调用几乎把传统搜索引擎、OTA在线旅游平台和客服机器人三件事合并成了一条链路。本文会围绕这个功能展开先理清 AI Mode 与普通搜索的区别再从工程视角拆解“价格追踪”和“酒店预订”的实现逻辑最后给出一套可运行的模拟项目示例帮助后端开发者和 AI 应用开发者理解这类功能落到工程上大概需要哪些模块。内容偏系统设计与代码实现不涉及具体厂商 API 的细节重点演示设计思路。1. 背景与核心概念1.1 Google AI Mode 是什么Google AI Mode 是 Google 搜索中基于大语言模型LLM的交互式搜索模式。用户不再通过输入关键词获取十条蓝色链接而是可以输入一句完整的口语化需求例如帮我找下个月从上海到东京的机票如果价格低于 2500 元就提醒我。传统搜索引擎会返回一堆航班比价网站链接而 AI Mode 会尝试理解这句话里的几个关键信息出发地上海目的地东京出行时间下个月价格阈值2500 元用户需求价格追踪提醒这个过程本质上是一次意图解析Intent Parsing把自然语言转成结构化查询条件再调用航班查询接口、价格历史接口和订阅提醒服务最后把结果汇总成一段自然语言回答。新增的“机票价格追踪”功能意味着 AI Mode 具备了持续监控能力。它不再只是回答“现在多少钱”而是定期检查目标航线的价格变化并在价格低于阈值或出现大幅波动时通知用户。这里有个容易混淆的点传统机票 App 的“降价提醒”是围绕固定航班或航线做的规则任务而 AI Mode 的“机票价格追踪”是围绕一段对话上下文来做的 Agent 任务。用户可以说“顺便也看看高铁”“只选星空联盟的航班”“如果是红眼航班就不要提醒”这些约束会被一起纳入追踪条件。1.2 酒店预订功能的产品逻辑“酒店预订”接入 AI Mode 后用户可以在对话里完成从搜索、比价到下单的完整闭环。典型的对话流程如下用户帮我找下周五到周日杭州西湖附近的酒店预算 600 元以内。AI Mode返回符合条件的酒店列表并标注距离、评分、早餐、取消政策。用户选第二家吧要带早餐的房间。AI Mode展示房型和价格询问入住人信息。用户确认后AI Mode 调起预订接口完成下单。从产品形态来看这更像是把 Google 的旅行生态能力Flights、Hotels、Maps封装成一组可被大模型调用的工具Tool/Function。大模型负责理解用户意图、维护多轮对话状态、生成最终回复真正查数据、下单、支付的动作仍然由专业服务完成。对开发者来说这个功能最有借鉴意义的地方在于它演示了 AI Agent 如何与真实业务系统对接以及如何通过工具调用层把不可控的生成结果限制在可控的业务动作范围内。1.3 几个需要区分的技术概念AI Mode面向用户的交互界面本质是搜索入口 对话界面 Agent 调度器。搜索意图解析从自然语言中提取结构化信息例如日期、地点、预算、人数。工具调用Function CallingLLM 生成结构化的函数调用参数由后端系统执行真实业务逻辑。价格追踪任务一种定时任务或事件驱动任务定期拉取价格数据并与用户设置的阈值比较。预订状态机酒店预订涉及查询、选房、填写信息、确认、支付、完成等多个状态需要可靠的状态管理。理解这些概念后再往下看系统架构就会顺畅很多。2. 系统架构与核心模块拆解2.1 整体架构分层从工程实现角度一个完整的 AI 旅行助手可以拆成四层用户对话层 │ ▼ AI Agent 调度层意图识别、多轮对话、上下文管理、决策 │ ▼ 业务工具层航班查询、价格追踪、酒店搜索、预订状态机、支付 │ ▼ 数据层航班价格库、酒店房源库、用户订阅表、预订订单表AI Mode 在这种架构中承担的是“调度层”的角色它不直接拥有航班和酒店数据而是以工具调用的方式访问底层服务。这样做的好处是机票和酒店的价格、库存、退改政策都由专业业务系统维护AI 只负责理解用户和生成回复避免大模型幻觉污染核心交易数据。2.2 查询理解与意图识别模块用户输入一段自然语言后系统需要完成以下任务识别领域旅行、购物、天气、新闻等。识别动作搜索、比价、订阅提醒、下单。抽取实体出发地、目的地、日期、人数、预算。提取约束偏好航空公司、酒店品牌、取消政策、早餐要求。一个实用的做法是使用 Function Calling。把可用的工具以 JSON Schema 的形式传给大模型例如搜索酒店{ name: search_hotels, description: 根据条件搜索可用酒店, parameters: { type: object, properties: { city: { type: string, description: 城市名 }, area: { type: string, description: 区域或地标 }, check_in: { type: string, description: 入住日期 yyyy-MM-dd }, check_out: { type: string, description: 离店日期 yyyy-MM-dd }, budget: { type: number, description: 每晚预算上限 } }, required: [city, check_in, check_out] } }大模型会根据用户输入生成类似下面这样的调用请求然后由后端执行真实的酒店搜索{ city: 杭州, area: 西湖, check_in: 2025-06-13, check_out: 2025-06-15, budget: 600 }在演示项目中这类解析可以由大模型完成也可以用规则和词表完成。规则方式虽然效果粗糙但成本低、可控性强适合验证原型。2.3 价格追踪任务机制价格追踪和普通搜索最大的不同在于“持续性”。用户搜索机票时只得到一个瞬时结果而价格追踪要求系统在用户设置条件后持续运行直到满足条件或用户取消。价格追踪的核心组件如下追踪规则表记录用户 ID、航线/日期、价格阈值、通知方式、创建时间、状态。定时调度器周期性执行价格查询任务。价格比较器将最新价格与阈值比较触发变更事件。通知服务通过邮件、短信、App Push 等方式告知用户。用户取消入口允许用户随时停止追踪。在架构上价格追踪任务需要考虑三个问题查询频率机票价格一天内变化多次但过于频繁的查询会给上游接口带来压力。常见做法是价格波动期提高频率平稳期降低频率。避免重复通知价格第一次低于阈值时通知一次不能每次调度都重复提醒。任务失败重试上游接口超时或返回异常时需要记录日志并稍后重试不能直接丢失任务。2.4 酒店预订的闭环状态管理酒店预订比价格追踪复杂因为它是多步骤、有状态、涉及资金操作的流程。预订通常分为以下几个状态状态说明INIT用户发起预订意向QUOTED服务端返回报价和可订房型FORM_FILLED用户填写入住人信息CONFIRMED渠道确认预订成功PAID支付完成CANCELLED用户取消或预订失败在 AI Mode 的对话场景里状态管理尤其关键因为用户可能随时改变主意说“算了换一家”或者问“刚才那个订单现在什么状态”。Agent 必须把对话上下文和业务订单状态同步起来否则就会出现“AI 说已预订、实际订单不存在”的问题。推荐的做法是AI Agent 只负责收集信息和展示结果真正的订单状态统一由后端预订服务维护Agent 每次通过查询接口获取最新状态而不是把状态存在对话里。3. 环境准备与工具选择看完架构我们先准备一个可运行的模拟环境用来实现一个简化版的“AI 机票价格追踪 酒店预订助手”。3.1 技术选型本文示例使用以下技术栈Python 3.9FastAPI提供 Web 接口模拟 AI Agent 调度入口APScheduler实现价格追踪的定时任务SQLite存储用户、订阅、订单数据Pydantic做数据模型校验Uvicorn本地启动服务具体版本不固定读者可根据自己的 Python 环境调整。整个项目的目的是演示核心设计不依赖任何第三方商业 API。3.2 项目结构ai-travel-agent/ ├── app │ ├── __init__.py │ ├── main.py # FastAPI 入口 │ ├── models.py # 数据模型 │ ├── schemas.py # 请求/响应校验模型 │ ├── tools.py # 工具层搜索酒店、查航班、模拟下单 │ ├── tracker.py # 价格追踪调度器 │ └── database.py # SQLite 初始化与连接 ├── requirements.txt └── README.md3.3 安装依赖pip install fastapi uvicorn pydantic apscheduler安装完成后把项目结构创建好接下来逐个模块实现。需要说明的是这里所有数据均为模拟数据目的是把系统运行链路跑通。如果要在真实环境中落地应替换为合规的航班和酒店数据源并在授权前提下获取用户预订和通知所需的信息。4. 完整实战示例AI 旅行助手核心模块4.1 初始化数据库首先实现database.py负责创建数据库和基础表结构。# 文件路径app/database.py import sqlite3 from contextlib import contextmanager DB_PATH travel_agent.db SCHEMA CREATE TABLE IF NOT EXISTS price_alerts ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, route TEXT NOT NULL, depart_date TEXT NOT NULL, threshold_price REAL NOT NULL, status TEXT NOT NULL DEFAULT active, notified INTEGER NOT NULL DEFAULT 0, created_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE IF NOT EXISTS hotel_bookings ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id TEXT NOT NULL, hotel_name TEXT NOT NULL, city TEXT NOT NULL, check_in TEXT NOT NULL, check_out TEXT NOT NULL, room_type TEXT NOT NULL, total_price REAL NOT NULL, status TEXT NOT NULL DEFAULT QUOTED, created_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP ); contextmanager def get_conn(): conn sqlite3.connect(DB_PATH) conn.row_factory sqlite3.Row try: yield conn conn.commit() finally: conn.close() def init_db(): with get_conn() as conn: conn.executescript(SCHEMA) if __name__ __main__: init_db() print(数据库初始化完成)这里把两张表放在一起price_alerts用于价格追踪订阅hotel_bookings用于保存酒店预订状态。注意status字段后续预订状态机要靠它流转。4.2 定义数据模型下面是models.py使用 Pydantic 定义 API 出入参模型。# 文件路径app/models.py from typing import Optional from pydantic import BaseModel class PriceAlertRequest(BaseModel): user_id: str route: str # 例如 上海-东京 depart_date: str # 例如 2025-07-10 threshold_price: float # 阈值价格 email: Optional[str] None class HotelSearchRequest(BaseModel): city: str area: Optional[str] None check_in: str check_out: str budget: Optional[float] None class HotelBookingRequest(BaseModel): user_id: str hotel_name: str city: str check_in: str check_out: str room_type: str total_price: floatPydantic 的作用是保证进入核心业务逻辑的数据是合法、完整的。比如threshold_price必须是数字check_in必须是字符串且建议在业务层再校验日期格式。4.3 实现工具层工具层模拟真实业务系统。这里会实现以下函数search_hotels()返回模拟酒店列表。create_booking()创建预订记录。cancel_booking()取消预订。get_flight_price()模拟返回航线价格。create_price_alert()创建价格追踪任务。# 文件路径app/tools.py import random from datetime import datetime from database import get_conn # ---------- 酒店模拟数据 ---------- MOCK_HOTELS [ { hotel_name: 西湖湖畔酒店, city: 杭州, area: 西湖, price_per_night: 520, rating: 4.5, breakfast_included: True, }, { hotel_name: 河坊街精品客栈, city: 杭州, area: 河坊街, price_per_night: 380, rating: 4.2, breakfast_included: False, }, { hotel_name: 钱江新城商务酒店, city: 杭州, area: 钱江新城, price_per_night: 650, rating: 4.7, breakfast_included: True, }, ] def search_hotels(city: str, area: str, check_in: str, check_out: str, budget: float): 模拟酒店搜索返回与条件匹配的酒店列表 nights calculate_nights(check_in, check_out) results [] for hotel in MOCK_HOTELS: if hotel[city] ! city: continue if area and hotel[area] ! area: continue if budget and hotel[price_per_night] budget: continue total_price hotel[price_per_night] * nights results.append({ hotel_name: hotel[hotel_name], area: hotel[area], price_per_night: hotel[price_per_night], total_price: total_price, rating: hotel[rating], breakfast_included: hotel[breakfast_included], }) return results def calculate_nights(check_in: str, check_out: str) - int: 计算入住晚数 in_date datetime.strptime(check_in, %Y-%m-%d) out_date datetime.strptime(check_out, %Y-%m-%d) nights (out_date - in_date).days if nights 0: raise ValueError(离店日期必须晚于入住日期) return nights def create_booking(user_id: str, hotel_name: str, city: str, check_in: str, check_out: str, room_type: str, total_price: float): 创建酒店预订记录初始状态为 QUOTED with get_conn() as conn: cursor conn.execute( INSERT INTO hotel_bookings (user_id, hotel_name, city, check_in, check_out, room_type, total_price, status) VALUES (?, ?, ?, ?, ?, ?, ?, QUOTED) , (user_id, hotel_name, city, check_in, check_out, room_type, total_price), ) booking_id cursor.lastrowid return {booking_id: booking_id, status: QUOTED} def confirm_booking(booking_id: int): 模拟确认预订将状态从 QUOTED 更新为 CONFIRMED with get_conn() as conn: conn.execute( UPDATE hotel_bookings SET status CONFIRMED WHERE id ?, (booking_id,), ) return {booking_id: booking_id, status: CONFIRMED} def get_flight_price(route: str, depart_date: str) - float: 模拟实时机票价格加入小幅随机波动 base_price_map { 上海-东京: 2800, 北京-上海: 680, 上海-杭州: 420, } base base_price_map.get(route, 1500) # 模拟价格波动 return round(base random.randint(-300, 300), 2) def create_price_alert(user_id: str, route: str, depart_date: str, threshold_price: float): 创建价格追踪订阅 with get_conn() as conn: cursor conn.execute( INSERT INTO price_alerts (user_id, route, depart_date, threshold_price, status, notified) VALUES (?, ?, ?, ?, active, 0) , (user_id, route, depart_date, threshold_price), ) alert_id cursor.lastrowid return {alert_id: alert_id, status: active}代码里值得注意的点calculate_nights()里对日期做了基本校验防止入住日期晚于离店日期。预订初始状态为QUOTED后续通过confirm_booking()流转到CONFIRMED。机票价格是模拟值每次调用会返回不同结果方便后面演示价格追踪。4.4 实现价格追踪调度器价格追踪是核心亮点我们用 APScheduler 实现一个简单的后台任务。# 文件路径app/tracker.py import logging from datetime import datetime from apscheduler.schedulers.background import BackgroundScheduler from database import get_conn from tools import get_flight_price logger logging.getLogger(__name__) def check_price_alerts(): 扫描所有 active 状态的价格追踪任务与最新票价比较 with get_conn() as conn: alerts conn.execute( SELECT * FROM price_alerts WHERE status active AND notified 0 ).fetchall() for alert in alerts: latest_price get_flight_price(alert[route], alert[depart_date]) if latest_price alert[threshold_price]: logger.info( 用户 %s 订阅的 %s 价格 %s 已低于阈值 %s, alert[user_id], alert[route], latest_price, alert[threshold_price], ) # 标记为已通知避免重复提醒 with get_conn() as conn: conn.execute( UPDATE price_alerts SET notified 1, status triggered WHERE id ?, (alert[id],), ) else: logger.info( 用户 %s 订阅的 %s 当前价格 %s 未低于阈值 %s, alert[user_id], alert[route], latest_price, alert[threshold_price], ) scheduler BackgroundScheduler() scheduler.add_job(check_price_alerts, interval, seconds30, idprice_tracker, replace_existingTrue) def start_scheduler(): if not scheduler.running: scheduler.start() logger.info(价格追踪调度器已启动每 30 秒执行一次)为什么这里要设notified 0作为过滤条件因为价格追踪的核心诉求是“只在第一次达到条件时通知”否则用户每 30 秒收到一条降价提醒体验会很差。用户如果要重新追踪可以创建一条新的订阅记录。4.5 实现 FastAPI 入口把工具层和调度器串起来提供 Web 接口。# 文件路径app/main.py from fastapi import FastAPI, HTTPException from models import PriceAlertRequest, HotelSearchRequest, HotelBookingRequest from tools import ( search_hotels, create_booking, create_price_alert, confirm_booking, ) from tracker import start_scheduler from database import init_db app FastAPI(titleAI Travel Agent Demo) init_db() app.on_event(startup) def on_startup(): start_scheduler() app.get(/) def root(): return {message: AI Travel Agent Demo is running} app.post(/api/hotels/search) def api_search_hotels(req: HotelSearchRequest): 酒店搜索接口 try: hotels search_hotels( cityreq.city, areareq.area, check_inreq.check_in, check_outreq.check_out, budgetreq.budget, ) except ValueError as e: raise HTTPException(status_code400, detailstr(e)) return {results: hotels} app.post(/api/hotels/booking) def api_create_booking(req: HotelBookingRequest): 创建酒店预订 result create_booking( user_idreq.user_id, hotel_namereq.hotel_name, cityreq.city, check_inreq.check_in, check_outreq.check_out, room_typereq.room_type, total_pricereq.total_price, ) return result app.post(/api/hotels/booking/{booking_id}/confirm) def api_confirm_booking(booking_id: int): 确认酒店预订 result confirm_booking(booking_id) return result app.post(/api/price-alerts) def api_create_price_alert(req: PriceAlertRequest): 创建价格追踪订阅 result create_price_alert( user_idreq.user_id, routereq.route, depart_datereq.depart_date, threshold_pricereq.threshold_price, ) return result这个入口文件把核心接口暴露出来真实项目中还可以加用户鉴权、限流、日志等中间件。这里只保留最基础的逻辑。4.6 运行与验证先启动服务cd ai-travel-agent uvicorn app.main:app --reload --port 8000启动后会看到调度器日志说明价格追踪每 30 秒跑一次。然后模拟一个价格追踪场景。用 curl 创建一个“上海-东京”的降价提醒阈值设为 2500 元curl -X POST http://localhost:8000/api/price-alerts \ -H Content-Type: application/json \ -d { user_id: user01, route: 上海-东京, depart_date: 2025-07-10, threshold_price: 2500 }如果当前模拟价格高于 2500日志会显示“未低于阈值”。如果价格随机波动到 2500 以下日志会显示“已低于阈值”并且任务状态被标记为triggered不会重复通知。再模拟酒店搜索curl -X POST http://localhost:8000/api/hotels/search \ -H Content-Type: application/json \ -d { city: 杭州, area: 西湖, check_in: 2025-06-13, check_out: 2025-06-15, budget: 600 }预期返回结果中只有“西湖湖畔酒店”符合条件每晚 520 元两晚总价 1040 元。接着可以创建一个预订curl -X POST http://localhost:8000/api/hotels/booking \ -H Content-Type: application/json \ -d { user_id: user01, hotel_name: 西湖湖畔酒店, city: 杭州, check_in: 2025-06-13, check_out: 2025-06-15, room_type: 大床房, total_price: 1040 }返回结果会包含新增的booking_id此时状态为QUOTED。接着确认curl -X POST http://localhost:8000/api/hotels/booking/1/confirm状态更新为CONFIRMED。到这里一个简化版的核心链路就完整跑通了。下一节来分析实际接入 AI Mode 时常见的问题。5. 常见问题与排查思路5.1 大模型生成了错误的工具调用参数问题现象常见原因解决思路大模型把“下个月”解析成了错误日期时间表达依赖当前日期上下文模型对相对时间理解不稳定在后端做日期归一化结合服务端当前时间解析相对日期城市名带上了“市”字导致匹配失败实体抽取结果未标准化维护城市别名表统一映射到标准城市编码用户说“不要靠近火车站”模型忽略了反向约束约束条件抽取不完整使用更强的意图解析策略或增加一轮追问这类问题在 AI Mode 场景里很常见。解决思路不是让大模型更准而是在大模型和业务系统之间加一层参数校验和实体归一化服务。大模型负责“理解”业务系统负责“执行”中间加一个 adapter 负责“翻译”。5.2 价格追踪任务没有触发问题现象常见原因解决思路价格追踪任务一直不跑调度器没有启动检查启动日志确认start_scheduler()是否被调用条件已满足但没通知notified字段为 1检查数据库中该订阅的状态确认是否已被触发过通知信息缺失订阅时没有保存联系方式在创建订阅接口强制要求邮箱或手机号任务执行失败上游接口超时或返回异常在check_price_alerts中加入 try-except 并记录日志失败任务延时重试5.3 酒店预订状态不一致用户在 AI 对话里说“帮我预订”但最终订单可能没有真正生成。原因是对话流程中的“预订”只是 Agent 的意图真实状态必须由预订服务持久化。排查时按以下顺序确认用户输入是否真的触发了create_booking调用。查看hotel_bookings表中是否存在对应记录。检查预订接口返回的booking_id是否被 Agent 正确保存。如果 Agent 在生成回复时丢失了booking_id需要设计从对话上下文读取最新订单 ID 的逻辑。5.4 用户隐私与数据授权价格追踪和酒店预订都会涉及用户个人数据比如邮箱、手机号、住客姓名、支付信息。这部分在实际产品中必须谨慎处理获取用户订阅和预订需要明确授权。通知功能只能通过用户主动订阅开通。存储用户信息时要加密并且遵循最小够用原则。涉及支付操作时不能在日志中打印完整卡号或敏感凭证。6. 最佳实践与工程建议6.1 所有工具调用都要可追踪AI Mode 的本质是多轮对话 工具调用。每一次真实业务动作查价格、创建订阅、下单都应该有独立的调用记录。建议在工具层增加统一的日志埋点至少记录调用来源哪个会话、哪条消息调用参数返回结果耗时错误信息这样当用户反馈“AI 自动给我订了酒店”时可以快速定位到具体是哪个环节产生的动作方便回滚和追责。6.2 不要让大模型直接执行不可逆操作酒店预订、机票出票、取消订单这类操作建议设计为两阶段确认第一阶段Agent 生成预订参数返回给用户确认。第二阶段用户明确确认后再执行真正的下单动作。对应到状态机上就是QUOTED → CONFIRMED需要一次显式操作而不是大模型生成一句“好的已为您预订”就直接调下单接口。6.3 价格追踪宜采用“查询窗口 动态频率”策略固定频率调度虽然简单但不够灵活。航线起飞前 7 天和起飞前 24 小时的价格波动特性完全不同。更合理的方式是起飞时间远时每天查询 1 到 2 次即可。起飞时间临近时提高查询频率到每小时或每 30 分钟。用户阈值非常接近历史低位时也可以提高频率。注意提高频率会给数据源增加压力真实环境中需要评估上游接口的限流策略。6.4 酒店搜索要有缓存和排序策略AI Mode 返回酒店列表时响应速度直接影响用户体感。酒店房源数据相对稳定价格和库存会变但基础信息可以缓存。建议酒店基础信息名称、地址、设施、评分缓存 24 小时。实时价格和库存按需查询缓存 5 到 10 分钟。搜索结果按“综合推荐”排序不要只按价格否则用户问“评分高的”时又要重新排序。缓存的同时要保证价格准确不能让用户看到缓存过期价格后下单失败。6.5 维护会话上下文中的业务状态在多轮对话场景里用户可能先搜索酒店再问“这个能取消吗”最后说“订了吧”。每一步都可能改变上下文中的业务对象。建议为每个会话维护一个轻量级的上下文对象结构类似{ session_id: session_001, last_booking_id: 1001, last_search_condition: { city: 杭州, area: 西湖, check_in: 2025-06-13, check_out: 2025-06-15 }, pending_booking: { hotel_name: 西湖湖畔酒店, room_type: 大床房, total_price: 1040 } }注意这个上下文只用于自然语言理解和展示层订单最终状态以数据库为准。6.6 安全边界与合规注意AI Mode 接入真实交易时安全是最重要的工程约束必须对每个 API 请求做身份认证和权限校验。用户只能查询和修改自己的订阅、订单。下单、取消、退款等敏感操作需要二次确认。涉及支付时必须走正规支付渠道不在日志中记录完整凭据。遵守当地关于个人信息保护的法律法规在用户授权范围内使用数据。演示项目里没有做这些但真实产品一个都不能少。7. 总结与学习路线从 Google AI Mode 这次更新可以看出AI 搜索正在从“给链接”转向“办事情”。机票价格追踪意味着 AI 具备了持续执行的 Agent 能力酒店预订则意味着 AI 深入到交易闭环。对开发者来说这两块能力对应的技术点其实非常清晰自然语言转结构化参数、Function Calling、任务调度、状态机、用户授权与安全边界。本文用一个可运行的示例项目演示了这些核心模块包括如何把用户意图映射为工具调用参数。如何用 APScheduler 实现价格追踪任务。如何用 SQLite 持久化订阅和预订状态。如何通过 FastAPI 暴露真实业务接口。如果你想继续深入可以按下面路线学习先掌握 FastAPI 和 Pydantic 的基础用法把接口层写扎实。再学习 Function Calling 的原理和提示词设计理解大模型如何生成结构化调用参数。接着研究状态机的设计模式把预订流程的每个状态流转梳理清楚。最后再把消息队列如 RabbitMQ、Kafka引入价格追踪提升任务处理的吞吐和可靠性。推荐的方式是先把本文示例跑通然后逐步把模拟价格改成真实数据源把模拟下单改成调真实渠道接口在改造过程中你会遇到大量细节问题这些坑本身就是最有价值的实践经验。希望这篇文章能帮你少走一些弯路。如果本文对你有帮助可以先收藏备用。后续我再结合实际项目继续分享 AI Agent 与交易系统打通的相关经验。