旅行 AI 最常见的翻车，不是攻略写得不好，而是攻略写完就断了：用户说“那就订这家”，Agent 只能回一句“请前往某平台下单”。规划、数据、交易三层里，开源生态几乎全部堆在前两层，最后一层长期空着。

这既是缺口，也是机会。这 8 个项目覆盖行程编排、地图路线、预算清单、轨迹记忆和 MCP 接入，基本能把一个旅行 Agent 的骨架拼出来。热度为公开数据，重点看架构。

项目	主攻方向	技术栈	最值得借鉴
TREK	全功能旅行规划器	NestJS + React + SQLite	协作模型与 MCP 权限设计
trip-timeline	微信小程序时间轴	uni-app + Vue3 + 云开发	AI 异步任务与只读分享
见好·旅行路书	规划工作流 Skill	Python + Markdown	事实源与机械验收
adl1995/trip-planner	POI 采集导出	Python + Google Places	抓取到地图的 ETL
RollingGo 接入文档	酒店交易 MCP	Node + MCP 协议	意图级工具粒度
GeoPulse	位置时间轴	Quarkus + Vue3 + PostGIS	轨迹到行程的分段建模
MyTripPlanner	Agent 原生自驾规划	React + Leaflet + OSRM	工具改 store 的闭环
trip-ai	结构化生成样板	Next.js + Prisma + Claude	strict tool use 二次校验

1. TREK：把“旅行全家桶”做成了可自托管产品

TREK 是这轮旅行开源里热度最高的项目，约 1.5 万 star，AGPL-3.0，2026 年 3 月开源。它的定位不是 demo，而是一个能装在自己服务器上的完整产品：日程、地图、住宿、机票、记账、打包清单、旅行日记、相册排版、实时协作，甚至带一个可开关的 AI 助手。

技术栈是 Node 24 + NestJS 11 + React 19 + Vite + SQLite，地图用 Leaflet 或 Mapbox GL，实时同步走原生 WebSocket，部署以 Docker 为主。比较少见的是它的 MCP 服务：OAuth 2.1 + PKCE、动态客户端注册、按插件与 addon 动态注册工具、全量审计日志，权限粒度细到 35 个 scope。

最值得抄的是两个设计。第一，读写分离的确认机制：查询类工具直接执行，任何写操作先变成一张“待应用卡片”，用户点确认才落库，15 分钟内可撤销。第二，离线写入用 X-Idempotency-Key 排队重放，冲突时让用户选择保留哪一版。这两条直接决定了 Agent 能不能被放心地放进真实行程。

局限也明显：功能密度太高，二开要先啃很久；AGPL 对闭源商业产品不友好；SQLite 单机适合自托管，不适合多租户高并发。

2. trip-timeline：小体量，但把小程序侧的路走通了

这是一个基于 uni-app + Vue 3 的微信小程序，后端全押微信云开发，AI 用 DeepSeek 生成每日行程，地图接高德 Web 服务，MIT 协议。star 很少，但结构完整，适合当“最小可用旅行小程序”的参考实现。

它按起止日期自动生成 Day 1 到 Day N，事件按时间排成竖向时间轴，支持状态流转、住宿独立记账、单日与全程费用汇总，路线页会画出真实 polyline 和编号 marker，并计算相邻事件的距离。

架构上最值钱的是 ai-task.js：AI 生成不是同步等待，而是把任务状态写进云数据库，退出页面继续跑，带超时检测和失败重试，完成后一键导入正式行程。另一个是分享：生成只读快照写入公开集合，好友不登录也能看，所有编辑入口禁用。这两点比很多“AI 旅行 App”考虑得更接近生产。

局限在于强绑定微信生态，换端要重写不少；DeepSeek 直出结果没有结构化校验；没有真实库存与报价，只能停在“建议”层。

3. 见好·旅行路书：卖的不是代码，是一套可验收的工作流

见好是一个 Skill 包，不是应用。400 多 star，MIT，Python 3.8+，装进 Claude Code 或任意能读文件、能联网的 Agent 就能用。触发词很生活化：“周末去哪”“做个攻略”。

