智能旅行规划助手：高德地图 API 与工具增强生成

写在前面

在旅行规划场景里，模型最容易出现的问题就是“编”。它可以生成很流畅的行程，但景点、地址、酒店、天气这些信息如果没有真实数据支撑，就很难让用户信任。

所以这个项目的第三步是接入高德地图 API，把外部工具返回的真实数据作为 LLM 的上下文输入。

为什么要接地图 API

如果只依赖大模型，可能会出现这些情况：

• 景点名称不准确
• 地址不真实
• 景点之间距离不合理
• 酒店推荐没有依据
• 天气建议泛泛而谈

旅行规划和普通聊天不同，它天然依赖现实世界的信息。因此我的思路是：模型负责规划和表达，工具负责提供事实。

工具数据类型

项目里主要接入了三类数据：

1. POI 搜索

根据用户目的地和旅行偏好，搜索候选景点。

例如用户选择“历史文化”，就优先搜索博物馆、古迹、文化景区等；如果选择“自然风光”，就偏向公园、山水、湖泊。

2. 酒店搜索

根据目的地和住宿偏好获取酒店候选项。

住宿偏好不是简单地传给模型，而是先映射成搜索条件，再将搜索结果整理给模型。

3. 天气查询

天气数据主要用于生成出行建议：

• 是否适合户外景点
• 是否需要雨具
• 是否调整行程强度
• 是否优先安排室内景点

这类信息不一定需要非常复杂，但它能让计划看起来更贴近真实出行。

工具封装

我把高德地图能力封装成独立服务，而不是直接写在 Agent 里：

1
2
3
4
5
6
7
8
9

class AMapService:
    async def search_pois(self, city: str, keywords: str) -> list[POI]:
        ...

    async def search_hotels(self, city: str, level: str) -> list[Hotel]:
        ...

    async def get_weather(self, city: str) -> WeatherInfo:
        ...

这样做有几个好处：

• Agent 不关心具体 HTTP 请求细节
• 后续替换地图服务成本更低
• 工具返回数据可以统一清洗
• 更方便写兜底逻辑

数据清洗

第三方 API 返回的数据通常不能直接丢给模型，需要先整理。

我主要做了几类处理：

• 过滤没有名称或地址的 POI
• 限制候选景点数量，避免 Prompt 太长
• 提取名称、地址、类型、经纬度等关键字段
• 酒店和景点分开整理
• 天气信息压缩成简短描述

整理后的上下文大概是这样的：

1
2
3
4
5
6
7
8
9

候选景点：
1. 故宫博物院，地址：北京市东城区景山前街4号，类型：文化景区
2. 天坛公园，地址：北京市东城区天坛东里甲1号，类型：历史文化

候选酒店：
1. 某经济型酒店，地址：北京市东城区...

天气：
晴，温度 18-26 摄氏度，适合户外游览

模型拿到的是清洗后的候选事实，而不是完整 API 原始响应。

工具增强生成

这个项目里的工具增强生成流程可以概括为：

1
2
3
4
5

用户需求
  -> 高德地图 POI / 酒店 / 天气查询
  -> 清洗成 LLM 上下文
  -> Prompt 约束模型只能基于候选数据规划
  -> 输出结构化旅行计划

关键点是 Prompt 中明确要求：

• 优先使用候选 POI
• 不要虚构不存在的景点
• 每天行程要控制数量
• 输出必须符合 TripPlan Schema

遇到的问题

接入真实 API 后，项目也出现了一些新问题：

• API 可能没有返回足够景点
• 某些城市或关键词搜索结果质量不稳定
• 返回字段不统一，需要做兼容处理
• 网络超时会影响整体规划流程

所以工具调用也需要兜底，比如：

• 搜索结果为空时更换关键词
• POI 不足时扩大搜索范围
• API 失败时使用本地备用结构
• 记录错误但不直接让整个接口崩掉

小结

这一阶段的核心收获是：AI 应用不能只靠模型生成，真实数据接入非常关键。地图 API 提供事实，LLM 负责组织和规划，两者结合后，旅行计划的可信度会明显提升。

下一篇会继续记录多 Agent 协作流程，也就是如何把景点、天气、酒店、行程规划拆成多个可控子任务。