LangChain 2026 代理商：ReAct、LangGraph 和 Production Patterns

AgentExecutor 與 LangGraph：發生了什麼變化及其重要性

了解遷移路徑需要了解 AgentExecutor 停用的原因。它不是任意的——當開發人員嘗試建立生產系統時，它遇到了基本的架構限制。

最痛苦的 AgentExecutor 限制是無法在運行中暫停並稍後恢復。任何真正的工作流程——想想「起草報告，等待人工批准，然後發布」——都需要跨時間界限的持久狀態。 LangGraph 的檢查點本身就解決了這個問題。

ReAct 模式：推理+行動循環

ReAct（理性 + 行動）是大多數 LangChain 代理背後的基本提示模式。它指示法學碩士在兩種模式之間交替： Thought （關於下一步該做什麼的內在推理）和 Action （使用特定參數呼叫特定工具）。

在實踐中，循環看起來像這樣：

1. Thought: 法學碩士對使用者的請求和可用工具進行推理。
2. Action: LLM 輸出結構化工具呼叫（名稱+參數）。
3. Observation: 該工具執行並傳回結果，附加到上下文中。
4. Thought again: 法學碩士對觀察結果進行了推理。
5. 最終答案： 當法學碩士確定它有足夠的資訊時，它會輸出最終響應。

在 LangGraph 中，每個步驟都是一個 節點 在圖表中。 LLM節點檢查後的條件邊：“模型是否調用了工具，或者是否輸出了最終答案？” - 以及相應的路線。這使得 ReAct 循環變得明確且可檢查，而不是隱含在黑盒執行器中。

現代 LLM（GPT-4o、Claude 3.7、Gemini 2.5）透過其函數呼叫/工具使用 API 本地處理 ReAct。您不再需要手動格式化“Thought/Action/Observation”字串 - 模型的工具使用功能在 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 年真實世界 LangChain 代理用例

上述模式解鎖了廣泛的生產應用。以下是 LangGraph 代理商如今提供真正價值的類別。

如何為您的用例選擇正確的代理架構

並非每個問題都需要複雜的多智能體圖。這是一個基於您實際想要建立的決策框架。

實用的啟發式： 從可能有效的最簡單模式開始，使用 LangSmith 進行檢測，然後識別瓶頸。預先設計複雜性的工程師幾乎總是過度設計他們的第一個代理系統。隨著需求變得清晰，LangGraph 中的模式可以輕鬆升級到更複雜的架構。

常見問題

最後的想法：LangGraph 是 2026 年的代理標準

您應該在 2026 年建置的「LangChain 代理程式」是 LangGraph 狀態機。已棄用的 AgentExecutor 時代已經結束。 LangGraph 的明確狀態、條件路由、持久檢查點和本機多代理組合並不是可有可無的——它們是您在生產中信任的任何東西的先決條件。

ReAct 模式仍然是大多數任務的正確起點。只有當單一代理明顯達到其極限時，才增加多代理的複雜性。從第一天起就用 LangSmith 來檢測一切——沒有痕蹟的調試是在需要 10 分鐘才能透過可見性進行診斷的問題上浪費一周時間的最快方法。

最重要的轉變是Notion上的：LangGraph 代理程式不是附加工具的聊天機器人。它們是有狀態、持久的系統，由法學碩士驅動控制流。像分散式系統一樣設計它們——具有故障模式、重試邏輯、狀態邊界和可觀察性——它們將為您帶來連經驗豐富的工程師都感到驚訝的可靠性。

如果您正在建立內容自動化、SEO 管道或多步驟研究工作流程， EasyClaw 是查看這些模式實際應用的最快方法 - 無需花費數週時間自行連接基礎設施。