LangChain 入门与实践

这篇文档的目标不是把 LangChain 讲成一个“大而全”的框架百科，而是从工程视角回答几个更实际的问题：

• LangChain 到底是什么？
• 它适合当前处在哪个阶段？
• 它和 LangGraph、LangSmith 分别是什么关系？
• 什么时候该直接上 LangChain，什么时候自己手写更合适？
• 如果要快速跑一个最小 agent，应该怎么开始？
• 它和本专题里已经有的章节，应该怎么对照着看？

本文内容以 LangChain 官方文档为主，尤其参考：

• LangChain overview
• LangGraph overview
• LangSmith docs

1. LangChain 是什么

先说一句最重要的话：

LangChain 不是模型，也不是“自动帮你做完 AI Agent”的黑盒。

按照官方文档现在的表述，LangChain 是一个 open source framework，核心定位是：

• 提供 prebuilt agent architecture
• 提供统一的 model interface
• 提供大量 tool / model integrations
• 让你能更快搭起可运行的 agent 或 LLM application

如果用更工程化的话来翻译，它做的事情大致是：

1. 帮你把不同模型厂商的调用方式统一起来。
2. 帮你把消息、工具、结构化输出、流式输出等常见能力组织成较一致的接口。
3. 帮你减少“自己反复写 agent loop、tool registration、message plumbing”的重复劳动。
4. 在需要的时候，往下可以衔接 LangGraph 的编排能力，往外可以接 LangSmith 的调试、追踪和评测能力。

所以 LangChain 适合被理解成：

一个偏应用层、偏 agent 开发体验的框架层。

它不是最低层，也不是最高层，更不是唯一正确答案。它的价值主要在于：

• 起步快
• 抽象适中
• 可先简单，后续再逐步加复杂度

1.1 官方文档强调的几个核心收益

根据官方 overview，LangChain 现在重点强调的能力主要有：

• Standard model interface：不同模型提供商接口差异很大，LangChain 帮你统一交互方式，降低切换成本。
• Easy to use, highly flexible agent：可以很快写出一个最小 agent，同时又保留一定灵活性。
• Built on top of LangGraph：LangChain 的 agents 建在 LangGraph 之上，因此天然可以接上更底层的执行能力。
• Debug with LangSmith：方便接入 tracing、debugging、evaluation。

如果只看一句总结，可以记成：

LangChain 解决的是“更快把 agent 应用搭起来”这件事。

2. LangChain 适合什么阶段

很多人第一次接触 Agent 框架时，真正的问题不是“LangChain 好不好”，而是：

我现在这个阶段，是否已经适合用它？

我更建议按下面三个阶段来判断。

2.1 阶段一：刚理解模型、Prompt、工具调用

如果还在学习这些基础：

• prompt 是怎么影响输出的
• messages 是怎么组织的
• tool calling 的输入输出长什么样
• 一个最小 loop 是怎么跑起来的

这时 可以用 LangChain，但不要过度依赖它的抽象。

更具体地说：

• 可以用 LangChain 快速搭 demo
• 但同时最好知道底层到底发了什么消息、工具 schema 长什么样、返回结果怎么进入下一轮上下文

这一阶段更稳妥的做法，不是“完全不用框架”，也不是“只会调框架 API”，而是：

把 LangChain 当作一个帮助你减少样板代码的练习平台。

2.2 阶段二：开始做自己的第一个可用 agent

如果已经开始进入这些需求：

• 接一个或多个工具
• 做多轮对话
• 想要结构化输出
• 想加简单 memory
• 想把代码做成最小可运行项目

这通常就是 LangChain 非常合适的阶段。

因为这时候你最需要的不是“极致底层控制”，而是：

• 尽快把系统搭起来
• 把模型、工具、消息、状态这些核心部件串起来
• 保持代码可读、可改、可调试

LangChain 的价值，会在这一阶段最明显。

2.3 阶段三：进入更复杂的 agent 工程化

当你开始需要这些能力时：

• 更长生命周期的状态流转
• 更复杂的多步编排
• deterministic workflow 和 agentic workflow 混合
• human-in-the-loop
• durable execution
• 更细颗粒度的节点控制

这时就要开始考虑：

