LangChain 1.3实战入门：大模型与Agent核心解析

为什么现在必须学习 LangChain

随着大模型技术在企业级应用中快速落地，招聘市场对相关技能的要求也在悄然变化。据这门 LangChain 1.3 教程的讲师观察，如今几乎所有涉及 AI 的岗位——无论是数据分析、测试还是前端方向——都开始要求候选人掌握大模型开发能力，其中以 LangChain / LangGraph 生态的需求最为突出。

对于有工作经验但久未关注新技术的开发者来说，看到招聘要求中的这些陌生名词往往望而却步。但讲师明确指出：LangChain 本质上只是一个框架，并没有想象中那么难。它的核心目标很简单——帮助开发者更方便地构建 AI 应用。

框架背景：LangChain 由 Harrison Chase 于 2022 年 10 月创立，最初以开源项目形式发布在 GitHub 上，短短数月内即成为增长最快的开源项目之一。其诞生背景恰逢 ChatGPT 引发的 AI 应用爆发期——开发者普遍面临「有了大模型 API，却不知道如何系统构建生产级应用」的困境。LangChain 正是为填补这一工程化空白而生，从 0.x 时代的快速迭代到 1.0 正式版的架构稳定，框架经历了多次重大重构，API 设计趋于成熟。值得一提的是，LangChain 的成功也催生了整个 AI 应用框架赛道的繁荣——LlamaIndex、Haystack、AutoGen 等框架相继涌现，但 LangChain 凭借先发优势与持续迭代，始终保持着最高的社区活跃度与企业采用率。

说个细节，目前 B 站及各类网站上流传的 LangChain 教程大多基于 0.x 旧版本（如 0.2、0.6、0.8）。讲师强调，1.0 之前的版本已基本不再使用，学习意义有限。本课程完全基于最新的 1.3 版本 展开，也是当前 LangChain 的最新稳定版本。

---

从 Harness 架构看 LangChain 的技术定位

要理解 LangChain 在整个技术栈中的位置，需要先了解一个在招聘市场频繁出现的概念——Harness 架构。

Harness、DeepAgent 与 LangGraph 的关系

Harness 架构（Agent Harness）是 AI 工程领域新兴的系统设计范式，核心思想是为 LLM 提供一套「脚手架」，使其能够突破单次推理的局限，执行多步骤、跨工具的复杂任务。其关键组成包括：上下文窗口管理（动态裁剪与压缩长对话）、工具注册与路由（让模型知道何时调用哪个 API）、执行状态追踪（记录多步任务的中间结果）、以及错误恢复机制。

Harness 架构的工程演进背景：Harness 架构代表了 AI 工程从「单次推理」向「持续执行」的范式跃迁，其技术内涵远比字面含义丰富。在上下文窗口管理层面，现代 Harness 实现通常采用动态截断（保留最近 N 轮对话）、摘要压缩（将历史对话提炼为结构化摘要）和选择性检索（基于语义相似度召回相关历史片段）三种策略的组合。在工具路由层面，早期实现依赖硬编码的 if-else 规则，而现代实现则训练模型通过 Function Calling 自主判断工具调用时机，这要求模型具备「元认知」能力——知道自己「不知道」什么，并据此决定是否需要借助外部工具。执行状态追踪则借鉴了分布式系统中的 Saga 模式，将长流程任务分解为若干原子步骤，每步成功后提交状态快照，失败时可从最近检查点恢复，而非从头重试。类比于操作系统对进程的管理，Harness 架构对 LLM 的推理过程进行了系统级封装，使其从「计算器」升级为「工作流引擎」。具体到技术实现，Harness 涵盖上下文管理、工具管理、执行状态管理、上下文压缩以及提示词工程等一整套机制。值得关注的是，Harness 架构的成熟不仅推动了 Agent 系统的工程化进步，也深刻影响了大模型底层能力的演进方向——工具调用（Function Calling）、结构化输出（Structured Output）等能力正是模型厂商为配合 Harness 架构需求而专项强化的推理特性。DeepAgent 正是这种架构思想的一种企业级具体实现，将这些能力封装为可复用的组件，大幅降低了 Agent 系统的开发门槛。

