LangChain编程框架

一 LangChain

1 LangChain定义

​ 是 2022年10月 ，由哈佛大学的 Harrison Chase （哈里森·蔡斯）发起研发的一个开源框架。 LangChain中的“Lang”是指language，即⼤语⾔模型，“Chain”即“链”，也就是将⼤模型与外部数据&各种组件连接成链，目标是把 LLM 与外部工具、数据源和复杂工作流连接起来。它不仅仅是对LLM API的封装，而是提供了一套完整的工具和架构，让开发者能够更轻松地构建上下文感知和推理能力的AI应用。

2 LangChain生态

2.1 模型层（Model I/O）

统一模型抽象层，为所有模型提供标准化调用，覆盖文本、多模态、Embedding、Rerank 等多类型模型，实现跨供应商一致体验。

  1. 输⼊(Format)：输入提示，Prompt Template
  2. 大模型（Model）：各类型大模型
  3. 模型处理(Predict)：模型调用，invoke()
  4. 输出(Parse)：输出解析(器)，Output Parser
2.2 工具层（Tools）

工具系统提供统一 Tool 抽象，支持所有主流模型的 Tool Calling，深度集成 LangGraph，构建可执行 agent 环境的关键能力层。

  • 内置工具：搜索、计算、代码执行等100+工具
  • 自定义工具：@tool装饰器 / BaseTool / ToolNode
  • 工具包：Toolkit（如GitHub、Slack集成）
2.3 记忆层（Memory）

记忆层提供统一 State 管理、对话记录、长期检索、多模态 Memory 等能力，支持持久化与复杂工作流状态流转。

  • 短期记忆：消息历史自动管理
  • 长期记忆：向量数据库存储（Chroma, Pinecone）
  • 存储接口：Store（跨会话持久化）
2.4 Agent层（Agents）

Agents系统实现从碎片化到标准化升级，以create_agent为核心接口，基于LangGraph构建统一Agent抽象，10行代码即可创建基础Agent，封装"模型调用→工具选择→执行→结束"闭环流程

  • 核心API：create_agent()
  • 执行引擎：LangGraph Runtime（自动持久化）
  • 中间件：Middleware（HITL、压缩、路由）
2.5 工作流层（Workflows）

Workflows 体系实现从 线性链式（Chain）到图结构（Graph） 的范式转移，以 StateGraph 为核心画布，将业务逻辑解耦为 “节点（Node）+ 边（Edge）+ 状态（State）”，原生支持循环（Loop）与条件分支，完美适配复杂任务编排、容错重试及长会话保持。

  • 简单链：Chain（快速串联）
  • 复杂图：LangGraph（条件分支、循环）
  • 模板库：LangChain Hub（共享Agent模板）
2.6 检索（Retrieval）

对应着RAG，检索外部数据，然后在执行生成步骤时将其传递到 LLM。步骤包括文档加载、 切割、Embedding等

  1. **Source：数据源，即大模型可以识别的多种类型的数据：视频、图片、文本、代码、文档等。 **
  2. Load ：负责将来自不同数据源的非结构化数据，加载为文档(Document)对象。
  3. Splitters：文本分割‌，将加载的文档按一定规则拆分成适合处理的小块，以便后续嵌入和检索。
  4. **Embed ：将文本编码为向量的能力。一种用于嵌入文档，另一种用于嵌入查询（在向量空间中进行语义相似度匹配） **
  5. Store ：将生成的向量存入向量数据库（如 Chroma、Pinecone、FAISS 等），并建立索引以提高检索效率。
  6. Store：存储与索引‌，将生成的向量存入向量数据库（如 Chroma、Pinecone、FAISS 等），并建立索引以提高检索效率。
  7. ‌Retrieve：检索，根据用户输入的查询，通过向量相似度或关键词匹配等方式，从索引中召回相关文档。
2.7 调试监控层（Debugging）

LangChain 1.0 调试监控层实现了从 日志黑盒到全链路可观测性（Observability） 的质变，深度集成 LangSmith 平台，自动捕获链（Chain）与图（Graph）的每一步骤状态、Token 消耗及延迟，支持"Trace → Playground"一键回放调试，彻底解决复杂 Agent 逻辑难以排查的痛点。

  • 本地日志：verbose=True
  • 云端平台：LangSmith（可视化链路追踪）
  • 评估工具：LangChain Evaluate（效果评估）
2.8 其他关键组件 (LangGraph & LangServe)
  • langgraph: 这是一个底层的Agent 调度框架 (Agent Runtime)，是一个相对“低级”（Low-level）的编排框架，它专注于解决复杂的“控制流”问题，用于构建健壮且有状态的多角色 LLM 应用程序。LangChain 1.0 中的新 Agents (通过 create_agent()) 就是建立在 LangGraph 之上的。
  • langserve: 用于将任何 LangChain chain 或 agent 部署为 REST API 的包，方便快速将应用投入生产环境。

3 LangChain 1.0 核心依赖包

3.1 langchain-core

包含 核心抽象与接口：LLM/ChatModel 抽象、Prompt 抽象、Chain/Agent 的基类、schema、消息格式等。

3.2 langchain 主包

对外的主入口包

