2026 年 LangChain 代理：ReAct、LangGraph 和生产模式

AgentExecutor 与 LangGraph：发生了什么变化及其重要性

了解迁移路径需要了解 AgentExecutor 被停用的原因。它不是任意的——当开发人员尝试构建生产系统时，它遇到了基本的架构限制。

最痛苦的 AgentExecutor 限制是无法在运行中暂停并稍后恢复。任何真正的工作流程——想想“起草报告，等待人工批准，然后发布”——都需要跨时间界限的持久状态。 LangGraph 的检查点本身就解决了这个问题。

ReAct 模式：循环推理 + 行动

ReAct（Reason + Act）是大多数浪链代理背后的基本激励模式。它指示法学硕士在两种模式之间交替： 想法 （关于下一步该做什么的内部推理）和 行动 （使用特定参数调用特定工具）。

在实践中，循环看起来像这样：

1. 想法： 法学硕士对用户的请求和可用工具进行推理。
2. 行动： LLM 输出结构化工具调用（名称+参数）。
3. 观察： 该工具执行并返回结果，附加到上下文中。
4. 又想： 法学硕士对观察结果进行了推理。
5. 最终答案： 当法学硕士确定它有足够的信息时，它会输出最终响应。

在 LangGraph 中，每个步骤都是一个 节点 在图表中。 LLM节点检查后的条件边：“模型是否调用了工具，或者是否输出了最终答案？” - 以及相应的路线。这使得 ReAct 循环变得明确且可检查，而不是隐含在黑盒执行器中。

现代法学硕士（GPT-4o、Claude 3.7、Gemini 2.5）通过其函数调用/工具使用 API 本地处理 ReAct。您不再需要手动设置“想法/行动/观察”字符串的格式 - 模型的工具使用功能可以在 API 级别处理此问题。 LangGraph 干净地包装了这一点，因此您的节点可以专注于业务逻辑。

逐步构建 LangGraph 代理

这是 Python 中的最小 LangGraph 代理模式。每个生产代理都是这个骨架的变体。

1. 定义状态

状态是流经每个节点的单一事实来源。使用 TypedDict 或 Pydantic 模型：

from typing import Annotated, Sequence
from langchain_core.messages import BaseMessage
from langgraph.graph.message import add_messages
from typing_extensions import TypedDict

class AgentState(TypedDict):
    messages: Annotated[Sequence[BaseMessage], add_messages]
    # add any custom fields your agent needs
    context: str
    iteration_count: int

2. 定义工具

工具是用 @tool 修饰的普通 Python 函数。文档字符串成为 LLM 看到的工具描述：

from langchain_core.tools import tool

@tool
def search_web(query: str) -> str:
    """Search the web for current information about a topic."""
    # your search implementation here
    return results

@tool
def write_file(filename: str, content: str) -> str:
    """Write content to a file on disk."""
    with open(filename, 'w') as f:
        f.write(content)
    return f"Written {len(content)} chars to {filename}"

tools = [search_web, write_file]

3. 构建图表

from langgraph.graph import StateGraph, END
from langgraph.prebuilt import ToolNode
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o").bind_tools(tools)

def agent_node(state: AgentState):
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

def should_continue(state: AgentState):
    last_message = state["messages"][-1]
    if last_message.tool_calls:
        return "tools"
    return END

graph = StateGraph(AgentState)
graph.add_node("agent", agent_node)
graph.add_node("tools", ToolNode(tools))
graph.set_entry_point("agent")
graph.add_conditional_edges("agent", should_continue)
graph.add_edge("tools", "agent")

app = graph.compile()

4. 添加持久性检查点

from langgraph.checkpoint.sqlite import SqliteSaver

checkpointer = SqliteSaver.from_conn_string("./agent_memory.db")
app = graph.compile(checkpointer=checkpointer)

# Now every run is persisted and resumable
config = {"configurable": {"thread_id": "user-session-123"}}
result = app.invoke({"messages": [("human", "Research LangGraph and write a summary")]}, config)

JavaScript / TypeScript 中的 LangGraph：全功能奇偶校验

截至 2026 年，@langchain/langgraph 具有与 Python SDK 相同的完整功能。如果您正在构建 Node.js 后端、Next.js 服务器操作或 Nuxt API 路由，我们将全力支持您。

import { StateGraph, END } from "@langchain/langgraph";
import { ChatOpenAI } from "@langchain/openai";
import { tool } from "@langchain/core/tools";
import { z } from "zod";

// Define a tool with Zod schema
const searchWeb = tool(
  async ({ query }) => {
    const results = await yourSearchFunction(query);
    return results;
  },
  {
    name: "search_web",
    description: "Search the web for current information",
    schema: z.object({ query: z.string() }),
  }
);

// State type
interface AgentState {
  messages: BaseMessage[];
}