讲师梳理了它们之间的依赖链条：

• DeepAgent 是 LangGraph 生态内部高度封装的组件；
• 它基于 大模型（LLM）+ Agent 构建；
• Agent 的底层本质上是一种 LangGraph（graph tool） 的实现。

LangGraph 深度解析：LangGraph 是 LangChain 团队于 2024 年推出的状态机与图执行框架，其核心数据结构是有向无环图（DAG）或带条件边的有状态图（Stateful Graph）。与传统的链式（Chain）调用不同，LangGraph 允许节点之间存在条件分支、循环和并行执行路径，这使得复杂 Agent 的「思考—行动—观察」循环得以优雅建模。每个节点代表一个处理单元（如 LLM 调用、工具执行），边上可附加条件函数决定流转路径。从工程实现角度看，LangGraph 的「状态（State）」概念是其区别于其他框架的核心设计：每次节点执行后，状态对象会被更新并传递给下游节点，整个图的执行过程本质上是对共享状态的一系列有序变换。这种设计天然支持多 Agent 协作场景——不同专业化 Agent（如搜索 Agent、代码执行 Agent、汇总 Agent）可以作为图中的不同节点，共享同一状态空间并相互传递中间结果，构建出远比单一 Agent 更强大的多智能体系统。LangGraph 对 ReAct（Reasoning + Acting）、Plan-and-Execute 等主流 Agent 架构模式提供原生支持——ReAct 由普林斯顿大学与谷歌联合提出，通过交替生成推理轨迹（Reasoning Trace）和行动指令（Action），让模型在动态环境中实现更可靠的任务执行。此外，LangGraph 完整的**状态持久化（State Persistence）**能力通过 Checkpointer 组件将图执行状态写入数据库（支持内存、SQLite、PostgreSQL 等后端），不仅支持 HITL 中的状态恢复，还为 Agent 的时间旅行调试（Time Travel Debugging）提供了基础设施。这也是 DeepAgent 选择以其为底层的根本原因。

这也回应了社区中"LangGraph 是否过时"的争论。讲师认为这种说法过于片面：虽然 LangGraph 中的工作流（workflow）部分使用频率有所降低，但作为 DeepAgent 和 Agent 的底层支撑，LangGraph 依然是绕不开的核心组件。

---

大模型的三大局限与框架的价值

课程以大模型（LLM）本身为切入点，再延伸至 Agent 开发。讲师特别强调：学习大模型应用开发，并不等于研究算法原理。企业真正需要的是利用大模型的现成能力服务业务、构建 AI 应用，而非从零训练模型。

大模型的三个固有局限

大模型的三大局限并非设计缺陷，而是其训练范式的必然产物。讲师用通俗的方式总结了以下三大核心限制：

1. 知识截止时间：模型只掌握训练时间点之前的互联网知识，对此后发生的事件一无所知。这源于预训练的静态本质——模型参数在训练完成后即被冻结，无法自动更新。值得注意的是，即便是知识截止日期之内的信息，模型也存在「长尾知识遗忘」问题：训练语料中低频出现的专业领域知识往往被高频的通用知识所稀释，导致模型在小众领域的表现远不如其在通用问答上的表现——这也是企业级 RAG 应用大行其道的深层原因之一。

2. 没有记忆能力：模型本身不存储对话历史。你告诉它"我叫张三"，下一轮对话它并不记得。这一局限根植于 Transformer 架构的无状态设计——该架构由 Google 团队于 2017 年在论文《Attention Is All You Need》中提出，其自注意力机制（Self-Attention）在推理阶段表现为纯函数映射：给定输入 token 序列，输出概率分布，不保留任何跨调用的内部状态。这与 RNN/LSTM 等循环网络存在隐状态（Hidden State）传递的机制有本质区别。因此，历史对话必须由外部系统显式注入上下文窗口——我们现在看到的"记忆"效果，都是由应用层自行管理和维护的，这也是 LangChain Memory 模块存在的根本工程动因。在工程实践中，记忆管理通常分为两类：短期记忆（将近期对话历史直接拼入 Prompt）和长期记忆（将关键信息持久化到向量数据库或结构化存储，按需检索召回），二者各有适用场景，LangChain 对两种模式均提供了成熟的模块化支持。

