LangChain入门：从Model到Agent的完整实践指南

用原生方式调用大模型接口时，每个业务场景都要重复处理请求参数、消息格式、重试、结果解析，更麻烦的是，一旦需要模型自己决定调用哪个函数、按什么顺序执行，代码就变得很难维护。LangChain 恰好是围绕这些问题设计的一套开发框架，它把模型调用、提示词管理、链式编排和工具调用拆成可组合的模块，让开发者把注意力放在业务逻辑上，而不是每次都在请求层做重复工作。

这篇文章会带读者完成一条完整链路：先理解 LangChain 的模块划分，然后配置 Python 环境和模型 API，接着用 Model 模块完成一次基础对话，再用 LCEL 组装成 Chain，最后实现一个带工具调用的 Agent 智能体项目。整个过程会给出可直接运行的代码、参数说明和排查方法。文章末尾还会说明从 LangChain 走向 LangGraph 时应该关注哪些差异。

阅读本文不需要预先熟悉 LangChain，但最好具备以下基础：会使用 Python 虚拟环境，了解pip安装依赖，知道openai这类 SDK 的基本调用方式。如果之前没有写过任何大模型应用，建议先按顺序跑通第 3 章的代码，再进入 Agent 部分。

1. 先搞清楚 LangChain 在模型调用中扮演什么角色

1.1 大模型 API 调用看起来很直接，为什么还需要框架

直接调用大模型接口，最少的代码可能只有三行：创建客户端、拼接消息、拿到返回文本。这个流程本身不复杂，复杂的是它被放到业务系统之后出现的问题。

真实应用通常不是“问一次就结束”，而是多轮对话、上下文管理、结果格式化、工具调用、权限控制、日志追踪和错误重试同时存在。比如一个客服机器人，用户会连续问多个问题，系统需要保留历史消息；用户问“查询订单状态”时，系统需要调用订单接口，再把接口返回的数据交给模型整理成自然语言；如果接口超时，系统还要决定是重试还是换一种表达方式。这些逻辑如果全部写在业务代码里，会让每次调用变成一大坨难以维护的样板代码。

LangChain 并没有发明新的模型协议，它做的事情是把模型调用之外的可复用逻辑抽象成模块：模型统一封装、提示词模板、输出解析、链式编排、记忆管理、工具注册和 Agent 执行器。每个模块都有清晰边界，开发者可以单独使用，也可以组合使用。

1.2 LangChain 的核心模块和它们的分工

LangChain 的核心模块可以从一张表看起。

这个划分不是设计文档里的空洞概念，而是实际代码组织方式。后面写 Agent 时，最直观的感受就是：工具函数不需要感知模型怎么调用它，只需要用@tool声明参数和描述，模型会通过描述来决定什么时候调用、传什么参数。

1.3 Model、Chain、Agent 三层演进关系

初学者最容易混淆 Model、Chain 和 Agent 的关系。可以按“控制权”来理解它们的递进关系。

Model 层是单次对话。输入一组消息，输出一个回答。控制权完全在开发者手里，模型只负责生成文本。

Chain 层是把固定流程串起来。比如先格式化用户输入，再调用模型，再把模型输出转成 JSON。流程顺序是开发者写死的，每一步做什么都确定。

Agent 层把选择权交给了模型。开发者只负责准备工具和说明目标，模型会自己决定是否调用工具、先调用哪个、观察结果后再决定下一步。这个“思考-行动-观察-再思考”的循环，就是 Agent 区别于 Chain 的核心特征。

实际项目里，并不总是 Agent 比 Chain 好。流程固定、步骤确定的任务，用 Chain 更稳、更快、更容易测试；步骤不确定、需要根据中间结果动态决策的任务，才适合用 Agent。这个判断会直接影响后面代码怎么写。

2. 初始化环境和依赖：版本选择决定后面代码能不能跑

2.1 Python 虚拟环境与依赖安装

LangChain 对应 Python 3.9 及以上版本，建议使用 3.10 或 3.11，兼容性更稳。首次入门不要直接安装在系统全局 Python 里，先建一个独立虚拟环境，避免不同项目之间的依赖互相影响。

python -m venv .venv source .venv/bin/activate

Windows 下的激活命令不同：

.venv\Scripts\activate

