【LangChain系列】 零基础入门实战：从环境搭建到 LCEL 链式完整 Demo 详解

可涵不会debug2026-07-28 11:06

前言：

之前学习了关于LangChain的基础知识入门，下面我们就开始上手写一些简单的代码！~

我们做一个LangChain最简单的demo~

我们先做一下前置环境准备工作

1、申请openAI的API keys

然后点击create new secret key,注意这里选择all

2、配置电脑的环境变量 API_KEY

我们首先打开电脑系统自带的环境变量

注意在环境变量里面创建的变量名必须都是大写并且有下标线，这是固定的，不能变！

TIP：

注意如果我们先打开编译器，再配置的环境变量，需要我们重启一下编译器，这样环境变量才会生效。

3、 安装所需要大模型的包

python 复制代码 
pip install -U langchain-openai

显示这个就代表已经安装成功了

下面是真正的demo环节~

1. 定义OpenAI模型

代码：

python 复制代码 
# 默认从系统环境变量中读取 OPENAI_API_KEY
model = ChatOpenAI(model="gpt-5-mini",
                   api_key="sk-DNsxaP1T5VAVYGQucVtDpTNQMskzCLMB8i",
                   base_url="https://api.fe8.cn/v1")

我们之前已经在系统的环境变量中定义过了，所以这里的api_key这个变量我们可以不填，系统会默认读取我们之前定义的。

base_url是什么含义，我这里使用的是中转代理

本质：第三方 API 中转代理（API 中转站）

因为OpenAI 官方接口 api.openai.com 国内无法直连、且需要境外信用卡充值；所以我们就需要使用国内的中转站进行调用。api.fe8.cn 是国内兼容 OpenAI 协议的中转平台：

  • 你发给 api.fe8.cn 的请求，它会转发到 OpenAI 官方服务器
  • 中转平台提供国内可访问网络、支付宝 / 微信充值、现成 sk- 密钥
  • 协议完全兼容 OpenAI，代码几乎不用改动，只替换 base_url + api_key

2、定义消息列表

代码：

python 复制代码 
# 2. 定义消息
# 用户消息 HumanMessage
# 系统提示消息 SystemMessage  通常作为第一条消息传入
# AI 消息 AIMessage
messages = [
    SystemMessage(content="请帮我进行翻译，由英文翻译成中文！"),
    HumanMessage(content="my name is xiaoming")
]

参数说明：

  • SystemMessage:表示系统角色消息，系统消息通常作为输入消息序列中的第一条传入，是用来启动AI行为的消息。给模型下达全局指令、设定角色、约束输出规则，整轮对话全程生效。
  • HumanMessage:表示用户角色消息，是来自用户的、从用户传递到模型的消息。代表人类用户输入的提问 / 文本，每一轮用户输入都用它包裹。

3.调用大模型

model是LangChain Runnable (可运行)接口的实例，这意味着model提供了一个标准接口供

我们与之交互。要简单地调用模型，我们可以将消息列表传递给.invoke方法。下面是代码：

python 复制代码 
result = model.invoke(messages)
print(result)

没有问题，调用成功！

输出结果：

bash 复制代码 
content='你好!' additional_kwargs={'refusal': None} response_metadata=
{'token_usage': {'completion_tokens': 2, 'prompt_tokens': 20, 'total_tokens':
22, 'completion_tokens_details': {'accepted_prediction_tokens': 0,
'audio_tokens': 0, 'reasoning_tokens': 0, 'rejected_prediction_tokens': 0},
'prompt_tokens_details': {'audio_tokens': 0, 'cached_tokens': 0}},
'model_name': 'gpt-5-mini-2024-07-18', 'system_fingerprint': 'fp_560af6e559',
'id': 'chatcmpl-C5l29mi6KkQSFO3qaElDJD5Lj9nBn', 'service_tier': 'default',
'finish_reason': 'stop', 'logprobs': None} id='run--777ef0be-55c2-411a-a4ab-
104a45c22f20-0' usage_metadata={'input_tokens': 20, 'output_tokens': 2,
'total_tokens': 22, 'input_token_details': {'audio': 0, 'cache_read': 0},
'output_token_details': {'audio': 0, 'reasoning': 0}}

输出说明：

1. 核心文本

content='你好!'

模型真正输出的回答内容，也就是你需要的文本。

