evotravel

EvoTravel 是一个会学习的 AI 旅行规划助手——它记得你的偏好，自动规划最优路线，在地图上实时展示行程，让每一次出行都更懂你。 EvoTravel 技术方案 一、技术实现思路 核心架构：LLM + 结构化输出 + API 协同 传统旅行规划产品依赖规则引擎和固定数据库，灵活性差、体验僵硬。我 们的思路是让大模型做"大脑"，用结构化输出协议做"手"，让 Agent 能真正操控地图、POI、交通等外部服务。 1. LLM 驱动决策，而非正则猜测 - 意图识别、城市提取、地点替换——全部交给大模型输出结构化 JSON，前端只做字段解析 - 不用正则去"猜"用户说了什么，而是让模型理解语义后精确输出 2. 地图服务协同 - 高德 POI 搜索定位具体地点，支持同城多分店自动选最近的一家（基于上一站坐标 参考） - 高德路线规划 API 计算通勤时间和方式 - 12306 查询跨城列车（CORS 限制时有 LLM fallback 推荐车次） 3. 地点校验反馈循环 - 地理编码后校验坐标是否在目标城市内 - 不在目标城市的地点 → 让 大模型推荐同城同类型替代 → 重新校验 - 最多 3 轮，保证不会把"楼外楼"标到崇明岛 4. 偏好记忆系统 - 每轮对话后台提取用户偏好（节奏、口味、兴趣类型等），持久化到 localStorage - 跨旅程保留，新旅程自动带入历史偏好影响规划 二、Agent 进化路径 L0 规则助手 — 正则匹配意图，固定模板回复。这是我们最早期的状态，用关键词匹配判 断用户想干什么，体验僵硬且容易误判。已经完全淘汰。 L1 LLM 对话 — 接入大模型做自然语言对话，回复质量大幅提升，但只能"说"不能"做 "——无法调用地图、POI、交通等外部服务，用户问完还是得自己去 查。也经历过。 L2 结构化 Agent — 当前核心能力。LLM 输出结构化数据（JSON / 标记列表），前端解析后调用高德地图、POI 搜索、路线规划、12306 等 API，形成"感知 → 规划 → 执行"的完整闭环。真正让 AI 从"聊天工具"变成了"能动手的助手"。 L3 自校正 Agent — 当前核心能力。地理编码结果与目标城市不匹配时，自动反馈给 LLM 重新推荐同城同类型替代地点，重新校验，最多循环 3 轮。解决 LLM 幻觉导致的地点错误问题（比如把杭州楼外楼标到崇明岛）。 L4 记忆 Agent — 当前已实现。跨会话偏好记忆系统，每轮对话后台提取用户偏好（节奏、 口味、兴趣类型等），持久化存储。用户开始新旅程时偏好自动带入，用 得越多规划越准。 关键跃迁：从 L0 到 L2——我们把"正则理解用户"变成"LLM 理解用户"，把"正则解析地点"变成"LLM 结构化输出 + API 验证"。这一步让系统从"看起来像 AI"变成"真的是 AI 在做决策"。 三、业务价值说明 1. 个性化体验闭环 - 传统 OTA 给所有人推同样的行程，EvoTravel 记住用户偏好后每次规划都不一样 - 用得越多越懂你，形成使用粘性 2. 从"搜索"到"对话"的范式升级 - 用户不需要知道"该搜什么"，只需要说"我想去杭州玩两天，不喜欢人 多的地方" - 降低旅行规划的门槛，覆盖不会用复杂搜索工具的用户群体 3. 自动化路线优化 - 自动计算最优游览顺序、通勤方式、时间估算 - 同城多分店自动选最近的，跨城交通自动推荐车次 - 用户不用自己算"从 A 到 B 怎么走最快" 4. 可扩展的商业化路径 - 接入酒店/门票预订 API → 佣金变现 - 偏好数据积累 → 精准推荐增值服务 - 企业版 → 差旅规划、团建方案批量生成 5. 技术护城河 - LLM 结构化输出 + 外部 API 协同的架构，不是简单套壳 - 自校正反馈循环解决 LLM 幻觉问题，保证地点准确性 - 偏好记忆系统形成数据壁垒 [ 队伍介绍 ] 翱翔突击队 [ 队伍成员介绍 ] 李旭东 冯波翰