返回博客
AI 旅行 Agent
AI 旅行 Agent 架构指南：从意图理解到真实预订
一套面向生产环境的 AI 旅行 Agent 架构：分离模型推理、实时出行库存、交易确认与基于 Webhook 的订单状态。
龙虾出行工程团队发布于 更新于 12 分钟阅读
直接答案
生产级 AI 旅行 Agent 应让模型负责理解意图和制定计划，让出行工具提供实时库存与可预订报价，在交易前要求明确确认，并在下单后以订单 API 和 Webhook 事件作为状态事实来源。
什么是 AI 旅行 Agent？
AI 旅行 Agent 是把用户的出行目标转化为搜索、比较、预订与售后动作的软件系统。它不只是聊天界面，因为真实出行需要连接实时系统、处理约束，并准确保存交易状态。
- 大模型理解目的地、日期、旅客、预算和偏好。
- 出行工具返回当前班次、库存、房价、运价和政策。
- 应用负责身份、权限、确认界面和支付准备。
- 订单 API 与 Webhook 负责待确认、已确认、改签、取消等履约状态。
最重要的边界
模型文本可以解释结果，但不能成为价格、订单、支付或履约事件的事实记录。这些事实必须来自工具和交易系统。
从意图到真实预订的参考架构
稳健的设计会把可逆的规划过程与涉及订单、资金的动作明确分开。
- 1. 收集意图提取出发地、目的地、日期、旅客、预算、偏好与尚未明确的约束。
- 2. 制定工具计划决定需要调用机票、酒店、用车、高铁或巴士工具，并识别可并行查询。
- 3. 搜索实时供给通过结构化工具读取当前库存，并保留供应商、搜索和报价标识。
- 4. 验价与校验检查可用性、总价、退改规则、旅客资料和企业政策。
- 5. 明确确认展示最终选项和完整价格，在创建订单前取得清晰授权。
- 6. 追踪履约通过订单查询与 Webhook 获取确认、出票、司机、改签和取消状态。
MCP、REST API 和 Webhook 如何分工
三者解决不同问题。把它们混成一个接口，通常会让 Agent 的权限和状态更难控制。
| 接口 | 适合承担的职责 | 不应承担的职责 |
|---|---|---|
| MCP 工具 | 供模型发现和调用的搜索、报价与规划能力 | 隐藏支付或无确认自动下单 |
| REST API | 由应用控制的下单、查询、改签和取消 | 充当非结构化对话记忆 |
| Webhook | 供应商和订单生命周期的异步事件 | 直接作为面向用户的解释层 |
| 应用界面 | 身份、授权、政策和最终交易确认 | 替代实时库存与验价调用 |
可落地的做法是：把低风险、只读能力开放给模型，把创建订单和资金动作留在应用控制的服务端接口。模型可以建议动作，但应用决定动作是否被允许、是否已获得确认。
把交易边界设计成显式流程
出行订单同时涉及身份信息、易变库存、政策限制和资金，不能把一句自然语言默认视为交易授权。
创建订单前至少校验：
- 旅客姓名与所选产品要求的身份字段一致。
- 日期、城市、机场、车站、上车点和时区没有歧义。
- 报价仍可用，最终总价没有出现未解释的变化。
- 退改、行李、房型、取消和企业差旅政策已展示。
- 用户确认的是即将提交的同一产品和同一总价。
下单之后
不要因为请求已经发出就让助手宣称成功。只有订单 API 或后续事件返回确认状态后，才能向用户展示已确认。
生产环境检查表
| 领域 | 最低生产要求 |
|---|---|
| 工具契约 | 类型化输入输出、职责单一、稳定标识 |
| 可观测性 | 请求 ID、工具延迟、供应商错误、订单事件和用户可见状态 |
| 恢复能力 | 安全重试、超时处理、支持幂等时使用幂等、人工接管 |
| 安全 | 服务端凭证、最小权限、审计记录、明确确认 |
| 体验 | 解释备选项、披露不确定性、保留上下文但不编造事实 |
常见问题
AI 旅行 Agent 和旅行聊天机器人有什么区别？
聊天机器人可能只回答问题；AI 旅行 Agent 还会协调结构化工具、实时库存、应用政策、交易确认和订单状态，支持真实出行工作流。
AI 旅行 Agent 可以自动下单吗？
搜索和规划通常可以自动运行。创建、改签、取消订单或支付应经过明确的用户确认或企业政策授权，并留下可审计记录。
Agent 如何保证出行数据是最新的？
在做决定时调用实时搜索和报价工具，保留报价标识，在下单前重新校验，并在提交后使用订单 API 与 Webhook 事件追踪状态。