什么是 LangChain Agents?(以及为什么大多数教程都讲错了)
最常见的误解是:LangChain agents 只是更聪明的 chains。并不是。
Chain 是固定序列:输入进去,输出出来,每一步都预先决定。Agent 是一个循环。它会推理下一步该做什么,采取行动,观察结果,然后决定任务是否完成,还是需要再走一步。
Agent 循环如下:
用户输入
->
[Reason] -> 我需要做什么?
->
[Act] -> 调用工具(搜索、计算器、API 等)
->
[Observe] -> 工具返回了什么?
->
[Repeat or Answer] -> 我完成了吗?如果没有,再次推理。
这个循环,即 Reason -> Act -> Observe,是 agents 和 chains 的根本区别。LLM 在每次迭代中都是决策者,而不只是文本转换器。
过时教程的问题是真实存在的。截至 2026 年,网上大多数 LangChain agent 内容仍然引用 LangChain 0.0.x 或早期 0.1.x 的 AgentExecutor 类。LangChain 现在已经推荐使用 LangGraph 来处理生产级 agent 工作负载。如果你跟随的指南没有提到 LangGraph,你学到的就是旧路径。
LangChain Agents 实际如何工作(2026 架构)
旧模型:AgentExecutor
AgentExecutor 是最早的编排层。你会定义一个 agent(LLM + prompt),挂上工具,然后 executor 运行循环。它能工作,但有真实限制:
- 状态控制有限:很难在执行中暂停、分支或恢复
- 多智能体支持较弱:不是为 orchestrator/subagent 模式设计的
- 失败模式不透明:生产中经常出现静默错误
当前模型:LangGraph Agents
从 LangChain v0.3+ 开始,LangGraph 是构建 agents 的推荐方式。LangGraph 把 agent 循环建模成显式状态机:一个有向图,其中每个节点是函数,边表示条件转换。
这很重要,因为:
- 你可以在循环中的任何位置检查和修改状态
- 分支逻辑(例如“如果工具失败,尝试 fallback”)是一等能力
- 多智能体系统可以自然地组合为嵌套 graphs
- Human-in-the-loop 中断非常容易添加
两种方式仍都在使用。它们的对比如下:
| 维度 | AgentExecutor(旧版) | LangGraph Agents(当前) |
|---|---|---|
| 设置复杂度 | 低 | 中 |
| 状态控制 | 有限 | 完整 |
| 多智能体支持 | 需要 workaround | 原生支持 |
| 调试 | 困难 | 优秀(LangSmith) |
| 生产就绪度 | 适合简单使用 | 推荐用于全部场景 |
| 迁移工作量 | 不适用 | 中等(1-2 天) |
| LangChain 推荐 | 已过时路径 | 活跃开发 |
结论:如果你在 2026 年从零开始,用 LangGraph 构建。如果你已有 AgentExecutor 代码,请规划迁移;API 表面变了,但Notion可以直接迁移。
用真实示例解释 ReAct 模式
ReAct(Reason + Act) 是大多数 LangChain agents 背后的核心范式。LLM 不只是回答,它会在每次行动前叙述自己的推理。
对于查询 “What's the current price of GPT-4o API calls and how much would 1 million tokens cost?”,真实 ReAct trace 如下:
Thought: 我需要找到当前 OpenAI GPT-4o 的价格。
Action: web_search
Action Input: "OpenAI GPT-4o API pricing 2026"
Observation: 截至 2026 年 Q1,GPT-4o 价格为每 100 万输入 tokens $2.50,每 100 万输出 tokens $10.00。
Thought: 我已经有价格。现在可以计算 100 万 tokens 成本。
Action: calculator
Action Input: 1000000 * 0.0000025
Observation: 2.5
Thought: 100 万输入 tokens 是 $2.50。我已有完整答案。
Final Answer: 按当前 OpenAI 价格,100 万 GPT-4o 输入 tokens 成本为 $2.50。输出 tokens 每百万为 $10.00。
每一步在 LangSmith 中都会显示为独立 span。这对调试非常关键,尤其是工具返回垃圾数据或 LLM 误解 observation 时。
AgentExecutor vs. LangGraph Agents:2026 年该用哪个?
使用 AgentExecutor,如果:
- 你已有可工作的代码,而且没有生产问题
- 任务简单、单工具、无状态
- 你需要在下一个小时内交付东西
使用 LangGraph,如果:
- 你正在构建任何会进入生产的东西
- 你需要分支、重试或多智能体协调
- 调试和可观测性对团队重要
- 你正在构建别人依赖的 SaaS 功能或内部工具
LangChain 自己的文档写道:“We recommend that new projects use LangGraph for agent workflows.” 这是直接信号,而不是随口建议。
15 分钟构建你的第一个 LangChain Agent(逐步教程,2026 API)
这里使用 LangChain v0.3+ 和 LangGraph。所有代码都附有说明。
步骤 1:安装依赖
pip install langchain langchain-openai langgraph langsmith tavily-python
步骤 2:设置环境变量
import os os.environ["OPENAI_API_KEY"] = "your-key" os.environ["TAVILY_API_KEY"] = "your-key" os.environ["LANGCHAIN_API_KEY"] = "your-key" # for LangSmith tracing os.environ["LANGCHAIN_TRACING_V2"] = "true" # enable tracing os.environ["LANGCHAIN_PROJECT"] = "my-first-agent"
步骤 3:定义工具和模型
from langchain_openai import ChatOpenAI from langchain_community.tools.tavily_search import TavilySearchResults from langgraph.prebuilt import create_react_agent # Define the tools the agent can use tools = [TavilySearchResults(max_results=3)] # Bind the model - gpt-4o works well for tool-calling agents model = ChatOpenAI(model="gpt-4o", temperature=0)
步骤 4:创建并调用 agent
# create_react_agent is the 2026 idiomatic way - no AgentExecutor needed
agent = create_react_agent(model, tools)
# Invoke with a message
result = agent.invoke({
"messages": [("human", "What are the top 3 AI agent frameworks in 2026?")]
})
# The final answer is the last message in the response
print(result["messages"][-1].content)
这就是一个可工作的 agent。它会搜索网页、推理结果,并返回有依据的答案,代码不到 20 行。
向 Agent 添加自定义工具
@tool 装饰器会把任何 Python 函数包装成 LangChain 兼容工具。docstring 会成为工具描述,一定要写好,因为 LLM 会读它来决定何时调用该工具。
from langchain_core.tools import tool
import requests
@tool
def get_domain_authority(domain: str) -> dict:
"""
Look up the Domain Authority (DA) score for a given domain.
Use this when the user asks about SEO metrics or site authority.
Returns DA score, spam score, and backlink count.
"""
response = requests.get(
f"https://api.yourseotool.com/da?domain={domain}",
headers={"Authorization": "Bearer YOUR_TOKEN"}
)
return response.json()
# Add to your agent's tool list
tools = [TavilySearchResults(max_results=3), get_domain_authority]
agent = create_react_agent(model, tools)
关键原则:docstring 越清晰,LLM 的工具选择越好。模糊描述会导致错误工具调用,这是生产中最常见的 agent 失败之一。
使用 LangSmith 开启可观测性
设置 LANGCHAIN_TRACING_V2=true 就够了。之后每次 agent 运行都会以 span 树形式出现在 LangSmith dashboard 中。
如何阅读 trace 来调试失败:
- 在 LangSmith 中打开失败运行
- 找到发生错误的 tool call span
- 检查 inputs:LLM 是否传入了正确参数?
- 检查 outputs:工具是否返回错误或意外格式?
- 检查 next Thought:LLM 是否正确理解 observation?
一个常见模式:工具把 429 rate-limit 错误作为字符串返回,LLM 把它当作有效数据,最终答案就会幻觉。LangSmith 能在几秒内让这一点可见。没有它,你只能读原始日志,希望找到 bug。
真实 LangChain Agent 使用场景(含完整示例)
1. SEO 内容研究 Agent
给定目标关键词后,搜索排名靠前页面,抓取要点,并生成结构化内容 brief。
工具:TavilySearch、custom web_scraper、content_gap_analyzer
// System prompt template
You are an SEO research assistant. When given a keyword, use the search tool to find the top 5 ranking pages, then use the scrape tool to extract their main headings and key topics...
输出:一份 Markdown brief,其中映射竞品 H2、标记缺失子主题,并给出建议大纲,90 秒内生成。
2. 客服分流 Agent
分类新进客服工单,检查知识库,起草回复,并在置信度较低时升级。
关键补充:通过 LangGraph 中的 MemorySaver 使用持久记忆
from langgraph.checkpoint.memory import MemorySaver
memory = MemorySaver()
agent = create_react_agent(
model, tools, checkpointer=memory
)
config = {"configurable": {"thread_id": "ticket-8821"}}
3. 带代码执行的数据分析 Agent
接收 CSV 文件路径和自然语言问题,编写 Python 代码分析数据,执行它,并返回发现。
工具:langchain_experimental 中的 PythonREPLTool
生产警告:一定要沙盒化代码执行。使用 Docker 或受限执行环境,绝不要在生产中以不受限制的文件系统访问运行 PythonREPLTool。
使用 LangChain 构建多智能体系统:一个 Agent 不够时
单个 agent 会遇到真实限制:长任务会撑爆上下文窗口,工具列表太大会让选择不可靠,而且无法并行化。
解决方案:使用一个 orchestrator agent 把任务拆成子任务,并委派给专门子 agents。在 LangGraph 中,subagents 只是父 graph 中的节点。orchestrator 使用 Send 将工作并行分发给 subagents 并收集结果。
Microsoft Foundry 集成(2026 年 3 月):Microsoft 的 Azure AI Foundry 现在原生支持 LangGraph agent 部署。你可以在本地定义 graph,并把它部署为带自动扩缩容、内置评估管线和 Azure AD auth 的托管 endpoint。对已经在 Azure 生态中的企业团队来说,这消除了自托管 agents 的大部分基础设施开销。
LangChain vs. CrewAI vs. AutoGen vs. LangGraph:聚焦对比
| 维度 | LangChain Agents | LangGraph | CrewAI | AutoGen |
|---|---|---|---|---|
| 学习曲线 | 中 | 中高 | 低 | 中 |
| 多智能体支持 | 有限(旧版) | 原生、一等能力 | 原生 | 原生 |
| 生产就绪度 | 中 | 高 | 中 | 中 |
| 可观测性 | 优秀(LangSmith) | 优秀(LangSmith) | 有限 | 基础 |
| 云部署 | 通过 LangServe / Foundry | 通过 LangServe / Foundry | 自托管 | 自托管 |
| 生态规模 | 非常大 | 大(子集) | 成长中 | 成长中 |
| 最适合 | 原型、RAG 管线 | 生产 agents、多智能体 | 基于角色的 crews | 对话式多智能体 |
坦诚看法:CrewAI 在多智能体场景中的学习曲线更平缓。AutoGen 擅长对话式 agent 模式。但它们都比不上 LangGraph 的可观测性故事;对需要调试生产故障的团队来说,LangSmith 是真正的差异化能力。
根据你的情况选择正确 Agent 模式
新手构建副项目
从 create_react_agent + Tavily search 开始。暂时跳过 LangGraph。先让东西跑起来,理解循环,再增加复杂度。
独立开发者发布 SaaS 功能
从第一天就使用 LangGraph。在写第一个工具前设置 LangSmith tracing。如果需要会话上下文,添加 MemorySaver。用 LangServe 部署。
企业工程团队
LangGraph + LangSmith + Azure AI Foundry(如果你们是 Azure-native)。投入评估管线,在每次部署前用已知输入数据集测试 agent。对高风险动作实现 human-in-the-loop interrupts。
生产中已有 AgentExecutor 代码
不要急着迁移。逐步把现有逻辑包装成 LangGraph nodes,不需要一次性全部重写。先给当前代码添加 LangSmith tracing(零迁移),这样你能看到实际失败点。
常见 LangChain Agent 失败以及如何修复
以下是你会在生产中遇到的五类失败,以及真正的修复方式。
1. 无限循环
症状
Agent 不断调用工具,却无法到达最终答案
诊断
检查 max_iterations 限制;默认值通常过高(25+)
修复
在 LangGraph config 中设置 recursion_limit=10。在系统提示词中添加显式 fallback
2. 工具调用幻觉
症状
Agent 编造不存在的工具参数
诊断
查看 LangSmith trace,检查原始 tool call arguments
修复
使用 Pydantic models 收紧工具输入 schema;在工具函数内部添加参数验证
3. 上下文窗口溢出
症状
长多步骤任务出现 ContextLengthExceeded 错误
诊断
在 LangSmith 中统计完整 message history 的 tokens
修复
使用 trim_messages 修剪旧 observations,或切换到 128k+ 上下文模型
4. 错误工具选择
症状
Agent 对某一类查询持续选择错误工具
诊断
把工具 docstring 与触发错误选择的查询模式进行对比
修复
用更清晰的 “use this when...” 和 “do NOT use this when...” 指引重写 docstring,这是最高杠杆修复
5. 静默错误
症状
Agent 返回自信但事实错误的答案,且没有抛出错误
诊断
工具把错误消息作为字符串返回,而不是抛出异常
修复
添加显式错误处理:抛出异常,而不是返回错误字符串
为什么 EasyClaw 在 AI 驱动内容工作流中胜出
构建 LangGraph agents 只是拼图的一块。更难的问题,尤其对内容团队来说,是把 agents 连接到可靠运行、输出一致,并且不需要 DevOps 工程师维护的生产工作流。
EasyClaw 是一个桌面原生 AI agent 平台,专为内容和 SEO 工作流构建。不同于纯云工具,EasyClaw 在本地运行:你的数据留在机器上,提示词保持私密,文件操作延迟降为零。它内置用于关键词研究、内容 brief 和文章生成的预构建 agent graphs,并已接入真实 SEO 数据源。
桌面原生
没有云依赖。你的数据、你的机器、你的控制。
预构建 Agent Graphs
SEO 研究、内容 brief 和文章生成,开箱即用。
LangSmith 就绪
从第一次运行开始内置完整 tracing 和可观测性。
常见问题
问:2026 年 LangChain 还值得学吗,还是已经被 LangGraph 替代了?
答:二者并不互斥,LangGraph 是 LangChain 生态的一部分。LangChain 提供工具集成、模型抽象和检索原语;LangGraph 提供 agent 编排层。学习 LangChain 仍然值得,但构建 agent 时应把重点放在 LangGraph,而不是 AgentExecutor。
问:从 AgentExecutor 迁移到 LangGraph 实际需要多久?
答:对于一个包含 3-5 个工具且没有持久记忆的简单 agent,预计需要 4-8 小时。Notion可以直接映射(agent -> graph node,tools -> tool nodes,executor loop -> graph edges),但 API 表面差异足够大,你需要重写编排逻辑。LangChain 迁移指南覆盖了常见模式。
问:我需要 LangSmith 吗?可以用其他可观测性工具吗?
答:LangSmith 是可选的,但强烈推荐,尤其是用于调试。LANGCHAIN_TRACING_V2=true 是获得可见性的最快路径。Arize Phoenix 和 Langfuse 等替代方案支持来自 LangGraph 的 OpenTelemetry traces。对于简单项目,使用 callbacks API 的结构化日志可能也够用。
问:2026 年 LangChain/LangGraph agents 最适合用什么模型?
答:GPT-4o 和 Claude 3.5 Sonnet 都很适合 tool-calling agents。对成本敏感的用例,GPT-4o-mini 能可靠处理许多单工具任务。关键变量是工具调用可靠性:在投入使用前,用你的具体工具 schema 测试每个候选模型。经过 function-calling 微调的模型在结构化工具调用上明显优于基础模型。
问:如何防止 LangGraph agent 跑出巨额 API 账单?
答:三个杠杆:(1) 在 graph config 中设置 recursion_limit 限制最大步骤;(2) 添加 token budget tracker,在超过阈值时抛出异常;(3) 中间推理步骤使用更便宜的模型(GPT-4o-mini),只在最终综合时调用昂贵模型。LangSmith 的成本追踪可以实时显示每次运行花费。
问:LangGraph agents 可以部署到 serverless(AWS Lambda、Vercel 等)吗?
答:可以,但有条件。无状态的单次调用 agents 在 Lambda 或 Vercel Functions 上运行良好。带持久记忆(MemorySaver)的 agents 需要外部状态存储(Redis、Postgres),在纯 serverless 设置中无法跨调用正确工作。LangServe 和 Azure AI Foundry 是为有状态需求的 agents 设计的部署选项。
最终结论:2026 年 LangChain Agents 仍然值得吗?
值得,但有一个重要前提。
LangChain 的生态优势是真实存在的。工具集成、社区、文档以及 LangSmith 可观测性工具合在一起,目前仍然难以匹敌。如果你在生产中构建任何接触 LLM 的东西,LangSmith + LangGraph 的组合是当下最成熟的调试和编排方案。
前提是:LangChain 的 API 变化曾经非常剧烈。如果你曾被破坏性变更伤过,这种挫败感是合理的。随着 v0.3,代码库已经稳定很多,但你仍应该锁定依赖,并在升级前阅读 changelog。
从这里开始,如果
你是开发者,正在构建生产级 LLM 功能,并需要可观测性、记忆和多工具编排,以及文档完善的生态。
只考虑 LangGraph,如果
你已经理解 agent Notion,并希望获得最干净、最可控、没有旧 LangChain agents 包袱的实现。
评估替代方案,如果
你正在构建基于角色的 crew 工作流(-> CrewAI),或一个简单性胜过灵活性的对话式多智能体系统(-> AutoGen)。
Agent 时代并没有放慢。LangChain 决定把 LangGraph 作为生产原语,是正确选择;2026 年正是这个选择开始兑现的一年。