深度解析:LangChain、Agent、RAG、FC、ReAct、LangGraph、A2A、MCP — 区别、联系与全景图
目录
2.1 Function Calling(FC)— 工具调用能力
2.2 RAG(Retrieval-Augmented Generation)— 检索增强生成
2.3 ReAct(Reasoning + Acting)— 推理与行动范式
2.5 MCP(Model Context Protocol)— 模型上下文协议
2.6 A2A(Agent-to-Agent Protocol)— 智能体间通信协议
5.4 Multi-Agent System(多智能体系统)
5.5 Agentic Design Patterns(智能体设计模式)
5.6 OpenAI Agents SDK / Responses API
一、总览:技术全景图
这些概念并非平行关系,而是分属不同的层级。可以这样理解:
┌─────────────────────────────────────────────────────────┐
│ 应用层 (Application) │
│ ChatBot / Copilot / 自动化工作流 / 多Agent系统 │
├─────────────────────────────────────────────────────────┤
│ 框架层 (Framework) │
│ LangChain / LangGraph / CrewAI │
│ AutoGen / Dify / Coze 等 │
├─────────────────────────────────────────────────────────┤
│ 编排模式层 (Pattern) │
│ ReAct / Plan-and-Execute / Multi-Agent │
│ Reflexion / LATS 等 │
├─────────────────────────────────────────────────────────┤
│ 能力层 (Capability) │
│ Agent / RAG / Function Calling / Memory │
│ Tool Use / Planning 等 │
├─────────────────────────────────────────────────────────┤
│ 协议/接口层 (Protocol) │
│ MCP / A2A / OpenAPI │
├─────────────────────────────────────────────────────────┤
│ 模型层 (Model) │
│ GPT / Claude / Gemini / DeepSeek / Qwen 等 │
└─────────────────────────────────────────────────────────┘
关键认知: RAG 是一种技术方案,FC 是一种模型能力,ReAct 是一种推理范式,Agent 是一种系统角色,MCP 和 A2A 是通信协议,LangChain 和 LangGraph 是开发框架。它们不在同一维度上。
二、逐个击破:核心概念详解
2.1 Function Calling(FC)— 工具调用能力
本质:模型的底层能力
Function Calling 是大语言模型提供的一种能力,让模型能够在对话过程中识别用户意图,并生成结构化的函数调用请求(通常是 JSON 格式),由外部系统执行后将结果返回给模型。
工作流程:
用户提问 → 模型判断需要调用某个工具 → 模型输出函数名+参数(JSON)
→ 外部代码执行该函数 → 将执行结果返回给模型 → 模型生成最终回答
核心特点:
- 由 OpenAI 于 2023 年 6 月 率先推出,现已成为行业标准能力
- 它不是框架,不是模式,而是模型本身的一项能力
- 本质上解决了"让 LLM 能够与外部世界交互"的问题
- 后续演化为 Tool Use(工具使用),各厂商命名不同,但原理一致
代码示例(OpenAI 风格):
tools = [{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的天气",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "城市名"}
}
}
}
}]
response = client.chat.completions.create(
model="gpt-4",
messages=[{"role": "user", "content": "北京今天天气怎么样?"}],
tools=tools
)
# 模型返回: 调用 get_weather(city="北京")
与其他概念的关系:
- FC 是构建 Agent 的基石能力——没有 FC,Agent 就无法调用工具
- RAG 系统中也可以用 FC 来调用检索工具(但更常见的是直接在 pipeline 中集成检索)
2.2 RAG(Retrieval-Augmented Generation)— 检索增强生成
本质:一种技术方案/架构模式
RAG 的核心思想是:在 LLM 生成回答之前,先从外部知识库中检索相关信息,将检索结果作为上下文注入到 Prompt 中,再让模型生成回答。
标准流程:
用户提问
↓
[检索阶段] 将问题向量化 → 在向量数据库中检索相关文档片段
↓
[增强阶段] 将检索到的文档片段 + 原始问题 拼接成新的 Prompt
↓
[生成阶段] LLM 基于增强后的 Prompt 生成回答
核心解决的问题:
- LLM 的知识截止日期问题(知识过时)
- LLM 的幻觉问题(通过提供事实依据减少编造)
- 私有数据/领域知识的注入
典型技术栈:
| 环节 | 常用工具 |
|---|---|
| 文档加载 | Unstructured, LlamaParse |
| 文本分割 | LangChain TextSplitter |
| 向量化 | OpenAI Embedding, BGE, Jina |
| 向量数据库 | Milvus, Pinecone, Chroma, Weaviate |
| 检索策略 | 稠密检索、稀疏检索、混合检索、Reranking |
| 生成 | GPT-4, Claude, DeepSeek 等 |
RAG 的进阶演化:
| 阶段 | 名称 | 说明 |
|---|---|---|
| Naive RAG | 基础 RAG | 检索 → 生成,最简单的 pipeline |
| Advanced RAG | 进阶 RAG | 加入 Query Rewriting、HyDE、Reranking、多路召回 |
| Modular RAG | 模块化 RAG | 可插拔的模块组合,灵活编排 |
| Agentic RAG | 智能体 RAG | 用 Agent 动态决定是否需要检索、检索什么、检索几次 |
与其他概念的关系:
- RAG 可以独立存在——不需要 Agent,一个简单的 pipeline 就能实现
- RAG 也可以是 Agent 使用的工具之一——Agent 决定何时检索、检索什么
- Agentic RAG 是 RAG 和 Agent 的结合体,代表了更高级的形态
2.3 ReAct(Reasoning + Acting)— 推理与行动范式
本质:一种 Prompt/推理框架
ReAct 由普林斯顿大学和 Google 于 2022 年 提出(论文:ReAct: Synergizing Reasoning and Acting in Language Models),核心思想是让模型交替进行推理(Reasoning) 和行动(Acting)。
经典模式:
Thought: 用户问的是北京的天气,我需要先查询天气工具
Action: get_weather(city="北京")
Observation: 北京今天晴,25°C
Thought: 我已经获得了天气信息,可以回答用户了
Answer: 北京今天天气晴朗,气温25°C。
核心特点:
- Thought(思考):模型解释自己的推理过程
- Action(行动):模型决定调用哪个工具
- Observation(观察):模型接收工具返回的结果
- 三者交替循环,直到任务完成
与其他范式的对比:
| 范式 | 特点 | 适用场景 |
|---|---|---|
| CoT(Chain-of-Thought) | 只推理不行动 | 数学题、逻辑推理 |
| Act-only | 只行动不推理 | 简单工具调用 |
| ReAct | 推理 + 行动交替 | 复杂多步骤任务 |
| Plan-and-Execute | 先规划再执行 | 需要全局规划的任务 |
| Reflexion | 执行后反思改进 | 需要自我纠错的任务 |
与其他概念的关系:
- ReAct 是 Agent 最常用的推理模式之一
- Function Calling 提供了"行动"能力,ReAct 提供了"推理"框架,两者结合就形成了最基础的 Agent
2.4 Agent(智能体)— 自主决策的执行者
本质:一种系统角色/架构模式
Agent 不是某个具体的库或工具,而是一种设计理念:让 LLM 具备自主感知环境、制定计划、调用工具、完成任务的能力。
一个完整 Agent 的核心组成:
┌─────────────────────────────────────┐
│ Agent │
│ │
│ ┌──────────┐ ┌──────────────┐ │
│ │ LLM │ │ Memory │ │
│ │ (大脑) │ │ (记忆系统) │ │
│ └────┬─────┘ └──────────────┘ │
│ │ │
│ ┌────▼─────┐ ┌──────────────┐ │
│ │ Planning │ │ Tools │ │
│ │ (规划能力) │ │ (工具集) │ │
│ └──────────┘ └──────────────┘ │
│ │
│ ┌──────────────────────────────┐ │
│ │ Reasoning Strategy │ │
│ │ (推理策略: ReAct/Plan等) │ │
│ └──────────────────────────────┘ │
└─────────────────────────────────────┘
Agent 与其他概念的层级关系:
Agent 是一个上层建筑,它组合了:
├── LLM(推理能力)
├── FC/Tool Use(工具调用能力)
├── ReAct/Plan-and-Execute(推理策略)
├── Memory(记忆管理)
├── RAG(知识检索能力,可选)
└── Planning(任务规划能力)
Agent 的分类:
| 类型 | 说明 | 例子 |
|---|---|---|
| ReAct Agent | 使用 ReAct 范式的 Agent | LangChain ReAct Agent |
| Plan-and-Execute Agent | 先规划后执行 | BabyAGI 思路 |
| Tool-Use Agent | 主要通过工具完成任务 | GPTs |
| Multi-Agent | 多个 Agent 协作 | CrewAI, AutoGen |
| Autonomous Agent | 高度自主的 Agent | AutoGPT, Devin |
2.5 MCP(Model Context Protocol)— 模型上下文协议
本质:一个开放协议/接口标准
MCP 由 Anthropic 于 2024 年 11 月 发布,目标是为 LLM 连接外部数据源和工具提供一个标准化的协议。
类比理解:
如果 Function Calling 是"让模型知道有哪些工具可以用",那么 MCP 就是"定义这些工具应该如何被发现、描述和调用的统一标准"。
MCP 之于 AI 工具,就像 USB 协议 之于外设——统一了接口标准。
MCP 的架构:
┌──────────────┐ MCP协议 ┌──────────────┐
│ MCP Client │ ◄────────────► │ MCP Server │
│ (AI应用/IDE) │ │ (工具/数据) │
└──────────────┘ └──────────────┘
MCP Server 可以封装:
├── 数据库连接
├── 文件系统访问
├── API 调用
├── 浏览器操作
└── 任意自定义工具
MCP 提供的三种核心能力(Primitives):
| 能力 | 说明 |
|---|---|
| Resources | 暴露数据/文件供模型读取(类似 GET 请求) |
| Tools | 暴露可执行的操作供模型调用(类似 POST 请求) |
| Prompts | 预定义的 Prompt 模板 |
MCP vs Function Calling:
| 维度 | Function Calling | MCP |
|---|---|---|
| 层级 | 模型能力 | 开放协议 |
| 工具定义 | 每次请求时在代码中定义 | MCP Server 标准化暴露 |
| 可发现性 | 需要开发者手动注册 | 客户端自动发现可用工具 |
| 复用性 | 绑定在特定应用中 | 一个 MCP Server 可被任何 MCP Client 使用 |
| 标准化 | 各厂商格式不统一 | 统一的 JSON-RPC 2.0 协议 |
| 生态 | 封闭在应用内部 | 可构建共享的 MCP Server 生态 |
2.6 A2A(Agent-to-Agent Protocol)— 智能体间通信协议
本质:Agent 间的互操作协议
A2A 由 Google 于 2025 年 4 月 发布,是专门用于 Agent 与 Agent 之间通信的开放协议。
核心解决的问题:
MCP 解决的是"Agent 如何连接工具和数据",而 A2A 解决的是"Agent 如何发现、连接并协作其他 Agent"。
A2A 的关键概念:
| 概念 | 说明 |
|---|---|
| Agent Card | Agent 的"名片",以 JSON 格式描述 Agent 的能力、端点、认证方式(发布在 /.well-known/agent.json) |
| Task | Agent 之间的任务单元,有完整的生命周期(创建 → 执行 → 完成/失败) |
| Message | Agent 之间传递的消息,包含多个 Part(文本、文件、结构化数据) |
| Artifact | 任务的输出产物 |
A2A 的工作流程:
Agent A(客户端) Agent B(远程)
│ │
│ 1. 发现 Agent Card │
│ ──────────────────────────────────►│
│ │
│ 2. 创建 Task │
│ ──────────────────────────────────► │
│ │
│ 3. 接收任务状态更新/流式结果 │
│ ◄────────────────────────────────── │
│ │
│ 4. 任务完成,获取 Artifact │
│ ◄────────────────────────────────── │
A2A vs MCP:
| 维度 | MCP | A2A |
|---|---|---|
| 通信对象 | 模型 ↔ 工具/数据 | Agent ↔ Agent |
| 抽象层级 | 低层级(函数调用) | 高层级(任务协作) |
| 有状态性 | 通常是无状态的请求-响应 | 有状态的任务生命周期 |
| 交互模式 | 同步为主 | 支持同步、异步、流式推送 |
| 类比 | USB 接口(设备连接标准) | HTTP 协议(服务间通信标准) |
| 发布者 | Anthropic(2024.11) | Google(2025.04) |
互补关系:
MCP 和 A2A 并非竞争关系,而是互补的——MCP 是 Agent 的"手"(连接工具),A2A 是 Agent 的"嘴"(连接其他 Agent)。
2.7 LangChain — LLM 应用开发框架
本质:一个开源开发框架/SDK
LangChain 是目前最流行的 LLM 应用开发框架,由 Harrison Chase 于 2022 年 10 月 创建。它提供了构建 LLM 应用所需的各种组件和抽象。
核心模块(LangChain 生态):
LangChain 生态
├── langchain-core # 基础抽象层(Runnable接口、Prompt模板等)
├── langchain # 核心链(Chain、Agent、Retriever等)
├── langchain-community # 第三方集成(数百个工具/模型/数据库接入)
├── langchain-openai # OpenAI 专用集成
├── langchain-anthropic # Anthropic 专用集成
├── langgraph # 有状态多Agent编排(独立包)
├── langsmith # 可观测性平台(LLM应用调试/监控)
└── langserve # LangChain应用部署为REST API
LangChain 提供的核心抽象:
| 抽象 | 说明 |
|---|---|
| Model | 统一的 LLM/ChatModel 接口 |
| Prompt Template | 结构化 Prompt 管理 |
| Chain (LCEL) | 组件的链式组合(LangChain Expression Language) |
| Retriever | 统一的检索接口 |
| Agent | 工具调用 + 推理循环 |
| Memory | 对话历史管理 |
| Tool | 工具定义和调用 |
LangChain 的定位:
- 它是胶水层,把 LLM、Prompt、工具、检索、记忆等组件粘合在一起
- 它是框架,不是协议、不是模型、不是模式
- 它覆盖了从简单 Chain 到复杂 Agent 的全场景
一个简单的 LangChain RAG 示例:
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough
from langchain_core.output_parsers import StrOutputParser
# 构建检索器
vectorstore = Chroma.from_documents(docs, OpenAIEmbeddings())
retriever = vectorstore.as_retriever()
# 构建 RAG Chain
prompt = ChatPromptTemplate.from_template(
"根据以下上下文回答问题:\n{context}\n\n问题:{question}"
)
chain = (
{"context": retriever, "question": RunnablePassthrough()}
| prompt
| ChatOpenAI(model="gpt-4")
| StrOutputParser()
)
chain.invoke("什么是向量数据库?")
2.8 LangGraph — 有状态多智能体编排框架
本质:LangChain 生态中的编排框架
LangGraph 由 LangChain 团队于 2024 年 发布,是专门用于构建有状态、多步骤、多 Agent 应用的框架。
LangGraph vs LangChain 的核心区别:
| 维度 | LangChain | LangGraph |
|---|---|---|
| 执行模型 | 链式(线性 pipeline) | 图(有向图,支持循环) |
| 状态管理 | 有限 | 内置持久化状态 |
| 流程控制 | 顺序执行为主 | 支持条件分支、循环、并行 |
| 适用场景 | 简单 Chain、RAG | 复杂 Agent 工作流、多 Agent 协作 |
| 人机交互 | 较难实现 | 原生支持 Human-in-the-loop |
| 时间旅行 | 不支持 | 支持状态回溯/重放 |
LangGraph 的核心概念:
from langgraph.graph import StateGraph, START, END
# 定义状态
class AgentState(TypedDict):
messages: list
next_step: str
# 构建图
graph = StateGraph(AgentState)
graph.add_node("reasoner", reasoner_node)
graph.add_node("tool_caller", tool_caller_node)
graph.add_node("responder", responder_node)
# 定义边(包括条件边)
graph.add_edge(START, "reasoner")
graph.add_conditional_edges("reasoner", route_after_reasoning)
graph.add_edge("tool_caller", "reasoner")
graph.add_edge("responder", END)
# 编译并运行
app = graph.compile()
result = app.invoke({"messages": [user_message]})
LangGraph 的典型应用场景:
- 多步推理的复杂 Agent
- 多 Agent 协作系统(如:研究员 Agent + 写手 Agent + 审核 Agent)
- 需要 Human-in-the-loop 的审批流程
- 需要状态持久化的长时间运行任务
三、关系矩阵:它们之间到底是什么关系?
3.1 层级依赖关系
┌─────────────┐
│ 完整的AI应用 │
└──────┬──────┘
│
┌────────────┼────────────┐
│ │ │
┌─────▼─────┐ ┌───▼────┐ ┌────▼─────┐
│ Multi- │ │ Agent │ │ Simple │
│ Agent │ │ System │ │ RAG App │
│ System │ └───┬────┘ └──────────┘
└─────┬─────┘ │
│ │
┌─────────┼───────────┤
│ │ │
┌───▼──┐ ┌───▼────┐ ┌────▼────┐
│LangGraph││LangChain││LangGraph│
└───┬──┘ └───┬────┘ └────┬────┘
│ │ │
├─────────┼───────────┤
│ │ │
┌───▼──┐ ┌───▼────┐ ┌────▼───┐
│ A2A │ │ ReAct │ │ RAG │
│协议 ││ 推理模式 │ │ 技术方案│
└───┬──┘ └───┬────┘ └────┬───┘
│ │ │
└─────────┼───────────┘
│
┌─────▼─────┐
│Function │
│Calling │
│/ MCP │
└─────┬─────┘
│
┌─────▼─────┐
│ LLM │
└───────────┘
3.2 功能定位关系
| 这个概念... | 解决的问题 |
|---|---|
| LLM | 提供语言理解和生成能力 |
| Function Calling | 让模型能"动手"调用外部函数 |
| MCP | 标准化"动手"的接口(工具连接协议) |
| RAG | 让模型能"查资料"获取外部知识 |
| ReAct | 让模型学会"边想边做"(推理策略) |
| Agent | 将上述能力整合为一个自主执行单元 |
| A2A | 让多个 Agent 能"对话协作"(通信协议) |
| LangChain | 提供构建上述系统的工具包 |
| LangGraph | 提供编排复杂 Agent 工作流的框架 |
3.3 协作关系举例
场景:构建一个"AI研究助手"
用户:"帮我调研 MCP 协议的最新进展,写一份报告"
执行流程:
1. [LangGraph] 编排整个工作流
2. [Agent-研究员] 接收任务
├── 使用 [FC] 调用搜索工具 → 获取最新资料
├── 使用 [RAG] 检索本地知识库 → 补充背景知识
└── 使用 [ReAct] 范式 → 边推理边行动
3. [Agent-写手] 接收研究员的资料
├── 使用 [RAG] 检索写作风格参考
└── 生成报告初稿
4. [Agent-审核员] 审核报告质量
└── 通过 [A2A] 协议与写手沟通修改意见
5. [MCP Server] 提供文件系统访问 → 保存最终报告
四、横向对比表
4.1 全维度对比
| 维度 | FC | RAG | ReAct | Agent | MCP | A2A | LangChain | LangGraph |
|---|---|---|---|---|---|---|---|---|
| 类型 | 模型能力 | 技术方案 | 推理范式 | 架构角色 | 通信协议 | 通信协议 | 开发框架 | 编排框架 |
| 层级 | 能力层 | 能力层 | 模式层 | 能力层 | 协议层 | 协议层 | 框架层 | 框架层 |
| 是否可独立使用 | 否(需模型) | 是 | 否(需Agent) | 是 | 是 | 是 | 是 | 是(但需LLM) |
| 发布者 | OpenAI | Meta/FB | Princeton | - | Anthropic | LangChain | LangChain | |
| 发布时间 | 2023.06 | 2020.05 | 2022.10 | - | 2024.11 | 2025.04 | 2022.10 | 2024 |
| 是否需要其他组件 | 需要LLM | 需要Embedding+向量库 | 需要LLM+Tools | 需要LLM+FC+… | 需要Client | 需要Agent | 需要LLM | 需要LLM |
| 是否有标准规范 | 各厂不同 | 无统一标准 | 论文定义 | 无统一标准 | 有(RPC 2.0) | 有(JSON) | 有(API) | 有(API) |
4.2 竞争/互补关系
| 关系 | 说明 |
|---|---|
| MCP ↔ FC | 互补且部分竞争:MCP 是 FC 的标准化升级,但 FC 更底层更灵活 |
| MCP ↔ A2A | 完全互补:MCP 管"Agent↔工具",A2A 管"Agent↔Agent" |
| LangChain ↔ LangGraph | 包含关系:LangGraph 是 LangChain 生态的一部分,但可独立使用 |
| LangChain ↔ CrewAI/AutoGen | 竞争关系:都是多Agent框架,不同实现方案 |
| ReAct ↔ Plan-and-Execute | 互补/替代关系:不同的推理策略,适用于不同场景 |
五、补充:容易遗漏的重要概念
5.1 Tool Use(工具使用)
Function Calling 的更广义称呼。FC 特指模型输出结构化函数调用的能力,而 Tool Use 泛指 LLM 使用外部工具的整个过程(包括发现、选择、调用、处理结果)。MCP 协议本质上就是标准化了 Tool Use 的接口。
5.2 Memory(记忆系统)
Agent 的核心组件之一,负责管理对话历史和长期记忆。
| 类型 | 说明 | 技术实现 |
|---|---|---|
| 短期记忆 | 当前对话上下文 | Context Window |
| 长期记忆 | 跨对话的信息持久化 | 向量数据库 + 检索 |
| 工作记忆 | 任务执行中的中间状态 | LangGraph State |
5.3 Planning(规划能力)
Agent 将复杂任务分解为子任务的能力。常见策略:
- Task Decomposition:将大任务拆分为小步骤
- Plan-and-Execute:先制定完整计划,再逐步执行
- Tree of Thoughts (ToT):探索多条推理路径
5.4 Multi-Agent System(多智能体系统)
由多个专业化 Agent 协作完成复杂任务的系统。
| 框架 | 发布者 | 特点 |
|---|---|---|
| LangGraph | LangChain | 图编排,灵活控制流 |
| CrewAI | 社区 | 角色化,模拟团队协作 |
| AutoGen | Microsoft | 对话式多Agent |
| OpenAI Swarm | OpenAI | 轻量级Agent编排(实验性) |
| Dify | 社区 | 低代码Agent构建平台 |
| Coze | 字节跳动 | 低代码Agent构建平台 |
5.5 Agentic Design Patterns(智能体设计模式)
Andrew Ng(吴恩达)总结的四种 Agent 设计模式:
| 模式 | 说明 |
|---|---|
| Reflection | Agent 反思并改进自己的输出 |
| Tool Use | Agent 使用外部工具(FC/MCP) |
| Planning | Agent 分解任务并制定执行计划 |
| Multi-Agent | 多个 Agent 协作 |
5.6 OpenAI Agents SDK / Responses API
OpenAI 于 2025 年推出的 Agents SDK,提供了原生的 Agent 构建能力,内置了 Handoff(Agent 间交接)、Guardrails(安全护栏)等机制。这代表了大模型厂商正在从"提供模型"向"提供 Agent 基础设施"转型。
5.7 LangSmith
LangChain 生态中的可观测性平台,用于:
- Trace 追踪(查看每一步 LLM 调用)
- 评估(自动化测试 Agent 表现)
- 监控(生产环境的性能监控)
- Debugging(回放和调试 Agent 执行过程)
六、典型技术选型场景
场景 1:简单的知识问答系统
需求:基于内部文档的 Q&A 系统
选型:RAG pipeline
技术栈:LangChain + Chroma + GPT-4
不需要:Agent、A2A、MCP
场景 2:多功能 AI 助手
需求:能搜索、计算、查天气的聊天助手
选型:ReAct Agent + Function Calling
技术栈:LangChain/LangGraph + Tools + GPT-4
可选加入:MCP(标准化工具接入)
场景 3:复杂工作流自动化
需求:自动化研究报告生成(调研→分析→写作→审核)
选型:Multi-Agent + LangGraph
技术栈:LangGraph + 多个专业化 Agent + RAG
可选加入:A2A(如果 Agent 来自不同系统)
场景 4:企业级 Agent 平台
需求:构建可插拔、可扩展的 Agent 平台
选型:MCP + A2A + LangGraph
技术栈:MCP Server(标准化工具接入)+ A2A(Agent 间通信)
+ LangGraph(工作流编排)+ LangSmith(可观测性)
七、总结与展望
一句话总结每个概念
| 概念 | 一句话 |
|---|---|
| FC | 让模型有"手",能调用外部函数 |
| RAG | 让模型有"图书馆",能查资料再回答 |
| ReAct | 让模型学会"三思而后行" |
| Agent | 把手、脑、记忆、计划整合为一个自主实体 |
| MCP | 统一了"手"的接口标准 |
| A2A | 统一了"Agent 之间说话"的方式 |
| LangChain | 构建这一切的工具箱 |
| LangGraph | 编排复杂 Agent 工作流的导演 |
行业趋势
- 协议标准化:MCP 和 A2A 的出现标志着行业正在走向标准化,未来 Agent 生态将更加互联互通
- 框架收敛:LangChain/LangGraph 生态已经非常成熟,但 OpenAI Agents SDK 等原生方案也在快速追赶
- 从 RAG 到 Agentic RAG:RAG 正在从静态 pipeline 演化为由 Agent 动态控制的自适应系统
- Multi-Agent 成为标配:复杂任务越来越多地由多个专业 Agent 协作完成
- 可观测性至关重要:随着 Agent 系统复杂度增加,LangSmith 等可观测性工具将成为刚需
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐

所有评论(0)