基于HelloAgents的智能旅行助手

Posted at 2025-12-22 技术 学习  AI-Agents 

期末的人工智能原理大作业选择了这个Datawhale 社区的智能体学习教程作为课题。关于整个项目，包括Agent、LLM的历史、知识，在教程中都有详细介绍。本文属于一篇学习记录与演示文稿。

知识可能比较基础。希望其中的一些粗浅的经验和思考能帮助到大家。

原项目地址：hello-agents
本项目地址：trip-planner-agent
B站演示Demo：【开源】基于HelloAgents的旅行助手Web应用（Demo）

一、关于AI Agent

对AI Agent做一个简单的介绍。

OpenAI 发布的《A practical guide to building agents》白皮书中的话的解释是：

Agents are systems that independently accomplish tasks on your behalf.
智能体是能够独立代表你完成任务的系统。

如今各类LLM的的常见使用模式是在对应的网页端或者客户端提出我们的问题，然后由对应的模型返回给我们一个答案，但最后还是需要我们进行操作并根据反馈给AI提出新的要求。LLM与外界实际的交互其实很少。

而Agent以LLM为大脑，当拿到用户的需求之后自主地进行思考，并调用工具自主执行。
现在的AI IDE，像Cursor、Codex、Antigravity，包括一些插件Roo Code等就都属于Agent，拿到用户的代码需求之后可以检索整个项目、上网检索实时信息并生成与修改代码。

注意区分于时兴的MCP：

什么是 MCP？ 
Model Context Protocol (MCP) 是一种标准化方式，可供 AI 工具访问外部工具和数据源。

MCP是一种通用、标准的协议，解决了以往Agent中碎片化硬编码各类服务API的不便，让每一个Agent可以更加灵活地根据需求去调用不同服务商提供的服务，让Agent更加方便地调用工具。就像TypeC的协议能在设备之间传输数据，也能充电一样。但最后决定与使用工具的还是理解需求之后的Agent。

总结说，AI Agent是以LLM为大脑的决策者与执行者，它在完成思考之后可以通过连通外部、调用工具，来完成任务。它能思考，能推理，能感知，也能自己行动。
翁荔（Lilian Weng）当年提出了Agent的开发公式即：Agent=大模型+记忆+主动规划+工具使用

二、Agent范式、框架

开始做项目之前，先了解了一下Agent的范式和框架

范式

范式就是一张AI工作的思维导图，决定了 Agent 怎么思考。
针对不同的任务复杂度，业界演化出了几种主流的思维范式：

• ReAct (Reasoning and Acting)：边想边做。Agent 产生一段思考，执行一个行动，观察结果后再进行下一步。
• Plan-and-Solve：先定计划。Agent 拿到任务后，先将其拆解为 1、2、3 步计划，然后严格执行。
• Reflection：做完再查。Agent 生成初步结果后，由另一个“评审角色”进行检查并提出修改意见。
  
  

框架

框架是开发者的工具箱，决定了代码怎么实现。
目前 Agent 领域存在多种框架，下面列写一些主流的以及本次使用的。

• LangChain： 目前全球最流行的框架，核心思想是将大模型的所有操作串联成“链”。
  生态极其丰富，适合需要快速集成多种第三方服务、构建超大规模复杂应用的工程。但封装较重，学习成本高。

• LlamaIndex： 它专注于解决 Agent 的“记忆力”和“知识量”问题，是 RAG（检索增强生成）领域的热门。
  擅长对海量私有文档进行切片、索引和高效检索。它是大模型连接私有数据的强大桥梁。

• AutoGen： 这是目前多智能体领域的权威框架。
  主打“对话即任务”。它让多个 Agent 像人类开会一样对话，擅长处理多个Agent之间的工作协调。适合复杂的软件开发自动化、多角色的模拟决策。

• HelloAgents (本项目选择)：
  它轻量化，除了 OpenAI SDK 和必要库，无重型依赖。代码分层清晰（核心层、实现层、工具层），将上面现成框架里的复杂东西都抽象为“工具”。反正就是好学一点好用一点。

  
  

分类

目前的Agent从实现技术上还可以分成两类，workflow型和autonomous型。这块具体的知识可以看一下锦恢的博客，写得很清楚。

三、关于本项目

在本项目中，我们利用 HelloAgents 框架构建了一个高度模块化的多智能体系统。通过将复杂的旅行规划任务拆解为多个专业领域的子任务，并引入 MCP（Model Context Protocol）协议，实现了工具调用的标准化与流程的自动化。

1. Agent 的职责分工

为了保证规划的专业性，我们在后端定义了四个核心 Agent。每个 Agent 通过专门的 system_prompt 约束其职责边界：