模块 核心内容 来源说明
langchain.agents create_agent, AgentState 智能体创建核心
langchain.messages AIMessage, HumanMessage, trim_messages 从langchain-core重新导出
langchain.tools @tool, BaseTool 从langchain-core重新导出
langchain.chat_models init_chat_model, BaseChatModel 统一模型初始化
langchain.embeddings init_embeddings 嵌入模型管理
3.3 langchain-community 第三方集成库

  langchain-community 作为 LangChain 1.0 的“功能扩展层”，通过社区贡献的非官方集成组件显著扩展了主包的功能边界，其核心价值体现在工具类组件与平台集成两大维度。

​ 工具类组件覆盖文档处理全流程，包括 DirectoryLoader 文档加载器（支持 PDF、文本等多格式文件批量导入）、RecursiveCharacterTextSplitter 文本分割器（按语义边界将文档切分为检索友好的 Chunk）、PGVector 向量存储（PostgreSQL 生态的向量数据库适配）及 HuggingFaceEmbeddings 嵌入模型（本地部署模型的向量化能力），这些组件共同构成了 RAG 应用的技术基础。

​ 平台集成方面，支持与 DeepSeek、阿里云通义千问等模型的对接，例如通过 langchain_community.chat_models.ChatTongyi 类初始化通义千问模型，或利用 Ollama 类调用本地部署的 DeepSeek-R1 模型。

​ 收集并维护 社区/第三方贡献的集成（例如某些云厂商、开源向量库、特殊工具适配器等）。这些集成实现了langchain-core定义的接口，但不属于主包维护范畴。官方会把这些放到 langchain-community仓库/包，便于社区共同维护。

  包含内容：

  • 数据库：MySQL, PostgreSQL, MongoDB, Neo4j等连接器
  • 存储服务：AWS S3, 阿里云OSS, Google Cloud Storage
  • 工具集成：Slack, Notion, GitHub, ArXiv, YouTube等API
  • 向量数据库：Chroma, Pinecone, Qdrant, Milvus等
  • 文档加载器：PDF, CSV, HTML, Markdown解析器
3.4 langchain-openai（厂商/提供者集成包）

​ 厂商特定集成包（如 langchain-openai、langchain-anthropic、langchain-google 等）通过封装 API 细节，为开发者提供“零适配成本”的模型对接方案，其核心价值在于简化特定 API 对接流程，使开发者能够直接使用厂商特有功能。以 langchain-openai 为例，其关键组件包括模型客户端、工具调用适配和多模型支持三大模块。

​ 此外，该类还支持通过配置 openai_api_base 和 openai_api_key 参数对接兼容 OpenAI API 格式的第三方模型，如 DeepSeek 模型

  • 专门负责把 OpenAI 的 SDK 与 LangChain 抽象连接起来：提供 ChatOpenAI、OpenAIEmbeddings、OpenAI等类的实现。
  • 这类包通常是 “按厂商拆分”：langchain-openai、langchain-azure、langchain-anthropic、langchain-deepseek等。
  • 官方深度集成特定LLM提供商，更新频繁，功能最全.

  主流厂商包列表：

  • langchain-openai：OpenAI, Azure OpenAI

  • langchain-anthropic：Claude系列

  • langchain-google：Gemini, Vertex AI

  • langchain-deepseek：DeepSeek模型

  • langchain-ollama：本地Ollama部署

3.5 langchain-classic
  1. 兼容包 / 迁移包：把 LangChain v0.x 中的 老 API / legacy 功能 搬到单独包里，以便 v1.0 保持精简，但仍给用户向后兼容的迁移通道。

  • 包含如：老的 Chain 实现、旧版 retrievers、索引 API、hub 模块等被标记为“legacy”的功能。

    • 旧版AgentExecutor

    • Legacy Chains（LLMChain, SequentialChain等）

4 环境搭建

  1. 虚拟环境列表

    # 列出所有可用的环境（*标识为当前激活环境）
conda env list

  2. 激活环境

    conda activate env_agent

  3. 安装的库

    核心库

    pip3 install langchain -i https://pypi.tuna.tsinghua.edu.cn/simple
pip3 install langchain-core -i https://pypi.tuna.tsinghua.edu.cn/simple
pip3 install langchain-community -i https://pypi.tuna.tsinghua.edu.cn/simple

    三方库

    pip3 install langchain-openai -i https://pypi.tuna.tsinghua.edu.cn/simple


pip3 install python-dotenv -i https://pypi.tuna.tsinghua.edu.cn/simple
pip3 install psycopg langgraph-checkpoint-postgres -i https://pypi.tuna.tsinghua.edu.cn/simple
pip3 install streamlit PyPDF2 faiss-cpu
pip3 install docx2txt -i https://pypi.tuna.tsinghua.edu.cn/simple
pip3 install langchain-ollama -i https://pypi.tuna.tsinghua.edu.cn/simple

    langchain-huggingface langchain-text-splitters docx2txt

    pip3 install langchain-huggingface -i https://pypi.tuna.tsinghua.edu.cn/simple
    pip3 install sentence-transformers -i https://pypi.tuna.tsinghua.edu.cn/simple # langchain-huggingface

    pip3 install langchain-community -i https://pypi.tuna.tsinghua.edu.cn/simple

    pip3 install openai -i https://pypi.tuna.tsinghua.edu.cn/simple

    pip3 install langchain-ollama -i https://pypi.tuna.tsinghua.edu.cn/simple

    pip3 install langchainhub -i https://pypi.tuna.tsinghua.edu.cn/simple

    pip install --upgrade langchain-core

    其他库