3. 无法主动获取外部数据：模型本身是纯粹的函数映射（输入 → 输出），没有网络 I/O 能力。要让模型服务于具体业务，必须通过**绑定工具（Tools）**的方式，让它获取训练数据之外的额外知识。这一机制在技术层面通过「函数调用（Function Calling）」实现——OpenAI 于 2023 年在 GPT-3.5/4 中率先引入这一能力，允许模型在推理时输出结构化的工具调用请求（包含工具名称与参数），由外部系统执行后将结果返回模型，形成完整的「模型推理→工具执行→结果注入」闭环。值得关注的是，Function Calling 能力的引入不仅是一个工程接口层面的创新，更深刻改变了模型的训练方式——主流大模型厂商会专门收集工具调用场景的高质量数据进行指令微调（Instruction Fine-tuning），使模型能够准确判断「何时需要调用工具」「调用哪个工具」以及「如何正确构造参数」，这三项判断能力的优劣直接决定了 Agent 系统在复杂任务中的可靠性。

这三大局限共同指向同一个工程解法：在模型外部构建「记忆层 + 工具层 + 编排层」。正是这三大局限，催生了以 LangChain 为代表的 AI 应用开发框架。这些框架系统性地解决了记忆管理、工具调用、上下文与状态维护等问题，让开发者无需重复造轮子。

---

LangChain 框架的核心特点

作为最早一批成熟的 AI 应用开发框架，LangChain 在生态完整度和企业普及率上占据明显优势。类似框架还有 Claude SDK、OpenAI SDK 等，但 LangChain 在企业中的采用率最高。

为什么选择 Python 而非 Java

讲师针对这一高频疑问给出了两点关键理由：

• 私有化部署的刚性需求：大模型私有化部署必须依赖 Python 生态。以 vLLM 为例——这是加州大学伯克利分校开源的高性能 LLM 推理框架，其创新的 PagedAttention 内存管理机制借鉴了操作系统虚拟内存分页管理的思想，将 KV Cache（Key-Value 缓存，即 Transformer 注意力机制在推理时产生的中间计算结果）从连续内存块改为分页管理，从根本上解决了显存碎片化问题。值得补充的是，vLLM 的 PagedAttention 还支持 Prefix Cache 共享——当多个并发请求使用相同的系统提示词时，对应的 KV Cache 只需计算一次即可复用，大幅降低首 Token 延迟（TTFT）。在 vLLM 之上，企业通常还会叠加 Triton Inference Server 或 Ray Serve 等分布式框架，构建支持水平扩展的生产级推理集群。这一创新使得同一块 GPU 可以同时服务更多并发请求，相比原生推理可提升 20 倍以上的吞吐量，已成为企业私有化部署的事实标准。除 vLLM 外，Python 生态还涵盖了 Ollama（本地模型快速部署）、TGI（Text Generation Inference，HuggingFace 出品的生产级推理服务）等工具链，共同构成了从模型下载、量化压缩到服务化部署的完整闭环。整个部署链路完全依托 Python 生态，Java 生态目前缺乏对应工具。
• 生态先发优势：LangChain 出现最早，几乎所有新推出的大模型 API 都会优先支持 LangChain / LangGraph 生态。

数据显示，90% 以上的公司在大模型开发中使用 Python，语言选型无需纠结。

LangChain 的两大核心能力

LangChain 框架主要提供以下两方面价值：

