企业官网建设流程全解析

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度

在实际 AI 应用开发中，当我们需要构建一个能够自主规划、使用工具、处理复杂任务的智能体时，常常会面对 LangChain、LangGraph 和 Deep Agents 这三个名字。它们听起来相似，功能上似乎也有重叠，这让很多开发者感到困惑：它们到底是什么关系？我的项目到底该用哪一个？是选一个就够了，还是需要组合使用？

这种困惑的根源在于，这三个组件并非简单的替代关系，而是分别扮演着“工具箱”、“工作流引擎”和“开箱即用的智能体框架”三种不同的角色。理解它们各自的定位和协作方式，是高效构建可靠 AI 应用的关键。本文将从一个“打工人”团队的比喻出发，结合具体的代码示例和架构图，帮你彻底厘清 LangChain、LangGraph 和 Deep Agents 的区别与联系，并指导你如何根据项目需求做出正确的技术选型。

1. 从“打工人”团队理解三者的核心定位

我们可以将构建一个复杂 AI 应用的过程，想象成组建一个高效的项目团队。LangChain、LangGraph 和 Deep Agents 分别对应着团队中的三种关键角色。

1.1 LangChain：提供“工具”和“标准操作流程”的专家

LangChain 是这个团队里的“资深工程师”或“工具专家”。他的核心职责是提供构建模块和标准化接口。

• 他做什么？他负责准备和封装所有可能用到的“工具”（Tools），比如调用搜索引擎的 API、读取数据库的函数、操作文件的工具。同时，他也定义了与大型语言模型（LLM）交互的标准方式（如Runnable接口）、管理对话历史（Memory）的机制、以及从文档中提取知识（Retrieval）的通用流程。
• 他的产出是什么？一套高质量、可复用的“工具包”和“操作手册”。例如，一个封装好的GoogleSearchTool，或者一个标准的ConversationBufferMemory组件。
• 类比开发：就像你在项目中引入的requests库用于 HTTP 请求，或者sqlalchemy用于数据库操作。LangChain 提供了与 LLM 及其周边生态（工具、记忆、检索等）交互的底层抽象和实现。

# LangChain 的角色示例：定义工具和链 from langchain.tools import Tool from langchain.memory import ConversationBufferMemory from langchain.chains import LLMChain from langchain.prompts import PromptTemplate # 1. 定义工具（这是LangChain的强项） def get_weather(city: str) -> str: """获取城市天气。""" # 这里模拟调用天气API return f"查询{city}的天气：晴朗，25°C。" weather_tool = Tool.from_function( func=get_weather, name="get_weather", description="根据城市名称查询天气" ) # 2. 管理记忆（这也是LangChain的强项） memory = ConversationBufferMemory(memory_key="chat_history") # 3. 组合提示词和LLM形成链（基础编排） prompt = PromptTemplate.from_template("你是一个助手。历史对话：{chat_history}\n用户问题：{input}") # 假设 llm 已初始化 # chain = LLMChain(llm=llm, prompt=prompt, memory=memory)

关键点：LangChain 让“调用工具”和“管理记忆”变得规范，但它本身不负责决定“何时”以及“以何种顺序”去使用这些工具。它提供了零件，但没规定组装流水线。

1.2 LangGraph：设计“工作流”和“调度逻辑”的架构师

LangGraph 是团队里的“系统架构师”或“项目经理”。他的核心职责是设计和编排复杂、有状态的工作流程。

• 他做什么？他关注的是“控制流”。当一个任务需要多个步骤，并且这些步骤之间存在条件判断、循环、或并行处理时，就轮到 LangGraph 出场了。他用“图”（Graph）来定义工作流，节点（Node）代表一个步骤（如调用LLM、执行工具），边（Edge）代表步骤之间的流转条件。
• 他的产出是什么？一个可视化的、可持久化执行状态的工作流蓝图。例如，“先分析用户意图，如果是查询天气则调用A工具，如果是订餐则并行调用B和C工具，最后汇总结果”。
• 类比开发：就像你用Airflow或Prefect来编排数据管道，或者用状态机库来管理一个复杂业务对象的生命周期。LangGraph 专门用于编排 LLM、工具和其他任务之间的执行逻辑。

