news 2026/10/30 17:50:58

RAG 进阶:Agentic RAG 与多智能体协作(1):从“问答机器人“到“AI 员工“

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
RAG 进阶:Agentic RAG 与多智能体协作(1):从“问答机器人“到“AI 员工“

RAG 的流水线搭完了:解析 → 切片 → 索引 → 检索 → 重排 → 生成 → 服务化。但这套系统有个本质局限——它是被动的。

用户问一句,它答一句。用户不问,它不动。它不会主动查天气、不会调 API、不会写数据库、不会在回答前先确认"你要的是 2024 年还是 2025 年的数据?"

Agent 要解决的就是这个问题:让 AI 从"回答者"变成"行动者"。


一、RAG vs Agentic RAG:本质区别在哪?

维度传统 RAGAgentic RAG
流程线性:检索 → 生成循环:感知 → 规划 → 行动 → 观察 → 再规划
工具无,只查向量库可调用搜索、API、数据库、代码解释器
决策无,固定流水线有,根据上下文决定下一步做什么
状态无状态,每轮独立有状态,记住历史动作和中间结果
适用场景知识问答复杂任务、多步推理、需要外部数据

一句话总结:传统 RAG 是"查资料写答案",Agentic RAG 是"接到任务后自己想办法完成"。


二、Agent 的核心组件

一个 Agent 由四个基本零件组成,缺一不可:

1. 大脑(LLM + Prompt)

负责理解任务、做决策、规划步骤。这里的关键不是模型多大,而是Prompt 里是否清晰定义了"你可以做什么"和"你该怎么做"。

2. 工具集(Tools)

Agent 的"手"。每个工具是一个函数,有明确的输入输出签名。常见工具:

  • search_knowledge_base(query)— 查知识库
  • web_search(query)— 联网搜索
  • query_database(sql)— 查数据库
  • send_email(to, subject, body)— 发邮件
  • calculator(expression)— 计算器
3. 记忆(Memory)

Agent 需要记住:

  • 短期记忆:当前任务的历史对话和已执行的动作
  • 长期记忆:跨会话的用户偏好、历史经验(可选)
4. 规划器(Planner)

决定"下一步做什么"。有两种主流模式:

  • ReAct:Reason + Act,交替进行推理和行动
  • Plan-and-Execute:先列完整计划,再逐步执行

三、ReAct 模式详解:最经典的 Agent 循环

ReAct 的核心思想是:先想清楚再动手,每动一步再想想。

一个典型的 ReAct 循环长这样:

Thought: 用户想知道上季度销售额,我需要先查数据库。 Action: query_database("SELECT SUM(amount) FROM sales WHERE quarter='Q3'") Observation: 1250000 Thought: 数据拿到了,但用户可能还想知道环比增长。 Action: query_database("SELECT SUM(amount) FROM sales WHERE quarter='Q2'") Observation: 1100000 Thought: 环比增长 = (1250000-1100000)/1100000 = 13.6% Final Answer: 上季度销售额为 125 万元,环比增长 13.6%。

关键点:LLM 每次输出都包含Thought(思考)、Action(行动)、Observation(观察结果)三个部分,循环直到产出Final Answer。


四、动手:用 LangGraph 搭建第一个 Agent

LangGraph 是目前最流行的 Agent 框架,它把 Agent 建模成一个状态图,每个节点是一个动作,边是决策逻辑。

下面是一个最小可用的 ReAct Agent 实现:

from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated from langchain_core.messages import HumanMessage, AIMessage, ToolMessage from langchain_openai import ChatOpenAI import operator # 1. 定义状态 class AgentState(TypedDict): messages: Annotated[list, operator.add] # 消息历史自动累加 next_step: str # 下一步动作 # 2. 定义工具 def search_knowledge_base(query: str) -> str: """搜索内部知识库""" # 这里替换成你实际的 RAG 检索逻辑 return f"知识库中关于 '{query}' 的信息..." def web_search(query: str) -> str: """联网搜索""" return f"网络搜索结果: {query}" tools = { "search_knowledge_base": search_knowledge_base, "web_search": web_search, } # 3. 定义 LLM llm = ChatOpenAI(model="gpt-4o", temperature=0) llm_with_tools = llm.bind_tools([ {"name": "search_knowledge_base", "description": "搜索内部知识库", "parameters": {"query": {"type": "string"}}}, {"name": "web_search", "description": "联网搜索最新信息", "parameters": {"query": {"type": "string"}}}, ]) # 4. 定义节点 def agent_node(state: AgentState): messages = state["messages"] response = llm_with_tools.invoke(messages) return {"messages": [response]} def tool_node(state: AgentState): last_message = state["messages"][-1] tool_calls = last_message.tool_calls results = [] for tool_call in tool_calls: tool_name = tool_call["name"] tool_args = tool_call["args"] result = tools[tool_name](**tool_args) results.append(ToolMessage(content=result, tool_call_id=tool_call["id"])) return {"messages": results} # 5. 定义路由逻辑 def should_continue(state: AgentState): last_message = state["messages"][-1] if last_message.tool_calls: return "tools" # 还有工具要调用,继续 return END # 没有工具调用了,结束 # 6. 构建图 workflow = StateGraph(AgentState) workflow.add_node("agent", agent_node) workflow.add_node("tools", tool_node) workflow.set_entry_point("agent") workflow.add_conditional_edges("agent", should_continue, {"tools": "tools", END: END}) workflow.add_edge("tools", "agent") # 工具执行完回到 agent app = workflow.compile() # 7. 运行 result = app.invoke({ "messages": [HumanMessage(content="帮我查一下公司最新的报销政策,顺便搜一下同行是怎么做的")] }) for msg in result["messages"]: print(msg.type, ":", msg.content[:100])

