基于LangChain的简易智能旅游助手Agent

一、项目背景与功能实现

本文分享基于 LangChain 框架开发的智能旅游助手 Agent，核心功能是「查询城市天气 + 根据天气推荐景点」，并对比 ReAct 与 FunctionCall 两种 Agent 实现模式的差异，同时总结 LangChain 框架的使用优势。

核心功能拆解

1. 天气查询工具：调用 wttr.in 开源天气接口，获取指定城市实时天气（天气描述+温度），仅支持实时查询，忽略日期参数；
2. 景点推荐工具：基于 Tavily 搜索引擎，构造「城市+天气+适合景点」查询词，获取精准的景点推荐结果；
3. Agent 逻辑控制：限制每个城市的工具调用次数（天气/景点各1次），获取有效景点结果后直接返回最终回答，避免重复调用；
4. 前端交互：基于原生 HTML/JS 实现简洁的对话界面，支持消息发送、加载状态、对话重置。

核心文件技术细节

1. lc_react.py：ReAct 模式

ReAct 模式的核心是「思考-行动-观察」循环，通过提示词约束 LLM 输出固定格式的文本（Thought/Action/Action Input），再解析文本执行工具。

关键函数：

_json_objects_in_text：从 LLM 输出的杂乱文本中提取 JSON 对象（解决 LLM 易拼接无关文本的问题）；

_weather_params_from_input/_attraction_params_from_input：解析工具入参，分别适配天气/景点工具的参数结构；

工具装饰器 @tool：定义工具描述与入参格式，ReAct 模式下工具入参为 JSON 字符串，需手动解析；

Prompt 模板：严格定义 ReAct 格式（Thought/Action/Action Input/Final Answer），并加入「防重复调用」规则约束。

Agent 初始化：

agent = create_react_agent(
    llm=llm,
    prompt=prompt_template,
    tools=[get_weather, get_attraction],
)
​
agent_executor = AgentExecutor(
    agent=agent,
    memory=memory,
    tools=[get_weather, get_attraction],
    verbose=True,
    handle_parsing_errors="返回到上一步并重新尝试，确保Action Input是有效的JSON格式",
    max_iterations=8,
    early_stopping_method="generate",
    stream_runnable=False,
)

2. lc_functioncall.py：FunctionCall 模式

FunctionCall 模式利用 LLM 的工具调用能力，让模型输出结构化的工具调用指令，无需手动解析文本。

• 关键优化：
  • 基于 Pydantic 定义工具入参 Schema（WeatherInput/AttractionInput），替代 ReAct 模式的 JSON 字符串解析；
  • 工具函数直接接收结构化参数（city: str, weather: str），无需手动提取；
  • Prompt 模板简化：使用 MessagesPlaceholder 管理对话历史与 Agent 思考过程，无需手动定义 ReAct 格式。
• Agent 初始化： agent = create_tool_calling_agent( llm=llm, prompt=prompt_template, tools=[get_weather, get_attraction], )

3. main.py：FastAPI 服务封装

• 动态加载 Agent 模式：根据 .env 中的 AGENT_MODE 加载 ReAct 或 FunctionCall 版本的 Agent；
• 接口设计：
  • /api/chat：接收用户消息，调用 Agent 并返回结果；
  • /api/chat/reset：清空对话记忆；
• 静态资源挂载：将 index.html 作为静态页面挂载，实现前后端一体化部署。

4. index.html：前端交互

• 原生 JS 实现核心逻辑：消息发送 / 接收、加载状态、自适应文本框、对话重置；
• 样式设计：响应式布局（移动端隐藏侧边栏）、气泡式消息展示、加载动画；
• 接口交互：通过 fetch 调用后端接口，处理网络错误与服务端异常。

二、开发过程中遇到的问题与解决办法

问题 1：ReAct 模式下 LLM 输出格式不规范

现象

LLM 输出的 Action Input 常拼接无关文本（如 Observation 内容），导致 JSON 解析失败，报错「无法解析 LLM 的输出」。

解决办法

1. 编写解析函数：_json_objects_in_text 从杂乱文本中精准提取 JSON 对象，忽略无关拼接内容；
2. 参数提取优化：_weather_params_from_input/_attraction_params_from_input 针对天气 / 景点工具的参数结构，分别处理 JSON 解析逻辑；
3. 切换模式：改用 FunctionCall 模式，利用 LLM 原生的工具调用能力，输出结构化参数，从根源避免格式问题。

问题 2：重复调用工具

现象

LLM 可能因「确认天气」「翻译推荐结果」等原因重复调用同一城市的天气 / 景点工具。

解决办法

• 在 Prompt 中加入严格规则：每个城市的 get_weather/get_attraction 最多调用 1 次；
• 景点推荐结果有效时，强制返回 Final Answer，禁止后续工具调用。

三、ReAct 与 FunctionCall 模式对比

四、LangChain 对比原生手写 Agent 的优势

1. 工具封装与管理

• LangChain 提供 @tool 装饰器，可快速定义工具描述、入参 Schema，原生手写需手动设计工具注册 / 调用逻辑；
• 内置工具调用解析器，无需手动处理 LLM 输出的格式校验、参数提取。

2. 记忆能力

• LangChain 提供 ConversationBufferMemory 等记忆组件，一键集成对话上下文管理，原生手写需手动维护会话状态；
• 记忆组件与 Agent 解耦，可灵活切换记忆策略（如有限窗口记忆、摘要记忆）。

3. Agent 执行框架

• AgentExecutor 封装了「思考 - 调用工具 - 处理结果」的循环逻辑，原生手写需手动实现循环控制、最大迭代次数、错误处理；
• 内置错误处理机制（如 handle_parsing_errors），可快速适配 LLM 输出异常场景。

4. 多模式适配

• 支持 ReAct、FunctionCall、OpenAI Functions 等多种 Agent 模式，切换成本低；
• 原生手写需为每种模式重新设计解析逻辑与执行流程。

5. 生态集成

• 无缝集成 OpenAI/Tavily 等第三方服务，无需手动封装 API 调用；
• 提供 Prompt 模板、输出解析器等组件，降低提示词工程成本。

五、总结

本次项目通过 LangChain 实现了两种模式的旅游助手 Agent，实践发现：

1. ReAct 模式适合需要显式推理过程的复杂场景，但需投入大量精力处理格式解析问题；
2. FunctionCall 模式更适合简单工具调用场景，稳定性高，开发效率高；
3. LangChain 框架大幅降低了 Agent 开发成本，尤其是工具管理、记忆、执行循环等核心模块，相比原生手写可节省 70% 以上的代码量；
4. 实际开发中，建议优先使用 FunctionCall 模式（稳定性高），复杂推理场景结合 ReAct 模式的显式思考过程。

后续可优化方向：

• 增加多轮对话的上下文理解能力（如识别「昨天问的上海天气」等指代）；
• 接入更多工具（如景点门票、交通信息）；
• 优化景点推荐结果，增加本地化 / 个性化策略。
• 添加RAG？虽然暂时没想好怎么个做法，但为了学习是肯定会融入RAG的。

Github连接：https://github.com/KevinJosephDavis/TravelAgent.git