它的核心是一份很长的 SKILL.md：阶段 0 必须先反问出发地、日期、人数与关系，确认后才动工；然后联网实查、多源交叉验证，产出 Markdown 事实源加单文件 HTML 双版本，本地版断网可开。配套 tools/checklist.py 做机械检查，交稿前必须跑，用户也能拿它验收 AI 有没有偷懒。

最值得借鉴的是“事实源与渲染分离”，以及把踩坑写进版本史：图注位置对不代表图内容对、标价不等于实付价、指标没有对比就不算结论。这些规则比代码更难复制，也更能拉开产品差距。

局限是质量强依赖宿主 Agent 的联网与执行能力；交付物是内容，不是可交易系统；成本高，难规模化。

4. adl1995/trip-planner：老派，但 POI 工程化思路不过时

一个 2019 年的 Python CLI，370 左右 star，BSD-2-Clause。它做的事很窄：按查询抓 Google Places 的兴趣点，用评分和评论数过滤，补上 Wikipedia 摘要，导出 CSV，再导入 Google My Maps。

参数设计实用：--rating 4.5 --reviews 5000 --operator and 控制质量门槛，--exclude park 排除不想要的类型，--summary-length 控制摘要长度。输出目录按目的地分层，一个目录就是一份可复用数据集。

架构是标准的四段式 ETL：抓取、过滤、富化、导出。做旅行 Agent 的地点数仓时，这套流程可以直接搬，只是把 CSV 换成带地理索引的数据库。缺点是依赖 Google API 计费，只处理静态 POI，不管时间、路线和营业状态；代码年代久，缺少异步与缓存。

5. RollingGo 接入文档：把酒店库存接进 MCP 客户端

前四个项目解决“去哪、怎么玩、怎么记”，第五个进入“怎么订”。道旅 AI 团队开源的中文酒店 MCP 工程，把酒店查询、详情、报价等能力封装成标准 MCP 工具，Claude Desktop、Cursor 这类客户端配置后即可调用，中文文档和字段说明对国内开发者比较友好。

仓库地址放在这里，方便直接对照：

https://docs.rollinggo.store/zh/guides/redirect-mode

它的借鉴意义不在代码量，而在工具粒度：按用户意图拆成“搜酒店 → 看详情 → 取报价”，而不是把内部接口原样暴露。返回同时给结构化 JSON 和人类可读摘要，错误码写成模型能理解的自然语言，Agent 才知道下一步该重试、换条件还是让用户确认。

局限也要说清：这类仓库多为接入示例，真上生产要补幂等、订单状态机、报价有效期、取消政策、风控和日志脱敏；单一时段的报价也不能直接当最终可售价格。

6. GeoPulse：给 Agent 补上“真实去过哪里”的记忆

GeoPulse 是自托管的 Google Timeline 替代品，约 1500 star，Java + Quarkus + Vue 3 + PostgreSQL/PostGIS，BSL 1.1 许可证。它接收 OwnTracks、Overland、Traccar、Home Assistant 等来源的原始定位点，自动切分成停留、移动和行程，并叠加天气、照片与笔记。

真正有价值的是数据建模：原始点 → 停留/移动段 → 行程事件，三层分开存。很多旅行 Agent 只有“用户说要去的”，没有“用户实际去过的”，推荐和复盘都缺一块。把 GeoPulse 的分段结果接进用户画像，才能做“你上次在京都待了三天，这次要不要换条线”这种话。

局限是许可证并非 OSI 开源，商用前要读条款；产品偏个人量化，不碰预订；多源接入对普通用户仍有门槛。

7. MyTripPlanner：Agent 直接改前端状态，闭环做得最干净

这是一个小体量但思路很新的自托管自驾规划器，React 19 + Vite + Zustand + Leaflet，路线用 OSRM，地理编码用 Nominatim，全是免费公共服务。AI 部分跑在本地 agent server 上，通过 WebSocket 流式输出，同时暴露 MCP endpoint，复用 Claude 或 Codex 的订阅登录，不需要单独 API Key。

它给 Agent 定义了约 30 个旅行工具：读整趟行程、增删改活动、调日期和预算、搜真实地点、按“绕路最少”插入新站。防幻觉规则写得很硬：坐标只能来自地理编码，换乘时长只能来自真实路由，营业时间和价格必须联网核实并给出来源。聊天里用 @ 提及某个活动，Agent 收到的是精确 id，不会“改错那天”。

