如果你在2022年底开始接触大语言模型应用开发，大概率会听说过一个名字：LangChain。这个框架在ChatGPT爆火后迅速崛起，成为连接LLM与外部世界的“胶水”，让开发者能快速搭建起一个能调用工具、拥有记忆的智能体（Agent）。然而，随着项目复杂度提升，很多开发者发现，早期的LangChain虽然上手快，但在构建复杂、可控、可观测的生产级应用时，显得有些力不从心。抽象层级过高、调试困难、状态管理混乱等问题逐渐暴露。

这正是LangChain 1.0诞生的背景。它不仅仅是一次版本号升级，而是一次彻底的“核心迁移”和架构重塑。根据官方资料，1.0版本将过去的高层接口与全新的底层运行时LangGraph深度融合，进行了全面重写和标准化。这次重构的目标非常明确：在保留快速开发能力的同时，为复杂、长流程、高可靠的智能体应用提供工业级的编排与控制能力。

这篇文章要解决的，正是开发者从“玩具Demo”迈向“生产级应用”过程中最核心的痛点： 如何构建一个既灵活又可靠、既强大又可维护的AI智能体？ 我们将深入剖析LangChain 1.0的核心变革，并通过一个从零到一的完整项目实战，展示如何利用其新特性（尤其是LangGraph）来构建一个具备多步骤决策、工具调用和状态持久化能力的“科研助理”智能体。无论你是想了解LangChain 1.0的架构思想，还是急需一份能直接上手的实践指南，这篇文章都将为你提供清晰的路径和可复现的代码。

1. 这篇文章真正要解决的问题

很多开发者对LangChain的认知可能还停留在“一个能快速调用OpenAI API并串联工具的开源库”。这个认知在1.0版本之前基本正确，但也正是问题的根源。当你的智能体需要处理包含条件判断、循环、并行执行或多个智能体协作的复杂工作流时，旧版基于“链”（Chain）的线性思维就显得捉襟见肘。

LangChain 1.0的核心价值，在于它解决了“复杂智能体工作流的工程化”问题。 它不再只是一个简单的函数调用封装器，而是一个完整的智能体运行时（Agent Runtime）框架。具体来说，它解决了以下三个关键问题：

  1. 状态管理的混乱 ：在传统的多轮对话或长任务中，对话历史、中间结果、工具调用状态散落在各处。LangChain 1.0通过LangGraph的 StateGraph 引入了中心化的、强类型的状态管理，让整个工作流的生命周期变得清晰可控。
  2. 控制流的缺失 ：旧版的“Agent Executor”是一个黑盒，你很难干预其决策流程。1.0版本将执行流程显式化为“图”（Graph），节点代表原子操作（如调用LLM、执行工具），边代表执行路径。你可以轻松实现“如果A成功则执行B，否则执行C”的逻辑，甚至引入循环和并行。
  3. 生产就绪性的不足 ：开发与部署脱节。1.0版本通过 Checkpointer 机制支持状态持久化，解决了服务重启或扩缩容时的状态恢复问题。同时，与LangSmith的深度集成提供了强大的可观测性，便于调试和监控。

因此，本文的目标读者是那些已经体验过LangChain基础功能，但苦于无法将其应用于复杂业务场景的中高级开发者和架构师。我们将通过一个具体的“科研信息收集助理”案例，带你跨越从概念到生产的鸿沟。

2. 基础概念与核心原理：从“链”到“图”的范式迁移

要理解1.0的变革，必须抓住两个最核心的新概念： LangGraph 和 状态（State） 。

2.1 什么是LangGraph？

你可以把LangGraph理解为LangChain的“操作系统内核”。它提供了一个基于有向图的工作流编排引擎。与传统线性“链”相比，“图”能描述任何复杂的流程拓扑。

  • 节点（Node） ：代表一个执行单元。可以是一个简单的函数、一次LLM调用、一个工具调用，甚至是另一个子图。每个节点接收一个全局“状态”对象，处理它，并返回更新后的状态。
  • 边（Edge） ：定义了节点之间的执行顺序和条件。可以是简单的顺序连接，也可以是基于状态值的条件分支（ conditional_edge ）。
  • 状态（State） ：一个贯穿整个工作流的共享数据结构（通常用 TypedDict 或Pydantic模型定义）。它包含了工作流所需的所有上下文信息，如用户输入、中间结果、对话历史等。

