7 个核心概念，一文看懂 LangChain 如何搭建AI Agent

如果只是调用一次大模型，代码通常并不复杂：准备 Prompt，发送给模型，再拿到返回结果。

但当需求变成“先判断问题，再查询数据，根据结果继续执行，必要时调用多个工具，并记住前面的信息”，单次 LLM 调用就不够了。开发者需要管理模型、工具、上下文、执行状态、异常处理以及整个调用循环。

这正是 AI Agent 要解决的问题。

LangChain 的作用，可以理解为把这些能力组织成一套统一的 Agent 开发框架。理解它不需要先记大量 API，先掌握 Model、System Prompt、Tools、Agent Loop、State / Memory、Middleware、Structured Output 这 7 个概念，就能建立完整的认识。

AI Agent 可以简单理解为：由大模型负责判断下一步做什么，并能够使用外部工具持续执行任务的程序。

普通 LLM 调用通常是：

01用户输入 → 模型 → 返回结果

而 Agent 更接近：

01用户输入
02   ↓
03模型判断
04   ↓
05是否需要工具？
06   ↓
07调用工具
08   ↓
09获得结果
10   ↓
11再次交给模型判断
12   ↓
13……
14   ↓
15最终答案

也就是说，两者最大的区别不是有没有 Prompt，而是有没有一个持续运行的决策—执行循环。

LangChain 当前通过 create_agent() 提供 Agent 的高层入口。它负责把模型、工具、状态、中间件等组件组装起来，底层则使用 LangGraph 的图运行时执行整个 Agent 循环。

因此可以把相关层级大致理解为：

01应用程序
02   ↓
03LangChain Agent
04   ↓
05Model / Tools / Middleware / Memory
06   ↓
07LangGraph Runtime

LangChain 更关注“怎样方便地搭建 Agent”，LangGraph 则提供更底层的状态、节点、边和执行能力。

理解这个关系之后，再看下面 7 个概念就会清楚很多。

第一个概念是模型（Model）。

模型是 Agent 的决策中心。它负责阅读当前上下文，理解用户目标，并决定是直接回答，还是调用某个工具。

LangChain 对不同模型提供了统一接口。例如可以直接通过模型标识创建 Agent：

01from langchain.agents import create_agent
02 
03agent = create_agent(
04    model="openai:gpt-5.5",
05    tools=[]
06)

也可以先创建具体模型对象，再交给 Agent。这样更方便配置温度、超时、Token 数量等参数。

和 Model 紧密相关的是第二个概念：系统提示词（System Prompt）。

模型决定“怎么思考”，System Prompt 则规定“应该按照什么规则工作”。

例如：

01agent = create_agent(
02    model="openai:gpt-5.5",
03    tools=[],
04    system_prompt="""
05你是一个库存管理助手。
06回答库存问题时必须以系统查询结果为准，
07不得自行猜测库存数量。
08"""
09)

这里真正解决的问题，不是让 Prompt 写得更长，而是明确 Agent 的行为边界。

实际项目中，模型看到的不只有 System Prompt，还包括消息历史、可用工具、当前状态以及输出格式等。这些内容共同构成模型每一次调用时的上下文。LangChain 将这部分工作归入 Context Engineering，也就是上下文工程。

第三个概念是工具（Tool）。

LLM 本身主要负责语言理解和生成，并不能访问你的数据库、内部 API 或业务系统。

如果希望 Agent 查询库存，就需要把查询库存的能力包装成 Tool。

01from langchain.tools import tool
02 
03@tool
04def get_stock(product: str) -> int:
05    """查询指定商品当前库存数量。"""
06    stocks = {
07        "机械键盘": 12,
08        "无线鼠标": 5,
09    }
10    return stocks.get(product, 0)

这里的函数并不是由开发者直接决定什么时候调用。

LangChain 会把工具的名称、参数和描述提供给模型。模型结合用户问题判断是否需要调用，以及应该传入什么参数。工具执行后的结果又会重新放回 Agent 上下文，让模型继续判断下一步。

于是：

01“机械键盘还有库存吗？”

可能被转换为：

01调用 get_stock(product="机械键盘")

得到：

0112

模型再根据这个结果生成最终回答。

这也是 Tool Calling 与普通函数调用的重要区别：函数由程序流程决定调用，Agent Tool 通常由模型根据当前任务决定是否调用。

第四个概念是 Agent Loop。

如果只理解 Tool，而没有理解 Agent Loop，很容易把 Agent 看成“会自动调用函数的聊天机器人”。

