AgentState负责描述一次 Agent 运行中有哪些状态，以及节点和 Tool 应该如何读取、更新这些状态。 但是，只有 State 还不等于拥有记忆。如果没有配置持久化组件，一次 invoke() 结束后，下一次调用不会自动恢复上一

Context 适合保存用户 ID、用户名和权限等调用开始时已经确定的数据，在一次运行中通常按只读方式使用。 但是 Agent 运行起来以后，还会不断产生新的内容。例如用户消息、模型生成的工具调用、工具执行结果，以及工具从外部系统得到的数据

前文已经完成本地 Tool、流式工具调用和 Agent API 的介绍。调用 Agent 时，我们一直把用户问题放在 messages 中，但实际应用除了问题本身，通常还需要知道是谁发起了请求。 例如，一个用户询问“告诉我当前用户的年龄”，

上一篇已经介绍了 Tool 的几种定义方式，并使用 bind_tools() 手动完成了一次工具调用循环。非流式调用比较容易理解：模型一次返回完整的 AIMessage，应用从 tool_calls 中读取工具名称和参数，再执行对应函数。

前面创建天气 Agent 时，模型能够判断什么时候查询天气，并把城市名称交给 get_weather()。这个过程看起来像是模型执行了 Python 函数，实际并不是这样。 大模型只负责理解问题、选择工具并生成参数。真正查找工具、调用 Py

上一篇已经使用 langgraph dev 启动天气 Agent，并在 Studio 中看到了模型调用工具的完整过程。但 Studio 主要用于开发和调试，真正开发 Web 页面、后端服务或命令行工具时，程序还需要通过 API 调用 Age

本篇启动两个本地服务：Qwen3 负责模型推理，Agent Server 负责运行 Graph、执行工具并提供 HTTP 接口。 最终需要验证的不只是“服务端口能访问”，还要确认模型真的生成了工具调用，工具结果也确实返回模型。 1. 依赖服

本篇开始搭建第一个 LangGraph 项目：安装 CLI，认识项目配置，再使用本地 Qwen3 和一个模拟天气工具创建最小 Agent。 这一步只完成项目和 Graph，不启动 Agent Server。服务启动和调试放到下一篇。 1.

LangChain 系列已经完成模型调用、提示词、结构化输出和聊天应用，RAG 系列又补齐了 Embedding、向量数据库与检索问答。到这里，程序可以完成多轮聊天和知识库问答，但执行路径仍然由代码提前写好：先改写问题，再检索文档，最后让模

上一篇文章已经实现了一条基础 RAG 链：用户提出问题，Retriever 从 Chroma 中找到相关文档，本地 Qwen3 再根据文档回答。 这条链可以回答“什么是任务分解？”，但是连续对话时还会遇到一个问题： 用户第一轮问“什么是任

前面已经完成了 Embedding、语义搜索和三种向量数据库的原生调用，但这些示例都停在“找出相似文本”这一步。 真正的 RAG 还要把检索结果交给大语言模型，让模型只根据外部知识回答问题。本文使用一篇公开网页、本地 Qwen3-Embed

FAISS 和 Chroma 都可以直接嵌入 Python 程序。Milvus Standalone 不同，它是一个独立运行的向量数据库服务，应用通过网络端口访问。 本文章启动 Milvus 2.6.9 Standalone，使用 PyMi