LangChain
面向 LLM 应用与 agent 的通用开发框架，统一模型、tools、state、retrieval 和 agent loop 的工程接口。
#tech / ai
#resource / langchain
#type / resource
#status / growing
[!info] related notes
LangChain
这是什么
LangChain 更像一个面向 LLM 应用和 agent 的通用开发框架。它不提供模型本身，而是把模型、消息、工具、检索、状态和 agent loop 组织成统一接口。
它在系统里主要管什么
如果把 LLM 应用看成“控制层”，LangChain 主要负责这些拼装工作：
- 统一不同模型供应商的调用接口
- 把 Python 函数或外部能力封装成 tools
- 让模型在推理和工具调用之间形成 loop
- 管理 messages、state 和部分 memory 接口
- 组织 RAG 所需的 retrieval 组件
- 用 middleware、structured output 等机制收紧行为边界
核心抽象
理解 LangChain 时，最值得先抓住的不是旧时代的 chain API，而是这些较稳定的构件：
- chat model / embeddings：模型推理和向量化接口
- messages：system、human、ai、tool 等消息层
- tools：给模型看的动作接口
- agent：模型决定下一步是回答还是调工具
- state：消息、上下文和中间结果
- retrieval：documents、embedding、vector store、retriever
- middleware：在模型调用和工具调用前后做拦截、注入和控制
- structured output：把结果约束成程序可消费的结构
和 LangGraph 的关系
LangChain 更像上层开发框架；LangGraph 更像底层运行时。
- LangChain 提供更直接的 agent、tool、structured output 和 retrieval 开发体验
- LangGraph 提供状态图、分支、checkpoint、durable execution 和 HITL 这类更底层控制
- 简单 agent 可以先用 LangChain 起步；当流程需要更强状态机控制时，往往会下钻到 LangGraph
如果再加上 langsmith，三者可以粗略记成：
- LangChain 负责搭 agent 应用
- LangGraph 负责跑 stateful workflow
- LangSmith 负责 tracing、debug 和 eval
更完整的分层关系见：LangChain、LangGraph 与 LangSmith 的分层
一个典型请求怎么穿过 LangChain
从 agent 系统角度看，LangChain 最常见的执行路径是：
messages -> model -> tool call -> tool result -> model -> final output
这里真正重要的不是“多轮对话”，而是：
- 模型能否根据上下文决定该不该调用工具
- 工具返回的结果能否被重新写回消息流
- state、retrieval 和 middleware 能否让这条 loop 更稳定
所以 LangChain 的价值，本质上是把“模型 + 工具 + 消息 + 状态”组织成一套更容易开发和替换的工程接口，而不只是包一层 prompt。
常见用途
- RAG 问答或知识库助手
- 会调工具的业务 agent
- 需要结构化输出的抽取或路由系统
- 需要 tracing、状态和多步推理的 LLM 应用
使用边界
- LangChain 解决的是工程组织问题，不是“让模型自动更聪明”
- 自由度高是优点也是代价，抽象一多就容易把系统做复杂
- 需要明确区分哪些决策交给模型，哪些规则由代码硬控
相关链接 / 官方入口
- 官方文档：https://docs.langchain.com/
- Python 文档：https://python.langchain.com/