LangChain 全家桶入门到精通：LangChain/LangGraph/LangSmith 架构对比 + 智能体记忆与上下文工程实践

m0_48891301

857人浏览 · 2025-09-19 10:15:00

m0_48891301 · 2025-09-19 10:15:00 发布

1、LangChain v.s. LangGraph

作为 LangChain 生态中两款核心开发工具，LangChain 与 LangGraph 均由同一团队打造，旨在解决大语言模型（LLM）集成与协同问题，但二者在工作流设计理念上存在本质区别，常被开发者混淆。从命名即可直观感知其核心差异：

LangChain（链式架构）：采用静态线性工作流，任务执行严格遵循预先定义的步骤顺序，如同流水线作业，每个环节仅接收上一环节的输出，无法根据中间结果调整路径。
LangGraph（图式架构）：基于动态分支工作流，以有向图为核心结构，允许在每个节点根据任务状态（如推理结果、工具反馈）进行决策，灵活选择后续分支，支持循环、并行、回溯等复杂逻辑。

工作流架构对比图

应用场景与协同关系

两者的定位差异决定了适用场景的分野，且并非互斥关系，而是可形成“基础组件+高级编排”的协同模式：

LangChain：聚焦于提供标准化组件（如 LLM 调用接口、工具集成模块）与 LCEL（LangChain Expression Language）链式编程语法，适合简单一次性任务（如单轮问答、文档摘要、固定流程的数据处理），能快速搭建轻量化 LLM 应用。
LangGraph：作为构建有状态智能体（Agent）系统的高级框架，擅长处理多步骤动态任务（如复杂问题拆解、多智能体协作、需要人工介入的审批流程），其核心优势在于对“状态连续性”的支持。

在实际开发中，二者常结合使用：LangGraph 中的每个“节点（Node）”可直接调用 LangChain 定义的链式流程。例如，在智能客服的问题分类节点后，针对“退款咨询”分支，可嵌入 LangChain 构建的“用户订单查询→退款规则匹配→回复生成”固定链条。因此，建议开发者先掌握 LangChain 的组件使用与 LCEL 语法，再学习 LangGraph 的图式编排逻辑——尽管无需完全精通 LangChain 即可上手 LangGraph，但扎实的基础能显著降低复杂智能体的开发难度。

核心特性与执行模式对比

维度	LangChain	LangGraph
工作流结构	线性链条，无分支/循环	有向图，支持分支、循环、并行
状态管理	轻量会话记忆，无全局状态追踪	内置强大状态（State）管理模块
人工介入	不支持中途干预	提供检查点（Checkpoints）支持人工审核
适用规模	轻量化、单流程应用	大规模、复杂智能体系统
核心能力	组件标准化、快速集成	复杂流程编排、多智能体协同

特性对比图
应用场景对比图

2、LangChain：LLM 应用开发的“基础设施”

LangChain 定位为 LLM 应用开发的基础框架，通过封装行业通用的接口与工具，解决“重复造轮子”问题，帮助开发者聚焦业务逻辑，显著提升开发效率。其核心价值在于提供“模块化、可组合”的组件体系，覆盖从 LLM 调用到复杂流程编排的全链路需求。

官方文档：https://python.langchain.com/docs/introduction/

核心功能模块

统一 LLM 调用接口：兼容 OpenAI、Anthropic、Google Gemini 等主流模型，开发者无需修改代码即可切换模型，降低跨平台适配成本。
工具集成生态：内置搜索（Google Search、SerpAPI）、文档处理（PDF/Word 解析、文本分割）、向量数据库（Pinecone、Chroma）等工具接口，支持自定义工具扩展。
链式编程（Chains）：将多个组件（如“提示词模板→LLM→输出解析器”）串联为可复用的流程，简化多步骤任务开发。
记忆（Memory）管理：提供会话记忆（ConversationBufferMemory）、摘要记忆（ConversationSummaryMemory）等多种实现，支持长对话上下文连续性。
提示词模板（Prompt Templates）：支持动态变量注入（如用户问题、历史对话）、格式约束（如 JSON 输出），提升提示词的复用性与稳定性。
输出解析器（Output Parsers）：将 LLM 生成的自然语言转换为结构化数据（如 JSON、Python 字典），便于后续业务系统对接。

LangChain 组件架构图

LCEL 语法实战示例

LangChain 3.0 推出的 LCEL（LangChain Expression Language）是其核心编程范式，通过“|”符号实现组件的链式编排，代码简洁且可扩展性强。以下示例展示如何构建一个“提示词模板→LLM 调用”的基础问答链：

# 导入核心模块
from langchain.chat_models import ChatOpenAI
from langchain.prompts import ChatPromptTemplate
from langchain.schema.output_parser import StrOutputParser

# 初始化 LLM（指定模型版本与温度参数）
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0.7)

# 定义提示词模板（支持动态变量 {question}）
prompt = ChatPromptTemplate.from_messages([
    ("system", "你是一位专业的 AI 助手，擅长用简洁易懂的语言解答问题。"),
    ("user", "请回答：{question}")
])

# LCEL 链式编排（提示词模板 → LLM → 输出解析器）
qa_chain = prompt | llm | StrOutputParser()