• 继续用 LangChain agent 抽象是否够用
• 是否要下沉到 LangGraph
• 是否要把 observability、evaluation、deployment 单独体系化

这并不代表 LangChain 失效了，而是说明：

这通常说明系统正在从“快速搭应用”进入“精细编排系统”阶段。

官方文档也明确给出这个建议：

• 如果是刚开始做 agent，或希望用更高层抽象，优先用 LangChain agents
• 如果需要更高级的、低层次的编排能力，再考虑 LangGraph

3. LangChain、LangGraph、LangSmith 的关系

这三个名字经常一起出现，但它们解决的问题并不相同。

最简单的理解方式是：

• LangChain：偏开发框架，负责更快构建 agent / LLM 应用
• LangGraph：偏底层编排运行时，负责复杂、长时、可控的 agent orchestration
• LangSmith：偏观测、评测、调试、部署平台，负责把系统从“能跑”推进到“可看、可测、可上线”

3.1 LangChain 和 LangGraph 的关系

官方文档里有两个非常关键的点：

1. LangChain agents are built on top of LangGraph
2. You do not need to know LangGraph for basic LangChain agent usage

把这两句话翻译成工程语言就是：

• LangChain 并不是和 LangGraph 平行对立的替代品
• LangChain 的 agent 能力，本身就是构建在 LangGraph 提供的底层能力之上的
• 但你在做基础 agent 时，不需要先把 LangGraph 学完再开始

可以把它们理解成：

• LangChain 给你高层、开箱更快的开发入口
• LangGraph 给你低层、可控性更强的编排与运行能力

3.2 LangGraph 更适合什么

根据官方 LangGraph overview，LangGraph 更强调这些点：

• durable execution
• human-in-the-loop
• memory
• streaming
• production-ready deployment

并且官方明确说：LangGraph 是一个 very low-level、专注于 agent orchestration 的框架。

因此：

• 如果只是要一个最小工具型 agent，直接从 LangChain 起步通常更省力
• 如果已经开始需要“图式状态流转、节点级控制、长流程恢复、复杂状态管理”，LangGraph 会更对口

3.3 LangSmith 更适合什么

LangSmith 官方现在的定位很清楚：它是一个 framework-agnostic platform，也就是：

它不是只服务 LangChain，也不是必须和 LangChain 绑定。

它主要做这些事：

• Trace requests
• Evaluate outputs
• Test prompts
• Manage deployments

因此：

• 可以用 LangChain + LangSmith
• 也可以用手写 agent + LangSmith
• 也可以用其他 agent stack + LangSmith

所以三者关系最稳妥的理解应该是：

• LangChain：帮你搭
• LangGraph：帮你编排和控制
• LangSmith：帮你观察、评测、部署

3.4 一张最简关系图

应用代码
  ↓
LangChain（高层 agent / model / tools 抽象）
  ↓
LangGraph（更底层的 orchestration/runtime 能力）
  ↓
模型、工具、状态流转

LangSmith（横向接入 tracing / evals / deployment）

这个图不表示它们必须一起用，而是表示：

• LangChain 常常会建在 LangGraph 能力之上
• LangSmith 则偏横向增强层

4. 什么时候用 LangChain，比自己搭更合适

这是最容易问错的问题。

真正该问的不是：

LangChain 强不强？

而是：

在当前这个问题里，LangChain 能不能省掉足够多、且不会让系统失去关键控制权的重复工作？

4.1 适合直接用 LangChain 的场景

下面这些情况，通常都可以直接考虑 LangChain：

4.1.1 要尽快做出第一个可运行 agent

比如你现在想做的是：

• 一个带 1 到 3 个工具的问答 agent
• 一个带检索的最小 RAG agent
• 一个内部效率工具 agent
• 一个实验性质的 demo 或 PoC

这时 LangChain 最有价值的地方是：

• 帮你统一模型接口
• 帮你减少 tool wiring 的重复代码
• 帮你更快从“空项目”到“能跑起来”

4.1.2 你希望保留一定抽象，但不想一开始就自己拼全套

很多人早期会遇到一个误区：

• 要么全手写
• 要么上特别重的框架

其实 LangChain 常常正好在中间。

它不是最底层，但也不是完全封死的黑盒。对于很多单 agent、轻多步 agent、轻量工具编排场景，它提供的是一种比较平衡的抽象层。