实际上，Agent 最重要的机制是循环执行。

一次任务可能经历：

01Model
02 ↓
03Tool
04 ↓
05Model
06 ↓
07Tool
08 ↓
09Model
10 ↓
11Final Answer

例如用户提出：

查询机械键盘库存，如果超过 10 件，告诉我是否可以接一个 8 件的订单。

模型第一次并不知道库存，因此调用 get_stock()。

工具返回 12。

结果重新进入模型后，模型发现：

0112 > 10

同时：

0112 >= 8

于是停止工具调用，给出最终答案。

LangChain 的 create_agent() 会自动建立这种循环。当模型继续产生 Tool Call 时，Agent 执行工具；当模型不再要求调用工具并产生最终输出时，循环结束。底层执行过程由 LangGraph 管理。

这一步实际上把开发者从大量手写流程代码中解放了出来。

否则你需要自己处理：

01while True:
02    response = call_model()
03 
04    if response.has_tool_call:
05        result = execute_tool()
06        append_result(result)
07    else:
08        break

而真实项目还会涉及多工具、失败重试、状态保存、调用限制等问题，循环很快就会变复杂。

第五个概念是状态（State）与记忆（Memory）。

Agent 在执行过程中需要不断保存数据。例如：

01用户说了什么
02模型返回了什么
03调用了哪个工具
04工具返回了什么
05当前执行到哪一步

这些数据构成 Agent 的 State。

LangChain Agent 默认会维护消息状态，因此同一次执行过程中，模型可以看到前面的 Tool Message 和对话消息。

但如果希望第二次调用还能记住第一次的信息，就需要持久化。

LangChain 的短期记忆以线程为范围，可以通过 Checkpointer 保存 Agent State。

例如：

01from langgraph.checkpoint.memory import InMemorySaver
02 
03checkpointer = InMemorySaver()
04 
05agent = create_agent(
06    model="openai:gpt-5.5",
07    tools=[get_stock],
08    checkpointer=checkpointer
09)

调用时指定同一个 thread_id：

01config = {
02    "configurable": {
03        "thread_id": "user-001"
04    }
05}

同一个线程后续执行时，就可以继续读取之前的状态。

需要注意，State 不等于长期记忆。

短期记忆通常服务于当前会话线程；如果希望跨会话保存用户偏好、档案或长期知识，LangChain 还提供基于 Store 的长期记忆机制。

可以简单记成：

01State / Checkpointer
02→ 当前会话发生了什么
03
04Store
05→ 跨会话长期保存什么

第六个概念是中间件（Middleware）。

当 Agent 从演示代码进入真实项目后，很快会出现新的需求：

01模型失败时自动重试
02工具调用失败时统一处理
03调用危险工具前需要审批
04对敏感信息进行过滤
05限制最大模型调用次数
06上下文太长时自动摘要
07根据任务动态选择模型或工具

如果把这些逻辑全部塞进 Tool 或 Prompt，Agent 会越来越难维护。

Middleware 的作用，就是在 Agent 生命周期的关键位置插入控制逻辑，而不需要改写整个 Agent Loop。

例如可以在模型调用前处理上下文，在工具执行前检查权限，在模型返回后验证结果。

LangChain 还提供了多种内置 Middleware，包括摘要、Human-in-the-loop、模型调用限制、工具调用限制、重试、PII 检测等。

因此可以把它理解成：

01Agent Loop
02    │
03    ├── before model
04    ├── model
05    ├── after model
06    ├── before / wrap tool
07    ├── tool
08    └── after tool

Middleware 并不是另一个 Agent，也不是独立 Runtime，而是嵌入 Agent 执行过程中的扩展机制。

第七个概念是结构化输出（Structured Output）。

很多 Agent 教程最后只打印一段自然语言：

01机械键盘目前库存 12 件，可以接受 8 件订单。

但真实系统往往不能只依赖这句话。

前端、数据库或后续业务逻辑可能更希望得到：

01{
02  "product": "机械键盘",
03  "stock": 12,
04  "can_accept_order": true
05}

这就是 Structured Output 要解决的问题。

LangChain 可以通过 response_format 指定 Pydantic Model、Dataclass、TypedDict 或 JSON Schema，让 Agent 最终返回可验证的数据结构。结果会保存在 Agent State 的 structured_response 中。

例如：

01from pydantic import BaseModel
02 
03class StockDecision(BaseModel):
04    product: str
05    stock: int
06    can_accept_order: bool

创建 Agent 时：