# 执行链条并获取结果
result = qa_chain.invoke({"question": "什么是大语言模型（LLM）？其核心技术原理是什么？"})
print(result)

上述代码中，StrOutputParser 用于将 LLM 返回的 AIMessage 对象转换为字符串，避免直接处理复杂的模型输出格式。LCEL 支持更灵活的扩展，例如在链条中插入“工具调用”“记忆读取”等组件，构建更复杂的流程。

3、LangGraph：复杂智能体的“编排引擎”

LangGraph 是基于 LangChain 构建的高级智能体编排框架，专为解决复杂工作流（如多步骤推理、多智能体协作）设计。其核心思想是“用图结构定义智能体的思考与行动流程”，通过节点（Node）表示任务步骤，边（Edge）表示流程分支规则，实现动态、灵活的任务执行逻辑。

官方文档：https://langchain-ai.github.io/langgraph/

三大核心能力

图结构驱动的控制流：支持条件分支（如“根据问题类型选择工具”）、循环（如“多次重试工具调用直到成功”）、并行（如“同时调用搜索与数据库查询”）、回溯（如“推理出错时返回上一步重新决策”）等复杂逻辑，覆盖真实场景中“非线性”任务需求。
全局状态（State）管理：通过自定义 State 类统一管理任务全生命周期的信息（如对话历史、工具调用结果、当前步骤），解决传统 LLM 调用“无状态”的痛点。后续节点可直接读取、修改 State 中的数据，确保上下文连续性。
检查点（Checkpoints）与人工介入：支持在关键节点设置检查点，暂停任务执行并等待人工审核（如“生成敏感内容前需人工确认”），审核通过后继续执行后续流程，平衡智能自动化与风险控制。

LangGraph 图结构示意图

核心概念：State 机制解析

传统 LLM API 调用为“单次请求-单次响应”模式，无法维持多步骤推理的连续性（例如，第二步无法直接使用第一步的工具调用结果）。LangGraph 的 State 机制正是为解决这一问题而生：

定义：State 是一个结构化数据容器（通常基于 TypedDict 或 Pydantic 模型），存储任务执行过程中的所有关键信息。
作用：将复杂任务拆解为多个节点后，每个节点的输入输出均与 State 交互——节点读取 State 中的数据进行处理，处理完成后更新 State，供后续节点使用。
优势：实现“步骤间数据共享”与“动态流程调整”，例如：节点可根据 State 中的“工具调用失败次数”决定是否重试，或根据“问题分类结果”选择不同的推理分支。

State 机制工作流程图

图结构编程实战示例

以下代码展示如何构建一个包含“任务初始化→分支处理→结果汇总”的简单图结构工作流：

# 导入核心模块
from langgraph.graph import StateGraph, END
from typing import TypedDict, List

# 1. 定义全局状态（存储任务全生命周期数据）
class TaskState(TypedDict):
    task_type: str  # 任务类型（如"text_summary"、"data_analysis"）
    input_content: str  # 任务输入内容
    intermediate_results: List[str]  # 中间结果列表
    final_result: str  # 最终结果

# 2. 定义节点函数（每个节点对应一个任务步骤）
def init_task(state: TaskState) -> TaskState:
    """初始化任务：打印任务信息并返回初始状态"""
    print(f"任务初始化：类型={state['task_type']}，输入={state['input_content'][:50]}...")
    return {**state, "intermediate_results": []}

def process_text_summary(state: TaskState) -> TaskState:
    """文本摘要处理节点（仅处理 task_type=text_summary 的任务）"""
    summary = f"【摘要】{state['input_content'][:100]}..."  # 模拟摘要生成
    return {**state, "intermediate_results": [summary]}

def process_data_analysis(state: TaskState) -> TaskState:
    """数据分析处理节点（仅处理 task_type=data_analysis 的任务）"""
    analysis = f"【分析结果】基于输入数据，关键指标为：XXX"  # 模拟数据分析
    return {**state, "intermediate_results": [analysis]}

def summarize_result(state: TaskState) -> TaskState:
    """结果汇总节点：生成最终结果"""
    final = f"任务完成！{''.join(state['intermediate_results'])}"
    return {**state, "final_result": final}

# 3. 构建图结构
graph = StateGraph(TaskState)

# 添加节点
graph.add_node("init", init_task)  # 初始化节点
graph.add_node("text_summary", process_text_summary)  # 文本摘要节点
graph.add_node("data_analysis", process_data_analysis)  # 数据分析节点
graph.add_node("summarize", summarize_result)  # 结果汇总节点

# 定义流程规则
# 3.1 初始化节点 → 分支决策（根据 task_type 选择后续节点）
def decide_branch(state: TaskState) -> str:
    if state["task_type"] == "text_summary":
        return "text_summary"
    elif state["task_type"] == "data_analysis":
        return "data_analysis"
    else:
        raise ValueError(f"不支持的任务类型：{state['task_type']}")

graph.add_conditional_edges(
    source="init",
    condition=decide_branch,  # 分支决策函数
    dests={"text_summary": "text_summary", "data_analysis": "data_analysis"}
)