4.1.3 你需要快速切模型或接更多 provider

官方文档非常强调统一模型接口的价值。

如果场景会频繁遇到：

• OpenAI 和 Anthropic 来回切
• 不同任务试不同模型
• 临时换 provider 做成本或效果比较

LangChain 会明显减少“换一家就重写一层”的摩擦。

4.1.4 你准备后续接 LangSmith 或进一步下沉 LangGraph

如果明确知道项目后面大概率会进入：

• tracing / evals
• 更复杂编排
• 更长生命周期状态管理

那从 LangChain 起步，通常比从零手写一套自定义抽象更平滑。

4.2 更适合自己手写的场景

下面这些情况，往往更建议先自己搭最小闭环。

4.2.1 你现在的目标是学习底层原理

如果主要目标是搞懂：

• tool calling 实际协议
• 消息历史如何回注
• loop 如何停止
• 工具错误如何处理

那先自己手写一版最小 agent，学习价值通常更高。

因为一旦你一开始就只使用高层抽象，可能会：

• 会调用 API
• 但不清楚系统为什么这样运行
• 出问题时难以判断是模型问题、prompt 问题、工具问题，还是框架抽象问题

4.2.2 流程非常简单，框架反而增加认知负担

比如你只需要：

• 一次模型调用
• 一个结构化输出
• 一个简单函数工具

那也许根本不需要 agent framework。

这时用原生模型 SDK 加少量手写 glue code，可能更直接。

4.2.3 你需要极端可控、极端透明的执行过程

有些业务场景很强调：

• 每一步状态必须完全可解释
• 每个节点和分支都必须显式定义
• 不希望有太多高层默认行为

这时你可能更适合：

• 手写编排
• 或直接下沉到 LangGraph

而不是停留在 LangChain agent 的更高层抽象上。

4.3 一个简单判断公式

可以用下面这个经验判断：

如果框架帮你省下的重复工作 > 你为理解和调试框架额外付出的复杂度，那就值得用。

对大多数“第一版可用 agent”来说，LangChain 往往是划算的。

对特别简单的实验，或者特别复杂的可控编排系统，则不一定。

5. 最小 Agent 示例

这里给一个非常接近官方 overview 的最小示例，使用 Python 版 create_agent 风格。

这个例子的重点不是功能强，而是帮助你快速理解 LangChain 的最小使用方式：

• 选一个模型
• 定义一个工具
• 创建 agent
• 用 messages 调用它

# 安装示例：pip install -qU langchain "langchain[openai]"
from langchain.agents import create_agent


def get_weather(city: str) -> str:
    """获取指定城市天气。这里先用 mock 数据代替真实 API。"""
    return f"{city} 是晴天，气温 25 度。"


agent = create_agent(
    model="openai:gpt-5.4",
    tools=[get_weather],
    system_prompt="你是一个简洁、可靠的中文助手。",
)

result = agent.invoke(
    {
        "messages": [
            {
                "role": "user",
                "content": "帮我查一下上海天气，然后用一句话总结。",
            }
        ]
    }
)

print(result["messages"][-1].content)

5.1 这个例子里发生了什么

可以拆成四件事来看：

1. model 这里选择了一个 LangChain 支持的模型标识。LangChain 会按统一接口去适配底层 provider。

2. tools 这里把 get_weather 注册成 agent 可用工具。对模型来说，这相当于“模型可以调用这个能力”。

3. system_prompt 这里定义 agent 的全局行为边界，比如输出风格、角色、约束。

4. messages 真正的输入不是一段裸字符串，而是一组消息。这个设计和现代 chat / agent 接口是一致的。

5.2 为什么这个例子适合作为第一步

因为它刚好能让你看到 LangChain 最重要的三层拼接：

• 模型
• 工具
• agent loop

一旦这个例子跑通，你下一步通常就可以自然扩展到：

• 多个工具
• 结构化输出
• 检索
• memory
• tracing

5.3 一个很重要的实践建议

刚开始时，不要一上来就做太多“高级能力叠加”。

更稳的节奏通常是：

1. 先跑通一个单工具 agent
2. 再观察它什么时候会调工具、什么时候不会
3. 再补 structured output 或 retrieval
4. 再接 LangSmith 做 tracing
5. 真正需要更复杂状态编排时，再考虑 LangGraph