这种“图”的抽象，使得智能体的行为从“不可预测的自动机”变成了“可设计、可调试的流程图”。

2.2 新旧架构对比

为了更直观地理解，我们用一个表格对比LangChain新旧版本的核心差异：

特性维度 LangChain (旧版， 0.x) LangChain 1.0 (融合LangGraph)
核心抽象 Chain (链)， Agent (代理) Graph (图) ， Runnable (可运行对象)
控制流 线性或有限的预定义模式（如ReAct）。 任意有向图 ，支持条件分支、循环、并行。
状态管理 分散在Memory、输入输出中，隐式传递。 中心化的State对象 ，在节点间显式传递，类型安全。
持久化 困难，需要自定义解决方案。 内置 Checkpointer ，支持将状态快照保存到数据库（如Postgres）。
调试难度 较高，Agent内部决策过程像黑盒。 较低 ，执行图可视化，每个节点的输入输出清晰。
适用场景 快速原型、简单的问答和工具调用。 复杂的多步骤工作流、长会话任务、多智能体协作 。
代码复杂度 简单场景下代码更简洁。 复杂场景下结构更清晰、更易于维护和扩展。

简单来说， 旧版LangChain帮你快速造一辆能跑的汽车，而1.0版本为你提供了设计整条汽车生产流水线的蓝图和工具。

2.3 核心组件一览

在深入实战前，快速了解1.0版本的几个核心组件：

  • Runnable ：所有可执行对象（LLM、工具、链、图）的通用接口。提供了 invoke , batch , stream 等统一方法。
  • Messages & Chat Models ：统一的消息格式，支持多模态内容块（ content_blocks ），无缝对接不同厂商的聊天模型。
  • Tools ：功能更强大的工具抽象，与LLM的函数调用（Function Calling）深度集成。
  • Output Parsers ：更可靠的结构化输出解析，支持Pydantic模型绑定。

接下来，我们将在一个实际项目中应用这些概念。

3. 环境准备与前置条件

我们将构建一个“科研助理”智能体，其功能是：用户输入一个研究主题，智能体自动进行网络搜索获取最新资讯，并查询arXiv获取相关论文，最后综合生成一份简要报告。

3.1 环境与工具

  • Python版本 ：建议使用 Python 3.10 或以上。
  • 包管理 ：使用 pip 进行安装。强烈建议在虚拟环境（如 venv 或 conda ）中进行。
  • 关键依赖 ：
    • langchain & langgraph : 核心框架。
    • langchain-openai : OpenAI模型集成。
    • langchain-community : 社区工具（包含我们需要的 SerpAPI 和 Arxiv ）。
    • pydantic : 用于定义结构化数据模型。
    • python-dotenv : 管理环境变量。
  • API密钥 ：
    • OpenAI API Key : 用于调用GPT模型。
    • SerpAPI Key (可选): 用于网络搜索。如果你没有，后续我们可以用其他方式模拟。
    • Google API Key (可选): 如果你想尝试Gemini模型。

3.2 初始化项目

首先，创建项目目录并安装依赖。

# 创建项目目录并进入
mkdir research_assistant && cd research_assistant

# 创建虚拟环境 (可选但推荐)
python -m venv venv
# Windows: venv\Scripts\activate
# macOS/Linux: source venv/bin/activate

# 安装核心依赖
pip install langchain langgraph langchain-openai langchain-community pydantic python-dotenv

# 可选：安装arxiv和duckduckgo-search作为免费工具替代
pip install arxiv duckduckgo-search

创建 .env 文件来安全地存储你的API密钥：

# .env
OPENAI_API_KEY=你的OpenAI密钥
# SERPAPI_API_KEY=你的SerpAPI密钥 (如果使用)

4. 核心流程拆解：构建一个LangGraph智能体

我们的“科研助理”工作流可以分解为以下几个步骤，非常适合用有向图来表示：

  1. 接收主题 ：用户输入研究主题。
  2. 并行任务 ：
    • 节点A：网络搜索 ：使用搜索工具获取最新动态和概述。
    • 节点B：论文检索 ：使用Arxiv工具获取相关学术论文。
  3. 汇总分析 ：等待以上两个并行任务完成后，将搜索结果和论文列表汇总，交给LLM生成一份结构化报告。
  4. 输出结果 ：返回生成的报告。

这个流程中，节点A和节点B可以并行执行以提高效率，这是一个典型的 有向无环图（DAG） 结构。

5. 完整示例与代码实现