• AttractionSearchAgent: 搜索专家，负责挖掘目的地高评分、符合偏好的景点。
• WeatherQueryAgent: 环境顾问，负责获取实时气候数据，为行程增减建议（如：雨天室内游）。
• HotelAgent: 住宿管家，根据景点分布情况寻找性价比最高的酒店。
• PlannerAgent: 首席规划师，不直接调用工具，而是负责将上述三者的零散数据汇总为结构化的 JSON。
  

# 初始化示例：赋予每个 Agent 独立的大脑和预设角色
self.attraction_agent = SimpleAgent(name="AttractionSearchAgent", llm=self.llm, system_prompt=ATTRACTION_AGENT_PROMPT)
self.weather_agent = SimpleAgent(name="WeatherQueryAgent", llm=self.llm, system_prompt=WEATHER_AGENT_PROMPT)
# ... 其他 Agent 初始化

2. 串行工作流

根据Agent的功能分类，本项目属于串行工作流。这种设计的考量是：旅行规划具有强依赖性——没有确定的景点，就无法推荐最优的酒店位置。虽然串行流增加了总耗时，但它保证了上下文的一致性，未来可以考虑将景点搜索和天气查询并行化，以进一步优化性能。

graph LR
    User([用户需求]) --> Coordinator{协同分发}
    
    subgraph Execution [顺序执行层]
        direction TB
        A[景点搜索
获取 POI 数据]
        W[天气查询
获取气候背景]
        H[酒店匹配
基于位置推荐]
    end

    Coordinator --> A --> W --> H --> Planner[最终规划
整合 JSON]
    Planner --> Result([结构化行程单])

    style Coordinator fill:#f5f5f5,stroke:#1890ff,stroke-width:2px
    style Planner fill:#f5f5f5,stroke:#1890ff,stroke-width:2px

sequenceDiagram
    participant U as 用户需求
    participant C as 共享上下文 (Context)
    participant A as 景点专家
    participant W as 天气顾问
    participant H as 酒店管家
    participant P as 首席规划师

    U->>C: "我想去北京..."
    Note over C: Context: { 目的地: 北京 }
    
    C->>A: 调取目的地
    A->>C: 注入景点列表 [A, B, C]
    Note over C: Context: { 景点: [...], 目的地: 北京 }

    C->>W: 调取日期/地点
    W->>C: 注入天气预警 "有雨"
    Note over C: Context: { 天气: "雨", 景点: [...] }

    C->>H: 调取景点位置
    H->>C: 注入酒店建议 "靠近景点A"
    
    C->>P: 调取所有碎片数据
    P-->>U: 生成结构化 JSON 行程单

3. 技术亮点：基于 MCP 协议的工具集成

本项目一个亮点是引入了 MCP (Model Context Protocol)。传统的工具调用需要为每个 API 编写适配器，而 MCP 像是一个“万能插头”，让 Agent 能够即插即用外部能力。
我们通过 npx 启动高德地图 MCP 服务器，将其挂载到 Agent 上：

# 初始化 MCP 工具并挂载
self.mcp_tool = MCPTool(
    name="amap_mcp",
    server_command=["npx", "-y", "@sugarforever/amap-mcp-server"],
    env={"AMAP_API_KEY": amap_api_key}
)
self.attraction_agent.add_tool(self.mcp_tool)

这种标准化的接入方式，使得 Agent 可以直接理解并调用 amap_maps_text_search 等 16 种地图能力，极大地提升了开发效率。

