LangChain 快速入门：从 Hello World 到第一个 Chain目录前言技术背景与演进逻辑2.1 第一阶段：裸 API 调用的蛮荒时代2.2 第二阶段：Provider SDK 的局部改善2.3 第三阶段：应用框架的统一抽象核心原理深度解析3.1 LangChain 四层架构全景图3.2 Runnable 协议：框架的宪法3.3 为什么 LCEL 选择管道语法核心模块详解4.1 环境搭建：从零开始的工程化配置4.2 Chat Model：统一的大语言模型接口4.3 Prompt Template：提示词的工程化管理4.4 Output Parser：从模型输出到业务数据4.5 LCEL 管道：组装你的第一个 Chain技术优缺点与适用场景实战落地全文总结下篇预告本期专栏更新说明参考资料前言核心痛点：2023 年以来，大语言模型（LLM）的能力以令人目眩的速度进化——GPT-4、Claude、Gemini 等旗舰模型在推理、代码生成、多模态理解等维度不断刷新上限。然而，当开发者试图将这些能力集成到实际应用中时，一个尴尬的现实浮现了：调用一次 API 只需 5 行代码，但构建一个可维护、可扩展的 LLM 应用却要面对成百上千行散落的胶水代码。提示词硬编码在字符串里、模型参数散落在各处、输出解析靠正则表达式硬扛——这些"能跑通"的代码在需求变更时脆弱得像纸牌屋。LangChain 的诞生，正是为了回答一个根本性问题：当 LLM 从"玩具"变成"基础设施"，我们用什么工程方法来驾驭它？适配人群：具备 Python 3.10+ 基础，已经用openaiSDK 或 REST API 调用过至少一个 LLM 服务（OpenAI / Anthropic / 本地模型均可），但对"如何系统化构建 LLM 应用"感到困惑的开发者。如果你能写出client.chat.completions.create()但不知道如何管理 50 个不同场景的提示词、如何优雅地串联多步推理、如何让团队协作开发 LLM 功能——这篇文章正是为你准备的。前置知识：Python 3.10+（类型注解、f-string、async/await 基础）、LLM API 调用基础（理解 API Key、temperature、token 等概念）、命令行基本操作（创建虚拟环境、pip 安装）。本篇位置：《LangChain/LangGraph 从入门到精通》系列第 1 篇 | 阶段：入门篇收获能力：读完本文，你将跨越"从脚本到工程"的关键门槛——亲手搭建 LangChain 开发环境，理解其四层架构设计和 Runnable 协议的核心思想，掌握 Model / Prompt / Parser / Chain 四大基础抽象的实际用法，学会用 LCEL 管道语法声明式地构建 LLM 处理流，最终交付一个结构清晰、可扩展、可复用的完整 Chain 应用。这是整个系列的地基——后续所有关于 RAG、Agent、LangGraph、生产部署的讨论，都建立在本文的核心概念之上。技术背景与演进逻辑理解一个框架的最佳方式，不是直接看它的 API 文档，而是先理解它解决了什么真实问题。在 LangChain 出现之前，LLM 应用开发经历了两个阵痛期。让我们逐一还原这些阶段的典型代码，感受其中的痛点。2.1 第一阶段：裸 API 调用的蛮荒时代2022 年末到 2023 年初，开发者与 LLM 的交互方式非常原始——直接发送 HTTP 请求，手动拼接 JSON，手动解析响应：# 【第一阶段典型代码】直接调用 OpenAI REST APIimportrequestsimportjson API_KEY="sk-xxxx"# 密钥硬编码在代码中 —— 安全隐患 #1API_URL="https://api.openai.com/v1/completions"defask_llm(prompt_text):"""每次调用都要手动构建 HTTP 请求"""headers={"Authorization":f"Bearer{API_KEY}","Content-Type":"application/json"}payload={"model":"text-davinci-003","prompt":prompt_text,"max_tokens":500,"temperature":0.7}response=requests.post(API_URL,headers=headers,json=payload)# 手动从深层嵌套的 JSON 中提取文本 —— 脆弱点 #2returnresponse.json()["choices"][0]["text"].strip()# 业务代码中散落着提示词字符串 —— 维护噩梦 #3result=ask_llm("将以下文本翻译为法语："+user_input)这段代码能跑。但三个问题从第一天就埋下了：Provider 锁定：切换模型（比如从 OpenAI 换到 Anthropic）意味着重写整个ask_llm函数——请求格式不同、认证方式不同、响应结构不同。提示词即字符串：所有 prompt 以原始字符串形式散落在业务代码中，无法复用、无法测试、无法版本管理。当一个应用有 50 个不同的 prompt 时，寻找和修改它们变成了一场噩梦。零工程化：没有重试机制、没有流式输出、没有错误分类处理。一段网络抖动就能让整个应用崩溃，而调用方浑然不知。2.2 第二阶段：Provider SDK 的局部改善OpenAI 和其他厂商很快发布了官方 Python SDK，封装了 HTTP 细节：# 【第二阶段典型代码】使用 openai SDKfromopenaiimportOpenAI client=OpenAI(api_key="sk-xxxx")defask_gpt(prompt_text):"""SDK 封装了 HTTP，但提示词管理仍然原始"""response=client.chat.completions.create(model="gpt-3.5-turbo",messages=[{"role":"system","content":"你是一个有帮助的助手。"},{"role":"user","content":prompt_text}],temperature=0.7,max_tokens=500)returnresponse.choices[0].message.content开发体验确实提升了——不再手动构建 HTTP 请求和解析 JSON。但两个致命缺陷依然存在：Provider 强绑定：from openai import OpenAI这一行决定了你的整个应用只能使用 OpenAI。想切换到 Anthropic？你需要安装anthropicSDK，修改所有 import，重写消息格式（Anthropic 的 Messages API 与 OpenAI 的 Chat Completions API 在结构上有细微但关键的差异），然后重新测试。这种"换模型=重写代码"的局面在多 Provider 架构中完全不可接受。提示词工程化 = 0：提示词仍然是裸字符串。在一个真实的客服机器人项目中，你可能有 30 个不同场景的 System Prompt（售前咨询、售后投诉、退款流程、物流查询…），每个 prompt 都需要经过产品经理、法务、运营的多轮审核。把这些 prompt 散落在 Python 文件的字符串里，意味着每次修改都要翻代码、担心转义、无法 diff 对比。更重要的是，SDK 解决的是"如何调用"的问题，但没有回答"如何编排"——当你需要将模型调用、数据库查询、外部 API 调用、结果校验串联成一个完整的业务流程时，SDK 帮不了你。2.3 第三阶段：应用框架的统一抽象LangChain 1.0（2025 年发布）标志着一个新的范式。它不再回答"如何调用某个模型"，而是回答**“如何用工程化的方式编排 LLM 能力”**。LangChain 的解决路径传统方式的三大痛点Provider 锁定换模型 = 重写代码提示词散落无法复用/测试/版本管理零编排能力多步骤流程靠 if-else 硬撑Model 抽象层统一 60+ Provider 的调用接口Prompt Template提示词模板化/参数化/可序列化Chain + LCEL声明式管道编排多步骤流程LangChain 的核心设计哲学可以用一句话概括：将 LLM 应用中的每一个"可变点"抽象为可替换的组件，并通过统一的 Runnable 协议将它们组合成可执行的管道。这里的"可变点"包括：可变点传统方式LangChain 抽象使用哪个模型？改 import + 改调用代码替换 Model 实例，管道其余部分不变提示词怎么写？修改字符串常量修改 Prompt Template，可序列化存储输出怎么解析？正则 / json.loads / 手动解析替换 Output Parser多个步骤怎么串联？if-else + 临时变量传递LCEL 管道 `理解了这张表，你就理解了 LangChain 存在的全部理由。核心原理深度解析3.1 LangChain 四层架构全景图LangChain 的架构设计遵循"关注点分离"原则，自底向上分为四个职责清晰的层次：
LangChain 快速入门：从 Hello World 到第一个 Chain
LangChain 快速入门：从 Hello World 到第一个 Chain目录前言技术背景与演进逻辑2.1 第一阶段：裸 API 调用的蛮荒时代2.2 第二阶段：Provider SDK 的局部改善2.3 第三阶段：应用框架的统一抽象核心原理深度解析3.1 LangChain 四层架构全景图3.2 Runnable 协议：框架的宪法3.3 为什么 LCEL 选择管道语法核心模块详解4.1 环境搭建：从零开始的工程化配置4.2 Chat Model：统一的大语言模型接口4.3 Prompt Template：提示词的工程化管理4.4 Output Parser：从模型输出到业务数据4.5 LCEL 管道：组装你的第一个 Chain技术优缺点与适用场景实战落地全文总结下篇预告本期专栏更新说明参考资料前言核心痛点：2023 年以来，大语言模型（LLM）的能力以令人目眩的速度进化——GPT-4、Claude、Gemini 等旗舰模型在推理、代码生成、多模态理解等维度不断刷新上限。然而，当开发者试图将这些能力集成到实际应用中时，一个尴尬的现实浮现了：调用一次 API 只需 5 行代码，但构建一个可维护、可扩展的 LLM 应用却要面对成百上千行散落的胶水代码。提示词硬编码在字符串里、模型参数散落在各处、输出解析靠正则表达式硬扛——这些"能跑通"的代码在需求变更时脆弱得像纸牌屋。LangChain 的诞生，正是为了回答一个根本性问题：当 LLM 从"玩具"变成"基础设施"，我们用什么工程方法来驾驭它？适配人群：具备 Python 3.10+ 基础，已经用openaiSDK 或 REST API 调用过至少一个 LLM 服务（OpenAI / Anthropic / 本地模型均可），但对"如何系统化构建 LLM 应用"感到困惑的开发者。如果你能写出client.chat.completions.create()但不知道如何管理 50 个不同场景的提示词、如何优雅地串联多步推理、如何让团队协作开发 LLM 功能——这篇文章正是为你准备的。前置知识：Python 3.10+（类型注解、f-string、async/await 基础）、LLM API 调用基础（理解 API Key、temperature、token 等概念）、命令行基本操作（创建虚拟环境、pip 安装）。本篇位置：《LangChain/LangGraph 从入门到精通》系列第 1 篇 | 阶段：入门篇收获能力：读完本文，你将跨越"从脚本到工程"的关键门槛——亲手搭建 LangChain 开发环境，理解其四层架构设计和 Runnable 协议的核心思想，掌握 Model / Prompt / Parser / Chain 四大基础抽象的实际用法，学会用 LCEL 管道语法声明式地构建 LLM 处理流，最终交付一个结构清晰、可扩展、可复用的完整 Chain 应用。这是整个系列的地基——后续所有关于 RAG、Agent、LangGraph、生产部署的讨论，都建立在本文的核心概念之上。技术背景与演进逻辑理解一个框架的最佳方式，不是直接看它的 API 文档，而是先理解它解决了什么真实问题。在 LangChain 出现之前，LLM 应用开发经历了两个阵痛期。让我们逐一还原这些阶段的典型代码，感受其中的痛点。2.1 第一阶段：裸 API 调用的蛮荒时代2022 年末到 2023 年初，开发者与 LLM 的交互方式非常原始——直接发送 HTTP 请求，手动拼接 JSON，手动解析响应：# 【第一阶段典型代码】直接调用 OpenAI REST APIimportrequestsimportjson API_KEY="sk-xxxx"# 密钥硬编码在代码中 —— 安全隐患 #1API_URL="https://api.openai.com/v1/completions"defask_llm(prompt_text):"""每次调用都要手动构建 HTTP 请求"""headers={"Authorization":f"Bearer{API_KEY}","Content-Type":"application/json"}payload={"model":"text-davinci-003","prompt":prompt_text,"max_tokens":500,"temperature":0.7}response=requests.post(API_URL,headers=headers,json=payload)# 手动从深层嵌套的 JSON 中提取文本 —— 脆弱点 #2returnresponse.json()["choices"][0]["text"].strip()# 业务代码中散落着提示词字符串 —— 维护噩梦 #3result=ask_llm("将以下文本翻译为法语："+user_input)这段代码能跑。但三个问题从第一天就埋下了：Provider 锁定：切换模型（比如从 OpenAI 换到 Anthropic）意味着重写整个ask_llm函数——请求格式不同、认证方式不同、响应结构不同。提示词即字符串：所有 prompt 以原始字符串形式散落在业务代码中，无法复用、无法测试、无法版本管理。当一个应用有 50 个不同的 prompt 时，寻找和修改它们变成了一场噩梦。零工程化：没有重试机制、没有流式输出、没有错误分类处理。一段网络抖动就能让整个应用崩溃，而调用方浑然不知。2.2 第二阶段：Provider SDK 的局部改善OpenAI 和其他厂商很快发布了官方 Python SDK，封装了 HTTP 细节：# 【第二阶段典型代码】使用 openai SDKfromopenaiimportOpenAI client=OpenAI(api_key="sk-xxxx")defask_gpt(prompt_text):"""SDK 封装了 HTTP，但提示词管理仍然原始"""response=client.chat.completions.create(model="gpt-3.5-turbo",messages=[{"role":"system","content":"你是一个有帮助的助手。"},{"role":"user","content":prompt_text}],temperature=0.7,max_tokens=500)returnresponse.choices[0].message.content开发体验确实提升了——不再手动构建 HTTP 请求和解析 JSON。但两个致命缺陷依然存在：Provider 强绑定：from openai import OpenAI这一行决定了你的整个应用只能使用 OpenAI。想切换到 Anthropic？你需要安装anthropicSDK，修改所有 import，重写消息格式（Anthropic 的 Messages API 与 OpenAI 的 Chat Completions API 在结构上有细微但关键的差异），然后重新测试。这种"换模型=重写代码"的局面在多 Provider 架构中完全不可接受。提示词工程化 = 0：提示词仍然是裸字符串。在一个真实的客服机器人项目中，你可能有 30 个不同场景的 System Prompt（售前咨询、售后投诉、退款流程、物流查询…），每个 prompt 都需要经过产品经理、法务、运营的多轮审核。把这些 prompt 散落在 Python 文件的字符串里，意味着每次修改都要翻代码、担心转义、无法 diff 对比。更重要的是，SDK 解决的是"如何调用"的问题，但没有回答"如何编排"——当你需要将模型调用、数据库查询、外部 API 调用、结果校验串联成一个完整的业务流程时，SDK 帮不了你。2.3 第三阶段：应用框架的统一抽象LangChain 1.0（2025 年发布）标志着一个新的范式。它不再回答"如何调用某个模型"，而是回答**“如何用工程化的方式编排 LLM 能力”**。LangChain 的解决路径传统方式的三大痛点Provider 锁定换模型 = 重写代码提示词散落无法复用/测试/版本管理零编排能力多步骤流程靠 if-else 硬撑Model 抽象层统一 60+ Provider 的调用接口Prompt Template提示词模板化/参数化/可序列化Chain + LCEL声明式管道编排多步骤流程LangChain 的核心设计哲学可以用一句话概括：将 LLM 应用中的每一个"可变点"抽象为可替换的组件，并通过统一的 Runnable 协议将它们组合成可执行的管道。这里的"可变点"包括：可变点传统方式LangChain 抽象使用哪个模型？改 import + 改调用代码替换 Model 实例，管道其余部分不变提示词怎么写？修改字符串常量修改 Prompt Template，可序列化存储输出怎么解析？正则 / json.loads / 手动解析替换 Output Parser多个步骤怎么串联？if-else + 临时变量传递LCEL 管道 `理解了这张表，你就理解了 LangChain 存在的全部理由。核心原理深度解析3.1 LangChain 四层架构全景图LangChain 的架构设计遵循"关注点分离"原则，自底向上分为四个职责清晰的层次：