5 LangChain 1.0 底层运行架构

			简化版架构示意图
┌─────────────────────────────────────────┐
│        LangChain 1.0 应用层              │
│  (create_agent, 工具和中间件)             │
└──────────────────┬──────────────────────┘
                   │
                   ▼
┌─────────────────────────────────────────┐
│        LangGraph 编排层                  │
│  (StateGraph, Nodes, Edges, Checkpoints)│
└──────────────────┬──────────────────────┘
                   │
                   ▼
┌─────────────────────────────────────────┐
│        LCEL 运行时层                     │
│  (Runnable接口, |运算符, 流式/批处理)      │
└──────────────────┬──────────────────────┘
                   │
                   ▼
┌─────────────────────────────────────────┐
│        大语言模型API(OpenAI/DeepSeek)     │
└─────────────────────────────────────────┘
  • LCEL：提供Runnable接口（invoke, stream, batch）和组合原语（|运算符），是无状态的函数式编排，构建“流水线（pipeline）”的工具
  • LangGraph：在LCEL基础上增加状态管理（State）、循环控制（Cycles）、持久化（Checkpoints），是有状态的图结构编排，构建“流程图（workflow/graph）”的工具

二 Model I/O模块

1. Model I/O模块介绍

​ Model I/O 模块是与语言模型（LLMs）进行交互的 核心组件 ，在整个框架中有着很重要的地位。

Model I/O 包括
	1. 输⼊(Format)：输入提示，Prompt Template
	2. 模型处理(Predict)：模型调用，Model 
	3. 输出(Parse)：输出解析(器)，Output Parser
针对每个环节，LangChain都提供了模板和工具，可以快捷的调用各种语言模型的接口。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

2.1 模型分类（一）

  1. 文本 模型
    • 仅支持文本输入（输入形式决定能力边界）
    • 只能感知 文本（读句子）
    • 依赖语言描述间接理解世界
    • 擅长逻辑推理、写作、翻译
    • 仅有语言模型
  2. 多模态 模型
    • 支持 文本、图像、音频、视频等多模态混合输入
    • 能感知 “看图” “听声” “读文” 综合理解
    • 直接处理真实世界的多维信号
    • 能像人一样边看边想，理解更接近真实场景
    • 视觉编码器 + 特征对齐层 + 语言模型
  3. Embedding 模型
    • 将文本、图像、音频等数据转换为‌高维向量‌（即“嵌入”），使语义相近的内容在向量空间中距离更近。
    • 单独处理每个输入（如一句话、一张图），生成一个固定长度的向量。
    • 通过向量相似度（如余弦相似度）快速匹配候选结果，实现‌大规模数据的高效检索‌。
    • 常用于 RAG 中的第一阶段：检索（Retrieval），从海量文档中快速找出 Top-K 相关片段。
  4. Rerank 模型
    • 对 Embedding 初步召回的结果进行‌精细化打分与重排序‌，提升最终结果的相关性。
    • 接收“查询 + 候选文档”作为输入，输出一个匹配度分数。
    • 基于深度语义理解（如 BERT 类模型）判断两者是否真正相关，能捕捉上下文、逻辑关系等细微差异。
    • 常用于 RAG 第二阶段‌：在大模型生成答案前，确保输入的是最相关的文档。

2.2 模型分类（二）

  1. 非对话模型（LLMs、Text Model）

    LLMs，也叫Text Model、非对话模型，是许多语言模型应用程序的支柱。

    • 输入：接受 文本字符串 或 PromptValue 对象
    • 输出：总是返回 文本字符串
    • 适用场景：仅需单次文本生成任务（如摘要生成、翻译、代码生成、单次问答）（ 优先推荐ChatModel ）
    • 不支持多轮对话上下文：每次调用独立处理输入，无法自动关联历史对话（需手动拼接历史文
      本）。
    • 局限性：无法处理角色分工或复杂对话逻辑。

  2. 对话模型（Chat Models）（ 推荐 ）

    ChatModels，也叫聊天模型、对话模型，底层使用LLMs。 大语言模型调用，以 ChatModel 为主！

    • 输入：接收文本字符串、消息列表 List[BaseMessage] 或 PromptValue ，每条消息可以指定角色（如 SystemMessage、HumanMessage、AIMessage）
    • 输出：总是返回带角色的 消息对象 （ BaseMessage 子类），通常是 AIMessage
    • 原生支持多轮对话。通过消息列表维护上下文（例如： [SystemMessage, HumanMessage, AIMessage, …] ），模型可基于完整对话历史生成回复。
    • 适用场景：对话系统（如客服机器人、长期交互的AI助手）

  3. 如何判断一个国产大模型是否为对话模型？

    可通过以下三个维度判断：

    判断维度 对话模型 非对话模型
    输入格式 支持 List[BaseMessage]（含System/Human/AIMessage） 多为字符串或PromptValue
    上下文管理 支持长上下文（如128K以上）和多轮记忆 通常无上下文保持机制
    功能侧重 闲聊、问答、情感理解、角色扮演 代码生成、数学推理、文档处理、Agent任务
    输出格式 总是返回带角色的 消息对象 AIMessage 总是返回 文本字符串