graph TD
    subgraph "智能体大脑 (HelloAgents)"
        Agent1[Attraction Agent]
        Agent2[Weather Agent]
        Agent3[Hotel Agent]
    end

    subgraph "标准化接口 (MCP Protocol)"
        Plug{"🔌 MCP 万能插座"}
    end

    subgraph "扩展能力库 (MCP Servers)"
        Amap["🗺️ 高德地图服务
(16+ 工具)"]
        Other["🛠️ 其他自定义工具"]
    end

    %% 连接关系
    Agent1 & Agent2 & Agent3 ==>|统一调用| Plug
    Plug <==>|即插即用| Amap
    Plug <==>|即插即用| Other

    style Plug fill:#f9f,stroke:#333,stroke-width:4px
    style Amap fill:#e1f5fe,stroke:#01579b

4. 体验改进：基于 SSE 的流式进度反馈

由于多智能体协作涉及多次模型推理和网络请求，全流程耗时通常在 20 秒以上。为了避免前端界面卡死，项目实现了基于 SSE (Server-Sent Events) 的流式反馈。
后端在执行每一个步骤时，会立即向前端推送一条状态消息：

# 基于 SSE 的进度推送片段
async def event_generator():
    yield f"data: {json.dumps({'step': 1, 'status': '🔍 正在搜索景点...', 'progress': 15})}\n\n"
    # 执行具体的 Agent 逻辑...
    yield f"data: {json.dumps({'step': 6, 'status': '✅ 规划完成', 'progress': 100, 'data': result})}\n\n"

这种设计将 Agent 的“思考过程”可视化，让用户能清晰看到每一个专家 Agent 的工作进度，提升了交互体验。

5. 演示效果

四、关于项目的不足和未尽事宜

自己开发这个项目的时间不长，然后在Web应用构建上的技术积累也不是很多，所以最后的成品也还是很粗糙。现在只是完成了初版。
现阶段就有几个比较大的遗憾。

1. 服务一般与规划粗糙

因为没有做很复杂的前后端协调，没处理并发，加上多智能体协同工作本来就挺费时，所以可能一次请求需要花比较多的时间才能返回结果，比较笨重。
同时，虽然是一个智能旅行助手，但是感觉其生成的旅行方案也还是不足以直接揣上就出门的，其中的住宿还是需要自己去预定，餐饮方面也还要根据自己的喜好、当天景点的位置去具体挑选，以及景点和路线安排上也不一定是最优的。相比之下，可能真的还是去xhs上找一个靠谱的旅行博主，抄一份自己喜欢的作业就好。所以在最后也开放了xhs、google和百度的拓展搜索，交叉完善你的方案。

2. 小红书相关笔记的引入失败

我本来是想让Agent在生成计划的同时，在前端同步呈现一些小红书旅游博主的笔记，作为补充信息。
但是做的时候才发现，小红书没有用户笔记的开放api，而且反爬非常厉害，我只是挂了自己的Cookie连着请求了几次就检测我异常了。
后面又了解到了RSS技术，正好喜欢的博主pseudoyu做过RSSHub上的小红书RSS订阅，试过用他的路由去请求，试过在本地自建RSS去请求然后上线的时候用docker再部署一下，可能是我没配对，总之效果都不太好。
RSS是订阅制的，那么就只能从有限的、订阅过的博主里搜索他们的笔记，失去了小红书本身的算法推流的助力。其次，我试过订阅很多旅行博主，但是也还是存在请求的博主没做过这个地点的笔记的问题，或者一次请求只返回给我几个博主的内容，想要提高检索效率还得处理并发请求，这方面积累不多也有点嫌麻烦就暂时没搞下去了。
所以最后还是单独搞了一个扩展搜索的功能。也是有点遗憾。

3. 预览图片的有限性

如果你计划的景点小众一些，或者是旅游需求小众一些（比如喜欢逛书店啥的），那么调用Unsplash api返回来的图可能就会货不对板。因为Unsplash主要是摄影师的作品，多为自然、人文的偏专业作品，像一些扫街出来的图片大概没有，所以去检索大概也不会有返回（而且检索过程本身智能体本身就要先做一个中译英的过程）。
之后有想过去调用调用视觉中国的api，或者直接从地图软件或者互联网上去爬取图片，这样对于旅游计划来说更严谨。这之中感觉还会有数据筛选、择优的过程，但之后有机会可以研究研究。

4. 上线

其实本打算演示的时候把整个项目部署到Zeabur上，答辩的时候给大家体验一下玩一下。但是前一晚折腾Zeabur的部署折腾半天没成功，就先把博客写了。只有有心情可能会上线一下，大家可以填填自己的key玩一玩（虽然在网站上填个人私钥不是好习惯），感兴趣可以关注这篇文章，之后上线了会把服务贴在这里。

5. 本文自身

因为时间有限，所以到演示的时候自己大概就只对本项目的一些内容做了解释。文章的深度和广度估计远不及锦恢佬和其他大佬们的文章，对大家的帮助和启发可能也很有限。这是本人当前能力和积累的局限，还是对耐心看到这里的你说声感谢。

参考资料

• OpenAI构建智能体的实用指南中文翻译 翻译了OpenAI的白皮书《A practical guide to building agents》
• Agent 的基本概念与分类锦恢大佬手笔的AI Agent小白教程，非常详细靠谱，学习到了很多
• GPT 应用开发和思考-guangzhengli 23年的一篇博客，介绍了prompt、RAG与当时的Agent
• MCP 终极指南-guangzhengli 上一篇博客的作者大佬25年年初的文章，有助于了解MCP作为Agent的中间层的作用
• 啥是AI Agent！2025年值得推荐入坑AI Agent的五大工具框架！（新手科普篇）
• 踏浪这是同学做的完整的旅行助手应用，技术力和完成度都很高。直到快做完才发现有佬做过类似的了，演示的时候估计自己后背要冒冷汗了www之后如果自己还更新这个项目的话可能会学习他的思路
• 智能体经典范式构建&智能旅行助手Datawhale的HelloAgents的两篇文章