# 3.2 处理节点 → 结果汇总节点
graph.add_edge("text_summary", "summarize")
graph.add_edge("data_analysis", "summarize")

# 3.3 结果汇总节点 → 流程结束
graph.add_edge("summarize", END)

# 4. 编译并运行图
app = graph.compile()

# 测试文本摘要任务
text_task_input = {
    "task_type": "text_summary",
    "input_content": "LangGraph 是 LangChain 生态中的高级智能体编排框架，基于图结构实现复杂工作流管理...",
    "intermediate_results": [],
    "final_result": ""
}
text_result = app.invoke(text_task_input)
print("文本摘要任务结果：", text_result["final_result"])

# 测试数据分析任务
data_task_input = {
    "task_type": "data_analysis",
    "input_content": "某产品 2024 年 Q1 销售额为 1000 万元，同比增长 20%，用户留存率 85%...",
    "intermediate_results": [],
    "final_result": ""
}
data_result = app.invoke(data_task_input)
print("数据分析任务结果：", data_result["final_result"])

执行模式对比图

4、LangSmith：LLM 应用的“全生命周期管理平台”

LangSmith 是 LangChain 生态配套的可视化开发与运维平台，专注于解决 LLM 应用“开发难调试、上线难监控、迭代难评估”的痛点，覆盖从原型开发到生产运维的全生命周期。

官方地址：https://www.langchain.com/langsmith

五大核心功能

智能调试（Debugging）：实时追踪 LLM 交互链路，高亮异常节点（如工具调用超时、JSON 解析失败、Token 超限制），并关联具体代码位置（如提示词模板第 15 行格式错误），帮助开发者快速定位问题根源。
全链路追踪（Tracing）：记录跨组件的完整调用链，包括 LangGraph 节点执行顺序、工具调用参数与返回值、数据库查询语句、API 请求详情等，形成可回溯的“任务执行日志”。
生产监控（Monitoring）：提供生产环境实时指标看板，涵盖请求量、平均响应延迟、错误率、Token 消耗分布（输入/输出占比）、工具调用成功率等核心指标，并支持自定义告警规则（如错误率超过 5% 时触发邮件通知）。
自动化测试与评估（Test & Evaluation）：支持创建测试数据集（输入问题+预期输出），对不同版本的提示词、LLM 模型（如 GPT-3.5 vs GPT-4）进行 A/B 测试，自动生成质量评分（如相关性、准确性、格式合规性），量化评估应用性能。
提示词优化（Prompt & Optimisation）：追踪每次提示词修改对输出结果的影响，记录“提示词版本-测试分数-生产指标”的关联数据，帮助开发者通过数据驱动优化提示词，而非依赖经验试错。

LangSmith 功能界面图

生态协同价值

LangSmith 与 LangChain、LangGraph 深度集成，无需复杂配置即可接入：

开发阶段：通过 LangSmith 追踪 LangChain 链条的执行过程，快速调试提示词与工具调用逻辑。
编排阶段：可视化 LangGraph 图结构的执行路径，直观查看节点间的状态流转与分支决策逻辑。
运维阶段：监控基于 LangChain/LangGraph 构建的智能体在生产环境的运行状态，及时发现并解决问题（如某工具调用成功率骤降）。

5、Agent-chat UI：智能体的“快速可视化工具”

Agent-chat UI 是 LangChain 生态中的轻量级 Web 界面工具，旨在帮助开发者快速搭建 AI 智能体的交互原型，无需手动开发前端界面即可实现智能体的可视化调试与演示。

项目地址：https://github.com/langchain-ai/agent-chat-ui

其核心优势在于“开箱即用”：

支持直接接入 LangChain/LangGraph 构建的智能体，自动渲染工具调用过程（如“正在调用搜索工具”“正在查询数据库”）。
提供对话历史记录、中间结果展示、日志查看等功能，方便开发者在调试时观察智能体的决策过程。
支持自定义界面主题、交互流程，可用于内部演示或初期用户测试，降低智能体产品化的前期成本。

6、RAG：破解 LLM 核心痛点的“知识增强方案”

RAG（Retrieval Augmented Generation，检索增强生成）是一种结合“外部知识检索”与“LLM 生成”的技术范式，核心目标是解决 LLM 固有的三大痛点：知识过时、生成幻觉、私域知识缺失。它已成为智能体与 LLM 交互的核心组件，通过“外挂知识”的方式，在不修改 LLM 模型参数的前提下，显著提升输出的准确性与实用性。

LLM 三大核心痛点解析

知识过时问题：LLM 的训练数据存在“时间截止线”（如 GPT-4 训练数据截止到 2023 年 10 月），无法获取实时信息（如 2024 年最新政策、股票行情），且模型版本迭代滞后于知识更新速度。
生成幻觉问题：当 LLM 面对知识盲区时，会基于训练数据中的局部信息进行“联想补全”，生成看似合理但与事实不符的内容（如虚构学术论文、错误的历史事件时间线），且往往无法识别自身的知识局限。
私域知识缺失问题：LLM 训练数据以公域信息为主，无法涵盖企业内部文档（如产品手册、客户资料、内部流程）、个人数据（如日程安排、笔记）等私域内容，导致在垂直场景中实用性受限。