3 提示(Prompts)

str（字符串）输入方式不支持多轮对话的主要原因是其‌缺乏上下文保持机制‌，无法维护这种连续性。当使用字符串作为输入时，每次调用模型都只处理当前的单个字符串，无法保留之前的对话历史或上下文信息。

List[BaseMessage] 和 PromptValue 输入方式可以通过显式地包含系统消息、用户消息和助手消息等来构建对话历史，从而支持多轮对话。每次对话时，将新的消息（如用户输入、系统提示等）添加到列表中，然后将整个列表传递给模型。这样模型就能基于完整的对话历史进行理解和响应。

3.1 字符串（str）
  • ‌用途‌：通常用于非对话场景，例如单次文本提示。
  • ‌处理方式‌：LangChain 会自动将其转换为 HumanMessage，作为消息列表的一部分传入模型。
  • 变量支持：不直接支持变量（需要需要手动拼接字符串）
  • ‌适用场景‌：适用于不需要维护上下文的简单文本输入，如一次性问答或文本生成任务。
3.2 消息列表（List[BaseMessage]）

  • ‌用途‌：用于支持多轮对话或需要明确指定角色的消息交互。

  • ‌组成‌：每条消息必须是 BaseMessage 的子类，如 SystemMessage、HumanMessage 或 AIMessage。

    • SystemMessage‌ 用于向模型提供系统级别的指令或上下文信息，通常在对话开始时使用，为模型设定角色或行为准则。例如，可以设置模型为"有帮助的助手"或"专业的翻译员"。

    • HumanMessage‌ 代表用户的输入内容，用于表示对话中来自人类用户的提问或指令。它通常包含用户的具体问题或请求。

    • ‌AIMessage‌ 代表模型的响应内容，用于表示模型对用户输入的回复。它包含模型生成的文本输出。

    • 多轮对话流程如下：

      1. ‌初始化对话‌：创建一个空的消息列表或包含系统消息的列表。
      2. 添加系统消息：将设定的角色或行为准则输入封装SystemMessage并添加到列表中。
      3. ‌添加用户消息‌：将用户的输入封装为 HumanMessage 并添加到列表中。
      4. ‌添加助手消息‌：将模型的响应封装为 AIMessage 并添加到列表中。
      5. ‌重复交互‌：在后续轮次中，继续添加新的 HumanMessage 和 AIMessage 到列表中。
      6. ‌模型处理‌：将整个消息列表传递给模型，模型会根据所有消息的内容进行理解和生成响应。

      这种方式使得模型能够理解对话的上下文，从而实现更自然、连贯的多轮对话体验。

  • 变量支持：不直接支持变量（需要手动构建消息对象）

  • ‌特点‌：允许开发者显式控制对话历史和角色分配，增强上下文理解能力。

3.3 提示词模版（PromptValue）

  • ‌用途‌：一种抽象的提示表示形式，可以转换为 List[BaseMessage] 或字符串。

  • ‌灵活性‌：通过 .to_messages() 方法可转换为消息列表，适用于需要灵活处理提示格式的场景。

  • ‌统一接口‌：当不确定底层模型类型时，可以通过 PromptValue 来统一处理输入。

  • 变量支持：完全支持变量（需要动态参数化的提示输入）

  • 使用方式‌：通过 PromptTemplate 或 ChatPromptTemplate 创建模板，支持变量占位符

    • PromptTemplate 主要用于非聊天场景的文本生成任务

      它将输入变量直接替换到模板字符串中，适用于简单的文本填充任务。例如，可以创建一个模板来生成邮件内容或文档类型转换，其中包含特定的变量占位符。

    • ChatPromptTemplate 则专门设计用于聊天模型的提示构建

      它能够处理消息列表格式的输入，支持系统消息、用户消息和助手消息的组合。这种方式更适合需要维护对话历史和角色区分的多轮对话场景。

    • 使用场景

      如果只需要简单的文本变量替换，PromptTemplate 就足够了；如果需要构建复杂的对话交互，ChatPromptTemplate 提供了更好的支持和灵活性。

4 Runnable底层执行引擎

​ Runnable 是 LangChain 1.0 的“统一接口标准”，任何可以运行的组件（模型、Prompt、工具、解析器、Memory、Graph 节点）在 1.0 中都被抽象为 Runnable。

​ Runnable 使所有 LangChain 组件能够以统一接口组合、执行、链式调用，并支撑 LCEL（LangChain Expression Language）的整个运行语义，支撑可组合、可并行、可路由的链式执行，是 LangChain 1.0 的核心底座之一。

  • LangChain 1.0 将所有链式元素统一为 Runnable（执行模型）：

    • LLM（OpenAI、vLLM、Ollama……）

    • Prompt

    • Parser

    • Retriever

    • Tool

    • Agent

    • 自定义函数

所有对象都可以 .invoke()、.batch()、.stream()、.astream_events()，这实现了真正的统一调用接口。

  • 工程价值：

    • 链路清晰。

    • 任意组件之间可无缝组合。

    • 所有执行方式（同步 / 异步 / 批处理 / 事件流）统一。

    • 这是 LangChain 1.0 最具革命性的改变，使其成为“模型调用管道”的事实标准。