虚拟环境激活后，终端提示符前面会出现(.venv)标志。接下来安装依赖。本文涉及的包有langchain、langchain-openai和python-dotenv，其中langchain-openai负责封装 OpenAI 兼容接口的模型调用。

pip install -U langchain langchain-openai python-dotenv

安装完成后，可以先打印版本确认环境正常：

python -c "import langchain; print(langchain.__version__)"

实际输出的版本号会随发布时间变化。要注意的是，LangChain 版本迭代较快，旧版本和新版本在某些 API 上不兼容。如果是从网上复制代码，先确认代码对应的版本，再决定是否升级依赖，不要盲目使用最新版。

2.2 模型 API Key 的三种配置方式

模型调用需要 API Key。这里用 OpenAI 兼容接口作为示例，因为国内外的不少模型服务都提供 OpenAI 兼容端点，langchain-openai可以统一适配。具体模型名称、请求地址和密钥，要以你实际使用的服务商为准。

配置文件使用.env管理密钥，避免把密钥写在代码里：

OPENAI_API_KEY=你的密钥 OPENAI_API_BASE=https://api.example.com/v1 OPENAI_MODEL_NAME=你的模型名称

代码中通过python-dotenv加载：

import os from dotenv import load_dotenv load_dotenv() openai_api_key = os.getenv("OPENAI_API_KEY") openai_api_base = os.getenv("OPENAI_API_BASE") openai_model_name = os.getenv("OPENAI_MODEL_NAME")

这里的关键点在于环境变量名只是约定，不是固定标准。只要代码里读取的变量名和.env里写的一致即可。OPENAI_API_BASE通常要包含协议和/v1路径，不同服务商可能有差异，配置错会出现连接或鉴权报错。

2.3 项目目录结构

为了让后面的演示代码能直接运行，建立一个统一的项目目录：

langchain-agent-demo/ ├── .env ├── requirements.txt └── src/ ├── model_demo.py ├── chain_demo.py └── agent_demo.py

model_demo.py演示 Model 基础调用，chain_demo.py演示 LCEL 链式调用，agent_demo.py演示 Agent 项目。三个文件相互独立，分别对应三个学习阶段。

注意：requirements.txt里建议锁定已经验证过的版本。实际项目中不要写langchain>=0.3这种宽松范围，因为大版本升级可能带来破坏性变更。

3. Model 基础调用：先把一次对话打通再说

3.1 最小可运行模型调用代码

model_demo.py的完整代码如下：