这段代码做了什么:

  1. LLM 收到问题后,决定调用search_knowledge_base和web_search
  2. 工具节点执行两个函数,把结果写回状态
  3. LLM 看到工具返回的结果,整合成最终答案

五、Agent 的三个常见陷阱

1. 无限循环

Agent 可能陷入"调用工具 → 结果不满意 → 再调用同一个工具"的死循环。解法:设置最大迭代次数(如 10 次),超时强制终止。

2. 工具参数幻觉

LLM 可能编造不存在的参数名或参数值。解法:用 Pydantic 严格校验工具输入,参数不对直接报错让 LLM 重试。

3. 状态爆炸

长对话中消息历史越来越长,超出上下文窗口。解法:定期压缩历史消息,只保留关键摘要。

最后说一句,技术成长不只是写代码,职业规划和自我包装同样重要。我整理了一份简历、面试和职业规划的学习资料,适合想在职场上走得更远的朋友看看。

资料展示

下面是我整理的AI大模型学习资料和工具包预览,适合收藏后按主题逐步学习。

如果你想看完整资料目录,可以在评论区留言「资料」;也欢迎告诉我你更关注AI大模型里的哪类内容。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/10/22 13:28:34

深入解析Java SPI机制与Spring Boot扩展实践

1. SPI机制的本质与Java原生实现在深入探讨Spring SPI之前,我们必须先理解SPI(Service Provider Interface)机制的本质。SPI是一种服务发现机制,它允许第三方为某个接口提供实现,而框架能够自动发现并加载这些实现。这…

作者头像 李华
网站建设 2026/10/23 13:24:22

Python单元测试框架unittest详解与实践指南

1. unittest框架概述unittest是Python标准库中内置的单元测试框架,它最初受JUnit启发而设计,为Python开发者提供了一套完整的测试解决方案。这个框架在2001年随Python 2.1版本首次引入,经过多年发展已成为Python生态中测试代码的基石工具。在…

作者头像 李华
网站建设 2026/10/23 8:18:54

Netty与SpringBoot整合实践:从Socket到TCP长连接的物联网设备接入全攻略

搞物联网设备接入这件事,我踩过不少坑,尤其是用Netty对接socket设备再配合SpringBoot做业务处理,中间有太多细节比官方文档里写的要曲折。最近团队刚完成一个仓储物流场景的设备接入平台,几十台扫码设备和传感器通过TCP长连接实时…

作者头像 李华
网站建设 2026/10/23 7:47:10

大模型API统一网关liteLLM:模型路由、密钥管理与成本控制实战

干这行最头疼的事,不是模型效果不好,而是“调接口调得想骂人”。手上一堆项目要接不同厂家的模型,有的用这种方式鉴权,有的要那种格式传参,A家的输出和B家的输出还不完全兼容。原本半小时能写完的功能,光对…

作者头像 李华
网站建设 2026/10/23 2:56:18

Vue3登录状态持久化实战:Pinia与localStorage实现Token管理

1. 为什么每个 Vue3 项目都得面对登录状态持久化做过前端的同学应该都有过这种体验:辛辛苦苦把登录页做完,接口也通了,跳转也正常了,结果自己按了一下 F5,心里瞬间一凉——又回到登录页了。更尴尬的是,明明…

作者头像 李华
网站建设 2026/10/22 21:24:18

COMSOL光子晶体能带计算:模式分离与伪模识别

1. 光子晶体能带计算的核心挑战在光子晶体仿真领域,能带结构计算是理解其光学特性的基础。COMSOL Multiphysics作为一款强大的多物理场仿真软件,为光子晶体研究提供了便捷的数值计算平台。但在实际计算过程中,模式分离和伪模识别一直是困扰研…

作者头像 李华