统一的模型接口：过去调用不同厂商的大模型需要适配各自独立的接口，每换一个模型就要改一次代码。LangChain 通过统一接口屏蔽底层差异，开发者只需替换模型名称（如切换到 DeepSeek），上层代码无需任何改动。这一设计思路与软件工程中的「适配器模式（Adapter Pattern）」高度契合——通过引入抽象层，将具体实现与业务逻辑解耦，使得技术选型的切换成本趋近于零。在大模型供应商竞争激烈、能力快速迭代的当下，这种灵活性对企业级应用尤为关键。从更宏观的视角看，统一接口的意义不仅在于降低切换成本，更在于为企业构建「模型中立」的技术架构：当某家厂商的模型出现服务中断、价格上涨或能力退化时，企业可以在数分钟内完成模型切换，而非陷入数周的重构工期，这对于以 AI 为核心竞争力的业务而言是不可忽视的风险对冲能力。

模块化架构：LangChain 将状态、上下文、历史消息、工具调用、提示词、中间件等能力拆分为独立模块。Agent、工具调用、记忆管理等在这套模块化体系中各司其职，极大降低了开发复杂度。自 1.0 版本起，LangChain 引入了 LCEL（LangChain Expression Language） 作为核心的链式组合语法，通过管道操作符（|）将各模块串联。LCEL 的设计哲学深受函数式编程范式影响，其管道操作符的语义等价于函数组合（a | b | c 等价于 c(b(a(x)))）。这种声明式组合方式带来了若干工程优势：所有通过 LCEL 构建的链自动获得流式输出能力（上游产出第一个 Token 时下游即可开始处理）、内置 async/await 支持（单链可在 asyncio 事件循环中并发处理多个请求）、以及 batch() 方法的并行批处理能力。LCEL 中每个组件都实现了统一的 Runnable 接口（包含 invoke、stream、batch、astream 等标准方法），自定义函数只需包装为 RunnableLambda 即可无缝嵌入管道，极大降低了框架的扩展成本。这既保留了 Python 的直观性，又实现了流式输出、异步执行、批量处理等高级特性的开箱即用。

---

LangChain 学习路径与内容体系

从课程规划来看，LangChain 部分已系统覆盖八大核心模块：环境配置、Model 模型调用、智能体（Agent）、短期记忆、长期记忆、人机协同（Human-in-the-loop / HITL）、安全护栏（Guardrails），以及 Runtime 上下文管理。配套笔记已达 284 页。

其中，人机协同（HITL） 和安全护栏是面试高频考点。HITL 是生产级 Agent 系统的关键安全机制，解决的核心问题是「如何在 AI 自主执行高风险操作前引入人工审批」。在 LangGraph 的实现中，HITL 通过「中断点（Breakpoint）」机制实现：开发者可在图的任意节点前后插入中断，Agent 执行到该节点时会暂停并将当前状态序列化持久化，等待人工确认后再恢复执行。这一机制的背后，是 LangGraph 完整的**状态持久化（State Persistence）**能力——通过 Checkpointer 组件将图的执行状态写入数据库（支持内存、SQLite、PostgreSQL 等后端），不仅支持 HITL 中的状态恢复，还为 Agent 的时间旅行调试（Time Travel Debugging，即回溯到历史任意节点重新执行）提供了基础设施。常见介入类型包括内容审核介入、工具调用授权、敏感数据访问确认等——这也是区分玩具级与生产级 Agent 系统的核心特征。面试中涉及的实操问题包括如何实现人工介入、有哪些介入类型、如何管理 Agent 上下文等。

安全护栏（Guardrails） 是另一个在生产环境中不可或缺的模块，其核心职责是在模型输入与输出两侧建立内容过滤与行为约束机制。输入侧护栏负责识别并拦截越狱攻击（Jailbreak）、提示词注入（Prompt Injection）等恶意输入；输出侧护栏则对模型生成内容进行事实性核查、有害内容过滤和格式合规检验。在工程实现上，Guardrails 通常以中间件形式嵌入请求处理链路，可基于规则引擎（正则匹配、关键词过滤）或另一个轻量级 LLM 实现——后者即所谓的「LLM-as-Judge」模式，以小模型评估大模型输出质量，在性能与成本之间取得平衡。

后续课程还将更新 MCP、**RAG（检索增强生成）**以及系统化的 LangGraph 内容。

