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 的核心设计哲学可以用一句话概括：将 LLM 应用中的每一个"可变点"抽象为可替换的组件，并通过统一的 Runnable 协议将它们组合成可执行的管道。这里的"可变点"包括：

可变点	传统方式	LangChain 抽象
使用哪个模型？	改 import + 改调用代码	替换 Model 实例，管道其余部分不变
提示词怎么写？	修改字符串常量	修改 Prompt Template，可序列化存储
输出怎么解析？	正则 / json.loads / 手动解析	替换 Output Parser
多个步骤怎么串联？	if-else + 临时变量传递	LCEL 管道 `