让我们一步步用代码实现这个智能体。我们将先使用免费的 DuckDuckGo 搜索和 arxiv 库来模拟工具，避免API密钥的依赖。

5.1 定义工作流状态

首先，我们需要定义在整个工作流中传递的状态结构。使用 TypedDict 可以确保类型安全。

# research_assistant.py
from typing import TypedDict, List, Optional
from langchain_core.messages import BaseMessage

class ResearchState(TypedDict):
    """科研助理工作流的状态定义"""
    # 用户输入
    topic: str
    # 中间结果
    search_results: Optional[str]
    papers: Optional[List[str]]  # 存储论文标题或摘要
    # 最终输出
    report: Optional[str]
    # 用于记录对话历史（可选）
    messages: List[BaseMessage]

5.2 实现工具节点

我们需要实现两个工具节点：一个用于网络搜索，一个用于查询arXiv。

# research_assistant.py (续)
from langchain_community.tools import DuckDuckGoSearchRun
from langchain_community.utilities import ArxivAPIWrapper
import arxiv

def search_node(state: ResearchState) -> ResearchState:
    """执行网络搜索的节点"""
    print(f"[搜索节点] 正在搜索主题: {state['topic']}")
    search_tool = DuckDuckGoSearchRun()
    try:
        # 执行搜索，限制结果长度
        result = search_tool.run(f"{state['topic']} latest research news 2024")
        # 截取前1000字符作为摘要，避免状态过大
        state["search_results"] = result[:1000]
        print(f"[搜索节点] 搜索完成，结果长度: {len(state['search_results'])}")
    except Exception as e:
        state["search_results"] = f"搜索过程中出现错误: {e}"
        print(f"[搜索节点] 搜索出错: {e}")
    return state

def arxiv_node(state: ResearchState) -> ResearchState:
    """查询arXiv论文的节点"""
    print(f"[论文节点] 正在查询arXiv主题: {state['topic']}")
    arxiv_tool = ArxivAPIWrapper(top_k_results=3, doc_content_chars_max=500)
    try:
        # 使用工具查询
        result = arxiv_tool.run(state['topic'])
        # 将结果按条目分割存储
        papers_list = result.split('\n\n') if result else []
        state["papers"] = papers_list[:3]  # 保留前3条
        print(f"[论文节点] 找到 {len(state['papers'])} 篇相关论文")
    except Exception as e:
        state["papers"] = [f"查询arXiv时出错: {e}"]
        print(f"[论文节点] 查询出错: {e}")
    return state

5.3 实现报告生成节点

这个节点需要等待搜索和论文结果都就绪后，调用LLM生成报告。

# research_assistant.py (续)
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from dotenv import load_dotenv
import os

load_dotenv()  # 加载环境变量中的OPENAI_API_KEY

def report_node(state: ResearchState) -> ResearchState:
    """生成研究报告的节点"""
    print("[报告节点] 开始生成综合报告...")
    
    # 准备输入数据
    topic = state["topic"]
    search_info = state.get("search_results", "暂无网络信息")
    papers_info = "\n".join(state.get("papers", ["暂无论文信息"]))
    
    # 构建提示词模板
    prompt_template = ChatPromptTemplate.from_messages([
        ("system", "你是一位专业的科研助理。请根据提供的网络搜索摘要和学术论文列表，生成一份关于特定研究主题的简明报告。报告需包含：1) 领域概述；2) 最新动态（来自网络）；3) 关键学术论文要点；4) 未来趋势或潜在研究方向。请使用中文输出。"),
        ("user", 
         "研究主题：{topic}\n\n"
         "网络搜索摘要：\n{search_info}\n\n"
         "相关学术论文：\n{papers_info}\n\n"
         "请生成研究报告：")
    ])
    
    # 初始化LLM
    llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0.7, api_key=os.getenv("OPENAI_API_KEY"))
    
    # 创建链并调用
    chain = prompt_template | llm | StrOutputParser()
    try:
        report = chain.invoke({
            "topic": topic,
            "search_info": search_info,
            "papers_info": papers_info
        })
        state["report"] = report
        print("[报告节点] 报告生成成功！")
    except Exception as e:
        state["report"] = f"生成报告时出错: {e}"
        print(f"[报告节点] 生成报告出错: {e}")
    
    return state

5.4 组装LangGraph工作流

现在是核心部分：将各个节点组装成一个有向图工作流。

# research_assistant.py (续)
from langgraph.graph import StateGraph, START, END