Runnable = LCEL 的语法基础

LCEL（| 运算符）是由 Runnable 定义的组合语义：

chain = prompt | model | StrOutputParser()
output = chain.invoke({"topic": "LangChain"})

这三者本质都是 Runnable：

PromptTemplate   → Runnable
Model            → Runnable
Parser           → Runnable

任何 LCEL chain = 多个 Runnable 的组合。

技术 在 LangChain 1.0 的角色
LangChain 构建 LLM + prompt + tool + outputparser 的组件生态
LangGraph 构建 Agent / 多步工作流 / 状态机的框架
LCEL / Runnable LangChain 的底层执行引擎，依然核心

5 输出解析（Output Parsers）

​ 很多时候，我们需要模型返回结构化的数据（如JSON），以便程序后续处理。输出解析器 (Output Parsers) 正是为此而生。

分类 常用解析器 作用
基础解析 StrOutputParser 将模型输出解析成纯字符串（默认）
JSON 结构化解析 JsonOutputParser 将 LLM 输出强制解析为 JSON
PydanticOutputParser 使用 Pydantic v1 模型进行结构化输出
PydanticOutputFunctionsParser 用于 Function Calling 的 Pydantic 结构化解析
列表解析 CommaSeparatedListOutputParser 输出如 "a,b,c"
→ ["a", "b", "c"]
ListOutputParser 更通用的列表解析
布尔/数值解析 BooleanOutputParser 输出 “yes” / “no” → True/False
FloatOutputParser 输出模型内容转 float
IntOutputParser 输出模型内容转 int
复杂结构化 EnumOutputParser 让模型输出固定几个选项之一
DataclassOutputParser 使用 Python dataclass 进行结构化输出

结构化输出关键要点：

  1. 输出json格式，提示词必须包含 “json” 关键词

    • DeepSeek API 要求提示词中包含 “json” 这个词
    • 否则会报错：Prompt must contain the word 'json'

  2. 推荐方案对比

    • 方案 1 (JsonOutputParser)：最简洁，推荐使用
    • 方案 2 (with_structured_output)：需要提示词包含 “json”
    • 方案 3 (可选手动 JSON 解析)：最稳定，适合关键应用

  3. 配置建议

    • 设置 temperature=0.0 获得更稳定的输出
    • 最好提供清晰的 JSON 格式示例

  4. 常见错误

    • 提示词中没有 “json” 关键词
    • 没有设置低温度参数
    • 没有提供 JSON 格式示例
    • 没有处理解析异常

2. 调用模型

​ LangChain作为一个“工具”，不提供任何 LLMs（大语言模型），而是依赖于第三方集成各种大模型。比如，将 OpenAI、阿里（Qwen）、深度求索（Deepseek）、智谱AI（ChatGLM） 等平台的模型无缝接入到你的 应用。

2.2. API调用

  • OpenAI提供的API

    OpenAI的GPT系列模型影响了⼤模型技术发展的开发范式和标准。
所以⽆论是Qwen、ChatGLM 等模型，它们的使⽤⽅法和函数调⽤逻辑基本 遵循OpenAI定义的规范 ，没有太⼤差异。
这就使得⼤部分的开源项⽬能够通过⼀个较为通⽤的接口来接⼊和使⽤不同的模型。

  • 其它大模型自家提供的API

    • 阿里云百炼平台（官网：https://bailian.console.aliyun.com/cn-beijing/#/home）

    • 百度千帆平台（官网：https://cloud.baidu.com/doc/qianfan-docs/s/Mm8r1mejk）

    • 智谱的GLM（官网：https://www.bigmodel.cn/）

    • 硅基流动平台（官网：https://www.siliconflow.cn/）

  • LangChain的统一方式调用API（ 推荐 ）

2.3. LangChain的API调用对话模型
2.3.1. ChatOpenAI() 创建对话类模型对象

​ 模型调用函数使用时需初始化模型，并设置必要的参数。

  • 必须设置的参数

    • base_url：大模型 API 服务的根地址
    • api_key：用于身份验证的密钥，由大模型服务商（如 OpenAI、百度千帆）提供
    • model/model_name：指定要调用的具体大模型名称（如 gpt-4-turbo 、 ERNIE-3.5-8K 等）

  • 其他参数

    • temperature：温度，控制生成文本的“随机性”，取值范围为0～1。

      值越低 → 输出越确定、保守（适合事实回答）
值越高 → 输出越多样、有创意（适合创意写作）
通常，根据需要设置如下：
    精确模式（0.5或更低）：生成的文本更加安全可靠，但可能缺乏创意和多样性。
    平衡模式（通常是0.8）：生成的文本通常既有一定的多样性，又能保持较好的连贯性和准确性。
    创意模式（通常是1）：生成的文本更有创意，但也更容易出现语法错误或不合逻辑的内容。

    • max_tokens ：限制生成文本的最大长度，防止输出过长。

      • Token
        • 基本单位: 大模型处理文本的最小单位是token（相当于自然语言中的词或字），输出时逐个token依次生成。
        • 收费依据 ：大语言模型(LLM)通常也是以token的数量作为其计量(或收费)的依据。
          • 1个Token≈1-1.8个汉字，1个Token≈3-4个英文字母
          • Token与字符转化的可视化工具
            • OpenAI提供：https://platform.openai.com/tokenizer
            • 百度智能云提供：https://console.bce.baidu.com/support/#/tokenizer
        • max_tokens 设置建议
          • 客服短回复：128-256。比如：生成一句客服回复（如“订单已发货，预计明天送达”）
          • 常规对话、多轮对话：512-1024
          • 长内容生成：1024-4096。比如：生成一篇产品说明书（包含功能、使用方法等结构）