# LangGraph 的角色示例：定义有状态、有条件的工作流 from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated import operator # 1. 定义状态（State），这是工作流中流转的数据 class AgentState(TypedDict): messages: Annotated[list, operator.add] # 消息列表 next: str # 下一个节点 # 2. 定义节点（Node）函数 def llm_node(state: AgentState): """节点：调用LLM分析用户意图""" # 模拟LLM调用，根据消息内容决定下一步 last_message = state["messages"][-1]["content"] if "天气" in last_message: return {"next": "call_weather_tool"} else: return {"next": "generate_response"} def weather_tool_node(state: AgentState): """节点：调用天气工具""" # 这里会实际调用前面LangChain定义的weather_tool city = "北京" # 简化处理，实际应从state中解析 result = get_weather(city) state["messages"].append({"role": "assistant", "content": f"工具调用结果：{result}"}) return {"next": "generate_response"} def response_node(state: AgentState): """节点：生成最终回复""" state["messages"].append({"role": "assistant", "content": "这是最终回复。"}) return {"next": END} # 3. 构建图（Graph） workflow = StateGraph(AgentState) workflow.add_node("analyze", llm_node) workflow.add_node("call_weather", weather_tool_node) workflow.add_node("respond", response_node) # 4. 设置边（Edge），定义流转逻辑 workflow.set_entry_point("analyze") workflow.add_conditional_edges( "analyze", # 根据 `llm_node` 返回的 state[“next”] 值决定去向 lambda x: x["next"], { "call_weather_tool": "call_weather", "generate_response": "respond" } ) workflow.add_edge("call_weather", "respond") workflow.add_edge("respond", END) # 编译成可执行的应用 app = workflow.compile() # 运行这个工作流：app.invoke({"messages": [{"role": "user", "content": "北京天气怎么样？"}]})

关键点：LangGraph 提供了强大的流程编排能力，但它不预置具体的工具、记忆管理策略或复杂的子任务调度逻辑。你需要自己定义每个节点做什么，以及它们如何连接。

1.3 Deep Agents：自带“团队”和“管理章程”的成熟产品经理

Deep Agents 是一位“经验丰富的产品经理”或“现成的项目团队”。他自带了一套完整的、为复杂智能体任务优化过的解决方案。

• 他做什么？他不仅带来了 LangChain 提供的工具包（Tools），还内置了 LangGraph 的流程引擎，并在此基础上，额外提供了一套开箱即用的高级功能：虚拟文件系统（让智能体可以安全地读写文件）、子智能体（Subagent）生成与调度（自动将大任务拆解并分派）、技能（Skills）与记忆（Memory）管理系统（按需加载领域知识）、人类干预（Human-in-the-loop）机制（在关键操作前暂停等待批准）。
• 他的产出是什么？一个功能完整、可直接投入复杂任务（如自动代码库分析、多步骤研究报告生成）的“智能体员工”。你只需要告诉他目标，他就能自己规划、使用工具、管理上下文、甚至在需要时创建临时助手（子智能体）来并行处理。
• 类比开发：就像你使用一个成熟的、高度集成的 SaaS 平台（如 Zapier 或 n8n）来构建自动化工作流，而不是自己从零开始搭建服务器、编写调度器和设计用户界面。Deep Agents 是一个建立在 LangChain 和 LangGraph 之上的“智能体应用框架”或“智能体运行时”。

# Deep Agents 的角色示例：快速创建一个功能完备的智能体 # 注意：以下代码基于Deep Agents的公开接口示例，实际安装命令为 `pip install deepagents` from deepagents import create_deep_agent # 1. 定义一个自定义工具（依然使用LangChain的风格） def search_web(query: str) -> str: """在网络上搜索信息。""" return f"搜索 `{query}` 的结果：..." # 2. 创建Deep Agent。一句话，它就具备了规划、文件操作、子任务分发等能力。 agent = create_deep_agent( model="openai:gpt-4", # 指定模型 tools=[search_web], # 加入自定义工具 system_prompt="你是一个研究助手，擅长拆解复杂问题并使用工具。", # Deep Agents 内部已集成：虚拟文件系统、任务规划(write_todos)、子智能体(task工具)等 ) # 3. 运行智能体。它会自动决定如何使用工具、是否创建子任务等。 result = agent.invoke({ "messages": [{ "role": "user", "content": "请分析当前项目目录下的README.md文件，并总结其核心功能，然后搜索一下类似的知名开源项目。" }] }) print(result["messages"][-1]["content"])