MCP（Model Context Protocol，模型上下文协议） 是 Anthropic 于 2024 年 11 月开源的标准化协议，旨在解决 AI 模型与外部工具/数据源集成的碎片化问题。其设计理念类似于编程语言的 LSP（Language Server Protocol）——通过统一协议规范，让任意 AI 模型能够与任意符合标准的工具服务器通信，无需为每个工具单独编写适配代码。MCP 定义了资源（Resources）、工具（Tools）和提示模板（Prompts）三类原语，采用 JSON-RPC 2.0 作为传输层协议。从架构上看，MCP 将「工具能力的提供者」与「工具能力的消费者」彻底解耦：MCP Server 负责暴露工具能力，MCP Client（通常是 AI 应用）负责发现与调用，二者之间仅通过标准协议通信。这一分层设计带来了显著的生态效应：工具开发者只需实现一次 MCP Server，便可被所有支持 MCP 的 AI 产品直接调用，彻底消除了此前「每个 AI 产品都要为同一工具单独开发插件」的重复劳动。值得补充的是，MCP 在传输层支持 stdio（进程间通信）和 SSE（Server-Sent Events，用于远程服务）两种模式，前者适合本地工具集成，后者适合云端服务暴露，这种双模式设计使其能够覆盖从本地 IDE 插件到云端 SaaS 工具的全场景需求。随着 Claude、Cursor、Windsurf 等主流 AI 产品相继宣布支持，MCP 正逐渐成为 Agent 工具调用领域的事实标准，LangChain 也已在 1.x 版本中提供了原生的 MCP 集成支持。

RAG（检索增强生成） 是解决大模型知识局限性最主流的工程方案，由 Meta AI 于 2020 年论文中正式提出，其核心思想是将参数化知识（模型权重中固化的信息）与非参数化知识（外部可检索数据库）相结合。工程实现上分为两个阶段：索引阶段（Indexing）将企业文档经过分块（Chunking）、向量化（Embedding）后存入向量数据库；检索生成阶段（Retrieval & Generation）在用户提问时执行语义近似检索，召回最相关的文档片段拼入 Prompt，引导模型基于真实资料作答。

RAG 工程深度：RAG 的工程挑战远不止「检索+生成」这两步。在实际落地中，分块策略（固定长度 vs 语义边界切分）、Embedding 模型选型（OpenAI text-embedding-3 系列 vs BGE-M3 等本地模型）、检索召回率优化（稠密检索 + 稀疏检索的混合检索方案、基于交叉编码器的重排序 Reranker）、以及上下文压缩（避免超出 Token 上限的同时保留关键信息）共同构成了 RAG 质量的决定性因素。当前工程实践中还涌现出 Advanced RAG 和 Modular RAG 等进阶范式：前者通过查询改写（Query Rewriting）、假设文档嵌入（HyDE，Hypothetical Document Embeddings——先让模型生成一段「假设性答案」，再以该答案的向量去检索真实文档，能显著提升语义匹配精度）等预检索策略大幅提升召回质量；后者将 RAG 流水线拆解为可自由组合的功能模块，允许根据业务场景灵活搭配检索策略。在向量数据库选型上，当前主流方案各有侧重：Faiss 专注高性能本地检索（Facebook AI 出品，支持十亿级向量的高效相似度搜索）、Chroma 适合开发调试（轻量嵌入式部署，API 设计对 LangChain 原生友好）、Pinecone 提供托管云服务（免运维，适合快速上线）、Weaviate 支持混合搜索（向量检索与关键词检索融合，适合对召回率要求极高的场景）。LangChain 为 RAG 全链路（DocumentLoader、TextSplitter、VectorStore、Retriever 等组件）提供了开箱即用的标准化实现，LCEL 的管道语法使得整个 RAG 流水线可以用数十行代码完成声明式组装，是学习 RAG 工程化实践的首选框架。

对于初学者而言，LangChain 的应用场景几乎覆盖了所有"AI + 业务"的落地需求——只要是能与 AI 结合的业务场景，基本都可以用 LangChain 来实现。这也正是它值得深入学习的根本原因。

---

核心要点