2.3.2. invoke(xxx) 执行模型调用
2.3.3. content 模型返回的实际文本内容
2.3.4. 模型调用示例
  1. 项目根目录，创建 .env 文件
  2. 代码编写

Agent层（Agents）

1. Agent核心概念

​ Agent智能体是一种以大语言模型（LLM）为"大脑"，能够自主感知环境、进行推理规划，并调用外部工具执行复杂任务的系统，具备一系列高级特征的复杂系统。

​ 根据LangChain框架的定义，Agent的核心是以大语言模型（LLM）作为其推理引擎，并依据LLM的推理结果来决定如何与外部工具进行交互以及采取何种具体行动。这种架构将LLM的强大语言理解与生成能力，与外部工具的实际执行能力相结合，从而突破了单一LLM的知识限制和功能边界。

​ Agent的本质可以被理解为一种高级的提示工程（Prompt Engineering）应用范式，开发者通过精心设计的提示词模板，引导LLM模仿人类的思考与执行方式，使其能够自主地分解任务、选择工具、调用工具并整合结果，最终完成复杂的任务。

Agent（智能体）已超越传统AI模型，成为能够自主完成多步骤复杂任务的智能数字助手。其核心特征在于自主性增强、执行能力和持续学习。

Agent（智能体）集成核心功能：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

  • Planning（规划）

    ​ 是智能体根据目标和当前状态生成执行计划的过程。

    ​ 它决定了智能体下一步应该采取哪些行动以达成目标。

    ​ 规划模块可以是基于规则，也可以是基于某个算法，来生成最优路径或策略。

  • Memory（记忆）

    ​ 用于存储智能体在交互过程中获得的信息，包括历史经验、知识库、状态变化等。

    ​ 记忆模块帮助智能体在后续任务中复用之前的经验，从而提升效率和性能。

    ​ 记忆可以分为短期记忆和长期记忆，分别用于临时存储和持久化存储信息。

  • Tools（工具）

    ​ 是智能体执行具体任务时所依赖的外部资源或功能模块。

    ​ 例如，图像识别工具、自然语言处理工具、数据库查询工具等。

    ​ 通过调用这些工具，智能体可以扩展其能力边界，处理更复杂的任务。

  • Action（行动）

    ​ 是智能体根据规划结果和当前状态所采取的实际操作。

    ​ 它可以是与环境的交互，如移动、点击按钮、发送消息等。

    ​ 行动模块将智能体的决策转化为具体的输出，使智能体能够对环境产生影响。

    这四个模块共同构成了一个完整的智能体工作流程：

    ​ 智能体首先通过记忆模块获取上下文信息，然后利用工具模块处理复杂任务，接着通过规划模块生成行动方案，最后执行行动并更新记忆。

2. Agent的核心特征

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

  • 自主性 (Autonomy)

    	自主性是Agent最核心的特征之一，指的是Agent能够在没有人类直接干预的情况下，独立地完成任务的感知、规划、决策和行动的全过程。在LangChain框架中，这种自主性体现在Agent能够根据用户的输入，自动判断是否需要调用外部工具，选择哪个工具，以及如何组织调用参数。
	例如，当用户询问"北京的天气怎么样？"时，Agent能够自主识别出这是一个需要实时信息查询的任务，并自动调用天气查询工具来获取答案，而无需开发者显式地编写"如果问题是关于天气，则调用天气API"这样的硬编码逻辑。
	这种自主性使得Agent能够处理更加开放和动态的问题，极大地提升了应用的灵活性和智能水平。

  • 感知能力 (Perception)

      感知能力是指Agent获取和理解环境信息的能力。在基于LLM的Agent中，环境信息主要以文本形式存在，包括用户的输入、工具的输出以及系统状态等。Agent通过其底层的LLM来解析和理解这些文本信息，从中提取关键指令、实体和上下文。
  例如，在接收到用户问题后，Agent需要感知问题的意图和关键实体（如地点、时间、人物），以便决定后续的行动。
  LangChain框架通过提供标准化的消息格式（如HumanMessage, AIMessage）和工具描述机制，为Agent的感知能力提供了坚实的基础，使其能够清晰地理解来自不同来源的信息。

  • 推理与规划 (Reasoning & Planning)

    	推理与规划是Agent智能的核心。
	Agent需要能够分析任务目标，并将其分解为一系列可执行的子步骤。
	LangChain中的Agent，特别是基于 ReAct（Reasoning and Acting）范式 的Agent，展现了强大的推理和规划能力。
	ReAct框架要求LLM在每一步都生成一个"思考"（Thought）过程，解释其当前的理解和下一步的计划，然后生成一个"行动"（Action），即调用某个工具。
	这个过程会循环进行，直到Agent认为已经收集了足够的信息来回答原始问题。
	例如，面对一个复杂的多步骤数学问题，Agent会先规划出解题步骤，如"首先计算A，然后用A的结果计算B"，并按此规划逐步调用计算工具来完成任务。

  • 行动能力 (Action)

      行动能力是指Agent执行具体操作以影响环境的能力。
  在LangChain框架中，Agent的行动能力主要通过调用外部工具（Tools）来实现。
  这些工具可以是API调用、数据库查询、代码执行器，甚至是其他Agent。
  Agent通过LLM来决定调用哪个工具，并生成符合工具要求的输入参数。
  工具执行后，其输出结果会作为新的环境信息反馈给Agent，供其进行下一步的推理和决策。
  这种"思考-行动-观察"的循环，使得Agent能够与外部世界进行有效的交互，从而完成各种复杂的实际任务，如信息检索、数据处理和自动化流程控制。

  • 学习能力 (Learning)

    	一个真正的智能体不仅仅是执行预设的程序，它还应该具备从经验中学习并不断优化自身行为的能力。
	这种学习能力通常通过强化学习、反馈机制或记忆系统来实现。
	智能体在每次行动后，会观察行动的结果，并根据结果（例如，用户的反馈或环境的奖励/惩罚信号）来调整其内部的决策模型或策略。
	例如，如果一个智能体推荐的商品被用户频繁购买，它就会学习到这种推荐是有效的；反之，如果推荐被用户忽略或拒绝，它就会调整其推荐策略。
	这种持续学习和优化的能力使得智能体能够随着时间的推移变得越来越"聪明"，更好地适应复杂多变的环境。

