先说结论。如果你想系统理解 Python Agent 框架LangChain 仍然值得作为第一篇。它不是最轻的也不是最“自动化”的但它把 Agent 应用里的关键零件都摆出来了模型、工具、状态、记忆、middleware、多 Agent 路由和 tracing。如果你只是想马上做一个复杂自动化 AgentLangChain 本身可能不够省事后面大概率会接 LangGraph 或 Deep Agents。但如果你想先看懂 Agent 应用到底由哪些模块组成LangChain 是很好的入口。1. 它到底解决什么问题LangChain 解决的不是“调用一次大模型”。它解决的是当一个 LLM 应用开始需要工具、上下文、记忆、权限控制、调试追踪时代码应该怎么组织。最小 Agent 入口现在非常直接from langchain.agents import create_agent你给它模型、工具和系统提示词它帮你跑一个基础 agent loop模型先判断要不要调用工具工具执行完把结果交回模型模型继续推理直到输出最终结果。2. 先看架构LangChain 把 Agent 拆成了什么可以把 LangChain Agent 理解成一个预组装好的运行图用户输入 ↓ messages / state ↓ 模型节点判断下一步 ↓ 工具节点执行工具 ↓ 工具结果写回 messages / state ↓ 继续模型调用或输出答案它底层依赖 LangGraph所以不是一个完全黑盒的“聊天机器人”。它更像一个预设好的 agent workflow。几个核心模块model负责推理和决定下一步tools让模型调用外部能力state保存 messages 和中间状态checkpointer保存短期会话状态store保存跨会话长期记忆middleware在模型调用、工具调用前后插入控制逻辑LangSmith看清每一步 trace3. 记忆、工具、多 Agent 是怎么处理的记忆LangChain 把记忆分成短期和长期。短期记忆就是当前会话里的上下文。它通常通过 checkpointer 保存比如同一个thread_id下的历史 messages。开发时可以用内存版生产环境通常要换成 Postgres 这类持久化方案。长期记忆通过 store 做。它更像一个跨会话资料库可以保存用户偏好、业务对象状态、历史任务结果等。简单说checkpointer 当前对话怎么接上 store 跨对话的信息怎么留下工具调用LangChain 的工具可以直接用 Python 函数定义。def get_weather(city: str) - str: Get weather for a given city. return fIts always sunny in {city}!函数名、参数类型、docstring 都会影响模型是否能正确调用工具。一个好的工具不只是“能跑”还要让模型知道什么时候该用、参数该怎么传、结果代表什么。多 Agent 交流LangChain 的多 Agent 不是“几个机器人随便群聊”。官方更推荐几种工程化模式subagent主 Agent 把子 Agent 当工具调用handoff通过工具调用切换当前负责的 Agentrouter先判断任务类型再路由到专门 Agentcustom workflow用 LangGraph 自己控制状态图它的核心还是 state、tool call 和 routing。多个 Agent 的交流本质上是状态和消息在不同 Agent 之间转移。4. 最小上手示例安装pip install -qU langchain langchain[openai]最小代码from langchain.agents import create_agent def get_weather(city: str) - str: Get weather for a given city. return fIts always sunny in {city}! agent create_agent( modelopenai:gpt-5.4, tools[get_weather], system_promptYou are a helpful assistant, ) result agent.invoke({ messages: [{role: user, content: Whats the weather in San Francisco?}] }) print(result[messages][-1].content)成功标志模型能识别天气问题调用get_weather最后输出带 San Francisco 的回答。官方示例里也会打印最后一条 message 的content_blocks方便你看到工具调用和最终文本。5. 一个真实使用场景我会用 LangChain 做一个“客服数据助手”用户问订单问题 ↓ Agent 判断是否需要查订单 ↓ 调用 search_orders 工具 ↓ 调用 refund_policy 工具 ↓ 生成回复建议 ↓ 保存会话状态这个场景里LangChain 的价值不是回答得多聪明而是你可以把工具、状态、权限、trace 拆开管理。6. 它不适合什么第一不适合完全不想理解架构的人。LangChain 的概念不少Agent、Tool、State、Middleware、Store、Checkpointer、LangGraph、LangSmith 都要看。第二不适合只想快速做一个“全自动复杂 Agent”的人。它是基础框架不是成品 Agent。第三如果你的工作流本来就是复杂状态图直接学 LangGraph 会更干脆。7. 和同类框架比它的位置在哪里和 LangGraph 比LangChain 更高层LangGraph 更底层。LangChain 帮你预组装常见 agent loopLangGraph 让你自己画状态图。和 CrewAI 比CrewAI 更像“组团队”LangChain 更像“搭运行时”。和 AutoGen 比AutoGen 更偏多 Agent 对话协作LangChain 更偏工具、状态和生产可控性。8. 结论LangChain 适合作为 Agent 框架系列的第一篇。它让你先建立这张地图模型负责推理 工具负责行动 状态负责过程 记忆负责延续 middleware 负责控制 LangSmith 负责观察 LangGraph 负责底层运行先用 LangChain 跑通一个单 Agent 两个工具 短期记忆 tracing再看后面的 LangGraph、CrewAI、AutoGen会清楚很多。
Agent 框架别急着乱学：先用 LangChain 搞懂 7 个基本模块
先说结论。如果你想系统理解 Python Agent 框架LangChain 仍然值得作为第一篇。它不是最轻的也不是最“自动化”的但它把 Agent 应用里的关键零件都摆出来了模型、工具、状态、记忆、middleware、多 Agent 路由和 tracing。如果你只是想马上做一个复杂自动化 AgentLangChain 本身可能不够省事后面大概率会接 LangGraph 或 Deep Agents。但如果你想先看懂 Agent 应用到底由哪些模块组成LangChain 是很好的入口。1. 它到底解决什么问题LangChain 解决的不是“调用一次大模型”。它解决的是当一个 LLM 应用开始需要工具、上下文、记忆、权限控制、调试追踪时代码应该怎么组织。最小 Agent 入口现在非常直接from langchain.agents import create_agent你给它模型、工具和系统提示词它帮你跑一个基础 agent loop模型先判断要不要调用工具工具执行完把结果交回模型模型继续推理直到输出最终结果。2. 先看架构LangChain 把 Agent 拆成了什么可以把 LangChain Agent 理解成一个预组装好的运行图用户输入 ↓ messages / state ↓ 模型节点判断下一步 ↓ 工具节点执行工具 ↓ 工具结果写回 messages / state ↓ 继续模型调用或输出答案它底层依赖 LangGraph所以不是一个完全黑盒的“聊天机器人”。它更像一个预设好的 agent workflow。几个核心模块model负责推理和决定下一步tools让模型调用外部能力state保存 messages 和中间状态checkpointer保存短期会话状态store保存跨会话长期记忆middleware在模型调用、工具调用前后插入控制逻辑LangSmith看清每一步 trace3. 记忆、工具、多 Agent 是怎么处理的记忆LangChain 把记忆分成短期和长期。短期记忆就是当前会话里的上下文。它通常通过 checkpointer 保存比如同一个thread_id下的历史 messages。开发时可以用内存版生产环境通常要换成 Postgres 这类持久化方案。长期记忆通过 store 做。它更像一个跨会话资料库可以保存用户偏好、业务对象状态、历史任务结果等。简单说checkpointer 当前对话怎么接上 store 跨对话的信息怎么留下工具调用LangChain 的工具可以直接用 Python 函数定义。def get_weather(city: str) - str: Get weather for a given city. return fIts always sunny in {city}!函数名、参数类型、docstring 都会影响模型是否能正确调用工具。一个好的工具不只是“能跑”还要让模型知道什么时候该用、参数该怎么传、结果代表什么。多 Agent 交流LangChain 的多 Agent 不是“几个机器人随便群聊”。官方更推荐几种工程化模式subagent主 Agent 把子 Agent 当工具调用handoff通过工具调用切换当前负责的 Agentrouter先判断任务类型再路由到专门 Agentcustom workflow用 LangGraph 自己控制状态图它的核心还是 state、tool call 和 routing。多个 Agent 的交流本质上是状态和消息在不同 Agent 之间转移。4. 最小上手示例安装pip install -qU langchain langchain[openai]最小代码from langchain.agents import create_agent def get_weather(city: str) - str: Get weather for a given city. return fIts always sunny in {city}! agent create_agent( modelopenai:gpt-5.4, tools[get_weather], system_promptYou are a helpful assistant, ) result agent.invoke({ messages: [{role: user, content: Whats the weather in San Francisco?}] }) print(result[messages][-1].content)成功标志模型能识别天气问题调用get_weather最后输出带 San Francisco 的回答。官方示例里也会打印最后一条 message 的content_blocks方便你看到工具调用和最终文本。5. 一个真实使用场景我会用 LangChain 做一个“客服数据助手”用户问订单问题 ↓ Agent 判断是否需要查订单 ↓ 调用 search_orders 工具 ↓ 调用 refund_policy 工具 ↓ 生成回复建议 ↓ 保存会话状态这个场景里LangChain 的价值不是回答得多聪明而是你可以把工具、状态、权限、trace 拆开管理。6. 它不适合什么第一不适合完全不想理解架构的人。LangChain 的概念不少Agent、Tool、State、Middleware、Store、Checkpointer、LangGraph、LangSmith 都要看。第二不适合只想快速做一个“全自动复杂 Agent”的人。它是基础框架不是成品 Agent。第三如果你的工作流本来就是复杂状态图直接学 LangGraph 会更干脆。7. 和同类框架比它的位置在哪里和 LangGraph 比LangChain 更高层LangGraph 更底层。LangChain 帮你预组装常见 agent loopLangGraph 让你自己画状态图。和 CrewAI 比CrewAI 更像“组团队”LangChain 更像“搭运行时”。和 AutoGen 比AutoGen 更偏多 Agent 对话协作LangChain 更偏工具、状态和生产可控性。8. 结论LangChain 适合作为 Agent 框架系列的第一篇。它让你先建立这张地图模型负责推理 工具负责行动 状态负责过程 记忆负责延续 middleware 负责控制 LangSmith 负责观察 LangGraph 负责底层运行先用 LangChain 跑通一个单 Agent 两个工具 短期记忆 tracing再看后面的 LangGraph、CrewAI、AutoGen会清楚很多。