RAG 解决痛点示意图

RAG 核心原理与价值

RAG 的本质是“动态知识注入机制”，通过构建外部知识库（通常为向量数据库），在 LLM 生成回答前，先检索与用户问题相关的知识片段，将其作为“上下文”注入提示词，最终让 LLM 基于“自身知识+外部检索知识”生成回答。其核心价值体现在：

解决知识过时：外部知识库可实时更新（如每日同步新闻、政策文件），用户提问时自动检索最新信息，确保回答的时效性。
缓解生成幻觉：检索到的知识片段为 LLM 提供“事实依据”，降低其“凭空捏造”的概率（尽管无法完全杜绝，需结合其他策略如事实校验）。
覆盖私域知识：将企业/个人私域数据（如 PDF 文档、Excel 表格）处理后存入知识库，让 LLM 能够“理解”并运用这些专属信息。

RAG 核心流程

RAG 通常分为三个阶段：检索（Retrieval）、增强（Augmentation）、生成（Generation），形成闭环流程：

检索阶段：
- 对用户输入的问题进行预处理（如分词、embedding 转换），生成向量表示。
- 基于向量相似度在知识库中检索Top-K 相关的知识片段（如文档段落、表格数据）。
- 对检索结果进行过滤（如去除低相似度片段）与排序，确保相关性。
增强阶段：
- 将检索到的知识片段与用户问题、对话历史等信息整合，构建“增强版提示词”（如“基于以下信息回答问题：[知识片段1][知识片段2]… 用户问题：XXX”）。
- 对提示词进行格式优化（如控制长度以适配 LLM 上下文窗口），确保 LLM 能有效利用检索到的知识。
生成阶段：
- 将增强后的提示词输入 LLM，生成最终回答。
- （可选）对 LLM 输出进行后处理，如引用标注（“答案来源：文档A第3章”）、格式美化等。

RAG 核心流程图

7、MCP：突破 LLM 上下文局限的“标准化协议”

MCP（Model Context Protocol，模型上下文协议）由 Anthropic 于 2024 年 11 月推出，旨在解决 LLM 应用中“上下文管理”的四大核心痛点，通过标准化的上下文传输与交互机制，提升智能体与外部工具、多模型协同的效率与灵活性。

LLM 上下文管理的四大痛点

长上下文传输瓶颈：传统采用 JSON 格式传输长上下文（如 10K Token）时，数据体积大、序列化耗时久，单次传输延迟常超过 500ms；而 MCP 通过高效压缩与结构化协议，可将延迟降至 20ms 以内。
动态更新低效：当上下文局部更新（如新增一轮对话、补充一条工具结果）时，传统方式需重传全量上下文，浪费带宽与时间；MCP 支持“增量更新”，仅传输变化部分。
多模型协同障碍：不同 LLM（如 GPT-4、Claude 3）的上下文格式、工具调用协议不统一，导致模型间数据流转需额外进行序列化/反序列化转换；MCP 提供标准化的上下文容器字段，实现模型间“无缝对接”。
扩展性与标准化缺失：智能体与 RAG、工具的交互逻辑缺乏统一标准，不同团队开发的组件难以复用，导致系统迭代成本高、稳定性差；MCP 从软件工程层面定义了交互规范，为 LLM 应用提供“可扩展的基础协议”。

MCP 核心优势与价值

MCP 最显著的特点是“解耦 LLM 与外部资源的交互逻辑”，让智能体无需为每个工具/模型单独开发适配代码，其核心价值包括：

标准化交互：统一智能体与工具、模型、数据源的交互协议，新工具/服务接入时只需实现 MCP 接口，无需修改智能体核心代码，显著提升扩展性。
降低开发复杂性：抽象化底层交互细节（如数据序列化、网络传输），开发者可聚焦智能体的核心逻辑（如决策、推理），减少重复开发工作。
促进集体智能：支持分布式智能体通过标准化协议共享信息、协同完成任务（如 A 智能体调用工具的结果可直接通过 MCP 传递给 B 智能体），突破单一智能体的能力边界。

MCP 架构组成

MCP 采用“客户端-服务器（C/S）”架构，核心组件包括：

组件	功能描述
MCP Host	LLM 应用的运行载体，如 ChatBot、AI IDE、智能体系统，负责协调 Client 与业务逻辑。
MCP Client	运行在 Host 内部，与 MCP Server 一一对应，负责向 Server 发起请求并处理响应。
MCP Server	作为“中间件”，左侧接收 Client 请求，右侧将请求转换为目标服务（Real Service）能理解的格式并转发。
Local Resources	运行在 Host 本地的工具或数据，如本地文件、终端命令、离线数据库。
Remote Resources	云端或在线可访问的服务，如 API 接口、远程数据库、搜索引擎、第三方工具。

MCP 的传输层基于 JSON-RPC 协议，支持多种消息传递方式：

Stdio（标准输入输出）：适用于本地工具交互（如调用终端命令）。
HTTP over SSE：支持服务器推送事件流（如实时获取工具执行进度、日志）。
自定义扩展：允许开发者根据需求实现其他传输方式（如 WebSocket）。

MCP 架构图
MCP 传输协议图