3. Agent技术架构核心

理解 Agent（智能体） 最难的地方在于理解它"如何自主决策"。Agent 更像是一个"拥有万能工具箱的超级项目经理"。

  • LLM（大模型）= 大脑（项目经理）：它负责思考、规划、决定下一步做什么。

  • Tools（工具）= 手脚（执行专员）：比如谷歌搜索（负责看世界）、计算器（负责算数）、数据库（负责查档案）。

  • Agent = 大脑 + 手脚 + 循环机制：把大脑和手脚结合起来，通过不断的"思考-行动-观察"循环来解决问题。

现代Agent的技术架构由五个核心模块构成，形成完整的"感知-思考-行动"闭环。

  • 感知模块 (Perception)：负责接收文本、图像、语音等多模态输入。
  • 认知中枢 (Brain/Planning)：基于大语言模型（LLM）和检索增强生成（RAG）技术，进行推理和决策，弥补LLM无法获取实时信息和执行具体操作的缺陷。
  • 记忆系统 (Memory)：通过短期记忆维持对话连贯，长期记忆积累经验与偏好。
  • 工具生态 (Tools)：通过API调用、数据库访问等方式与外部系统交互。
  • 执行引擎 (Action)：负责执行具体任务并反馈结果。

这一机制使得Agent能够构建一个完整的执行闭环：环境感知 → 任务规划 → 工具调用 → 执行反馈 → 自我反思 → 优化调整，从而在复杂环境中持续学习和改进。

4 Agent与LangChain结合机制

4.1 核心结合点：create_agent + LangGraph

create_agent作为上层统一入口，其内部实现依赖于LangGraph。当调用create_agent时，LangChain会自动构建一个基于ReAct（推理+行动）范式的图结构。这个图包含了Agent决策、工具调用、状态更新等核心节点，并通过边来控制逻辑流转。这种设计将Agent的"思考"过程映射为图的遍历，使得整个执行流程变得透明、可控。

LangChain 1.0 的 create_agent 通过这 9 个核心参数，实现了从快速原型到生产部署的全覆盖，开发者可根据场景灵活组合。

* create_agent 的核心价值在于它通过 “三要素 + 三扩展” 的极简抽象，彻底重构了 Agent 的开发范式。所谓三要素，即模型（Model）、工具（Tools）与提示词（System Prompt），这三者构成了 Agent 的"灵魂"——决定了它能思考什么、能做什么以及行为边界何在。而三扩展——中间件（Middleware）、内存管理（Memory）与状态管理（State）——则构建了 Agent 的"神经系统"，使其具备生产级应用所需的可靠性、可观测性与可维护性。

* 这一设计将开发者从繁琐的 ReAct 循环手写、工具调用异常处理、上下文压缩等底层细节中解放出来，转而采用声明式编程模式：只需描述"Agent 应该做什么"，框架自动编译为高效、可靠、安全的执行计划。其本质是 LangGraph 的编译器前端 ，将高层意图转换为优化的图结构，自动集成持久化、流式输出、断点恢复等运行时能力。

这种架构带来了三重革命性影响：首先，开发效率提升 10 倍，10 行代码即可构建一个可投产的智能客服或数据分析 Agent；其次，运维成本降低 60%，中间件机制将 PII 检测、人工审批、自动重试等横切关注点解耦，无需侵入业务代码；最后，可扩展性实现质的飞跃，通过 TypedDict 扩展 State，可无缝集成用户画像、多模态输入、性能监控等复杂场景。

