# travelagent67 — 旅行规划智能体 v2 ## 架构概述 ``` 用户请求 │ ▼ ┌──────────────────────────────────────────────────┐ │ 多 MCP 数据源 (SSE 建链) │ │ ┌──────────┐ ┌──────────────┐ ┌────────────┐ │ │ │ 高德地图 │ │ Google Maps │ │ 大众点评 │ │ │ │ (国内首选) │ │ (海外备用) │ │ (餐饮补充) │ │ │ │ priority:1│ │ priority:2 │ │ priority:3 │ │ │ └─────┬────┘ └──────┬───────┘ └─────┬──────┘ │ │ └───────────────┼───────────────┘ │ │ │ tools/list │ └────────────────────────┼─────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────┐ │ 用户偏好记忆层 (memory) │ │ 预算 | 饮食禁忌 | 出行方式 | 住宿 | 游览节奏 │ └────────────────────────┼─────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────┐ │ ReAct Agent Loop (最多 30 轮, 并行工具调用) │ │ │ │ 阶段0:偏好 → 阶段1:侦察 → 阶段2:POI采集 │ │ → 阶段3:编排 → 阶段4:校验 → 阶段5:JSON │ │ │ │ ┌───────────┐ ┌──────────────┐ │ │ │ LLM 推理 │───▶│ tool_calls? │ │ │ │ (Thought) │ │ Y: 并行调工具│ ──▶ SSE 推送 │ │ └───────────┘ │ N: 输出JSON │ 进度到前端 │ │ ▲ └──────┬───────┘ │ │ │ │ │ │ └──── 结果回灌 ◀───┘ │ └────────────────────────┼─────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────┐ │ 后处理校验层 (postProcess) │ │ ✓ 营业时间校验 ✓ 天气适配校验 │ │ ✓ 时间冲突检测 ✓ 预算校验 │ │ ✓ 通勤时间校验 ✓ 重复地点检测 │ │ ────────────────────────────── │ │ error → 拒绝并重试 | warning → 追加提醒 │ └────────────────────────┼─────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────┐ │ 输出解析 │ │ 1. 代码块清洗 (去除 ```json```) │ │ 2. 提取 JSON 块 ({...}) │ │ 3. 尝试根对象 → ItineraryPlan │ │ 4. 回退 data.itinerary / itinerary │ └────────────────────────┼─────────────────────────┘ │ ▼ ItineraryPlan JSON ``` --- ## v1 → v2 改进对照 | 改进方向 | v1 状态 | v2 实现 | 配置位置 | |---|---|---|---| | **多数据源** | 仅高德，海外不可用 | 高德 + Google Maps + 大众点评，优先级链式 fallback | `mcp.remoteServers[*].priority` | | **流式体验** | 同步阻塞，无进度反馈 | SSE 推送六阶段进度 + 工具调用事件 | `streaming.events` | | **用户偏好** | 无记忆，每次从零开始 | memory 持久化偏好（预算/饮食/出行/住宿/兴趣），30天有效 | `memory` + `memory.schema` | | **增量编辑** | 全量重跑，无法局部修改 | 识别修改指令，仅验证受影响 POI，保持其余不变 | `systemPrompt` 增量编辑模式 | | **行程校验** | 仅通勤时间约束 | 6 项后处理校验器（营业时间/天气/冲突/预算/通勤/重复） | `postProcess.validators` | | **并行工具** | 串行，每轮1个工具 | `maxConcurrent: 5`，无依赖工具同轮并行 | `mcp.policy.maxConcurrent` | | **成本控制** | 固定 $0.50 总预算 | CEK 引擎 + 7 个阶段预算 + 超额自动降级模型 | `runtime.stageBudgets` | --- ## App 亮点 — 实现机制解读 > 以下从产品视角说明"AI 行程规划"功能的核心卖点及其背后的技术实现。 ### 亮点一：每个推荐地点都是真实的，不是 AI 编的 **用户感知**：生成的行程中每个景点、餐厅、酒店都能在地图上找到，点击即可导航。 **实现机制**：Agent 通过 MCP 协议实时连接三大地图数据源（高德/Google/大众点评），所有地点均来自真实查询结果。系统提示词设置"反幻觉"硬约束 + 后处理重复检测校验器双重保障。 ### 亮点二：行程动线合理，不走冤枉路 **用户感知**：同一天的景点彼此不远，不会出现上午故宫、下午八达岭的离谱安排。 **实现机制**：逐日编排阶段要求同日行程地理聚集，`maps_driving`/`maps_transit` 验证通勤 ≤ 1h。后处理层的 `transit_duration_check` 校验器做二次确认。 ### 亮点三：AI 会看天气再安排行程 **用户感知**：下雨天自动安排室内景点，晴天安排户外活动。 **实现机制**：宏观侦察阶段调用 `maps_weather` 查天气，编排阶段据此动态调整。后处理层的 `weather_adaptation_check` 校验器确保雨天不超过 1 个户外景点。 ### 亮点四：一次生成完整行程，精确到经纬度 **用户感知**：生成结果直接可用于地图渲染，前端无需二次查询。 **实现机制**：v2 的 JSON Schema 更丰富 —— 除经纬度外，还包含 `timeSlot`（时间段）、`transitToNext`（到下一站的交通方式和时间）、`estimatedCost`（单项费用），前端可渲染带时间轴的地图路线。 ### 亮点五：实时看到 AI 在干什么 **用户感知**：等待时不再焦虑 —— 能看到"正在查询天气..."、"正在搜索景点..."、"正在验证路线..."的实时进度。 **实现机制**：SSE streaming 配置监听 Agent 输出中的 `[STAGE:X/5]` 标记和 tool_call/tool_result 事件，实时推送给前端，展示六阶段进度条和当前操作。 ### 亮点六：记住你的偏好，越用越懂你 **用户感知**：第二次使用时不需要重复说"我吃素"、"预算有限"，AI 已经记住了。 **实现机制**：memory 模块按用户隔离，持久化 6 个偏好维度（预算/饮食/出行/住宿/兴趣/节奏），30 天有效。阶段〇自动检查历史偏好，仅对缺失项向用户确认。 ### 亮点七：想改哪天改哪天，不用重新生成 **用户感知**：说一句"第二天午餐换成火锅"，只改那一项，其余行程不变。 **实现机制**：增量编辑模式解析修改指令（第几天/第几项/操作类型），仅对修改涉及的 POI 做工具查询验证，保持未修改部分不变。避免全量重跑的资源浪费和行程漂移。 ### 亮点八：网络抖动不怕，多源兜底 **用户感知**：不管网络多不稳定，行程都能正常生成。 **实现机制**：3 层容错 —— 单工具 3 次重试 + 指数退避；高德失败自动切 Google Maps；三源均失败则从已采集候选列表替代。绝不因单次网络问题中断整个规划。 --- ## 优点 ### 1. 多数据源冗余架构 三个 MCP 远程服务按优先级链式 fallback：高德（国内全覆盖） → Google Maps（海外覆盖） → 大众点评（餐饮深度信息）。单一数据源故障不影响整体可用性，且国内外目的地均可支持。 ### 2. 六阶段结构化规划 从 v1 的四阶段升级为六阶段（新增偏好采集 + 行程校验），每个阶段有明确目标、工具策略和进度标记。规划过程完全可观测、可调试。 ### 3. 并行工具调用 `maxConcurrent: 5` 允许单轮内并行发起多个无依赖的工具调用（如同时搜索景点/美食/酒店），将 POI 采集阶段的耗时从串行的 N 轮压缩到 ceil(N/5) 轮。 ### 4. 用户偏好记忆 跨会话持久化 6 个偏好维度，30 天有效。第二次使用时自动加载已有偏好，仅确认缺失项。越用越精准，减少沟通成本。 ### 5. 后处理校验层 6 个独立校验器（营业时间/天气适配/时间冲突/预算/通勤/重复）在 JSON 生成后做结构化验证。error 级别问题自动拒绝并要求模型重新生成，warning 级别追加到行程 tips 中提醒用户。 ### 6. 增量编辑能力 支持"修改第 N 天第 M 项"的局部更新，仅对修改涉及的 POI 做工具查询和路线验证。避免全量重跑带来的资源浪费、延迟和行程漂移。 ### 7. 分阶段成本控制 CEK 引擎支持 7 个阶段预算（偏好 $0.03 / 侦察 $0.05 / 采集 $0.25 / 编排 $0.20 / 校验 $0.15 / 输出 $0.05 / 预留 $0.07），超出阶段预算时自动从 qwen-max 降级到 qwen-plus 继续执行，兼顾质量与成本。 ### 8. 流式进度推送 SSE streaming 实时推送六阶段进度和工具调用事件到前端，用户在等待时能看到 AI 当前在做什么，大幅降低等待焦虑感。 --- ## 仍存在的局限 ### 1. 延迟仍然较高 虽然并行工具调用减少了轮次，但六阶段流水线 + 后处理校验 + 可能的重试，整体延迟仍在 2-4 分钟级别。对于"随便帮我规划一下"的轻量需求，等待时间偏长。 ### 2. Prompt 工程脆弱性 六阶段策略、增量编辑模式、并行工具引导、多数据源切换均依赖 system prompt 的约束力。换模型（如从 qwen-max 到 GPT-4o）可能需要重新调优 prompt。 ### 3. 后处理校验为声明式伪代码 `postProcess.validators` 中的 rule 是语义描述而非可执行代码，需要运行时框架实现对应的校验逻辑。当前 lambdagent 框架尚未原生支持 postProcess，需要在应用层（如 Java 后端）额外实现。 ### 4. Google Maps / 大众点评 MCP 依赖外部部署 高德有官方 MCP 服务 (`mcp.amap.com`)，但 Google Maps 和大众点评的 MCP 服务需要自行搭建或使用第三方封装，增加了部署复杂度。 ### 5. 偏好采集可能增加交互轮次 阶段〇的偏好确认需要用户回答问题，对于希望"一句话直接出结果"的用户可能感到繁琐。需要平衡个性化精度和交互简洁性。