MCP 运行流程与应用示例

典型运行流程

MCP Host 启动时，加载并初始化所需的 MCP Client。
用户发起任务（如“总结代码库最近 5 次提交”），Host 调用 Client 向对应的 MCP Server 发送“工具列表查询”请求。
MCP Server 返回支持的工具列表（如“git-log 工具：获取提交记录”）。
Host 将工具列表输入 LLM，LLM 根据任务需求选择合适的工具（如 git-log）。
Client 向 MCP Server 发送工具调用请求（含参数，如“–since=7days”）。
MCP Server 将请求转换为 git 命令并执行，获取提交记录后返回给 Client。
Host 将工具返回结果输入 LLM，LLM 生成最终总结并反馈给用户。

MCP 运行流程图

应用示例：代码提交记录总结

工具列表查询：MCP Client 向“代码管理 MCP Server”查询可用工具，Server 返回：

{
  "tools": [
    {"name": "git-log", "description": "获取代码仓库提交记录", "parameters": {"since": "时间范围", "limit": "记录条数"}}
  ]
}

工具列表查询结果

工具调用与结果返回：LLM 选择 git-log 工具，Client 发送请求（since=7days，limit=5），Server 执行 git 命令并返回提交记录：

{
  "result": [
    {"commit_id": "a1b2c3", "author": "张三", "time": "2024-10-01", "message": "修复登录bug"},
    {"commit_id": "d4e5f6", "author": "李四", "time": "2024-09-30", "message": "新增支付模块"}
  ]
}

工具调用结果

生成最终结果：Host 将提交记录输入 LLM，生成总结：
“近7天代码库共5次提交，主要包括：1. 修复登录功能bug（张三，10月1日）；2. 新增支付模块（李四，9月30日）；3. …”

8、A2A：AI 智能体协同的“标准化通信协议”

A2A（Agent2Agent Protocol，智能体间通信协议）由 Google 于 2025 年 4 月提出，是专为解决“多智能体协同”问题设计的标准化协议。它允许不同团队、不同技术栈开发的 AI 智能体之间进行高效通信、任务委托与结果共享，支持异步工作流与多模态交互，填补了智能体生态中“协同标准缺失”的空白。

A2A 与 MCP 的定位差异

MCP：聚焦于“智能体与外部工具/数据源的交互”，解决智能体“操作世界”的能力标准化问题。
A2A：聚焦于“智能体与智能体之间的交互”，解决智能体“协作彼此”的能力标准化问题。

两者相辅相成，共同构成智能体“对外操作+对内协作”的完整标准化体系。

A2A 与 MCP 定位对比图

A2A 核心架构与概念

A2A 基于 HTTP/S JSON-RPC 2.0 协议构建，兼容 Web 原生安全标准，核心架构包含以下组件与概念：

组件/概念	功能描述
A2A Client	作为“请求方”的智能体，通过读取其他智能体的 Agent Card 发现其能力，发送任务委托请求。
A2A Server	作为“服务方”的智能体，通过 HTTP Endpoint 提供服务，接收并处理 Client 的任务请求。
Agent Card	智能体的“名片”（JSON 格式），包含名称、版本、能力描述、访问地址、支持的消息类型、认证方式等信息，用于智能体间能力发现。
Task	任务对象，包含唯一 ID、状态机（submitted/working/input-required/completed/failed/canceled）、任务内容等，是智能体间协作的核心载体。
Message	通信消息体，由多个 Part 组成，支持多模态内容（文本、文件、结构化数据），包含发送方角色（user/agent）、时间戳等元信息。
Part	消息的“片段”，分为 TextPart（文本）、FilePart（文件链接/二进制数据）、DataPart（结构化 JSON），支持复杂信息交换。
Push Notifications	服务方智能体通过 Webhook 向请求方推送任务状态更新（如“任务进入 working 状态”），无需请求方轮询。
Artifact	任务执行过程中产生的持久化中间产物（如生成的报告、处理后的文件），支持请求方实时获取。
Streaming	流式传输能力，服务方通过 SSE 向请求方实时推送任务进度（如“推理完成 30%”），适用于长耗时任务。

A2A 架构图

A2A 典型工作流程

A2A 主要应用于多智能体协同场景（如“客服智能体+订单智能体+物流智能体”协作处理用户退货请求），其典型工作流程如下：

能力发现：Client 智能体通过 Server 智能体的“知名 URL”（如 https://agent.example.com/.well-known/agent.json）获取 Agent Card，了解其支持的任务类型与接口。
任务委托：Client 向 Server 的 Endpoint（如 https://agent.example.com/a2a/tasks/send）发送 Task 请求，包含任务 ID、内容、预期输出格式等信息。
任务处理：
- 非流式处理：Server 同步处理任务，处理完成后在 HTTP 响应中返回最终 Task 对象（状态为 completed/failed）。
- 流式处理：Server 启动任务后，通过 SSE 向 Client 推送 TaskStatusUpdateEvent（状态更新）或 TaskArtifactUpdateEvent（中间产物更新）。
交互补全（可选）：若 Task 进入 input-required 状态（如 Server 需要更多用户信息），Client 可通过相同 Task ID 发送补充消息，继续推进任务。
任务终止：Task 最终进入终止状态（completed/failed/canceled），Server 推送最终结果，Client 接收并处理（如整合到自身业务流程）。