const llm = new ChatOpenAI({ model: "gpt-4o" }).bindTools([searchWeb]);

// Build graph — identical pattern to Python
const graph = new StateGraph<AgentState>({ channels: messagesStateReducer })
  .addNode("agent", async (state) => ({
    messages: [await llm.invoke(state.messages)],
  }))
  .addNode("tools", new ToolNode([searchWeb]))
  .addEdge("__start__", "agent")
  .addConditionalEdges("agent", shouldContinue)
  .addEdge("tools", "agent");

const app = graph.compile();

JS/TS SDK 支持相同的检查点（用于开发的内存中，用于生产的 PostgreSQL）、相同的流 API (streamEvents) 以及相同的 LangSmith 跟踪集成。心理模型在语言之间直接转移。

多代理架构：协调器和子图

单代理系统很快就会达到极限：上下文窗口溢出、专业化受到影响、复杂的任务需要协调。到 2026 年，生产 LangGraph 部署几乎总是使用多代理模式。

三个核心模式

LangGraph通过以下方式实现多代理系统 子图组成。每个专家代理都是一个编译图，作为节点嵌入到父协调器图中。状态可以在级别之间流动，每个子图可以有自己的检查指针和内存。

生产模式：玩具演示没有向您展示的内容

让 LangGraph 代理在 Jupyter 笔记本中工作是一回事。大规模可靠地运行它是另一回事。以下是将原型与生产分开的模式。

错误处理和重试逻辑

工具故障是不可避免的——速率限制、网络超时、输出格式错误。 LangGraph 为您提供了两个杠杆：节点级 try/catch，将错误消息返回给 LLM（让它正常恢复），以及边缘上的图形级重试策略。

迭代限制

编译时始终设置 recursion_limit 。没有它，混乱的 LLM 可能会无限循环并消耗您的 API 预算。对于大多数任务来说，合理的默认值是 25 次迭代。

app = graph.compile(checkpointer=checkpointer)
# Invoke with recursion limit
result = app.invoke(
    {"messages": [("human", query)]},
    config={"recursion_limit": 25, "configurable": {"thread_id": thread_id}}
)

人在环中断

LangGraph 的 interrupt_before 和 interrupt_after 编译选项可让您在特定节点暂停执行、向人类显示当前状态、收集输入并恢复。这对于审批工作流程、内容审查门和高风险工具调用是必不可少的。

实时用户体验流式传输

对于面向用户的应用程序，流式传输是不可协商的。 LangGraph 的 astream_events 为您提供粒度事件：哪个节点正在运行、调用了哪个工具以及逐个令牌的 LLM 输出。将其连接到服务器发送事件 (SSE) 或 WebSocket，以在 UI 中获取实时进度。

LangSmith 的可观察性

设置 LANGCHAIN_TRACING_V2=true ，每个代理运行都会获得完整的跟踪：哪些节点被触发、LLM 看到了什么、每个工具返回了什么、总延迟和令牌成本。这就是调试“为什么它调用了错误的工具？”的方法。一类生产错误——不是打印语句。

2026 年浪链代理实际使用案例

上述模式解锁了广泛的生产应用。以下是 LangGraph 代理如今提供真正价值的类别。

如何为您的用例选择正确的代理架构

并非每个问题都需要复杂的多智能体图。这是一个基于您实际想要构建的决策框架。

实用的启发式： 从可能有效的最简单模式开始，使用 LangSmith 进行检测，然后识别瓶颈。预先设计复杂性的工程师几乎总是过度设计他们的第一个代理系统。随着需求变得清晰，LangGraph 中的模式可以轻松过渡到更复杂的架构。

常见问题解答

最后的想法：LangGraph 是 2026 年的代理标准

您应该在 2026 年构建的“LangChain 代理”是 LangGraph 状态机。已弃用的 AgentExecutor 时代已经结束。 LangGraph 的显式状态、条件路由、持久检查点和本机多代理组合并不是可有可无的——它们是您在生产中信任的任何东西的先决条件。

ReAct 模式仍然是大多数任务的正确起点。仅当单个代理明显达到其极限时，才增加多代理的复杂性。从第一天起就用 LangSmith 来检测一切——没有痕迹的调试是在需要 10 分钟才能通过可见性进行诊断的问题上浪费一周时间的最快方法。

最重要的转变是Notion上的：LangGraph 代理不是带有附加工具的聊天机器人。它们是有状态、持久的系统，由法学硕士驱动控制流。像分布式系统一样设计它们——具有故障模式、重试逻辑、状态边界和可观察性——它们将给您带来连经验丰富的工程师都感到惊讶的可靠性。

如果您正在构建内容自动化、SEO 管道或多步骤研究工作流程， 易爪 是查看这些模式实际应用的最快方法 - 无需花费数周时间自行连接基础设施。