关键点：Deep Agents 是一个更高层次的抽象。它为了追求“开箱即用”和“处理复杂任务”，做出了一系列内置的设计决策（如默认的文件系统工具、子智能体调用方式）。如果你需要极致的定制化控制，可能会觉得它“太重”或“不够灵活”；但对于快速构建功能强大的智能体，它是最高效的选择。

为了更直观地理解三者的层次和关系，可以参考下面的架构定位图：

| 应用场景与抽象层级 | 对应组件 | 核心价值 | |----------------------------|-------------------|----------------------------------------| | 开箱即用的复杂智能体应用 | Deep Agents | 内置最佳实践，快速构建可靠智能体 | | 自定义、有状态的复杂工作流 | LangGraph | 可视化、可持久化的流程编排与控制流 | | 与LLM交互的基础构件与抽象 | LangChain | 标准化工具、记忆、检索等组件的交互方式 | | 大型语言模型 (LLM) | OpenAI, Claude等 | 提供核心的推理与生成能力 |

如图所示，LangChain 是基础，LangGraph 是在此之上增加了强大的工作流编排层，而 Deep Agents 则是在前两者的基础上，封装成了一个面向复杂任务、功能集成的产品化框架。

2. 核心功能对比与选型指南

了解定位后，我们通过一个功能对比表，来具体看看在不同需求下该如何选择。

2.1 如何根据项目需求选择？

场景一：构建一个简单的基于知识库的问答机器人（RAG）

• 需求：查询外部知识库，结合LLM生成答案。流程基本固定：检索 -> 组合上下文 -> 生成。
• 选择：LangChain完全足够。它的RetrievalQA链可以轻松搞定。引入 LangGraph 或 Deep Agents 属于过度设计。

场景二：构建一个高级客服机器人，需要根据用户问题动态选择不同处理流程

• 需求：用户问题先分类。如果是“查订单”，走A流程（查DB->格式化）；如果是“投诉”，走B流程（记录->升级人工）。流程有分支和状态。
• 选择：LangGraph是最佳选择。你可以用图清晰定义分类节点、各个流程分支节点以及它们之间的流转条件。

场景三：构建一个AI研发助手，能自动分析项目代码、运行测试、并生成报告

• 需求：智能体需要能遍历文件目录、阅读代码、执行Shell命令、将大问题拆解为多个子任务（如先静态分析，再运行测试），并且要能安全地控制文件访问权限。
• 选择：Deep Agents是首选。它的内置文件系统工具、子智能体（Subagent）能力和权限控制，能直接满足这些复杂需求，极大提升开发效率。

组合使用策略： 在大型项目中，三者完全可以协同工作。常见模式是：使用 LangChain 来封装和接入各种工具与数据源；使用 LangGraph 来编排核心的业务流程和状态机；而对于其中特别复杂、需要自主规划的子模块（比如代码分析引擎），则直接使用一个 Deep Agent 作为“黑盒”组件集成到 LangGraph 的工作流中。

3. 实战：从零构建一个具备子任务拆分能力的智能体

下面我们通过一个具体的例子，分别使用 LangGraph 和 Deep Agents 来实现同一个需求，直观感受两者的不同。

需求：创建一个智能体，它能处理用户指令“帮我规划一个周末旅行，包括天气查询、景点推荐和预算估算”。

3.1 使用 LangGraph + LangChain 手动实现

这种方式需要我们自己定义工作流、工具和状态管理。