9、分层记忆系统：AI 智能体的“认知基石”

当前 AI 智能体的记忆系统尚未形成统一标准框架，但其核心设计理念已逐渐趋同——通过“分层存储+多策略检索”模拟人类记忆的短期、中期、长期特性，实现对信息的高效管理与利用。以下架构综合了 MemoryOS、Mem0、LangChain Memory 等主流系统的设计思路，以及相关学术研究的理论成果，具有较强的通用性。

核心架构与功能模块

分层记忆系统通过三层结构实现“信息的分级存储与按需检索”，配合智能更新机制，确保记忆的准确性与可用性：

短期记忆（Short-term Memory）：
- 存储内容：会话缓存（最近几轮对话）、临时任务状态（如当前执行步骤、未完成的工具调用）、即时上下文信息。
- 核心特点：访问速度快、存储周期短（任务结束或会话超时后清除）、容量有限（通常适配 LLM 上下文窗口大小）。
- 作用：确保当前任务步骤的上下文连续性，支持短时间内的快速信息复用（如“用户上一句提到的订单号”）。
中期记忆（Mid-term Memory）：
- 存储内容：近期任务记录（过去几天/几周的任务结果）、用户偏好（如“用户习惯简洁回答”）、常用工具调用历史、语义化的中间结果（如“某类问题的典型解决步骤”）。
- 核心特点：采用向量索引+时序索引存储，支持语义检索与时间范围筛选，存储周期中等（可配置过期时间）。
- 作用：支持跨会话的信息关联（如“用户上次咨询的产品与本次相关”），提供近期经验复用能力。
长期记忆（Long-term Memory）：
- 存储内容：知识图谱（实体关系，如“产品A属于品类B”）、结构化规则（如“VIP用户退货免运费”）、长期用户画像（如“用户行业为教育，关注AI教学工具”）、历史任务总结（如“年度业务报表中的关键结论”）。
- 核心特点：采用知识图谱+关系数据库存储，支持复杂推理与多维度查询，持久化存储（无过期时间，需手动更新）。
- 作用：构建智能体的“长期认知”，支持复杂问题的推理（如“基于历史数据预测用户需求”），形成稳定的决策依据。
多策略检索引擎：
- 整合语义检索（基于向量相似度）、关键词匹配（精确查找，如订单号）、图关系查询（知识图谱遍历，如“查找与产品A相关的所有用户反馈”）三种检索策略，根据当前任务需求自动选择最优方式，从三层记忆中提取相关信息。
智能记忆更新机制：
- 增量更新：仅更新变化的信息（如“新增一条用户偏好”），避免全量覆盖导致的数据丢失。
- 智能摘要：对长期记忆中的冗余信息进行自动摘要（如“将10次相似任务记录总结为一条通用规则”），减少存储压力。
- 去重合并：识别并合并重复信息（如“用户两次提到的相同偏好”），确保记忆的一致性。
- 分层存储调度：根据信息的访问频率与重要性，自动将短期记忆中的高频信息迁移至中期记忆，中期记忆中的核心知识迁移至长期记忆。

分层记忆系统架构图

应用价值

分层记忆系统让智能体摆脱“一次性记忆”的局限，具备类似人类的“经验积累”能力：

短期记忆确保当前任务的流畅执行，避免频繁重复输入。
中期记忆支持跨会话的个性化服务（如“记住用户上次未完成的操作”）。
长期记忆帮助智能体形成领域认知，提升复杂问题的解决能力（如“基于历史数据优化推荐策略”）。

10、Context Engineering：从“静态提示”到“动态上下文”的进化

Context Engineering（上下文工程）是 Prompt Engineering（提示工程）与 In-context Learning（上下文学习）的进阶范式。它针对智能体场景中“任务动态变化、上下文复杂”的特点，提出“动态构建最优上下文窗口”的解决方案，突破了传统静态提示的局限性。

从 PE/ICL 到 Context Engineering 的演进

1. 传统技术的核心特点与局限

Prompt Engineering（PE，提示工程）：
- 核心：通过设计结构化、精准的提示词（如包含指令、示例、格式约束），引导 LLM 生成符合预期的输出。
- 局限：提示词为“静态固定”，无法适应任务过程中的环境变化（如用户需求变更、工具反馈异常），在多步骤任务中需编写大量冗余提示。
In-context Learning（ICL，上下文学习）：
- 核心：在提示词中注入少量任务示例（Few-shot）或仅提供指令（Zero-shot），让 LLM 无需微调即可学习任务模式。
- 分类：
  - 零样本学习（Zero-shot）：仅靠指令与 LLM 预训练知识推理，适用于简单通用任务。
  - 少样本学习（Few-shot）：提供 2~5 个示例引导 LLM 模仿，适用于特定领域任务（如法律文书生成）。
- 局限：依赖“静态上下文注入”，无法处理长对话/长任务中的上下文膨胀问题（如历史信息超过 LLM 上下文窗口），且示例与当前任务的关联性难以动态调整。