如果不用 StrOutputParser，你需要手动取 .content 才能拿到字符串。

2.additional_kwargs 附加返回信息

additional_kwargs={'refusal': None}

refusal：拒绝标识，如果模型因安全策略拒绝回答，这里会填充拒绝理由；None 代表正常输出，无拦截。中转 / 官方模型额外返回的扩展字段都会存在这里。

3.

  • response_metadata 模型接口返回元数据（OpenAI 原生返回）
  • token_usage 消耗计费统计
  • prompt_tokens:20：输入提示词总 token（system + 用户提问）
  • completion_tokens:2：模型生成回答消耗 token
  • total_tokens:22：本轮总计费 token = 输入 + 输出
  • completion_tokens_details：生成细分 token
  • reasoning_tokens=0：无深度思考推理 token（非思考类模型）
  • audio_tokens=0：没有音频输入输出
  • prompt_tokens_details：输入细分
  • cached_tokens=0：没有命中缓存 token，全额计费

4.输出解析

若只想输出聊天模型返回的结果字符串，可以使用StrOutputParser输出解析器组件，将大模型

输出结果解析为最可能的字符串。核心代码：

python 复制代码 
# 定义str字符串输出解析器
from langchain_core.output_parsers import StrOutputParser
parser = StrOutputParser()
print(parser.invoke(result))

这样输出结果就只有一行字符串了！

这里我们调用解释器之后，就只输出了一个content

5、链式执行（重要）

但这样并没有体现出链式执行，那如何体现呢？

通过上述步骤，无论是调用大模型，还是输出解析，我们发现，每次都调用了一个invoke()方法，最终才会得到我们想要的结果。

对于LangChain，它给我们提供了链式执行的能力，即我们只需要定义各个"组件"，将它们"链起
来"，一次性执行即可得到最终效果。

提问：链式体现在哪里？（核心重点）

不使用链的原始写法（分步执行）

复制代码 
# 第一步：调用模型
result = model.invoke(messages)
# 第二步：手动解析输出
text = parser.invoke(result)
print(text)

逻辑拆分：

  1. 输入 messages → 交给 model 处理，输出 AIMessage 对象
  2. 把 model 的输出，手动传给 parser 做二次处理

使用链的写法（合并两步）

复制代码 
chain = model | parser
print(chain.invoke(messages))

| 管道符就是链式核心：

  • 左边组件的输出，自动作为右边组件的输入；
  • 不需要手动接收中间变量 result，流程自动串联；
  • 整个 chain 仍然是一个 Runnable，对外只暴露一个 invoke() 入口。

我感觉这里和Linux命令里面的管道符有异曲同工之妙。

两者设计思想一模一样：把上一步产出交给下一步消费，消除中间临时变量。

  • Linux 管道：操作系统层面的文本数据流流水线；
  • LangChain |：Python 业务代码层面的组件调用流水线。

注意链的结点不要写反了，类似于单链表，需要把前面的执行完毕的结果再传给下一个结点，环环相扣，缺一不可，并且顺序是固定的，默认就是从左到右。

源码

python 复制代码 
from langchain_core.messages import HumanMessage, SystemMessage
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnableSequence
from langchain_openai import ChatOpenAI

# 1. 定义OpenAI模型
# 默认从系统环境变量中读取 OPENAI_API_KEY
model = ChatOpenAI(model="gpt-4o-mini")

# 2. 定义消息
# 用户消息 HumanMessage
# 系统提示消息 SystemMessage  通常作为第一条消息传入
# AI 消息 AIMessage
messages = [
    SystemMessage(content="请帮我进行翻译，由英文翻译成中文！"),
    HumanMessage(content="my name is xiaoming")
]

# 3. 调用大模型
# result = model.invoke(messages)
# print(result)

# 链式体现在哪里？？？

# 4. 定义输出解析器组件
parser = StrOutputParser()
# print(parser.invoke(result))

# 5. 定义链
# 执行链
chain = model | parser
# chain = RunnableSequence(first=model, last=parser)
# chain = model.pipe(parser)
print(chain.invoke(messages))

博主的一些问题：

python 复制代码 
chain = model | parser
chain = model | messages | parser

为什么第二种写法是错的

解析：

chain = model | messages | parser 链式逻辑完全不成立

先记住一条铁律：

