智能旅行规划助手：多 Agent 协作与 Prompt 设计

写在前面

智能旅行规划助手的核心不是简单调用一次模型，而是把复杂旅行规划任务拆成多个相对清晰的子任务。

如果让一个 Prompt 同时完成景点筛选、天气分析、酒店推荐、行程编排、预算估算和 JSON 输出，模型很容易顾此失彼。所以我把它拆成多 Agent 协作流程。

多 Agent 拆分思路

项目里主要拆成四类 Agent：

景点搜索 Agent
  -> 天气分析 Agent
  -> 酒店推荐 Agent
  -> 行程规划 Agent

这种拆法不是为了追求概念，而是为了让每一步的职责更清楚。

景点搜索 Agent

景点搜索 Agent 的任务是根据用户偏好和地图 API 返回的 POI 数据，筛选适合的候选景点。

它关注的问题包括：

• 用户喜欢历史文化还是自然风光
• 每天安排几个景点比较合理
• 景点是否适合当前城市和日期
• 是否需要兼顾美食、购物、休闲

这一步输出的不是最终行程，而是候选景点集合。

天气分析 Agent

天气分析 Agent 用于判断行程安排是否需要调整。

比如：

• 下雨天减少户外景点
• 高温天气减少长时间步行
• 晴天优先安排自然风光
• 天气不好时增加博物馆、商场等室内选择

这一步不需要生成很长文本，只需要提供规划建议。

酒店推荐 Agent

酒店推荐 Agent 根据用户住宿偏好和地图返回的酒店数据进行筛选。

我的设计重点不是让模型凭空推荐“网红酒店”，而是让它基于候选酒店做选择：

• 经济型酒店：优先价格友好、交通便利
• 舒适型酒店：兼顾位置和体验
• 高端酒店：优先评分和服务

酒店推荐结果会作为每日住宿信息进入最终 TripPlan。

行程规划 Agent

行程规划 Agent 是最后的汇总者。

它拿到：

• 用户原始需求
• 景点候选数据
• 天气建议
• 酒店候选数据
• 交通偏好
• 输出 Schema

然后生成最终 JSON。

这里 Prompt 的重点是约束输出格式：

你必须输出合法 JSON，不要输出 Markdown。
JSON 必须符合 TripPlan Schema。
景点名称优先从候选 POI 中选择。
每天景点数量控制在 2-4 个。
如果信息不足，生成合理但保守的计划。

Prompt 设计经验

这个项目里我对 Prompt 的理解有几点变化。

1. Prompt 不是越长越好

一开始我尝试把所有规则都塞进去，结果模型反而更容易忽略关键要求。后来我把 Prompt 拆成几部分：

• 角色说明
• 用户需求
• 工具数据
• 输出格式
• 约束规则

结构清楚后，输出稳定性更好。

2. 示例比抽象描述更有效

对于 JSON 输出，仅仅说“请输出 JSON”不够。更有效的是给出字段结构和示例。

模型看到明确结构后，更容易按字段生成。

3. 必须限制模型自由发挥

旅行规划场景里，模型自由发挥越多，幻觉越容易出现。所以 Prompt 中要明确：

• 不要虚构景点
• 不要生成不存在的酒店
• 不要输出无法解析的解释文本
• 不要改变字段名

多 Agent 的价值

多 Agent 带来的最大价值不是“看起来高级”，而是让任务变得可控。

如果结果不合理，可以定位问题：

• 景点少，是 POI 搜索问题还是筛选问题
• 酒店不合适，是工具数据问题还是推荐逻辑问题
• JSON 解析失败，是 Prompt 约束不够还是模型输出不稳定

这比一个大 Prompt 黑盒生成更容易调试。

小结

这一阶段完成了多 Agent 协作流程和 Prompt 结构设计。下一篇会继续记录结构化输出解析与兜底机制，这也是 AI 应用从 Demo 走向可用必须解决的问题。