# 创建状态图
workflow = StateGraph(ResearchState)

# 添加节点
workflow.add_node("search", search_node)
workflow.add_node("fetch_papers", arxiv_node)
workflow.add_node("write_report", report_node)

# 设置执行路径
# 1. 从 START 开始，并行执行 search 和 fetch_papers
workflow.add_edge(START, "search")
workflow.add_edge(START, "fetch_papers")

# 2. search 和 fetch_papers 都完成后，才能进入 write_report
# 使用 `add_conditional_edges` 或 `add_edge` 集合点
# 这里我们采用简单方式：让两个节点都指向 write_report，LangGraph会等待所有前置节点完成
workflow.add_edge("search", "write_report")
workflow.add_edge("fetch_papers", "write_report")

# 3. write_report 完成后，流程结束
workflow.add_edge("write_report", END)

# 编译图
app = workflow.compile()

5.5 运行与测试

最后，我们编写一个主函数来运行这个智能体工作流。

# research_assistant.py (续)
from langchain_core.messages import HumanMessage

def main():
    """主运行函数"""
    print("=== 科研助理智能体启动 ===")
    
    # 初始化状态
    initial_state: ResearchState = {
        "topic": "Large Language Model fine-tuning",  # 你可以修改这里测试不同主题
        "search_results": None,
        "papers": None,
        "report": None,
        "messages": [HumanMessage(content="你好，请帮我调研一下大语言模型微调的最新进展。")]
    }
    
    print(f"研究主题: {initial_state['topic']}")
    print("开始执行工作流...\n")
    
    # 执行图
    final_state = app.invoke(initial_state)
    
    print("\n=== 执行完成 ===")
    print(f"\n生成的研究报告:\n{'-'*40}")
    print(final_state["report"])
    print("-"*40)
    
    # 可选：打印其他中间结果
    # print(f"\n搜索摘要 (前200字符): {final_state.get('search_results', '')[:200]}...")
    # if final_state.get('papers'):
    #     print(f"\n检索到的论文:")
    #     for i, paper in enumerate(final_state['papers'][:2], 1):
    #         print(f"  {i}. {paper[:100]}...")

if __name__ == "__main__":
    main()

现在，运行这个脚本：

python research_assistant.py

你将看到控制台输出执行步骤，并最终得到一份关于“大语言模型微调”的综合性研究报告。这个报告结合了网络最新动态和学术论文要点。

6. 运行结果与效果验证

成功运行后，你应该能看到类似以下的输出（具体内容因搜索和模型结果而异）：

=== 科研助理智能体启动 ===
研究主题: Large Language Model fine-tuning
开始执行工作流...

[搜索节点] 正在搜索主题: Large Language Model fine-tuning
[论文节点] 正在查询arXiv主题: Large Language Model fine-tuning
[搜索节点] 搜索完成，结果长度: 856
[论文节点] 找到 3 篇相关论文
[报告节点] 开始生成综合报告...
[报告节点] 报告生成成功！

=== 执行完成 ===

生成的研究报告:
----------------------------------------
**关于大语言模型微调的最新进展研究报告**

**1. 领域概述**
大语言模型微调是指利用特定领域或任务的数据对预训练好的大规模语言模型进行针对性调整，以提升其在特定场景下的性能...

**2. 最新动态（来自网络）**
近期，大语言模型微调技术正朝着高效化、低成本化方向发展。2024年出现了更多关于参数高效微调技术的研究与应用...

**3. 关键学术论文要点**
- 论文1: 《LoRA: Low-Rank Adaptation of Large Language Models》提出了一种低秩自适应方法，大幅减少可训练参数量...
- 论文2: 《QLoRA: Efficient Finetuning of Quantized LLMs》在LoRA基础上结合量化技术，进一步降低微调内存需求...
- 论文3: 《...》

**4. 未来趋势与研究方向**
未来微调技术将更注重...
----------------------------------------

如何验证成功？

  1. 流程正确性 ：观察控制台日志，确认 search 和 fetch_papers 节点几乎同时开始（并行），并且都在 write_report 开始前完成。
  2. 内容有效性 ：报告应包含从网络和arXiv获取的真实信息，并且结构符合提示词要求。
  3. 状态完整性 ： final_state 字典中应完整包含 topic 、 search_results 、 papers 和 report 字段，没有 None 值（除非出错）。

