LangChain入门：大模型局限、Agent原理与环境配置实战

为什么需要LangChain这样的框架

要理解LangChain存在的价值，首先要认清大语言模型（LLM）本身的三大天然局限。这个底层逻辑是入门AI应用开发的必修课，值得系统梳理。

第一，知识存在时间截点。大模型基于某个时间点之前的数据训练而成，超出训练截止日期的事件与知识，模型一概不知。

背景：为什么模型知识会"过期"？ 大语言模型通过对海量文本语料进行预训练，将世界知识以参数权重的形式"压缩"进模型，但这个过程是一次性的——训练完成后，模型参数冻结，知识不再更新。这与搜索引擎实时爬取索引的机制截然不同。以GPT-4为例，其知识截止日期为2023年4月；DeepSeek-V3的截止日期约为2024年7月。这意味着此后发生的任何事件，模型都无法通过"记忆"回答，只能依赖外部工具注入实时信息。

第二，大模型没有记忆能力。这是初学者最常见的误区。你告诉模型"我叫张三"，它能回应"你好张三"；但下一轮对话中单纯调用模型，它并不记得你叫张三。我们日常使用的对话产品能保持上下文，靠的是应用层自行维护历史消息，而非模型本身具备记忆。

背景：无状态API与对话上下文的实现原理 大模型的API调用本质上是"无状态"的HTTP请求——每次调用都是独立事务，服务端不保存任何会话信息。我们日常使用ChatGPT或Claude时感受到的"连贯对话"，是应用层将历史消息拼接为一个超长Prompt后，整体传入模型实现的。具体做法是将完整对话历史（含SystemMessage、HumanMessage、AIMessage交替排列）作为上下文窗口输入，模型在此基础上生成回复。这也解释了为何对话长度受限于模型的"上下文窗口"（Context Window）大小，主流模型从32K到200K Token不等。

第三，无法获取业务专属数据。模型知识有截止点，若要服务于具体业务，就必须主动"喂"给它业务数据——这正是**工具调用（Tool Calling）**概念的由来：通过工具让模型在推理时获取外部知识。

背景：工具调用的技术原理 工具调用（Tool Calling，早期也称Function Calling）是OpenAI于2023年首先引入的能力，现已成为主流模型的标准特性。其工作原理是：开发者在调用模型时，随Prompt附上一份工具定义清单（包括工具名称、功能描述、参数Schema）。模型在推理时若判断需要调用某工具，会在输出中返回结构化的调用指令，而非直接给出答案。应用层解析该指令、执行对应工具（如查询数据库、调用天气API）后，将结果以ToolMessage形式再次传入模型，模型最终基于工具返回值生成完整回复。这个"模型→工具→模型"的循环正是Agent多步推理的基础。

正是为了系统性地解决记忆管理、工具调用、上下文与状态维护这三大问题，LangChain这类AI应用开发框架才应运而生。它的定位非常清晰：LangChain是一个开发AI应用的框架，同类产品还有Claude SDK、OpenAI SDK等。

LangChain的核心特点与技术选型

为什么选Python而非Java

学大模型应用开发，不等于研究算法。当前企业里的主流工作，是将已有的大模型能力接入业务、构建AI应用，而非从零训练模型。

在语言选型上，业内90%以上的项目选择Python，原因有两点：

• 私有化部署刚需：大模型私有化部署强依赖Python生态（如vLLM等推理框架），Java生态中几乎找不到对应工具链。
• 框架生态先发优势：LangChain / LangGraph是最早一批成熟的AI应用框架，几乎所有新发布的大模型API都会优先适配LangChain生态，社区资源更丰富。

背景：vLLM与私有化部署生态 vLLM是由UC Berkeley开发的高性能大模型推理引擎，专为GPU集群上的生产级部署设计。其核心创新是PagedAttention技术，将GPU显存中的KV Cache管理类比为操作系统的虚拟内存分页，大幅提升了显存利用率和并发吞吐量。私有化部署场景中，企业通常需要将开源模型（如Llama、Qwen、DeepSeek等）部署在自有服务器上，以满足数据安全合规要求。Python是vLLM、Ollama、TGI（Text Generation Inference）等推理框架的唯一支持语言，这也是AI应用开发强依赖Python生态的根本原因之一。

两大核心框架特性

统一的模型接口：过去调用不同厂商的大模型，每家接口各不相同，换模型就要改代码。使用LangChain后，只需替换模型名称，上层业务逻辑无需改动，框架自动处理各厂商的兼容适配。

模块化架构：大模型应用涉及状态管理、历史消息、工具调用、RAG检索、提示词工程、中间件等诸多环节，LangChain将这些能力全部模块化拆分，开发者可以按需组合，降低系统复杂度。

背景：RAG检索增强生成 RAG（Retrieval-Augmented Generation，检索增强生成）是解决大模型知识时效性与业务专属数据问题的主流技术方案。其核心思路是：在模型推理时，先通过向量检索从外部知识库中找出与用户问题最相关的文档片段，再将这些片段作为上下文注入Prompt，让模型基于"实时检索到的事实"生成回答，而非单纯依赖训练时压缩的参数知识。RAG流程通常包括文档切分、向量嵌入（Embedding）、向量数据库存储、语义检索、Prompt组装五个环节，LangChain为这整套流程提供了完整的模块化支持，是后续实战的重点方向。

环境准备与API配置

推荐开发环境为 PyCharm + Python 3.13，配合 LangChain 1.3.2 与 LangGraph 1.2.x。

配置步骤如下：

