意图经济最近频繁出现在消费互联网产品讨论里，但真正落到技术侧，它不是一个营销包装词，而是一套需要被拆解的需求表达与执行链路：用户不再想自己打开多个App比价、排路线、看天气、订门票，而是愿意直接告诉系统“我想去杭州玩三天，预算五千，想看自然风光，不想太累”，剩下的事交给平台去完成。旅行是这个场景最典型的试验场，年轻人想要当甩手掌柜，本质上就是希望把“决策、编排、履约”都转交给系统。
对工程师来说，这句需求背后包含的并不是一个搜索问题，而是一连串工程问题：如何识别用户真正的意图；如何从自然语言里抽出目的地、天数、预算、偏好和节奏；如何把结构化意图翻译成可执行的行程；缺少关键信息时该继续问什么；如果资源和预算冲突，系统应该给出什么兜底方案。下面这篇文章会拆解一条从“一句话需求”到“一份可确认行程”的最小技术链路，适合正在做智能助手、旅行规划或 Agent 类产品的后端同学参考。示例会使用 Python 代码，核心思路也可以迁移到 Java、Go 等后端技术栈。
1. 先把“甩手掌柜式需求”翻译成可执行的技术流程
很多产品团队讨论意图经济时，最先想到的是提高推荐精度。但如果用户的目标已经变成“把旅行交给你来安排”，那么产品核心会从前端的召回排序，变成后半程的意图解析、任务编排和可靠执行。技术方案的设计顺序，也应该按这个逻辑调整。
1.1 意图经济解决的不是“搜索结果排序”问题
传统旅行平台解决问题的路径是：用户先输入“杭州攻略”，平台给出图文列表；用户自己读攻略，自己决定什么时候去灵隐寺，什么时候去九溪，再把门票、酒店、车票分别放到不同订单里。这个路径里，系统的主要职责是“召回相关结果并让用户自己筛选”。
而当用户说“帮我规划杭州三天自然风景的轻松行程”时，系统要做的就不只是返回攻略，而是要完成需求分析、槽位补齐、资源匹配、时间编排、预算控制和结果确认。用户表达的是一句意图，系统要执行的是一个任务。
从技术架构上观察，这种变化带来几个明显差异：
- AI 的交互单位从“查询词”变成了“整句需求”。
- 系统的输出从“候选列表”变成了“结构化方案”。
- 成功标准从“点击率”变成了“行程可执行、预订可完成”。
- 出错处理从“没有搜索结果”变成了“信息不完整时需要澄清”。
这也是为什么意图经济一出现，技术团队最需要补的不是更多个性化策略，而是意图理解和任务编排能力。
1.2 一句自然语言里到底藏着哪些结构化要素
可以拿标题中典型的甩手掌柜式需求做拆解：
想去杭州玩3天，预算5000左右，喜欢自然风光，不想太累。
这句话看起来很短，但落成程序能理解的结构化数据，至少包含这些字段：
| 字段 | 例子 | 含义 | 缺失时的影响 |
|---|---|---|---|
意图intent | plan_trip | 用户想要新建一个旅行计划 | 不确定是搜攻略、订酒店还是规划路线 |
目的地destination | 杭州 | 资源匹配的范围 | 无法建立 POI 知识库索引 |
天数days | 3 | 时间跨度 | 无法做每日路线分配 |
预算budget | 5000 | 资源约束上限 | 无法过滤高消费方案 |
兴趣标签interests | nature | 内容偏好 | 无法对 POI 做个性化排序 |
节奏pace | relaxed | 每天拥挤程度偏好 | 无法控制每日景点数量 |
| 补充约束 | 不想太累 | 隐含条件 | 需要被编码进排序规则 |
其中最容易出错的是“不想太累”这种表达。它不代表具体兴趣，而代表节奏约束。如果系统不做这句解析，而只把“自然风光”识别成兴趣标签，最终很可能输出一天塞五个景点的路线，和用户的真实需求完全相反。
一个健壮的意图解析服务，应该在请求入口就把这些字段显式定义出来。字段越清晰，后续的规则、模型、外部服务和异常处理就越容易对接。
1.3 意图识别不是只有大模型一条路
很多团队一听到自然语言理解，第一反应是接一个大模型。但在意图经济这种对稳定性和可解释性要求很高的场景里，大模型只是方案之一，甚至不该作为唯一入口。
可以在系统里分层处理：
- 第一层是规则和词典，负责处理“去杭州”“玩3天”“预算5000”这类高确定性表达。
- 第二层是文本分类模型或实体识别模型，负责处理没有固定模板的长尾说法。
- 第三层是大模型或对话模型，负责理解模糊表达、多轮补充和历史上下文。
- 最后一层是强校验逻辑，负责检查模型输出是否真实存在于自己的目的地库、POI 库、酒店资源池里。
规则负责快和稳，模型负责泛化，校验负责拦截幻觉。只依赖模型而不做资源侧校验的意图经济产品，很可能在 demo 里表现惊艳，一接真实供应链就频繁翻车。
2. 搭建最小闭环：旅行意图解析与自动规划环境
为了把“意图经济”落到看得见摸得着的代码上，这里搭建一个最小可运行案例。它的目标并不是做一个完整的旅行产品，而是验证一条链路：用户输入一句自然语言，系统返回一份可以被用户最终确认的行程草案。
2.1 系统模块怎么划分
需要考虑的最小模块包括：
- 请求入口模块：接收用户文本，判断当前会话是新增计划还是修改计划。
- 意图解析模块：判断意图类型，例如
plan_trip、refine_plan、off_topic。 - 槽位抽取模块：提取目的地、天数、预算、兴趣、节奏。
- 澄清回复模块：当槽位缺失时，返回需要用户补充的问题。
- 规划器模块：基于目的地知识库、POI 标签、节奏参数，生成每日路线。
- 响应校验模块：检查目的地或 POI 是否真实存在，避免生成“看起来合理但实际不存在”的方案。
学习环境里不需要把六个模块都做成独立微服务。把所有代码放在同一个 Python 项目里，用函数边界做模块划分，更容易看清楚每一步的输入和输出。
2.2 项目目录与依赖准备
推荐先建一个干净目录：
travel-intent-demo/ ├── data_models.py # 结构化数据定义 ├── intent_parser.py # 意图识别和槽位抽取 ├── travel_planner.py # 路线规划器 ├── main.py # 入口和演示脚本 └── requirements.txt当前最小案例不需要复杂框架。本地代码只需要 Python 3.9 以上和第三方库pydantic用来做字段校验，代码里也会使用标准库的dataclasses。requirements.txt可以写：
pydantic>=2.0.0如果后续接入大模型，再根据实际使用的模型网关增加 SDK。不要在项目初期一次性引入一堆依赖，意图解析链路的调试重点在字段抽取和资源校验，而不是在框架版本上。
2.3 先定义核心数据结构避免字段漂移
很多意图识别项目最后乱掉，不是因为模型效果差，而是因为上游输出的字段名称和下游使用的字段名称对不上。一开始就要用数据类把约定固定下来。
data_models.py可以这样写：
from dataclasses import dataclass, field from typing import List, Optional @dataclass class ParsedIntent: raw_text: str intent: str = "plan_trip" destination: Optional[str] = None days: Optional[int] = None budget: Optional[float] = None interests: List[str] = field(default_factory=list) pace: str = "balanced" missing: List[str] = field(default_factory=list) @dataclass class POI: name: str area: str duration_hours: float cost: float tags: List[str] @dataclass class DayPlan: day: int title: str poi_names: List[str] total_cost: float @dataclass class TripPlan: destination: str day_plans: List[DayPlan] poi_cost_estimate: float message: strParsedIntent中的missing字段特别关键。它不是用来记录解析错误的，而是用来驱动澄清对话的。只要目的地、天数或预算缺失，系统就能根据missing列表决定下一轮该向用户补问什么。这样做的价值是，用户不会面对一个只会报错的系统，而是会得到一个像真人助理一样的追问过程。
3. 实现意图识别与槽位抽取
这一部分会实现intent_parser.py。先不接入大模型，用规则和词典把最小链路跑通。规则方案虽然看起来简单，却能非常清楚地展示槽位抽取的边界，也为后续替换成模型方案提供对比基线。
3.1 用关键词先做意图粗分类
意图分类需要先定义业务边界。在旅行规划场景里，可以识别三类高频意图：
plan_trip：用户希望新增一次旅行规划。refine_plan：用户希望修改已经生成的计划。off_topic：用户表达的内容与当前功能无关。
用关键词做粗分类在冷启动阶段完全够用：
import re from data_models import ParsedIntent PLAN_KEYWORDS = ["去", "玩", "旅行", "旅游", "行程", "攻略", "规划", "度假"] REFINE_KEYWORDS = ["调整", "修改", "换成", "重排", "换一个"] def detect_intent(text: str) -> str: if any(k in text for k in REFINE_KEYWORDS): return "refine_plan" if any(k in text for k in PLAN_KEYWORDS): return "plan_trip" return "off_topic"这里的边界必须明确：关键词命中的只是“粗分类”，不是最终结果。例如用户说“我想换一个更轻松的行程”，虽然里面没有“旅游”，但REFINE_KEYWORDS里的“换一个”会命中，系统就能把它识别成修改意图。如果后续语料变多，建议换成短文本分类模型，因为关键词在口语化表达里很容易漏召回。
3.2 抽取目的地、天数和预算
槽位抽取是整个意图理解里最需要细致的部分。下面是针对中文口语句子的最小抽取逻辑：
KNOWN_CITIES = ["北京", "上海", "杭州", "成都", "西安", "厦门", "大理", "三亚"] def _extract_destination(text: str): for city in KNOWN_CITIES: if city in text: return city return None def _extract_days(text: str): m = re.search(r"(\d+)\s*(天|日)", text) return int(m.group(1)) if m else None def _extract_budget(text: str): # 最小示例只处理阿拉伯数字，例如“预算5000左右”。 m = re.search(r"预算\s*[:：]?\s*(\d+(?:\.\d+)?)\s*元?(以内|以下|左右|不超过)?", text) if not m: return None return float(m.group(1))这个写法的用意是先把最容易结构化的一部分文本抓住。它的限制很明显：
- “三千元”这种中文数字不会命中，需要额外接数字转小写逻辑。
- “预算别超过五千”这种倒装句不会命中，因为它不满足“预算”后紧跟数字的模式。
- “杭州到上海五日游”这种句子里的“上海”和“杭州”同时出现时，
KNOWN_CITIES的顺序会优先命中“北京”，可能出现错误。
真实系统里，这些边界正是 NER 模型和规则模板互相配合的原因。规则负责能确定的部分，模型负责不确定的部分，最后的兜底是澄清反问。
3.3 抽取兴趣和节奏
兴趣和节奏是比较容易被混淆的两类槽位。兴趣决定“看什么”，节奏决定“一天安排多少”。下面的代码把两者分开处理：
INTEREST_RULES = [ (["自然", "风景", "山水", "户外", "徒步", "森林"], "nature"), (["美食", "小吃", "餐厅", "吃"], "food"), (["历史", "人文", "博物馆", "古镇"], "culture"), (["都市", "商业", "商场", "热闹"], "city"), (["亲子", "孩子", "带娃"], "family"), ] def _extract_interests(text: str) -> list: result = [] for keywords, tag in INTEREST_RULES: if any(k in text for k in keywords): result.append(tag) return result def _extract_pace(text: str) -> str: if re.search(r"不想(太)?累|怕累|轻松|慢节奏|佛系|放松", text): return "relaxed" if re.search(r"紧凑|特种兵|暴走|赶时间|越多越好", text): return "intense" return "balanced"最后把它们组装成ParsedIntent：
def parse_intent(text: str) -> ParsedIntent: parsed = ParsedIntent(raw_text=text) parsed.intent = detect_intent(text) parsed.destination = _extract_destination(text) parsed.days = _extract_days(text) parsed.budget = _extract_budget(text) parsed.interests = _extract_interests(text) parsed.pace = _extract_pace(text) missing = [] if parsed.destination is None: missing.append("destination") if parsed.days is None: missing.append("days") if parsed.budget is None: missing.append("budget") parsed.missing = missing return parsed注意_extract_interests用的是“包含关键词就追加标签”，会存在重复追加的可能。比如文本里同时有“自然风景”和“山水”，会向nature标签重复添加两次。真实实现里要么使用去重集合，要么在标签集合外再维护关键词明细，方便调试时定位是哪一段文本触发了该标签。
3.4 用大模型解析时为什么还要保留上面的规则层
规则层不适合覆盖所有口语表达，但它有一个很重要的作用：可以作为大模型的 few-shot 示例、结果校验器和降级方案。比如在请求外部模型前，先用规则层快速判断是否已经具备完整槽位；如果具备，就直接进入规划器，不浪费模型调用。
如果需要用大模型补齐解析能力，可以在同一个函数里拼 prompt：
def parse_with_model(text: str) -> dict: # 实际项目中替换成内部模型网关调用，并限制输出为固定 JSON 结构 prompt = ( "你是旅行需求解析服务。只输出 JSON，不要输出解释。\n" "字段包括：intent、destination、days、budget、interests、pace、missing。\n" f"用户输入：{text}\n" ) response = model_chat(prompt) # 替换为真实模型网关 return json.loads(response)大模型的优势是能理解“不想太赶”“想深度玩”“主要想拍拍照”这类模糊表达。但它也有两个不可忽略的问题：
- 可能把“北京”和“上海”同时出现的复杂句子理解成折叠行程，而产品压根不支持。
- 可能生成一个词面上存在于知识库、实际上已经停业或不可预订的景点。
因此无论用规则还是大模型，输出后都要经过missing校验和资源库校验。这两层才是意图经济系统可靠性的底座。
4. 行程规划器：把结构化意图变成可确认的路线
当用户说出了完整的目的地、天数和偏好后，系统要进入下一个阶段：规划行程。规划不是把 POI 随机放进每一天，而要依据兴趣标签、节奏参数和资源总量做排序与切片。这个环节最容易暴露虚假的“智能感”。
4.1 准备一个最小 POI 知识库
在真实系统中，POI 数据来自景点库、地图服务或供应链。最小 demo 里可以用内存列表模拟：
from data_models import POI, DayPlan, TripPlan, ParsedIntent POI_DB = { "杭州": [ POI("西湖景区", "西湖区", 4.0, 0, ["nature", "culture"]), POI("九溪烟树", "西湖区", 3.0, 0, ["nature", "outdoor"]), POI("灵隐飞来峰", "西湖区", 3.0, 45, ["culture", "nature"]), POI("龙井村", "西湖区", 2.5, 0, ["nature", "food"]), POI("西溪国家湿地公园", "西湖区", 4.0, 70, ["nature", "relaxation"]), POI("清河坊历史街区", "上城区", 2.0, 0, ["city", "food", "culture"]), ] }这里的duration_hours表示游览需要花费的参考时间，cost表示门票参考价，tags用于和用户兴趣做匹配。真实落地时，POI 应该至少还要包含营业时间、建议游览季节、交通接驳方式、是否适合儿童、实时排队情况等字段。但在最小闭环里，先用tags和duration_hours已经足够说明编排逻辑。
4.2 按兴趣和节奏对 POI 排序
规划器的第一步是从知识库中选出最近于用户偏好的 POI。最简单的做法是计算兴趣标签重合度：
def _score_poi(poi: POI, parsed: ParsedIntent) -> int: score = 0 for interest in parsed.interests: if interest in poi.tags: score += 1 # 在真实系统中可以叠加用户历史偏好、季节、热度等因素 return score标签重合度只是第一版基准。如果用户要求自然风光，九溪烟树和西溪湿地都能得分，但到底先安排哪一个，还需要引入区域位置、交通耗时、当天天气等条件。初期案例不必追求完美，但必须在代码里留下扩展点。
每天安排多少 POI，主要看pace参数：
def _max_pois_per_day(pace: str) -> int: return {"relaxed": 2, "balanced": 3, "intense": 4}.get(pace, 3)relaxed会控制在一天不超过两个大景点，适合“不想太累”的用户；intense会排满四个景点，适合“特种兵式旅行”。节奏阈值的设定不是随机拍脑袋，它必须与每个 POI 的duration_hours配合。更完整的逻辑应该限制每日总游览时长，例如relaxed <= 5 小时、balanced <= 7 小时、intense <= 10 小时。
4.3 组合每日路线
有了排序结果和每日 POI 数量限制，可以先把路线做成分段结构：
def generate_trip_plan(parsed: ParsedIntent) -> TripPlan: if parsed.destination not in POI_DB: return TripPlan( destination=parsed.destination or "未知", day_plans=[], poi_cost_estimate=0, message="该目的地暂时不在示例知识库中，真实系统需要接入对应供应链", ) pois = sorted( POI_DB[parsed.destination], key=lambda p: _score_poi(p, parsed), reverse=True, ) day_count = parsed.days or 1 max_pois = _max_pois_per_day(parsed.pace) day_plans = [] total_cost = 0.0 for day_index in range(day_count): start = day_index * max_pois segment = pois[start:start + max_pois] if not segment: break day_cost = sum(p.cost for p in segment) total_cost += day_cost day_plans.append( DayPlan( day=day_index + 1, title="第一天：核心游览" if day_index == 0 else "后续行程", poi_names=[p.name for p in segment], total_cost=day_cost, ) ) return TripPlan( destination=parsed.destination, day_plans=day_plans, poi_cost_estimate=total_cost, message="示例版本只覆盖景点门票和时间，真实产品需要叠加酒店、交通、餐饮估算", )这段代码输出的是一个“可执行草案”，不是最终可支付订单。它把用户需求映射到了 POI 顺序和天数，同时保留了message字段说明当前成本的边界。这种做法在工程上非常重要：系统没有能力完整履约时，就不要让用户误以为输出就是最终报价。
4.4 槽位缺失时的澄清策略
如果用户没说预算，直接把预算算成 5000 默认值，会让系统显得聪明但危险。正确做法是先在对话层补问一句：
用户：想去杭州玩3天，喜欢自然风光，不想太累。 系统：已经收到您想去杭州、3天的轻松自然路线。您这次出行的人均预算大概在什么范围呢？这个追问在代码里对应missing列表的消费逻辑。只要解析后的ParsedIntent.missing不为空，就不应该直接调用规划器，而应返回澄清问题。
澄清策略需要有一个追问上限。一般来说，一次最多问 2 到 3 个字段，避免变成让用户填表。用户如果始终不回答预算，可以在后续方案里按“未知预算，默认不做价格过滤”来处理，并在方案里明确提示。
5. 运行验证、常见坑和排错路径
最小闭环跑通之后，下一步是建立一套稳定的验证机制。旅行意图系统最怕的不是单次结果差，而是同一句话在不同时间、不同版本下产生完全不同且无法解释的结果。因此，验证和排错要贯穿整个开发过程。
5.1 用一段输入跑通全流程
入口脚本可以这样写：
from intent_parser import parse_intent from travel_planner import generate_trip_plan def main(text: str): parsed = parse_intent(text) print("解析结果：", parsed) if parsed.missing: print("需要补充字段：", parsed.missing) return plan = generate_trip_plan(parsed) for day in plan.day_plans: print(f"第{day.day}天：", " -> ".join(day.poi_names)) if __name__ == "__main__": main("想去杭州玩3天，预算5000左右，喜欢自然风光，不想太累")正常输出应该类似于：
解析结果：ParsedIntent(raw_text='想去杭州玩3天，预算5000左右，喜欢自然风光，不想太累', intent='plan_trip', destination='杭州', days=3, budget=5000.0, interests=['nature', 'relaxation'], pace='relaxed', missing=[]) 第1天：西湖景区 -> 龙井村 第2天：九溪烟树 -> 西溪国家湿地公园 第3天：灵隐飞来峰 -> 清河坊历史街区这里有两个现象需要结合规则解释：
interests里出现了relaxation，是因为“放松”关键词命中了_extract_pace的规则，但兴趣规则里没有加入“放松”，实际上没有把“不累”当成显式兴趣。真实系统中应该再维护一组pace关键词，与interests分开统计。- 三天行程里依然出现了一天 2 个 POI，符合
relaxed的安排。如果想让系统更贴近真实，还要检查两个 POI 之间的车程是否超过 1 小时，但这不是当前最小闭环的阶段目标。
5.2 建立回归评测集
意图经济系统上线前，必须准备一批带标注的测试句。每一句都要写清楚期望的intent、destination、days、budget、interests和pace。
例如：
| 用户输入 | destination | days | budget | pace | 说明 |
|---|---|---|---|---|---|
| 我想去北京玩2天，预算2000，主要看历史遗迹 | 北京 | 2 | 2000 | balanced | 常规完整表达 |
| 成都周末三天怎么安排 | 成都 | 3 | 未知 | balanced | 预算缺失 |
| 把杭州的行程改得轻松一点 | 杭州 | 未知 | 未知 | relaxed | 修改意图 |
| 帮我找一个适合带娃的室内景点 | 未知 | 未知 | 未知 | balanced | 单点查询 |
每次改动规则或模型后，都要在这批测试集上跑回归，比较改动前后的结果差异。偏差未必一定是新版本错误，也可能旧版本本身就是错的，但必须有记录才能判断。
判断意图识别做得好不好，不只是看准确率，更要看槽位缺失时系统能不能用一两轮追问把信息补回来。
5.3 三个最容易踩的坑
结合这类系统的落地经验，以下三个坑非常常见。
第一个坑：把“用户没提预算”当成“没有预算约束”。
用户没说预算，可能是因为没想到，也可能是因为预算很高不需要说。直接按 0 或无限处理，会给下游报价和筛选带来隐性风险。推荐做法是：把budget的默认值设计成None，并把missing机制接进对话流程。在无法获得预算时，不要使用价格过滤，只输出成本参考。
第二个坑：只做大模型解析，不做资源侧校验。
大模型能生成看起来无比合理的“杭州三日游”，但真实景点可能近期闭园、需要预约、线路不顺。意图解析输出的目的地和 POI 必须和自己真实的资源库做匹配。校验失败时要走降级方案，而不是把幻觉数据返回给用户。
第三个坑：把“兴趣”和“节奏”混在一起。
“喜欢自然”是选择哪些景点的依据，“不想太累”是每天安排多少景点的依据。两者混在一起后，会出现用户说要自然风光，系统却推荐了一天去四个自然景点，因为系统认为自然标签多就是符合偏好。正确做法是维护两套独立参数，规划器分别读取。
5.4 排错链路：从输入异常到行程不可用
面对用户反馈或系统异常时，建议按下面顺序排查：
| 现象 | 可能原因 | 检查步骤 | 处理建议 |
|---|---|---|---|
| 目的地解析为空 | 城市名不在词典里 | 先看KNOWN_CITIES是否有该城市别名 | 补词典或接入 NER 模型 |
| 天数一直是 1 | 正则只匹配阿拉伯数字 | 打印raw_text，观察“3天”是否被截断 | 增加中文数字转换和倒装句式模板 |
| 预算抽成了巨大数值 | “预算5000元以内”被解析成 5000000 | 检查单位换算逻辑 | 增加“元/千/万”单位还原测试 |
| 路线为空 | 目的地知识库缺失或days为空 | 检查missing和POI_DB | 规划器要对未知目的地返回明确提示 |
| 输出 POI 不在本地业务范围 | 大模型产生了幻觉 | 核对 POI 名称是否在资源库中 | 增加名称归一化和资源过滤层 |
| 用户再次修改行程失败 | 会话状态没有保存上一轮ParsedIntent | 检查对话状态存储 | 维护session_id到解析结果的映射 |
如果问题发生在线上，一定要把用户原始文本、解析后结构化数据、最终行程这三层日志同时打出来。能看到哪一层出错，才能快速判断是 NLU 的问题、知识库的问题还是规划算法的问题。
6. 走向生产：从意图解析 Demo 到旅行托管服务
最小闭环证明的是“概念可行”，但用户真正想当甩手掌柜时，系统需要承担的远不止自然语言解析。若要让成品从 demo 走向可用的旅行托管服务，还有几个关键组件必须补齐。
6.1 会话记忆和状态管理
旅行规划通常不是一句话就能完成。用户会先说“想去杭州”，再补充“预算五千”，看到方案后又说“第三天这个景点换成西溪湿地”。这种多轮交互要求系统保存会话状态，至少包括：
- 当前用户的
session_id - 上一轮已经确认的
ParsedIntent - 已经生成的
TripPlan - 用户本轮提出的是新增、修改还是取消
如果每一轮都重新从零解析，系统会把“把杭州的行程改得轻松一点”解析成一次全新规划，因为这句话里没有再次提到杭州。正确做法是把当前用户原句和上一轮状态一起交给上下文解析器，让新意图对历史槽位做继承和覆盖。
6.2 与供应链和交易系统对接
行程最终要落到“可预订、可支付、可退款”。这一步需要连接酒店库存、交通票务、景点门票、租车等外部系统。每个资源都需要考虑：
- 资源是否存在且可预订。
- 价格是否实时且包含手续费。
- 出发地和目的地之间的接驳时间。
- 购买后是否支持改签或退款。
这个阶段的复杂度和自然语言解析完全不在一个量级。建议先从“只做行程推荐，不直接代付”的模式开始，用户确认后在平台侧生成待支付订单。理由很简单：自动生成路线出现偏差的代价是用户不满意，代付出错则直接涉及资金纠纷。
不要让模型直接去操作支付，至少要保留一个用户可确认的中间节点。
6.3 人工兜底和失败降级
不要假设意图经济和智能体可以做到百分百无人化。更稳妥的架构是在自动链路外侧保留人工兜底通道。系统无法确认用户需求、推荐多次失败或用户明确表达不满时，应转接人工旅行顾问。人工顾问应该能看到用户完整会话记录，包括原始文本、解析结果和已经尝试过的方案，否则转接后还要让用户从头复述，体验会更差。
降级