2. Context Engineering 的核心突破

PE 与 ICL 本质上是“静态一次性”的上下文构建方式，在 Chat 等简单场景中表现良好，但在追求自主决策的智能体场景中存在明显不足：

复杂度高：智能体任务常涉及数十上百个步骤（如“市场分析→方案生成→风险评估→报告撰写”），静态提示需覆盖所有可能场景，开发维护成本极高。
适用性差：任务过程中目标与环境会动态变化（如“用户突然补充新需求”“工具调用失败需更换策略”），静态提示无法实时适配。
持续性差：长期运行的智能体（如 24 小时在线客服）会产生海量历史信息，无法全部放入有限的 LLM 上下文窗口。

Context Engineering 的核心突破在于**“动态上下文构建”**：根据当前任务状态（如用户输入、工具反馈、记忆信息），实时筛选、整合、优化最相关的上下文内容，为 LLM 提供“恰到好处”的背景信息，而非固定不变的提示词。

Context Engineering 演进示意图

实现 Context Engineering 的三大核心技术

动态上下文的构建依赖于“外部信息注入”与“内部记忆调度”的协同，核心技术包括：

RAG（检索增强生成）：
- 作用：从外部知识库中实时检索与当前任务相关的信息（如最新政策、产品手册、用户资料），动态注入上下文，解决 LLM 知识过时、私域知识缺失问题。
- 示例：智能客服处理用户退货咨询时，通过 RAG 检索该用户的订单信息（购买时间、商品状态）与企业退货政策，生成包含具体数据的上下文。
工具调用（Tool Calling / Function Calling）：
- 作用：将工具调用的“输入参数”与“返回结果”动态整合进上下文，让 LLM 能够基于实时工具反馈调整决策（如“调用天气 API 后，根据降雨信息推荐用户携带雨伞”）。
- 示例：智能助手帮用户规划出行路线时，先调用地图工具获取实时路况，将“拥堵路段”信息注入上下文，再让 LLM 生成避开拥堵的路线建议。
智能体记忆系统（Agent Memory）：
- 作用：从分层记忆系统中动态检索最相关的历史信息（如用户偏好、过去任务经验），确保上下文的连续性与个性化。
- 示例：用户再次咨询“产品推荐”时，智能体从中期记忆中检索“用户上次偏好性价比高的产品”，从长期记忆中获取“用户行业为教育”，整合为个性化上下文。

上下文工程的三层信息维度

动态上下文需覆盖“即时-历史-外部”三层信息，形成完整的决策背景，示例如下（智能客服处理退货场景）：

即时信息：当前用户输入（“我想退这个商品”）、当前任务步骤（“等待用户提供订单号”）、最新工具反馈（“已查询到用户订单号：123456”）。
历史信息：用户历史交互记录（“3 天前购买该商品，未拆封”）、用户偏好（“用户曾多次选择上门取件退货”）、过去类似任务经验（“该商品支持 7 天无理由退货”）。
外部信息：企业退货政策（“VIP 用户退货免运费”）、商品库存状态（“该商品库存充足，支持全额退款”）、物流信息（“今日上门取件时间截止到 18:00”）。

这些信息并非静态存储，而是通过 RAG、工具调用、记忆系统实时获取并动态组合，形成“千人千面”的上下文窗口。例如，上述场景中，智能体最终生成的上下文可能为：
“用户（VIP）3 天前购买商品（订单号123456，未拆封），当前请求退货。根据政策，VIP 用户可享受免运费上门取件（今日截止18:00），该商品支持7天无理由全额退款。用户历史偏好上门取件，请优先推荐该方式。”

上下文工程三层信息示意图

Context Engineering 的终极目标：自适应性与自我改进

上下文工程的长期目标不仅是“构建动态数据上下文”，更在于实现“指令上下文的动态优化”，推动智能体向自适应性（Self-adaptive） 与自我改进（Self-improvement） 演进：

动态 Prompt 优化：
- 内容调整：基于任务进展自动优化提示词内容，如发现 LLM 输出冗长时，自动在后续上下文加入“请用3句话以内简洁回答”；若输出格式错误，自动补充“请严格按照 JSON 格式输出”。
- 策略切换：根据中间结果成败动态调整推理策略，如复杂数学推理任务中，若“思维链（CoT）”策略失败，自动切换为“树状思维（ToT）”策略，并在上下文注入新策略的示例。
自我改进机制：
- Prompt 自动迭代：通过 PromptWizard 等框架，让 LLM 基于自身输出结果进行“自我批评”（如“回答未覆盖用户提到的订单时间”），生成改进建议并迭代优化提示词，形成“生成-评估-优化”闭环。
- 进化算法优化：采用 Promptbreeder 等技术，通过进化算法让提示词在“代际更替”中不断优化（如对有效提示词进行“变异”“交叉”，生成更优版本），在数学推理、代码生成等任务中显著超越静态提示。
- 记忆驱动的策略沉淀：分析长期记忆中的“成功/失败案例”（如“采用 ToT 策略成功解决了10个复杂问题”），自动总结出高效的提示模板与行动策略，形成智能体的“经验库”。

Context Engineering 自我改进示意图

