Agent 旅游出行：先把库存、规则和人工改签串起来，再谈全自动旅行助理

很多关于旅游出行的文章，会把 Agent 写成一个全能助手：

• •自动做行程
• •自动下单
• •自动比价
• •自动处理改签退订

这些方向听起来都很好，但真实旅游服务的难点往往不是“推荐得够不够懂你”，而是：

• •库存和价格是不是实时的
• •退改规则、签证限制和行李政策有没有被正确纳入
• •多供应商链路里谁负责最终确认
• •出现航变、取消或超售时，系统能不能稳住服务流程

所以旅游 Agent 更适合先做“咨询、方案整理和异常协同助手”，而不是一个直接替代库存系统和出票流程的万能顾问。

如果第一版就想覆盖从需求收集、选品、支付、出票到售后全部流程，项目很快就会在库存、政策和客服边界上失控。

更现实的切入点通常是：

• •行程报价助手
• •改签退订协同
• •团单资料收集
• •行前准备提醒

以“改签与行程助手”为例，一个可交付的第一版通常已经很有价值：

• •收集旅客约束条件和当前订单事实
• •拉取库存、价格和退改政策
• •生成可行方案和差异对比
• •标记哪些动作需要人工客服或旅客确认
• •不直接绕过支付、出票和供应商确认链路

这类链路比“自动帮你搞定所有旅行安排”更适合真实业务。

1. 旅客需求与订单事实层

这一层至少要搞清楚：

• •出发地、目的地和时间窗
• •预算、舱位、酒店偏好和同行人数
• •当前订单状态
• •证件、签证和行李等特殊约束

如果这些基础事实没有被结构化记录，后面的推荐和售后都很容易跑偏。

2. 库存与政策规则层

旅游行业的复杂性，大量来自规则和供应商：

• •机票、酒店和地接库存
• •价格波动和锁价时效
• •退改签规则
• •供应商确认节奏
• •节假日、天气和航变等外部因素

Agent 在这里更适合整合规则和解释差异，而不是假装自己就是库存真源。

3. 方案生成与服务协同层

这一层最适合模型承担：

• •把模糊需求整理成结构化偏好
• •生成多个可比较方案
• •解释差旅政策、退改差异和风险
• •生成客服可接手的处理摘要

4. 支付、签约与人工兜底层

下面这些动作通常都应该保留明确确认：

• •支付
• •出票或确认酒店预订
• •高金额改签退订
• •涉及签证、儿童票、团单等复杂场景的例外处理

否则系统最容易在对外承诺上出问题。

在旅游场景里，一个更稳的职责拆分通常是：

更适合模型处理的部分

• •澄清旅行需求
• •比较方案差异
• •解释退改政策和限制
• •生成客服跟进摘要

更适合系统处理的部分

• •提供库存和实时价格
• •校验退改和供应商规则
• •执行支付、出票和订单变更
• •管理人工客服接力和外部供应商确认

如果让模型越过这些系统直接承诺“有位、能退、可改”，服务风险会非常高。

更稳的做法，是先让模型产出一份受限计划。

from typing import Literal
from pydantic import BaseModel, Field


class TravelPlan(BaseModel):
    lane: Literal["quote", "booking_review", "change_request", "handoff"]
    order_id: str | None = None
    traveler_constraints: list[str] = Field(default_factory=list)
    inventory_refs: list[str] = Field(default_factory=list)
    recommended_options: list[str] = Field(default_factory=list)
    requires_payment_confirmation: bool = True


def run_travel_workflow(plan: TravelPlan, tools):
    facts = tools.load_booking_facts(plan.order_id, plan.inventory_refs)
    draft = tools.generate_trip_options(plan.lane, facts, plan.traveler_constraints)
    checks = tools.validate_supplier_rules(plan.recommended_options, facts)

    if plan.requires_payment_confirmation or checks.has_blockers:
        return tools.route_to_travel_advisor(draft=draft, checks=checks)

    return tools.create_low_risk_service_ticket(draft=draft, checks=checks)

这个模式的价值在于：

• •先区分当前是在报价、订单复核还是改签请求
• •旅客约束条件和库存引用可以显式记录
• •高风险动作默认进入人工确认

旅游服务经常会遇到大量规则性资料：

• •退改签政策
• •供应商说明
• •团单材料要求
• •签证准备清单
• •行前须知

这类内容很适合通过文件检索做解释和引用，但库存、价格和订单状态仍然应该来自业务系统，而不是让模型自己猜。

旅游 Agent 的评估，更应该关注这些问题：

• •需求采集是否完整
• •报价和真实库存的一致度
• •改签退订场景里人工返工最多集中在哪
• •是否出现了错误承诺
• •客服接手时还需要补问多少关键信息

这些指标比“文案写得是不是很会旅行”更有价值。

1. 用过期库存和价格做承诺

旅游场景里最危险的错误之一，不是推荐不够个性化，而是承诺了实际上不可用的方案。

2. 让模型直接决定退改和赔付

这类动作往往涉及供应商规则、金额和人工裁量，不适合无条件自动执行。

3. 没有把旅客约束条件结构化下来

预算、证件、儿童同行、行李和时间窗这些条件只要漏掉一个，方案就可能失真。

旅游 Agent 真正可交付的价值，不是做一个“全自动旅行助理”，而是把原本分散在咨询、比价、订单和异常售后里的流程整理成更稳的服务链路：

• •先把需求、库存和规则事实拉齐
• •让模型承担比较、解释和摘要
• •把支付、出票和复杂改签留给受限系统与人工确认
• •用承诺正确率和返工成本，而不是口号来评估系统

只要把这些边界设计清楚，Agent 就能真正减少旅游服务里的沟通成本和异常处理压力。

• •OpenAI File Search
• •OpenAI Structured Outputs
• •OpenAI Conversation State
• •OpenAI Safety Best Practices
• •OpenAI Working with Evals