这个顺序通常比“一开始把所有抽象都堆满”更容易学明白，也更容易调试。

6. 和本专题现有章节怎么对应

如果把这个 AI 专题理解成一条学习路径，那么 LangChain 最适合放在“已经理解基础能力，准备开始把这些能力装进一个框架里”的位置。

可以这样对照看。

6.1 先补基础，再看 LangChain

先看这些基础章节，再看本文，会更容易理解 LangChain 在封装什么：

• Prompt Engineering Glossary
• Context Engineering Guide
• RAG Intro and Practice
• Tool Use and Function Calling

对应关系可以理解成：

• Prompt / Context：决定 agent 怎么想、怎么拿上下文
• Tool Use：决定 agent 怎么和外界交互
• RAG：决定 agent 怎么拿外部知识
• LangChain：把这些能力更快组装进一个应用框架里

6.2 和 Agent 工程章节的关系

往工程化继续推进时，本文和这些内容一起看会更顺：

• Agent Engineering Intro
• Workflow vs Agent
• Agent Memory and State
• Evaluation and Evals Intro
• Agent Observability and Debugging

对应方式大致是：

• 本文回答 用什么框架更快起步
• Agent Engineering 系列回答 系统应该怎么设计和落地
• Observability / Evals 系列回答 系统上线前后怎么验证和排查

6.3 和现有代码示例章节的关系

直接动手写代码时，本文和这些章节可以顺着读下去：

• Minimal Agent Code Implementation Examples
• Tool-Using Agent Code Implementation Examples
• RAG Agent Code Implementation Examples
• AI Agent Tech Stack and Framework Comparison

一个很实用的阅读顺序是：

1. 先读本文，搞清楚 LangChain 在整个栈里的位置
2. 再看 AI Agent 技术栈与框架对比，建立整体选型判断
3. 再看 Minimal Agent 和 Tool-Using Agent 示例，把抽象落到代码
4. 如果需要引入知识库，再看 RAG Agent 示例
5. 如果要上线、调试、评测，再串到 observability 和 evals 章节

6.4 在这个专题里，本文最适合充当什么角色

如果要给本文定一个位置，我会把它定义成：

从“基础概念”过渡到“框架落地”的那一篇桥接文档。

它不是最底层原理文，也不是最完整的工程实战文，而是帮助你回答：

• 现在要不要上 LangChain
• 上了之后它到底替我解决了什么
• 后面如果继续深入，该往 LangGraph 和 LangSmith 哪个方向走

7. 一份务实的选型建议

如果还在犹豫到底该怎么开始，可以先按一个务实顺序来：

7.1 你是初学者

建议路线：

1. 先理解 prompt、tool calling、RAG 这些基础
2. 手写一个极小 demo
3. 再用 LangChain 重写同样的 demo
4. 对比两版代码的差异

这样你最容易真正理解 LangChain 的价值，而不是把它当黑盒。

7.2 已经想开始做第一个可用 agent

建议路线：

1. 直接用 LangChain 起步
2. 先做一个单 agent、少量工具、少量状态的版本
3. 尽早接 LangSmith tracing
4. 等系统复杂度上来，再决定是否下沉到 LangGraph

7.3 已经在做复杂 agent 系统

建议路线：

1. 把 LangChain 当作高层开发入口
2. 对需要精细控制的部分考虑 LangGraph
3. 把 LangSmith 当作长期工程基础设施，而不是“最后才补”的可选项

8. 结论

最后把这篇文档压缩成几句话：

• LangChain 的核心价值，是帮你更快构建 agent 和 LLM application。
• 它最适合“已经懂一点基础、准备把系统真正搭起来”的阶段。
• LangChain 和 LangGraph 不是非此即彼的关系，前者更高层，后者更底层，且前者的 agents 本身就建立在后者之上。
• LangSmith 则偏横向平台层，负责 tracing、evaluation、debugging、deployment。
• 如果现在要做第一个真正可运行的 agent，LangChain 往往是一个非常务实的起点。
• 如果目标是学习底层原理，或者你需要极端透明、极端可控的流程，自己手写或直接用 LangGraph 可能更合适。

9. 官方参考链接

• LangChain Overview
• LangGraph Overview
• LangSmith Docs