# 假设已安装：pip install langchain langgraph from typing import TypedDict, Annotated, Union from langgraph.graph import StateGraph, END import operator from langchain.tools import Tool from langchain_community.chat_models import ChatOpenAI # 示例，需替换为实际模型 from langchain_core.messages import HumanMessage, AIMessage import json # --- 1. 定义工具 (LangChain) --- def get_weather(city: str) -> str: """模拟获取天气""" return json.dumps({"city": city, "weather": "晴朗", "temp": "22-28°C"}) def recommend_attractions(city: str) -> str: """模拟推荐景点""" return json.dumps({"city": city, "attractions": ["博物馆", "城市公园", "古街"]}) def estimate_budget(city: str, days: int) -> str: """模拟估算预算""" return json.dumps({"city": city, "days": days, "estimated_budget": f"{days * 500}元"}) weather_tool = Tool.from_function(func=get_weather, name="get_weather", description="查询城市天气") attraction_tool = Tool.from_function(func=recommend_attractions, name="recommend_attractions", description="推荐城市景点") budget_tool = Tool.from_function(func=estimate_budget, name="estimate_budget", description="估算旅行预算") # --- 2. 定义状态和节点 (LangGraph) --- class TravelPlanState(TypedDict): """旅行规划的状态""" messages: Annotated[list, operator.add] # 对话消息历史 city: Union[str, None] # 解析出的城市 days: Union[int, None] # 解析出的天数 weather_info: Union[str, None] attractions_info: Union[str, None] budget_info: Union[str, None] next_step: str # 控制下一步 llm = ChatOpenAI(model="gpt-4", temperature=0) # 初始化LLM def parse_intent_and_extract_info(state: TravelPlanState): """节点1：解析用户意图，提取关键信息（城市、天数）""" user_input = state["messages"][-1].content if state["messages"] else "" # 这里简化处理，实际应用应让LLM进行解析 prompt = f""" 用户请求：{user_input} 请从中提取旅行目的地城市和预计旅行天数（周末通常为2天）。 以JSON格式返回，只包含city和days两个字段。如果无法提取，设为null。 示例：{{"city": "北京", "days": 2}} """ response = llm.invoke(prompt) try: info = json.loads(response.content) state["city"] = info.get("city") state["days"] = info.get("days", 2) # 默认2天 state["next_step"] = "plan_tasks" except: state["city"] = None state["days"] = 2 state["next_step"] = "ask_for_clarification" return state def plan_tasks(state: TravelPlanState): """节点2：规划需要执行哪些子任务""" # 在实际应用中，这里可能用LLM来规划。此处我们硬编码任务列表。 state["next_step"] = "execute_weather" return state def execute_weather(state: TravelPlanState): """节点3：执行天气查询子任务""" if state["city"]: state["weather_info"] = weather_tool.run(state["city"]) state["next_step"] = "execute_attractions" return state def execute_attractions(state: TravelPlanState): """节点4：执行景点推荐子任务""" if state["city"]: state["attractions_info"] = attraction_tool.run(state["city"]) state["next_step"] = "execute_budget" return state def execute_budget(state: TravelPlanState): """节点5：执行预算估算子任务""" if state["city"] and state["days"]: state["budget_info"] = budget_tool.run(json.dumps({"city": state["city"], "days": state["days"]})) state["next_step"] = "synthesize_report" return state def synthesize_report(state: TravelPlanState): """节点6：汇总所有信息，生成最终报告""" report = f""" # 周末旅行规划报告 **目的地**：{state.get('city', '未指定')} **天数**：{state.get('days', 2)}天 **天气情况**：{state.get('weather_info', '无')} **推荐景点**：{state.get('attractions_info', '无')} **预算估算**：{state.get('budget_info', '无')} """ state["messages"].append(AIMessage(content=report)) state["next_step"] = END return state def ask_for_clarification(state: TravelPlanState): """节点X：请求用户澄清""" state["messages"].append(AIMessage(content="请问您想去哪个城市度周末？")) state["next_step"] = END # 等待用户下次输入，这里简化处理 return state # --- 3. 构建工作流图 (LangGraph) --- workflow = StateGraph(TravelPlanState) # 添加所有节点 workflow.add_node("parse", parse_intent_and_extract_info) workflow.add_node("plan", plan_tasks) workflow.add_node("do_weather", execute_weather) workflow.add_node("do_attractions", execute_attractions) workflow.add_node("do_budget", execute_budget) workflow.add_node("report", synthesize_report) workflow.add_node("clarify", ask_for_clarification) # 设置入口和边 workflow.set_entry_point("parse") workflow.add_conditional_edges( "parse", lambda s: s["next_step"], {"plan_tasks": "plan", "ask_for_clarification": "clarify"} ) # 从plan开始，顺序执行各个任务节点，最后到report workflow.add_edge("plan", "do_weather") workflow.add_edge("do_weather", "do_attractions") workflow.add_edge("do_attractions", "do_budget") workflow.add_edge("do_budget", "report") workflow.add_edge("report", END) workflow.add_edge("clarify", END) app = workflow.compile() # --- 4. 运行工作流 --- initial_state = {"messages": [HumanMessage(content="帮我规划一下上海周末的旅行")]} result = app.invoke(initial_state) print(result["messages"][-1].content)

这个实现的要点与不足：