如果运行失败，请首先检查：

  1. 网络连接 ：确保能访问外网（DuckDuckGo搜索和arXiv查询需要）。
  2. API密钥 ：如果使用OpenAI，确认 .env 文件中的 OPENAI_API_KEY 正确且有效。
  3. 依赖包 ：运行 pip list | grep langchain 确认 langchain 、 langchain-openai 、 langchain-community 等包已正确安装。

7. 常见问题与排查思路

在开发基于LangChain 1.0和LangGraph的智能体时，你可能会遇到以下典型问题：

问题现象 可能原因 排查方式 解决方案
ImportError: cannot import name 'StateGraph' langgraph 库未安装或版本不兼容。 检查 pip list 中 langgraph 的版本。 运行 pip install langgraph --upgrade 。确保 langchain 和 langgraph 版本匹配。
节点函数修改后，图行为未改变 图被编译( compile )后，其节点逻辑已被固化。 确认是否在修改节点函数后重新编译了图。 每次修改节点函数后，必须重新执行 workflow.compile() 。
并行节点未同时执行 错误地使用了 add_edge 导致串行依赖。 检查边的连接逻辑。确保并行节点的前驱都是 START 或同一个节点。 使用 add_edge(START, "node_a") 和 add_edge(START, "node_b") 来实现并行。使用 add_edge(“node_a”, “node_c”) 和 add_edge(“node_b”, “node_c”) 来实现汇聚。
状态（State）字段更新不生效 在节点函数中直接对传入的 state 字典进行了修改，但LangGraph可能期望返回一个新的字典。 检查节点函数是否返回了更新后的 state 。 确保节点函数总是返回一个完整的、更新后的状态字典 。遵循函数式编程思想，避免副作用。
LLM调用超时或报错 网络问题、API密钥无效、额度不足或模型服务不稳定。 1. 检查网络。
2. 验证API密钥。
3. 查看OpenAI控制台用量和错误信息。		 1. 设置 request_timeout 参数。
2. 实现重试机制（可使用 tenacity 库）。
3. 考虑降级到更稳定的模型（如 gpt-3.5-turbo ）。
工具调用失败（如搜索无结果） 工具API变化、输入格式错误或网络拦截。 1. 单独测试工具函数。
2. 查看工具返回的原始错误信息。		 1. 在工具调用外包裹 try...except ，在错误时返回友好信息到state。
2. 考虑使用备用工具或模拟数据。
生成的报告内容空洞或格式错误 提示词（Prompt）设计不佳或LLM未遵循指令。 启用 verbose=True 查看发送给LLM的实际提示内容。 1. 优化系统提示词，明确指令和格式。
2. 使用 with_structured_output 绑定Pydantic模型来强制结构化输出。
3. 在提示词中加入Few-shot示例。
工作流在某个节点后卡住 节点函数有未处理的异常，或状态流转条件不满足。 在每个节点函数内增加详细的日志打印。使用 app.invoke(initial_state, debug=True) （如果支持）查看执行轨迹。 1. 确保所有可能的异常都被捕获并处理。
2. 检查 conditional_edge 的条件函数逻辑是否正确。

8. 最佳实践与工程建议

将上述Demo推进到生产环境，你需要考虑更多工程化因素。

8.1 状态持久化与检查点（Checkpointing）

对于长时运行或需要故障恢复的智能体，状态持久化至关重要。LangGraph提供了 Checkpointer 接口。

from langgraph.checkpoint import MemorySaver
from langgraph.graph import StateGraph

# 在编译图时加入检查点存储器
memory = MemorySaver()
app = workflow.compile(checkpointer=memory)

# 使用线程ID或会话ID来区分不同运行实例
config = {"configurable": {"thread_id": "user_session_123"}}
initial_state = {...}
# 第一次调用，会创建检查点
result1 = app.invoke(initial_state, config=config)
# 模拟后续调用，可以从上次状态恢复（例如从另一个服务实例）
# 通过相同的 config 可以加载历史状态
result2 = app.invoke({"topic": "新的问题"}, config=config)

生产环境中，可以将 MemorySaver 替换为 PostgresSaver 等后端，将状态保存到数据库。

8.2 可观测性与调试：集成LangSmith

LangSmith是LangChain官方的监控调试平台。它能可视化工作流的执行过程，记录每个节点的输入输出，极大提升调试效率。

import os
os.environ["LANGCHAIN_TRACING_V2"] = "true"
os.environ["LANGCHAIN_API_KEY"] = "你的LangSmith API密钥"
os.environ["LANGCHAIN_PROJECT"] = "My Research Assistant"  # 设置项目名