01agent = create_agent(
02    model="openai:gpt-5.5",
03    tools=[get_stock],
04    response_format=StockDecision
05)

这样 Agent 的最终结果就不再只是供人阅读的文本，还能直接参与程序逻辑。

这也是开发 Agent 时很容易被忽略的一点：自然语言适合人与 Agent 交流，结构化数据更适合 Agent 与系统交流。

把前面的概念组合起来，可以得到一个很小但完整的 Agent。

先安装依赖：

01pip install -U langchain langchain-openai

LangChain 当前要求 Python 3.10 及以上；不同模型提供商的集成通常安装在独立 Provider Package 中，例如 OpenAI 使用 langchain-openai。

下面实现一个库存 Agent：

01from pydantic import BaseModel
02from langchain.agents import create_agent
03from langchain.tools import tool
04from langgraph.checkpoint.memory import InMemorySaver
05 
06 
07@tool
08def get_stock(product: str) -> int:
09    """查询指定商品当前库存数量。"""
10    stocks = {
11        "机械键盘": 12,
12        "无线鼠标": 5,
13    }
14    return stocks.get(product, 0)
15 
16 
17class StockDecision(BaseModel):
18    product: str
19    stock: int
20    can_accept_order: bool
21 
22 
23agent = create_agent(
24    model="openai:gpt-5.5",
25    tools=[get_stock],
26    system_prompt="""
27你是库存管理助手。
28判断是否能够接单时，必须先查询实际库存。
29只有库存数量大于等于订单数量时才能接单。
30""",
31    response_format=StockDecision,
32    checkpointer=InMemorySaver(),
33)
34 
35 
36result = agent.invoke(
37    {
38        "messages": [
39            {
40                "role": "user",
41                "content": "客户想订购 8 个机械键盘，可以接单吗？"
42            }
43        ]
44    },
45    {
46        "configurable": {
47            "thread_id": "order-001"
48        }
49    }
50)
51 
52print(result["structured_response"])

示例输出如下：

01product='机械键盘' stock=12 can_accept_order=True

从这个结果可以看到，代码本身并没有写：

01get_stock("机械键盘")

真正的执行过程是：

01用户提出订单需求
02↓
03模型理解任务
04↓
05决定调用 get_stock
06↓
07Tool 返回 12
08↓
09结果写回 Agent State
10↓
11模型继续判断
12↓
13生成 StockDecision
14↓
15Agent Loop 结束

Model 负责判断，System Prompt 规定规则，Tool 获取外部数据，Agent Loop 负责持续执行，State 保存过程信息，Structured Output 则把最终结果转换成程序可直接使用的数据。

这几部分组合起来，才形成一个完整的 Agent。

理解 LangChain 之后，还需要避免另一个误区：并不是所有 LLM 应用都需要 Agent。

如果业务流程完全确定，例如：

01读取文件
02→ 提取文本
03→ 调用模型总结
04→ 保存数据库

这种流程用普通代码或固定 Workflow 往往更合适。因为每一步都已经由开发者确定，没有必要让模型判断下一步。

Agent 更适合那些执行路径无法在开发时完全确定的任务，例如：

01根据问题决定查询哪个数据源
02根据搜索结果决定是否继续搜索
03根据用户意图选择不同工具
04根据执行结果动态调整下一步

如果只需要模型生成文本，直接调用 Model 就够了。

如果需要模型在有限工具之间自主决策，可以使用 LangChain Agent。

如果工作流包含大量明确的分支、并行节点、循环和人工审批，而且希望精确控制每一步，则可以进一步使用更底层的 LangGraph。

这种选择比单纯比较哪个框架“更强”更有意义。

本文介绍的 7 个概念，我们可以用一条执行链将这些概念串起来：

01System Prompt + State
02        ↓
03      Model
04        ↓
05决定是否调用 Tool
06        ↓
07     Tool Result
08        ↓
09更新 State / Memory
10        ↓
11Middleware 控制执行过程
12        ↓
13继续 Agent Loop
14        ↓
15Structured Output

由此可以看出，LangChain 并不是简单地给大模型增加几个工具，而是把模型决策、工具执行、上下文状态和运行控制组织成一个持续执行的 Agent 系统。

实际学习时，可以先从“一个模型 + 一个 Tool + create_agent()”开始，观察模型为什么调用工具、工具结果怎样重新进入模型。理解这条最小 Agent Loop 之后，再逐步加入 Memory、Middleware 和 Structured Output，会比一开始研究复杂多 Agent 架构更容易建立清晰认识。