• 要点：我们清晰地定义了一个包含多个步骤（节点）和简单顺序逻辑的工作流。每个节点职责单一。
• 不足：
  1. 子任务管理简陋：plan_tasks节点只是简单设置了下一个节点，没有真正的任务列表管理。
  2. 没有并行：天气、景点、预算查询是顺序执行的，实际上它们可以并行。
  3. 错误处理弱：工具调用失败、信息提取失败的处理逻辑需要大量额外代码。
  4. 代码量大：为了实现一个相对简单的需求，我们需要编写大量“胶水”代码来连接各个环节。

3.2 使用 Deep Agents 实现

现在，我们看看用 Deep Agents 如何更简洁地实现类似功能，并享受其内置的高级特性。

# 假设已安装：pip install deepagents langchain-openai from deepagents import create_deep_agent import json # --- 1. 定义工具（与之前相同）--- def get_weather(city: str) -> str: """模拟获取天气""" return json.dumps({"city": city, "weather": "晴朗", "temp": "22-28°C"}) def recommend_attractions(city: str) -> str: """模拟推荐景点""" return json.dumps({"city": city, "attractions": ["博物馆", "城市公园", "古街"]}) def estimate_budget(city: str, days: int = 2) -> str: # 注意参数变化 """模拟估算预算""" return json.dumps({"city": city, "days": days, "estimated_budget": f"{days * 500}元"}) # --- 2. 创建Deep Agent --- agent = create_deep_agent( model="openai:gpt-4", # 使用OpenAI模型 tools=[get_weather, recommend_attractions, estimate_budget], system_prompt="""你是一个旅行规划助手。你的任务是： 1. 理解用户请求，提取目的地城市和旅行天数。 2. 如果需要，使用`get_weather`、`recommend_attractions`、`estimate_budget`工具获取信息。 3. 如果任务复杂（比如涉及多个不相关的子查询），你可以使用`task`工具创建子智能体来并行处理。 4. 最后，汇总所有信息，生成一份清晰的旅行规划报告。 """, # Deep Agents 自动提供了 `task` 工具用于创建子智能体 # 还内置了文件系统访问、记忆管理等能力 ) # --- 3. 运行智能体 --- result = agent.invoke({ "messages": [{ "role": "user", "content": "帮我规划一个上海周末的旅行，包括天气查询、景点推荐和预算估算。" }] }) # 输出最终结果 final_message = result["messages"][-1]["content"] print("智能体最终回复：") print(final_message) # 你还可以查看完整的执行过程（包括可能的子任务调用） print("\n--- 执行流摘要 ---") for msg in result["messages"]: if msg["role"] == "assistant" and "tool_calls" in msg: for call in msg["tool_calls"]: print(f"工具调用: {call['function']['name']} -> {call.get('result', 'N/A')}")

Deep Agents 实现的核心优势：

1. 代码极简：核心逻辑就是创建一个agent并invoke。工作流的编排、子任务的决策（是否使用task工具）交给了智能体自身和 Deep Agents 运行时。
2. 内置子智能体：如果任务足够复杂，智能体可以自动使用内置的task工具来创建子智能体处理。例如，它可以创建一个子智能体专门负责“搜索景点评价”，另一个子智能体负责“计算交通预算”。这一切不需要你手动在图里定义节点和边。
3. 开箱即用的可靠性：Deep Agents 内部已经处理了上下文管理（避免令牌超限）、工具调用的错误处理、部分结果的缓存等生产级问题。
4. 可观察性：通过集成 LangSmith，可以方便地追踪整个调用链，包括主智能体和所有子智能体的思考过程、工具调用和结果。

4. 常见问题与排查指南

在实际使用中，你可能会遇到以下典型问题。

4.1 如何选择？我该从哪个开始学？

问题：我是新手，应该直接学 Deep Agents 吗？建议：

1. 从 LangChain 开始：理解Tool、Memory、Chain这些基础概念。用它构建一个简单的 RAG 应用或工具调用机器人。这是地基。
2. 然后学习 LangGraph：当你发现任务需要“循环”（比如让智能体反复思考直到满意）或“分支”（根据不同条件走不同路径）时，开始学习 LangGraph 的StateGraph、Node、Edge概念。用它构建一个简单的客服状态机。
3. 最后评估 Deep Agents：当你需要快速构建一个功能复杂、需要文件操作、自动任务拆解的智能体时，再深入研究 Deep Agents。此时你会更能理解它内置的各个模块（如Skills、Subagent）解决了什么问题。