import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI load_dotenv() llm = ChatOpenAI( model=os.getenv("OPENAI_MODEL_NAME"), api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_API_BASE"), temperature=0.7, timeout=30, max_retries=2, ) messages = [ {"role": "system", "content": "你是一个简洁的技术助手，回答不超过三句话。"}, {"role": "user", "content": "请解释一下什么是 LangChain？"}, ] response = llm.invoke(messages) print(response.content)

运行时执行：

python src/model_demo.py

正常情况下会输出一段关于 LangChain 的解释文本。这里有两个细节需要解释。

第一，ChatOpenAI里的参数名可能随版本不同而变化。老版本常用model_name，新版本推荐使用model，如果代码报出“unexpected keyword argument”或模型初始化报错，优先检查参数名。

第二，llm.invoke(messages)接收的是消息列表，不是普通字符串。列表里的每个元素包含role和content两个字段。system消息用来设定模型行为，user消息是用户输入。这是 Chat 模型和补全模型的本质差异。

3.2 模型参数到底应该怎么调

ChatOpenAI构造方法里的参数不是随便填的，每个参数都会直接影响调用结果和成本。下面列出最常用的几个参数：

这些参数在初学阶段不需要全用上，但timeout和max_retries建议一开始就配置。大模型接口不是内网接口，出现超时和限流是常态，没有这些参数，程序会在异常时卡很久。

3.3 处理返回结果和异常分支

模型返回的对象并不是单纯字符串。ChatOpenAI.invoke返回的是AIMessage对象，除了content字段，还有response_metadata、usage_metadata等属性，其中包含 token 用量信息。

response = llm.invoke("用一句话介绍 Python") print("回答内容:", response.content) print("token 用量:", response.usage_metadata)

如果只看content，很多信息会丢失。实际生产环境中，token 用量需要记录到日志或数据库中，用来做成本监控。

异常处理建议单独封装。直接调用模型接口时，常见异常包括鉴权失败、余额不足、限流、连接超时和模型不存在。把异常类型打印出来，而不是只打印error，能极大缩短排查时间。

from langchain_core.exceptions import LangChainException try: response = llm.invoke("你好") except Exception as e: print("调用失败，异常类型:", type(e).__name__) print("异常信息:", str(e))

初学阶段最容易犯的错误是只处理成功分支，忽略异常分支。建议把异常信息原样打印出来，等全部流程跑通后，再按照第 7 章的错误码做精细化处理。

4. 用 LCEL 把 Prompt、模型和输出解析串成 Chain

4.1 为什么需要 Prompt 模板而不是拼接字符串

直接在代码里写死提示词，第一次运行没问题，但业务提醒词往往需要根据用户输入动态变化。比如翻译场景，语言方向是动态的，内容也是动态的。用字符串拼接虽然能实现，但可读性差，而且无法复用。

LangChain 的PromptTemplate把提示词中的固定部分和动态部分分开：

from langchain_core.prompts import PromptTemplate prompt = PromptTemplate.from_template( "请把下面的中文翻译成英文，只输出翻译结果，不要解释。\n内容：{content}" ) filled = prompt.invoke({"content": "今天天气很好"}) print(filled.text)

{content}是占位符，invoke时传入字典就会自动替换。这个能力在 Chain 中的价值更大，因为变量可以来自上一个步骤的输出。

4.2 LCEL 链式调用的核心写法

LangChain 从 0.1 版本开始推荐使用 LCEL，也就是 LangChain Expression Language。LCEL 的核心是一个|操作符，它可以把多个可运行对象串联起来，前一个的输出自动作为后一个的输入。

chain_demo.py完整代码如下：

import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser load_dotenv() llm = ChatOpenAI( model=os.getenv("OPENAI_MODEL_NAME"), api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_API_BASE"), temperature=0.3, ) prompt = ChatPromptTemplate.from_template( "请用一句话回答：{question}" ) chain = prompt | llm | StrOutputParser() result = chain.invoke({"question": "什么是 CAP 定理？"}) print(result)

运行结果是一段纯文本字符串，不再是AIMessage对象。这是因为StrOutputParser把AIMessage的content提取出来了。这一步看起来简单，却解决了实际项目中的一个常见问题：Chain 中每一步拿到的数据类型不一致。

4.3 用输出解析器把结果变成结构化对象

实际项目中，很多下游系统需要的是 JSON，不是纯文本。比如要求模型从一段客服对话中抽取“客户ID、问题分类、紧急程度”三个字段，再用代码做后续处理。此时可以用PydanticOutputParser配合 Pydantic 数据模型。

from typing import Literal from pydantic import BaseModel, Field from langchain_core.output_parsers import PydanticOutputParser from langchain_core.prompts import ChatPromptTemplate class SupportTicket(BaseModel): customer_id: str = Field(description="客户 ID") category: str = Field(description="问题分类") priority: Literal["low", "medium", "high"] = Field(description="紧急程度") parser = PydanticOutputParser(pydantic_object=SupportTicket) prompt = ChatPromptTemplate.from_template( "从下面的客服对话中抽取信息，只输出 JSON。\n{format_instructions}\n对话内容：{content}" ).partial(format_instructions=parser.get_format_instructions()) str_llm = llm | StrOutputParser() chain = prompt | str_llm | parser result = chain.invoke({"content": "用户张三说他的订单已经两天没有发货了，非常着急。"}) print(result.customer_id) print(result.category) print(result.priority)

这里要特别注意：Pydantic 版本不同，Field和Literal的导入路径可能有差异。如果导入报错，优先检查pydantic版本是否兼容。

5. Agent 实战：让模型自己决定调用哪个工具

5.1 Agent 的工作原理：ReAct 循环

Agent 并不能凭空“思考”，它依赖一套明确的运行流程。LangChain 中最经典的是 ReAct 模式，即 Reasoning 加 Acting。流程如下：

1. 用户给出问题。
2. 模型先生成思考（Thought），判断当前是否可以直接回答。
3. 如果需要外部数据，模型输出动作（Action），指定工具名称和参数。
4. 系统执行工具，把结果作为观察（Observation）返回给模型。
5. 模型根据观察继续思考或生成最终答案。

这个循环会一直重复，直到模型输出Final Answer，或者达到最大迭代次数。理解这个循环对排错特别重要。后面的所有 Agent 报错，几乎都能对应到循环的某一个环节。

5.2 用@tool定义工具函数

Agent 中的工具必须能被模型理解，所以工具不仅要写函数逻辑，还要写清楚函数描述和参数描述。@tool装饰器会自动把函数的 docstring 和类型注解转换成模型能读取的工具定义。

agent_demo.py中定义两个工具：

from datetime import datetime from langchain_core.tools import tool @tool def get_current_time() -> str: """返回当前日期和时间，格式为 YYYY-MM-DD HH:MM:SS。""" return datetime.now().strftime("%Y-%m-%d %H:%M:%S") @tool def add(a: float, b: float) -> float: """计算两个数字相加的结果。参数 a 是第一个加数，参数 b 是第二个加数。""" return a + b

get_current_time没有参数，add有两个 float 类型参数。类型注解和 docstring 是模型选择工具和生成参数的关键依据。描述写得不清楚，模型就可能在该调用add时调用别的工具，或者生成错误参数。

5.3 创建 ReAct Agent 并运行

创建 Agent 需要三个东西：模型、工具列表、ReAct 提示词模板。模板中必须包含{tools}、{tool_names}、{input}、{agent_scratchpad}四个变量，分别对应工具描述、工具名称列表、用户输入和模型已有的思考轨迹。

import os from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain_core.prompts import PromptTemplate from langchain.agents import create_react_agent, AgentExecutor load_dotenv() llm = ChatOpenAI( model=os.getenv("OPENAI_MODEL_NAME"), api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_API_BASE"), temperature=0, ) tools = [get_current_time, add] prompt = PromptTemplate.from_template( """You are a helpful assistant. You have access to the following tools: {tools} Use the following format: Question: the input question you must answer Thought: you should always think about what to do Action: the action to take, should be one of [{tool_names}] Action Input: the input to the action Observation: the result of the action ... (this Thought/Action/Action Input/Observation can repeat N times) Thought: I now know the final answer Final Answer: the final answer to the original input question Begin! Question: {input} Thought: {agent_scratchpad}""" ) agent = create_react_agent(llm=llm, tools=tools, prompt=prompt) agent_executor = AgentExecutor( agent=agent, tools=tools, verbose=True, handle_parsing_errors=True, max_iterations=5, ) result = agent_executor.invoke({"input": "现在几点了？请输出时间。"}) print(result["output"])

运行命令：

python src/agent_demo.py

设置verbose=True后，终端会打印 Agent 的完整思考过程，包括Thought、Action、Action Input、Observation和Final Answer。这一步是理解 Agent 最好的方式，建议初学者第一次运行时一定要打开verbose。

5.4 观察 Agent 的多轮工具调用过程

上面代码只演示了一个工具被调用的情况。为了观察 Agent 连续调用多个工具，可以更换输入：

result = agent_executor.invoke( {"input": "计算 12 加 34 的结果，然后告诉我当前时间。"} )

这种情况下，模型有可能先调用add，再调用get_current_time，也可能先调用时间工具再计算。顺序不是代码写死的，而是模型根据工具描述自己决定的。如果某个工具没有进入调用流程，优先检查工具描述和模型对任务的理解是否匹配。

这里要说明一个常见误解：Agent 不是每次都重新思考“我有哪些工具”。模型提供的工具列表是固定在上下文里的，多轮执行时，上下文会累积大量Thought和Observation，导致 token 消耗明显增加。这也是后面第 8 章要讨论的 Agent 成本问题的来源。

6. 运行验证：分别观察 Model、Chain、Agent 的行为差异

6.1 验证 Model 的基础输出

运行model_demo.py后，观察两类输出：

• 正常输出：模型返回的文本内容。
• usage_metadata：包含input_tokens、output_tokens和total_tokens。

建议把耗时的输出和 token 用量明确打印出来。验证目标是确认 API Key 是否有效、模型名称是否被服务商支持、请求链路是否通了。如果这一步失败，后面的 Chain 和 Agent 都无法运行，所以不要跳过。

6.2 验证 Chain 的输出类型

运行chain_demo.py后，重点确认result的类型是str。如果去掉StrOutputParser，结果是AIMessage。初学者经常在这一步犯迷糊，明明使用相同的模型，为什么一个输出字符串、一个输出对象。这正好说明输出解析器在 Chain 中的地位：它决定了下游步骤拿到的数据类型。

可以增加一段代码验证输出解析效果：

print("输出类型:", type(result).__name__) print("输出内容:", result)

如果看到输出类型: str，说明 Chain 解析链路正确。

6.3 验证 Agent 的工具调用轨迹

Agent 运行后在终端会打印类似下面的文本：

> Entering new AgentExecutor chain... Thought: 用户想知道当前时间，我需要调用 get_current_time 工具。 Action: get_current_time Action Input: {} Observation: 2026-01-08 10:30:15 Thought: 我已经拿到当前时间，现在可以回答用户。 Final Answer: 当前时间是 2026-01-08 10:30:15。

Finished chain.

这是 Agent 最核心的验证点：是否存在 `Action` 和 `Observation` 的完整配对。如果只看到 `Thought` 直接跳到 `Final Answer`，说明模型没有调用工具，可能是问题不需要工具，也可能是工具描述不清晰。 ### 6.4 对比三种写法的适用场景 跑通三个文件后，可以整理出结论： | 写法 | 控制权 | 适用场景 | 输出稳定性 | | --- | --- | --- | --- | | 直接调用 Model | 开发者 | 单次问答、消息补全 | 高 | | Chain | 开发者 | 固定流程、多步骤后处理 | 高 | | Agent | 模型 | 动态决策、多工具选择 | 低，需要测试 | 这个对比决定了项目选型方向。不要因为 Agent 看起来更智能就到处用，很多场景用 Chain 反而更可靠。 ## 7. 常见问题排查：从错误信息反推配置和代码问题 ### 7.1 鉴权、连接和模型名称问题 模型调用阶段最常见的报错集中在三个方面： | 错误现象 | 常见原因 | 检查方式 | 处理建议 | | --- | --- | --- | --- | | `api_key not found` | `.env` 未加载或变量名错误 | 打印 `os.getenv("OPENAI_API_KEY")` 是否为空 | 确认 `.env` 在项目根目录，且代码在读取环境变量前调用了 `load_dotenv()` | | `Connection error` | `base_url` 错误或网络不通 | 用 `curl` 请求该地址验证可达性 | 确认地址包含协议头和 `/v1` 路径 | | `model is not supported` 或 `model is unavailable` | 模型名称写错，或当前服务商不支持该模型 | 对照服务商文档确认模型名称 | 不要随意猜测模型名，以服务商页面或文档为准 | | `This model's maximum context length is ... tokens` | 消息总 token 超出模型上限 | 打印 `usage_metadata` 统计输入 token | 截断历史消息，或换用更大上下文的模型 | 一个容易忽略的问题：不同服务商对模型名称的大小写和连字符要求不同。复制模型名称时不要手动输入，尽量从服务商控制台复制。 ### 7.2 模型参数不兼容 LangChain 版本的频繁迭代，直接导致参数在不同版本间出现差异。最典型的是 `ChatOpenAI` 的模型名参数，旧版本支持 `model_name`，新版本推荐 `model`。 遇到 `TypeError` 或 `ValueError` 时，按顺序排查： 1. 查看当前 `langchain-openai` 版本，确认文档对应版本。 2. 检查参数名是否被新版本移除或改名。 3. 如果代码来自网络教程，优先确认教程使用的版本区间。 不要为了适配一段旧代码而锁定过老的依赖版本，否则后面遇到安全更新或新功能时会很被动。 ### 7.3 Agent 解析失败和循环不终止 Agent 最常见的运行问题有两个。 第一个是 `Could not parse LLM output`。现象是模型输出的内容不符合 ReAct 模板要求，缺少 `Action` 或 `Action Input` 字段。解决方式是设置 `handle_parsing_errors=True`，让解析失败时把错误信息回传给模型，重新尝试生成。这个方法不保证 100% 成功，但能显著降低失败率。 第二个是 Agent 不断循环，最后提示超过 `max_iterations`。检查顺序： | 检查项 | 目的 | | --- | --- | | 工具描述是否清晰 | 模型选错工具时会反复尝试 | | 工具返回是否包含足够信息 | 返回太简单会让模型无法继续决策 | | `max_iterations` 是否合理 | 任务复杂时默认值可能不够 | | 模型是否具备较强的工具调用能力 | 某些轻量模型在复杂 ReAct 任务上表现不稳定 | 遇到循环问题，不要在 `max_iterations` 上无限调大，先观察 `verbose=True` 打印的轨迹，找到模型在哪一步开始出错，往往更有价值。 ### 7.4 多轮对话丢失上下文 Agent 的 `invoke` 只处理单次输入，不保留历史。用户问“现在几点”，得到回答后，再问“那明天呢”，Agent 并不记得之前的话题。 解决思路是给 Agent 增加记忆机制。LangChain 新版本推荐的方案是用 `RunnableWithMessageHistory` 或直接引入 LangGraph 管理状态。这里不展开完整代码，但要先建立正确的认知：Agent 的记忆不是自动的，需要显式传入历史消息，并控制历史长度，避免把上下文撑爆。 ## 8. 最佳实践与扩展方向：从 Demo 走向可用系统 ### 8.1 学习环境与生产环境的差异 上面的代码是为了验证核心流程，离生产环境还有一段距离。两者之间的差异主要集中在四个方面： | 关注点 | 学习环境 | 生产环境建议 | | --- | --- | --- | | 密钥管理 | `.env` 文件 | 使用配置中心或密钥管理服务，禁止写入代码仓库 | | 日志 | 打印到终端 | 记录结构化日志，包含模型名、token 用量、耗时、错误码 | | 监控告警 | 无 | 对错误率、token 成本、Agent 迭代次数设置监控 | | 异常处理 | try except 打印 | 区分可重试错误和不可重试错误，做降级或熔断 | 生产环境特别要关注成本。Agent 的多轮工具调用会消耗大量 token，一次看似简单的问题可能触发模型多次进出，成本远超普通对话。建议在 Agent 执行前设置好预算上限，例如限制最大迭代次数、限制单次对话 token 总量。 ### 8.2 参数和设计的落地建议 几个可以直接落地的建议： - 调用模型前先确认模型在私有化、开源、云服务之间的差异，不要在同一套代码里假设所有模型行为一致。 - `temperature` 在工具调用场景中设置为 0 或接近 0，因为工具调用需要确定性，创造性无意义。 - 每个工具的 docstring 都写清楚“什么时候使用、参数含义、返回内容”，这是 Agent 能否正确选工具的最关键因素。 - 不要把业务校验逻辑写在工具函数内部并让模型去解释错误，工具返回结构化错误信息，由上层逻辑决定如何处理。 - 对 Agent 的输出做格式校验，模型偶尔会产生与模板不符的格式，不能假设格式永远正确。 ### 8.3 从 LangChain 走向 LangGraph 把 Agent 做得越来越复杂时，LangChain 的 ReAct Agent 会暴露出一个限制：它是在一个循环里反复执行，流程只能由模型自主决定，开发者难以精确控制中途的每个状态。 LangGraph 的定位是“有状态的图编排”。它把 Agent 运行过程建模成一张图，节点是处理逻辑，边是状态转移条件。开发者可以明确控制“什么时候调用某个工具”“用户中断时怎么办”“多个工具并行还是串行”。两者的关系不是替代，而是不同复杂度层级：LangChain 适合快速搭 Agent，LangGraph 适合把 Agent 变成可审计、可恢复的生产系统。 如果目前还不需要复杂的循环、分支和人工介入，LangChain 的 Agent 已经足够；一旦要处理多角色协同、状态持久化、断点恢复这些需求，就可以学习 LangGraph。 ### 8.4 建议的学习路线 把这篇内容消化后，下一步建议按顺序完成四个练习： 1. 换一个真实业务工具，让 Agent 调用它。比如查询数据库、调用内部 HTTP 接口，验证工具定义的描述是否够用。 2. 给 Chain 加上多轮记忆，让连续对话能引用前文上下文。 3. 把 Agent 的日志、token 用量和错误率接入监控，观察一次完整问答消耗了多少 token。 4. 把同一个 Agent 用 LangGraph 重写一遍，对比两者的控制力和代码复杂度。 这四个练习覆盖了概念、调用、组合、排错、成本和架构演进，做完之后，LangChain 就不再只是书上的概念，而是一套能写进简历、能支撑业务开发的实际技能。