| 管道两边只能放 Runnable 组件（model、parser、prompt、工具等），messages 只是普通 Python 列表 [SystemMessage, HumanMessage]，不是 Runnable，不能塞进管道中间。

管道执行逻辑拆解

A | B | C 的执行流程：

  1. 输入 → A.invoke (输入) → 输出 A
  2. 输出 A → B.invoke (输出 A) → 输出 B
  3. 输出 B → C.invoke (输出 B) → 最终结果

前置知识：

什么是Runnable 什么是LCEL 这两者关系

1. 分别定义

Runnable（底层统一接口规范）

Runnable 是 LangChain 定义的标准化抽象接口，所有可执行组件都必须实现它。

核心约定

只要是 Runnable 对象，必须拥有三套统一执行方法：

  • invoke(input)：同步一次性执行
  • stream(input)：流式分段输出
  • ainvoke(input)：异步执行

同时重载了 | 运算符，支持管道拼接。

哪些是 Runnable？

ChatOpenAI、StrOutputParser、提示模板、检索器、工具、用 | 拼接出来的整条链，全部属于 Runnable。

LCEL（LangChain Expression Language，上层编排语法）

LCEL 是一套基于 Runnable 接口的流水线组装语法 ，专门用来把多个 Runnable 拼接成完整业务流程。核心语法：管道符 |

复制代码 
chain = prompt | model | parser

作用：自动把前一个 Runnable 的输出，传给下一个 Runnable 作为输入，省去手动接收中间变量。

2. 两者核心关系

① Runnable 是 LCEL 的底层基础（没有 Runnable 就没有 LCEL）

  1. LCEL 的 | 管道，本质调用 Runnable 内部重载的 __or__ 方法；
  2. 只有实现 Runnable 的对象，才能放在管道左右参与拼接；普通数据（list、字符串、数字）不是 Runnable，不能写在 | 中间；
  3. 管道自动流转数据的逻辑，依赖所有组件统一的 invoke/stream/ainvoke 方法。

举个反例：

复制代码 
# 报错，messages 是列表，不是 Runnable
chain = model | messages | parser

② LCEL 是 Runnable 的组合工具

单个 Runnable 只能完成单一任务（模型调用、解析文本）；LCEL 提供语法把多个 Runnable 串联 / 并行组合，生成一条新的 Runnable（RunnableSequence）。

拼接后的链依然是 Runnable：

python 复制代码 
chain = model | parser
# chain 本身也是 Runnable，可继续拼接更长链路
chain2 = chain | 其他解析器

③ 层级关系

plaintext

bash 复制代码 
底层：Runnable 统一接口（规定执行方法、管道运算符）
   ↓
上层：LCEL 表达式语法（利用接口实现组件流水线编排）

3. 一句话总结

  1. Runnable：统一标准，规定所有组件怎么运行、怎么拼接；
  2. LCEL：利用这套标准，提供简洁管道语法组装流水线；
  3. 依存关系：LCEL 完全依赖 Runnable 接口才能生效。
相关推荐
tedcloud1231 小时前
Orca 部署指南：开源 AI 推理服务的 Linux 部署实践
linux·运维·服务器·人工智能·开源·自动化·excel
phltxy2 小时前
LangChain_Agent中间件实战
人工智能·python·深度学习·语言模型·中间件·langchain
xian_wwq2 小时前
【学习笔记】框架层坍缩——LangChain 们正在被重新定义-14/15
笔记·学习·langchain
公众号:fuwuqiBMC2 小时前
(转自“服务器BMC”)服务器BMC芯片——AST2800
运维·服务器
HiDev_2 小时前
【非标自动化】2、认识元器件（流量传感器）
运维·自动化
xlq223222 小时前
高并发服务器day8（含服务器完整架构）
运维·服务器·php
梦想三三2 小时前
LangChain模型调用与多轮对话完整实战
阿里云·langchain·大模型·api
mapengfei2 小时前
LangChain学习背景
langchain·llm
Shell运维手记3 小时前
交换机（二层交换机）完整工作原理
运维·网络·网络协议·macos·交换机
热门推荐
01GitHub 镜像站点02如何新建文件夹？ 电脑新建文件夹的4种方法032026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片04AI科技热点日报 | 2026年07月01日05国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）06AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路072026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？082026 年 AI 大模型 & AI 编程工具实战全总结09微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新10幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南