4.2 集成与兼容性问题

问题：我的项目已经用了很多 LangChain 的组件，能平滑迁移到 Deep Agents 吗？解答：可以。Deep Agents 与 LangChain 生态兼容性很好。

• 工具：Deep Agents 的tools参数可以直接接收 LangChain 的Tool对象。
• 模型：通过langchain-*系列的集成包（如langchain-openai），可以轻松指定模型。
• 迁移策略：可以从一个独立的、复杂的模块开始尝试 Deep Agents，而不是全盘替换。例如，在一个 LangGraph 工作流中，将某个特别复杂的节点替换为一个 Deep Agent。

4.3 性能与成本考量

问题：Deep Agents 的子智能体（Subagent）功能会导致成本暴涨吗？解答：不一定，这取决于设计。

• 优势（节省成本）：Deep Agents 的上下文管理（如总结、卸载）和子智能体隔离，可以防止单个任务的冗长上下文挤占主智能体的令牌窗口，反而可能更经济。
• 风险（增加成本）：如果智能体过度拆解任务，为每个简单查询都创建子智能体，确实会增加 LLM 调用次数。
• 最佳实践：
  1. 设定明确规则：在系统提示词中约束智能体，只有对于独立、耗时、或需要不同专业知识的子任务才使用task工具。
  2. 使用更小/更便宜的模型给子智能体：Deep Agents 允许你为子智能体配置不同的模型。
  3. 监控与评估：利用 LangSmith 等工具监控每次运行的成本和令牌消耗，优化提示词和任务拆解策略。

4.4 调试与监控

问题：Deep Agents 或 LangGraph 工作流出错了，如何调试？排查路径：

1. 启用详细日志：设置环境变量LANGCHAIN_VERBOSE=true或LANGCHAIN_TRACING_V2=true并配置LANGCHAIN_API_KEY，将 trace 记录到 LangSmith。
2. 在 LangSmith 中查看：这是最强大的方式。你可以看到：
   • 完整的执行图：每个节点的输入输出。
   • 工具调用详情：参数、结果、耗时。
   • 子智能体调用：Deep Agents 创建的每个task都会是一个独立的 trace。
   • 令牌消耗：每个步骤的详细用量。
3. 简化测试：对于 Deep Agents，先创建一个只有基础工具、没有复杂系统提示词的智能体，看是否能正常运行。然后逐步添加功能。
4. 检查工具定义：确保工具函数的文档字符串（"""..."""）清晰准确，LLM 依赖它来决定是否以及如何调用工具。

5. 总结与最佳实践

LangChain、LangGraph、Deep Agents 构成了一个从基础到高级、从灵活到集成的 AI 智能体开发生态。

• LangChain 是“标准件仓库”：当你需要连接 LLM 与外部世界（工具、数据、记忆）时，它是你的首选。最佳实践是：熟练掌握其Runnable接口、Tool抽象和Memory管理，这是所有上层建筑的基石。
• LangGraph 是“自动化流水线设计软件”：当你需要编排一个包含判断、循环、多步骤的复杂业务流程时，它是你的核心引擎。最佳实践是：先用纸笔画出状态转换图，再转化为StateGraph；将状态（State）设计得清晰明了；善用conditional_edges和interrupts实现灵活控制。
• Deep Agents 是“智能机器人成品车间”：当你需要快速交付一个能处理开放式复杂任务（如代码库分析、自动化研究）、且希望它具备规划、文件操作、子任务拆分等高级能力的智能体时，它是你的加速器。最佳实践是：充分理解其内置能力（文件系统、Skills、Subagent），在系统提示词中明确其角色和边界；对于关键操作，使用interrupt_on配置人工审核点；通过 LangSmith 持续观察和优化其行为。

对于大多数团队，建议的演进路径是：从 LangChain 构建原型验证核心功能 -> 遇到复杂流程时引入 LangGraph 进行编排 -> 在项目需要高度自主的复杂智能体时，评估并引入 Deep Agents 作为特定模块或完整解决方案。理解这三者的互补关系，能让你在 AI 应用开发的工具箱中，为每个任务选择最趁手的工具。

🚀 30+款热门AI模型一站整合，DeepSeek/GLM/Qwen 随心用，限时 5 折。 👉 点击领海量免费额度