1. 在项目根目录创建 .env 文件，核心只需配置两项：DEEPSEEK_API_KEY 和 DEEPSEEK_BASE_URL。
2. 登录 DeepSeek 官网，在 API Keys 页面创建新密钥，并在接口文档中找到对应的 Base URL。
3. 使用 python-dotenv 加载 .env，将配置读取为环境变量供代码调用。

背景：为什么用.env文件管理密钥？ 在AI应用开发中，API Key属于高度敏感的凭证信息，直接硬编码在源码中存在严重的安全风险——一旦代码提交至公开仓库（如GitHub），密钥即刻面临泄露风险。业界通行做法是将所有密钥与配置写入.env文件，并在.gitignore中明确排除该文件，使其永不进入版本控制。python-dotenv库通过load_dotenv()函数将.env中的键值对注入当前进程的环境变量，代码中以os.getenv('DEEPSEEK_API_KEY')方式读取，实现配置与代码的彻底分离。这一模式与Kubernetes Secret、AWS Secrets Manager等生产环境密钥管理方案保持一致的设计哲学。

教程以 DeepSeek 为示例，但同等方式支持 OpenAI、Anthropic、腾讯混元、阿里通义千问、智谱等主流模型，切换时只需更换厂商标识与 API Key。

初始化大模型：init_chat_model 详解

配置就绪后，使用 LangChain 官方推荐的通用方法 init_chat_model 初始化模型：

from langchain.chat_models import init_chat_model

deepseek_llm = init_chat_model(
    model="deepseek-v4-pro",
    model_provider="deepseek",
    api_key=DEEPSEEK_API_KEY,
    base_url=DEEPSEEK_BASE_URL,
    extra_body={"thinking": {"type": "disabled"}}
)

这里有一个关键参数需要重点说明：extra_body 中将 thinking 设为 disabled，即关闭思考（推理）模式。原因如下：

• 性能考量：开启 Thinking 模式后，模型需要先经历思考过程再输出，回复速度明显变慢。对于构建智能体或常规AI应用，绝大多数业务场景并不需要深度推理。当前 DeepSeek Pro 版本本身能力已足够强，Chat 模式在多数场景下准确性完全可以满足要求。
• 兼容性问题：目前 LangChain 框架对思考模式的支持尚不成熟，开启后可能引发意料之外的异常。

通用方式 vs 具体模型类

LangChain 除通用的 init_chat_model 外，还提供了 ChatDeepSeek、ChatOpenAI 等厂商专属模型类。优先推荐通用方式——它兼容所有主流厂商，代码迁移成本极低；仅在使用自定义模型或某模型不被通用方式支持的情况下，才考虑使用具体模型类。

调用模型与四类消息类型

初始化完成后，通过 invoke 方法即可发起调用：

response = deepseek_llm.invoke("请介绍一下自己")
print(response)
print(type(response))

返回内容默认为 Markdown 格式，直接 print 可读性有限，但配合前端 Markdown 渲染效果极佳——这也是后续 Web 项目会重点演示的能力。

返回对象的类型是 AIMessage。理解 LangChain 的消息体系，是从"调用大模型"迈向"构建 Agent"的关键一步。langchain_core.messages 下主要有四类消息：

• SystemMessage：系统提示词，用于设定模型角色与行为边界
• HumanMessage：用户输入，调用时框架会自动将字符串包装为 HumanMessage
• AIMessage：模型返回的回复内容
• ToolMessage：工具调用返回的结果，是后续 Agent 开发的核心消息类型

背景：LangChain消息类型与OpenAI消息格式的渊源 LangChain的四类消息并非凭空设计，而是对OpenAI Chat Completions API消息格式的抽象封装。OpenAI API中定义了system、user、assistant、tool四种role，与LangChain的四类消息一一对应。这套格式后来成为事实标准，几乎所有主流大模型（包括Anthropic Claude、Google Gemini、DeepSeek、Qwen等）都兼容这一消息结构。LangChain在此基础上提供了面向对象的Python类封装，使开发者可以用强类型方式组织对话上下文，同时框架在调用不同厂商API时自动完成格式转换，屏蔽了底层差异。

掌握这四类消息的语义与使用场景，是构建任何 LangChain 应用的基础。

从大模型到Agent：核心差异与下一步

本系列教程的重心是 Agent 智能体开发。大模型解决的是"会不会说"的问题——基于训练数据做概率推理；而 Agent 在此基础上叠加了工具调用、记忆管理、多步规划等能力，让 AI 真正能够完成具体业务任务。

简单来说：大模型负责"思考"，Agent 负责"做事"。

背景：Agent智能体的架构演进 Agent（智能体）的概念源于AI研究中的"自主决策实体"，在大模型时代被重新定义。当前主流的LLM Agent架构遵循"ReAct"范式（Reasoning + Acting），由DeepMind于2022年提出：模型交替进行"思考（Thought）→行动（Action）→观察（Observation）"的循环，直至完成目标任务。LangGraph是LangChain团队针对复杂Agent场景推出的图计算框架，将Agent的工作流建模为有向图（节点为处理步骤，边为状态流转条件），支持循环、条件分支、并行执行等复杂控制流，相比早期的线性Chain更适合构建多步、多工具协作的生产级Agent系统。

理解了大模型的三大局限，以及 LangChain 如何通过统一接口与模块化架构来补足这些短板，就为后续的 Agent 实战与 RAG 检索增强项目打下了坚实基础。对于希望入门 AI 应用开发的工程师而言，熟练掌握 init_chat_model 的使用方式和四类 Message 的语义，是绕不开的第一课。

核心要点