11、知识图谱：提升智能体推理能力的“结构化知识核心”

尽管长上下文窗口、向量数据库、RAG 等技术能提供高效的语义检索能力，在通用场景中表现出色，但在实体关系密集的复杂推理场景（如法律合同分析、金融风控、医疗诊断）中，仍存在明显不足：检索结果缺乏结构化关联，导致推理精准性、可解释性与覆盖度不足。知识图谱通过建模实体及其关系，为智能体提供“类人类认知”的结构化知识，成为解决这类问题的关键技术。

知识图谱的核心价值：弥补传统技术的推理短板

在需要深度理解实体关系的场景中（如“分析合同中甲方、乙方、担保方的权利义务关系”），传统 RAG 技术的局限性凸显：

精准性不足：RAG 基于语义相似度检索，可能返回与实体相关但关系无关的内容（如“提到甲方的其他合同条款”而非“甲方与乙方的付款关系”）。
可解释性差：无法清晰展示推理路径（如“为什么判定甲方需先付款？”），输出结果难以追溯依据。
覆盖度有限：难以处理多实体、多关系的复杂网络（如“甲方→供应商→丙方→乙方”的间接关系）。

知识图谱通过以下特性弥补这些短板，为智能体提供更强的推理能力：

明确的实体与关系建模：清晰定义“谁（实体）在什么条件下（属性）做了什么（关系）”，如“（甲方，付款义务，乙方），（付款金额，100万元），（付款时间，2024-12-31）”。
动态可扩展的关系网络：支持随新信息快速更新关系（如“新增担保方，与甲方形成连带责任关系”），无需重构整个知识体系。
透明的推理路径：推理过程可追溯（如“甲方需先付款→依据条款5.1→条款5.1约定‘甲方在收到货物后30天内付款’→已确认乙方已发货”），提升结果可信度。
全面的关系覆盖：支持直接关系（甲方→乙方）与间接关系（甲方→供应商→丙方）的深度挖掘，覆盖复杂业务场景。

知识图谱推理示意图

知识图谱与 RAG 的融合：构建更强大的记忆系统

传统 RAG 系统常被比作“文档馆”，而知识图谱则是“结构化知识库”，两者融合可形成“既保留细节又具备推理能力”的新一代智能体记忆系统。以下以 Zep（一款支持时间特性的知识图谱软件）为例，解析其融合思路：

传统 RAG 的三大痛点

静态知识局限：假设知识固定不变，无法处理动态业务场景（如“用户偏好从‘性价比’变为‘高端化’”）。
信息冲突无法解决：当新信息与旧信息矛盾时（如“旧政策支持全额退款，新政策改为部分退款”），RAG 会同时返回两类信息，无法判断优先级。
缺乏时间维度理解：无法区分信息的时间属性（如“用户2023年偏好A产品，2024年偏好B产品”），导致推荐偏离实际需求。

Zep 的三层知识图谱架构（Graphiti 技术）

Zep 采用“Episode-Semantic Entity-Community”三层架构，结合 RAG 与知识图谱的优势，解决传统 RAG 痛点：

Episode 子图：
- 功能：完整存储原始数据（如对话记录、文档全文、JSON 数据），不丢失任何细节，相当于“RAG 的文档库”。
- 价值：保留数据原始性，支持后续追溯与重新解析。
Semantic Entity 子图：
- 功能：从原始数据中提取实体（如用户、产品、订单）、关系（如“购买”“退款”）与属性（如“购买时间”“金额”），并通过实体解析技术（如实体消歧、链接）整合新旧信息（如“将‘张三’‘张先生’合并为同一实体”）。
- 价值：实现知识的结构化建模，解决信息冲突（如“根据时间戳优先选择2024年的新政策”）。
Community 子图：
- 功能：通过标签传播算法对相关实体进行聚类（如“将‘A产品’‘B产品’归为‘高端系列’聚类”），形成高层次的概念理解（如“用户偏好高端系列产品”）。
- 价值：实现知识的抽象与归纳，支持更宏观的推理（如“基于用户所属‘高端客户’聚类，推荐专属服务”）。

这种架构让系统既能通过 Episode 子图保留原始细节（如合同全文），又能通过 Semantic Entity 子图建模实体关系（如合同中的权利义务），还能通过 Community 子图形成高层认知（如“某类合同的共性风险点”），完美融合了 RAG 的“细节保留”与知识图谱的“推理能力”。

Zep 三层知识图谱架构图

典型应用场景

法律合同审查：知识图谱建模合同中的“甲方/乙方/丙方”“权利/义务/违约责任”“时间/金额/标的”等实体与关系，智能体可快速定位“付款义务与违约条款的关联”“担保方的责任范围”，并生成带推理路径的审查报告。
金融风控：构建“用户-账户-交易-商户”知识图谱，智能体可识别“陌生账户多次向同一用户转账”“用户频繁在高风险商户消费”等异常模式，辅助风控决策。
医疗诊断：建模“患者-症状-疾病-药物”关系网络，智能体可基于患者症状（如“咳嗽+发烧+乏力”）与病史，推理可能的疾病（如“流感”），并解释“为什么排除肺炎（无胸闷症状）”。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】