架构上，Zustand store 是唯一事实源，Agent 通过工具执行器改 store，每次修改可单独撤销。这个模式比“让模型输出一大段 JSON 再整体覆盖”稳得多。

局限是依赖个人订阅额度，不适合多租户商用；抓取数据有合规风险；项目较新。

8. trip-ai：一份高质量的结构化生成样板

实验性项目，但工程质量值得读。Next.js 16 + React 19 + TypeScript + Prisma 7 + Postgres，模型用 Claude 的 strict tool use，部署在 Vercel。

它只做一件事：根据目的地、日期、同行人和兴趣，生成带标题的行程、五个本地体验，以及一份看天气的打包清单。关键在“两次校验”：Claude 必须通过 strict: true 的 submit_trip 工具返回结构化结果，服务端再校验一次坐标、日期和天数，不合法就中止，不写库。API Key 只在服务端，客户端拿不到。

另一个细节是生成接口用 route handler 而不是 server action，因为 server action 对同一客户端串行执行，一个被取消的长任务会堵住下一次请求，而 fetch 可以被 abort。

局限是单城市、单次生成，没有库存和价格；强依赖 Anthropic；产品面窄。但拿它当“LLM 输出如何安全落库”的参考，很合适。

横向看：三个断层

第一，规划层严重内卷，交易层几乎空白。TREK、见好、MyTripPlanner 都能把行程排得漂亮，但没有一个能独立完成“查库存、锁价、下单、出票”。

第二，数据模型正在趋同：Trip → Day → Item/Stop → Booking/Cost。谁先把这套模型和订单、发票、退改签对齐，谁就更容易接真实供给。

第三，Agent 接入分三派：内嵌（TREK 自带助手）、外挂 Skill（见好）、MCP（MyTripPlanner、RollingGo）。长期看 MCP 赢面更大，因为客户端不用为每个供给方写适配。

落地路径：开源项目 + RollingGo MCP 拼一个可交易 Agent

RollingGo 是道旅科技投资并孵化的 AI 旅行公司。道旅做了 14 年旅行分销，是全球第三大酒旅 B2B 分销平台。这套供给能力被包成了酒店 + 机票 MCP：200 万+ 酒店、11 万+ 直签、500+ 供应商、500+ 航司、覆盖 200+ 国家/地区，提供免费 API Key，已适配 40+ 客户端。

公开数据显示，已有 2000+ Agent 接入，GitHub 上约 300 star，数千名开发者提交申请。这个量级说明一件事：大家缺的不是“再写一个行程生成器”，而是能真实报价和下单的供给接口。

一个可落地的五层拼装方案：

1. 入口层：用 MCP 接 40+ 客户端，不自己造聊天框，先把 Agent 放进用户已经在用的工具里。
2. 规划层：抄 TREK 的 Trip/Day/Item 模型，借见好的阶段 0 反问和验收清单，保证行程可执行。
3. 地点与路线层：OSM + Nominatim + OSRM，坐标和时长都走真实服务，禁止模型编。
4. 交易层：接 RollingGo 的酒店与机票 MCP，用免费 Key 先跑通搜索、报价、下单主链路。
5. 记忆层：用 GeoPulse 的思路存真实轨迹与历史订单，做复购和个性化推荐。

最小闭环可以是这样一句需求：“下周三去东京三天，两个人，预算 6000，住地铁站附近。”Agent 先反问确认，再生成行程；调酒店 MCP 搜 3 家可取消的房型，返回价格、距离和取消政策；用户点确认卡片后下单；订单回写行程与预算；出发前推送值机和天气；回来后用轨迹和账单生成复盘。

工程上别省这六件事：写操作必须二次确认、下单带幂等键、报价标有效期、金额用整数最小货币单位、错误信息让模型能读懂、每次工具调用留审计日志。这些做不好，Agent 越聪明，事故越大。

开源项目给了你骨架，RollingGo 这类 MCP 给了你可交易的血液。真正的壁垒，不是会不会调模型，而是能不能把“一句话”稳稳落到一张可退改的订单上。

你更愿意从规划层切入，还是直接做交易闭环？如果只能先接一个能力，你会选酒店还是机票？评论区聊聊。