# 之后所有通过LangChain/LangGraph的调用都会被记录到LangSmith
result = app.invoke(initial_state)

在LangSmith界面，你可以看到完整的执行图、每个步骤的耗时、传递给LLM的精确提示词以及返回结果。

8.3 性能优化

  • 异步执行 ：对于IO密集型的节点（如网络请求、数据库查询），使用异步函数 async def 并在节点中调用 asyncio.gather 来并行执行，可以显著提升吞吐量。LangGraph原生支持异步节点。
  • 缓存 ：对于重复的、成本高的LLM调用或工具查询，使用 LangChain 的缓存功能（如 InMemoryCache 、 RedisCache ）。
  • 模型选择 ：在非关键路径上使用更小、更快的模型（如 gpt-3.5-turbo ），仅在需要高质量生成的节点使用 gpt-4 。

8.4 安全与可靠性

  • 工具权限控制 ：严格限制工具的能力。例如，一个文件写入工具应该只允许写入特定沙箱目录。
  • 用户输入净化 ：防止提示词注入攻击。对用户输入进行必要的清洗和校验。
  • 设置超时与重试 ：为LLM调用和外部工具调用设置合理的超时时间，并实现指数退避的重试策略。
  • 内容过滤 ：在LLM调用前后加入内容安全过滤层，防止生成有害或不适当的内容。

9. 总结与后续学习方向

通过本文的实践，我们完成了一次从旧版LangChain“链式思维”到1.0“图式思维”的升级。我们构建的“科研助理”智能体虽然只是一个示例，但它清晰地展示了LangGraph如何将复杂的、多步骤的、可能并行的AI工作流，建模成一个清晰、可维护、可观测的状态机。

LangChain 1.0的核心优势 在于它 统一了抽象 。无论是简单的提示链，还是复杂的多智能体协作，你现在都可以用同一套“状态”和“图”的概念来设计和实现。这种统一性降低了心智负担，也让代码更容易测试和扩展。

下一步，你可以从以下几个方向深化：

  1. 探索条件路由 ：在我们的例子中，流程是固定的。尝试修改图，让 report_node 根据搜索结果的 质量 （例如，是否包含足够信息）来决定是生成报告还是跳转回 search_node 进行更深入的查询。这需要使用 add_conditional_edges 方法。
  2. 引入人工审核节点 ：在关键节点（如报告发布前）加入“人工审核”节点，实现 Human-in-the-Loop 。这可以通过LangGraph的 interrupt 机制或创建一个等待外部输入（如API回调）的节点来实现。
  3. 构建多智能体系统 ：创建多个具有不同专长的智能体（例如，一个负责搜索，一个负责分析，一个负责撰写），并使用LangGraph协调它们之间的通信和协作。
  4. 深入集成向量数据库 ：将 search_results 和 papers 的内容存入向量数据库（如Chroma、Weaviate），让报告生成节点能够进行检索增强生成（RAG），引用更具体的信息。
  5. 部署为API服务 ：使用 FastAPI 或 LangServe 将编译好的 app 封装成RESTful API，供前端或其他服务调用。

LangChain 1.0的这次“核心迁移”，标志着AI应用开发正从早期的“拼接脚本”阶段，走向真正的“软件工程”阶段。掌握以状态和图为核心的编程范式，是你构建下一代复杂、可靠、可维护的AI智能体应用的关键。建议你从官方文档的 LangGraph 部分开始，深入研究其更高级的特性，如持久化检查点、多智能体通信模式等，这将为你打开AI工程化开发的新大门。

# 工作流
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

百万Token不是数字游戏：Kimi K3完整吞下10万行代码库后，我测出了它的真实理解力

avatar 亚马逊云科技技术品牌专区
cover

【2026最新版】Codex换肤助手下载和使用教程：一键美化 Codex 客户端，支持自定义主题

avatar 亚马逊云科技技术品牌专区

FastAPI + OpenAI 兼容协议 + DeepSeek 实战：大模型 Function Calling 工具调用全拆解

模型本身不能直接查天气、查数据库。我们告诉模型"你有这些函数可用"，模型在觉得需要时返回"我想调用某个函数、参数是这样"，真正的函数由我们本地执行，再把结果交还给模型整理成话。这就是"模型决策 + 本地执行"的混合模式。

avatar 亚马逊云科技技术品牌专区