LangChain RAG 与 Agent 实践:活动组件 AI 助手实现方案
概述
本文主要讲述采用 LangChain 开发 RAG(Retrieval-Augmented Generation,检索增强生成)和 Agent(智能体)应用的思路,分析 AIGC 在活动组件业务中的应用案例。通过构建活动组件 AI 助手,实现了从需求理解到工具调用的全流程自动化。
背景
活动组件 AI 助手的落地共经历了三个阶段:
- 快速落地:采用 Dify 等低代码平台,验证 AI 与业务结合的想法,快速实现第一版原型。
- 优化性能:采用 LangChain 框架开发具备 RAG 能力的第二版,提升检索精度与响应速度。
- 丰富功能:开发具备 Agent 能力的第三版,实现自主规划、工具调用及复杂任务拆解。
效果展示
RAG 实践效果
根据用户需求,系统能够推荐合适的活动组件,提供贴合需求的参考方案,显著降低组件选择成本。

Agent 实践效果
实现 Agent 的计划、拆解需求、反思、推理、执行工具的能力。AI 可根据用户需求自行选择工具解决问题。
场景一:查询符合需求的活动信息
例如:最近一个月最火的 3 个'x 游戏'活动。

场景二:查询使用过组件的活动列表
例如:最近有哪些活动在使用这个组件 xxxx。

落地实现
LangChain RAG 实践:LCEL + 云原生数据仓库
LangChain Expression Language(LCEL)是一种声明式方法,可以轻松地将链组合在一起。LCEL 从设计之初就支持将原型投入生产,从最简单的'prompt + LLM'链到最复杂的链,无需修改代码即可扩展。
核心流程
- LLM 润色用户需求:将自然语言转化为结构化查询意图。
- 知识库召回:利用向量检索能力获取相关上下文。
- 上下文整合:将知识上下文结合用户需求交给 LLM。
- 生成推荐:得到最终推荐的组件列表。
数据转换细节
- 自然语言转结构化数据:
利用 LLM 提取关键实体(如时间范围、游戏类型、指标类型),确保符合知识库数据结构。
from langchain.prompts import ChatPromptTemplate
from langchain_core.output_parsers import JsonOutputParser
parser = JsonOutputParser()
prompt = ChatPromptTemplate.from_template(
"""请将以下用户请求转换为 JSON 格式的结构化数据。
用户请求:{query}
要求包含字段:time_range, game_type, metric, limit.
{format_instructions}"""
)
structured_query = prompt | llm | parser
- 匹配知识库细节:
- 分类匹配:优先匹配组件分类标签。
- Top K 召回:召回 relevant_size 个 top k 结果。
- 二次筛选:召回数据根据 score 做二次筛选,过滤低置信度结果。
from langchain_community.vectorstores import FAISS
from langchain_core.retrievers import VectorStoreRetriever
retriever = VectorStoreRetriever(vectorstore=vector_store, search_type="similarity_score_threshold", search_kwargs={"score_threshold": 0.7})
relevant_docs = retriever.invoke(structured_query)
- 业务系统解析:
最终得到结构化业务数据,由后端系统解析并向用户展现内容。
LangChain Agent 实践
实现根据用户需求,自主规划任务和调用工具,查询所需的活动和组件数据。
ReAct Agent 核心流程
ReAct(Reasoning and Acting)模式结合了推理和行动。Agent run 核心流程如下:
- Thought:思考当前步骤需要做什么。
- Action:选择工具并执行。
- Observation:观察工具返回的结果。
- Final Answer:综合信息给出最终答案。
from langchain.agents import initialize_agent, Tool
from langchain.agents import AgentType
from langchain.chat_models import ChatOpenAI
def get_activity_stats(game_name: str) -> str:
return f"{game_name} 的统计数据..."
tools = [
Tool(
name="ActivityStats",
func=get_activity_stats,
description="用于查询特定游戏的活动统计数据"
)
]
llm = ChatOpenAI(temperature=0)
agent = initialize_agent(tools, llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, verbose=True)
response = agent.run("最近一周访问量最高的 3 个 x 游戏活动")
模型对比与选型
不同大模型在实现 Agent 时的表现差异明显,理解能力较强的大模型更适合实现复杂的 Agent。
-
模型 A:
- 耗时较长(50-70s)。
- 准确性不够高,理解能力稍差(例如将'按 pv 降序'理解为升序)。
- 适合简单问答场景。
-
模型 B:
- 性能高(10-20s)。
- 准确性高,理解能力强。
- 对 tool_call 方面的微调较好,对调用工具的需求比较敏感,比较适合实现复杂 Agent 的需求。
统一入口架构
最后把 RAG 和 Agent 的能力通过前置 AI 路由统一起来,实现 AI 服务统一入口。前端只需调用一个接口,后端根据意图自动分发至 RAG 模块或 Agent 模块。

总结
本文讲述了采用 LangChain 开发 RAG 和 Agent 应用的思路,分析 AIGC 在组件活动业务中的应用案例:活动组件 AI 助手。
- 应用案例分析:展示了活动组件智能 AI 助手的推荐组件能力及查询历史活动和组件数据的能力。
- 落地核心思路:分别讲述了 RAG 的 LCEL 链构建、向量检索策略,以及 Agent 的 ReAct 规划与工具调用机制。
- 模型评估:对比了不同大模型在实际 Agent 规划中的效果,强调了模型理解能力与工具调用敏感度对复杂任务的重要性。
- 架构演进:介绍了从单一功能到统一 AI 服务入口的架构演进过程。
常见问题与优化建议
1. 检索准确率优化
如果 RAG 检索结果不精准,建议检查向量分块(Chunk Size)策略。对于活动组件文档,建议按'组件属性'进行切分,而非纯文本切分,以提高语义匹配度。
2. Agent 幻觉控制
Agent 可能会产生幻觉,导致调用不存在的工具。建议在 Prompt 中明确限定工具列表,并在代码层面对工具调用参数进行校验(Validation)。
3. 延迟优化
Agent 的多步思考会增加延迟。对于简单查询,可配置路由直接走 RAG 流程;仅当检测到复杂意图时再触发 Agent 流程,以平衡体验与功能。
4. 数据安全
涉及业务数据的查询,务必在 Agent 层增加权限校验中间件,确保 AI 只能访问授权范围内的数据,防止敏感信息泄露。