参数 类型 必填 默认值 核心作用 最佳实践
model str/实例 ✅ - 推理引擎 生产环境实例化配置
tools list ✅ [] 执行能力 描述清晰，按需添加
system_prompt str ❌ None 行为准则 明确角色和约束
middleware list ❌ [] 功能扩展 组合日志、安全、摘要
checkpointer Saver ❌ None 短期记忆 生产用 PostgresSaver
store Store ❌ None 长期记忆 跨会话用 PostgresStore
state_schema TypedDict ❌ AgentState 扩展状态 用 TypedDict 非 Pydantic
context_schema TypedDict ❌ None 动态上下文 配合 middleware 使用
response_format BaseModel ❌ None 结构化输出 API 对接场景启用
4.2 ReAct范式与执行循环

  ReAct(Reasoning + Acting)范式强调"推理—行动—观察"的闭环:Agent先形成Thought(推理),据此选择并调用工具(Action),再吸收工具返回的Observation(观察),进入下一轮决策。闭环在达到最终答案、迭代上限或时间上限时终止。在LangGraph中,这一闭环由状态机与检查点驱动,保证每次行动的原子性、状态的可见性与轨迹的可回放性。并且推理与规划不是代码逻辑，而是LLM的生成行为，关键的 Thought: 步骤并非由确定性算法执行，而是prompt触发LLM生成推理文本。模型能力是ReAct性能的天花板

Agent的认知循环本质上是一个闭环反馈系统。每一次"行动"的执行结果都会作为新的输入反馈到系统，影响下一轮的"思考"和"行动"。这种反馈机制使得Agent能够动态调整策略，应对不确定的环境和复杂任务。在LangChain中，这一循环被实现为：

  1. Thought (推理)：大模型基于当前输入和历史记录进行思考，决定下一步行动。

  2. Action (行动)：大模型选择一个工具并构造输入参数，形成一个AgentAction。

  3. Observation (观察)：工具被执行，其返回结果作为观察值，并与AgentAction一起被添加到中间步骤（intermediate_steps）中。

  4. 循环决策：Agent将新的观察结果纳入上下文，进入下一轮"推理-行动"循环，直至达到最终目标或触发终止条件（如达到最大迭代次数）。

Agents的核心类型有两种模式： 方式1：Funcation Call模式 方式2：ReAct 模式

2.2.1 FUNCATION_CALL模式 基于 结构化函数调用 （如 OpenAI Function Calling） 直接生成工具调用参数（ JSON 格式 ） 效率更高，适合工具明确的场景

2.2.2 ReAct 模式 基于 文本推理 的链式思考（Reasoning + Acting），具备反思和自我纠错能力。 推理（Reasoning）：分析当前状态，决定下一步行动 行动（Acting）：调用工具并返回结果 通过 自然语言描述决策过程 适合需要明确推理步骤的场景。例如智能客服、问答系统、任务执行等。

三 工具层（Tools）

​ 工具是Agent与外部世界交互的桥梁。在LangChain中，工具的name、description和args_schema至关重要，它们共同决定了模型是否以及如何选择和调用工具。一个设计良好的工具描述是提示工程的关键部分。

行思考，决定下一步行动。

  1. Action (行动)：大模型选择一个工具并构造输入参数，形成一个AgentAction。

  2. Observation (观察)：工具被执行，其返回结果作为观察值，并与AgentAction一起被添加到中间步骤（intermediate_steps）中。

  3. 循环决策：Agent将新的观察结果纳入上下文，进入下一轮"推理-行动"循环，直至达到最终目标或触发终止条件（如达到最大迭代次数）。

Agents的核心类型有两种模式： 方式1：Funcation Call模式 方式2：ReAct 模式

2.2.1 FUNCATION_CALL模式 基于 结构化函数调用 （如 OpenAI Function Calling） 直接生成工具调用参数（ JSON 格式 ） 效率更高，适合工具明确的场景

2.2.2 ReAct 模式 基于 文本推理 的链式思考（Reasoning + Acting），具备反思和自我纠错能力。 推理（Reasoning）：分析当前状态，决定下一步行动 行动（Acting）：调用工具并返回结果 通过 自然语言描述决策过程 适合需要明确推理步骤的场景。例如智能客服、问答系统、任务执行等。

三 工具层（Tools）

​ 工具是Agent与外部世界交互的桥梁。在LangChain中，工具的name、description和args_schema至关重要，它们共同决定了模型是否以及如何选择和调用工具。一个设计良好的工具描述是提示工程的关键部分。

Logo
2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

理解多智能体深度确定性策略梯度（MADDPG）：完整指南

多智能体深度确定性策略梯度（MADDPG）是 DDPG 的扩展版本，旨在解决多智能体环境中的非平稳性问题。它采用“集中式训练、分散式执行”的范式。构建一个简单的 2 智能体协作导航任务：状态：两名智能体位置、各自目标位置每个智能体观测：自己的位置、另一智能体位置、自己的目标位置（归一化）动作：离散（上/下/左/右）奖励：共享；每步小惩罚；两者同时到达各自目标给大正奖励；加入距离 shaping 与

avatar 2048 AI社区
cover

2026别错过！AI论文网站 千笔AI VS 文途AI，专为本科生打造！

avatar 2048 AI社区
cover

综述不会写？AI论文软件 千笔·专业论文写作工具 VS 笔捷Ai 本科生专属利器

avatar 2048 AI社区