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

1. 从“聊天”到“干活”：为什么现在必须理解 AI Agent

别再只把大模型当成一个更聪明的聊天机器人了。如果你还在用“用户提问，模型回答”的单轮对话模式来思考 AI 应用，那你可能已经落后了。真正的变化在于，AI 正在从“回答问题”转向“完成任务”。这就是 AI Agent 的核心价值。

一个能“干活”的 Agent，不是简单地调用一次 API，而是能自主规划、调用工具、处理结果、并循环往复直到完成目标的智能体。它像一个数字员工，你给它一个目标，比如“帮我研究一下 LangChain 1.0 的新特性并写份摘要”，它会自己去搜索、整理信息、判断信息是否足够，最后生成一份报告。这个过程涉及多次决策和外部工具调用，这就是从“对话”到“行动”的范式切换。

为什么现在动手正合适？因为支撑 Agent 稳定运行的基础设施——包括大模型本身的能力和开发框架——已经成熟。2025年底，LangChain 和 LangGraph 同步发布了 1.0 版本，这标志着一个关键节点：框架从早期的探索阶段，进入了为生产级、长周期任务提供稳定支持的阶段。过去，自己从头实现一个能稳定循环、管理状态、处理异常的 Agent 是件极其复杂的工程；现在，像 LangChain 这样的框架已经把大部分脏活累活标准化了。

所以，这篇文章不是泛泛而谈概念，而是面向两类人：一是想了解 AI 应用开发最新实践的开发者，二是好奇“Agent 到底怎么工作”的技术爱好者。我会带你拆解 LangChain 实现 Agent 的核心机制，并手把手完成一个能实际运行的“智能研究助手”。最关键的是，我会告诉你从 Demo 到可用的工程化 Agent，中间有哪些必须跨过的坑。

2. LangChain Agent 的核心工作机制：ReAct 循环与四大组件

要自己造 Agent，首先得明白它的大脑是如何运转的。LangChain Agent 的核心运行机制可以归结为一个经典的范式： ReAct 循环 。

ReAct 代表 Reasoning（推理） 和 Acting（行动） 。这不是一次性的，而是一个“思考-行动-观察-再思考”的循环过程。下面这张图清晰地展示了这个流程：

用户输入任务
      ↓
LLM推理: 思考下一步该做什么
      ↓
     决策
     /  \
需要工具  任务完成
    ↓        ↓
选择工具并生成参数 → 生成最终答案
    ↓
执行工具调用
    ↓
观察工具返回的结果
      ↓
（将结果加入上下文，回到“LLM推理”步骤）

这个循环看起来简单，但背后的工程复杂度不低。LangChain 通过一套架构将这个过程标准化，这个架构主要由四大核心组件构成：

1. LLM（大语言模型） ：这是 Agent 的“大脑”。它负责理解任务、进行逻辑推理、做出决策（比如“下一步该调用搜索工具”）并生成最终的输出文本。它不直接执行具体操作，只负责“想”。
2. Agent（智能体） ：这是“调度员”。它封装了 ReAct 循环的逻辑，负责管理整个执行流程。它根据 LLM 的决策，调用相应的工具，并将工具返回的结果整理好，再次喂给 LLM 进行下一轮思考。在 LangChain 中，一个 Agent 对象就是模型、工具和提示词的组合体。
3. Tool（工具） ：这是“工具箱”或“双手”。任何 Agent 需要与外部世界交互的能力，都需要被封装成 Tool。它可以是一个搜索 API、一个数据库查询函数、一个计算器，甚至是发送邮件的接口。Tool 的定义非常灵活，只要它能被调用并返回结果。
4. Memory（记忆） ：这是“记事本”。它负责存储状态。短期记忆（如 ConversationBufferMemory ）能记住当前对话的历史，让 Agent 拥有上下文感知能力。长期记忆则可以跨会话存储信息，比如将关键信息写入数据库。记忆机制确保了 Agent 不是“金鱼脑”，能在多轮交互中保持连贯性。

所以，一个完整的 Agent = LLM（思考决策） + Tools（执行操作） + Agent（调度循环） + Memory（记录状态） 。LangChain 框架的价值，就是把这四部分优雅地组装起来，并提供稳定的运行时（Runtime）来执行这个可能很长、很复杂的循环任务。

3. 实战入门：从零构建你的第一个智能研究助手

理论说再多不如动手跑一遍。我们来构建一个“智能研究助手”：你问它一个问题，它能自动调用网络搜索工具，查找信息，并整理出答案。

3.1 环境准备与依赖安装

首先，确保你有一个可用的 Python 环境（建议 3.8 以上）。我们将使用 LangChain 和 OpenAI 的模型。此外，为了让 Agent 能“动手”搜索，我们需要一个搜索工具的 API。这里我选用 Tavily ，它是一个为 AI 应用优化的搜索引擎 API，比直接使用通用搜索引擎的 API 更简单、返回格式更规整。

打开终端，安装必要的包：

pip install langchain langchain-openai openai tavily-python

安装完成后，你需要准备两个 API Key：

• OpenAI API Key ：用于调用 GPT 模型作为 Agent 的大脑。你可以在 OpenAI 官网获取。
• Tavily API Key ：用于网络搜索。你可以在 Tavily 官网免费注册获取。

将这两个 Key 设置为环境变量，这是管理密钥的最佳实践，避免硬编码在代码中：

# 在 Linux/macOS 的终端中
export OPENAI_API_KEY="你的-openai-api-key"
export TAVILY_API_KEY="你的-tavily-api-key"

# 在 Windows 的 PowerShell 中
$env:OPENAI_API_KEY="你的-openai-api-key"
$env:TAVILY_API_KEY="你的-tavily-api-key"

3.2 定义工具：让 Agent 拥有“搜索”能力

工具是 Agent 能力的延伸。我们首先定义一个网络搜索工具。

创建一个 Python 文件，例如 research_agent.py ，开始编写代码：

from langchain.tools import tool
from tavily import TavilyClient

# 初始化 Tavily 客户端
tavily_client = TavilyClient(api_key=“你的-tavily-api-key”) # 实践中请使用环境变量

@tool
def web_search(query: str) -> str:
    """使用 Tavily 搜索引擎在互联网上搜索信息。输入是一个搜索查询字符串，返回是搜索结果的摘要文本。"""
    try:
        # 执行搜索，限制返回3条结果以保证上下文不会过长
        response = tavily_client.search(query=query, max_results=3)
        # 从结果中提取内容并拼接成字符串
        contents = [result["content"] for result in response["results"]]
        return "\n\n".join(contents)
    except Exception as e:
        # 工具层处理异常，返回错误信息，而不是抛出异常给Agent
        return f"搜索工具调用失败: {str(e)}"

关键点解释 ：

• @tool 装饰器：这是 LangChain 的标志，它将一个普通 Python 函数标记为一个可供 Agent 调用的工具。装饰器会自动处理函数签名和描述。
• 文档字符串（Docstring） ： """使用 Tavily...""" 这部分极其重要！LLM 通过阅读这个描述来决定在什么情况下调用这个工具。描述要清晰、准确。
• 异常处理 ：在工具内部捕获异常并返回友好信息。如果工具直接抛出异常，可能会中断整个 Agent 的执行循环。让工具返回错误描述，LLM 可以据此进行下一步推理（例如，“搜索失败了，我换个问法再试一次”或“直接基于已有知识回答”）。

3.3 创建并运行你的第一个 Agent

有了工具，我们就可以组装 Agent 了。

from langchain.agents import create_agent
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate

# 1. 初始化 LLM（大脑）
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0) # 使用 gpt-4o-mini，性价比高。temperature=0 使输出更确定。

# 2. 定义系统提示词，设定 Agent 的角色和行为准则
system_prompt = """你是一个专业的研究助手。当用户提出问题时，你应该遵循以下步骤：
1. 首先，判断是否需要搜索网络来获取最新或更详细的信息。
2. 如果需要，就调用 `web_search` 工具进行搜索。
3. 仔细阅读和分析搜索返回的结果。
4. 基于搜索结果和你自身的知识，组织一个清晰、准确、完整的答案。
5. 如果一次搜索的结果不足以回答问题，你可以决定进行多次搜索。
请确保你的最终答案是基于事实的，并且引用或总结搜索到的信息。"""

# 3. 创建 Agent
agent = create_agent(
    llm=llm,
    tools=[web_search], # 传入我们定义的工具列表
    prompt=system_prompt,
    # 注意：create_agent 是 LangChain 高阶 API，它内部封装了 ReAct 循环和状态管理
)

# 4. 运行 Agent
question = "LangChain 1.0 版本相比于 0.x 版本，有哪些主要的新特性和改进？"
print(f"用户提问: {question}\n")

try:
    # 调用 Agent。输入需要符合 LangChain 的消息格式。
    response = agent.invoke({
        "messages": [
            {"role": "user", "content": question}
        ]
    })
    # 从响应中提取 Agent 的最后一条消息（即最终答案）
    final_answer = response["messages"][-1].content
    print("研究助手回答:")
    print("-" * 40)
    print(final_answer)
except Exception as e:
    print(f"Agent 运行出错: {e}")

运行这个脚本。你会看到控制台输出 Agent 的思考过程（如果设置了 verbose 模式）和最终答案。Agent 会自动执行“思考 -> 决定搜索 -> 调用 web_search -> 获取结果 -> 再思考 -> 生成答案”的完整流程。

核心洞察 ：在这个例子中，你并没有写 if question_about_langchain: then search() 这样的逻辑。你只是 告诉了 Agent 它拥有一个搜索工具，并规定了它的角色（研究助手） 。 “什么时候用搜索工具”、“用什么样的查询词”、“搜索结果是否足够” 这些决策，全部交给了 LLM。这就是 Agent 编程的核心：从“指令式编程”（你规定每一步）转向“目标导向编程”（你规定目标，AI 规划步骤）。

4. 超越 Demo：工程化落地必须考虑的四个问题

写一个能跑的 Demo 很简单，但要让一个 Agent 在生产环境稳定、可靠地运行，完全是另一回事。以下是四个你必须提前规划和解决的问题。

4.1 控制循环：防止 Agent“鬼打墙”

Agent 在循环中自主决策，最怕陷入无限循环。比如，LLM 可能一直认为“信息还不够”，反复调用同一个工具。

解决方案 ： 强制设置最大迭代次数（ max_iterations ） 。这是 Agent 安全运行的生命线。在 create_agent 或底层 AgentExecutor 中都可以设置。

from langchain.agents import AgentExecutor, create_react_agent # 使用更底层的组件示例

# 假设我们用更底层的 API 构建
agent_executor = AgentExecutor(
    agent=your_agent_runnable, # 你的 Agent 逻辑
    tools=tools,
    max_iterations=10, # 关键：最多执行 10 轮思考-行动循环
    early_stopping_method="generate", # 当 LLM 生成 `Final Answer` 时提前停止
    handle_parsing_errors=True, # 处理 LLM 输出格式解析错误
)

经验之谈 ：对于大多数信息查询类任务，5-10 轮迭代通常足够。对于极其复杂的规划任务，可以设得更高，但必须配合超时机制和更细致的状态监控。

4.2 处理失败：工具调用不是百分百成功

工具可能因为网络超时、API 限流、权限错误、输入格式不对等原因失败。你不能让一个工具的异常导致整个 Agent 崩溃。

解决方案 ： 在工具层实现健壮性，并在 Agent 层面制定降级策略 。

1. 工具层 ：就像我们之前写的 web_search 函数一样，用 try...except 包裹核心逻辑，返回错误描述而非抛出异常。
2. Agent 层 ：在 LangChain 的 AgentExecutor 中，可以设置 handle_tool_errors=True 。当工具返回错误时，这个错误信息会作为 Observation 反馈给 LLM，LLM 可以决定是重试、换种方式，还是承认失败。
3. 设计层面 ：为关键工具设计重试机制（如使用 tenacity 库），或提供备用工具。

4.3 管理上下文：避免 Token 爆炸

每次循环，Agent 的“思考历史”（包括之前的 Thought, Action, Observation）都会被追加到提示词中，发送给 LLM。任务稍长，token 数量就会急剧增长，导致成本飙升甚至超出模型上下文限制。

解决方案 ： 利用框架的状态管理和总结能力 。

• 状态管理 ：LangGraph 的核心优势就在于其精细的状态管理。它不像简单的列表追加历史，而是维护一个结构化的状态对象，可以更灵活地控制哪些信息进入下一轮上下文。
• 记忆总结 ：对于长对话，可以使用 ConversationSummaryMemory 或 ConversationSummaryBufferMemory 。它们会定期将过长的历史对话总结成一段简短的摘要，用摘要代替原始文本来节省 token。
• 选择性记忆 ：只将关键的工具结果和决策点存入记忆，过滤掉中间冗长的推理文本。

4.4 保障可观测性：看清 Agent 的“黑盒”内部

Agent 的决策是非确定性的。同样的输入，每次运行的路径可能略有不同。上线一个你完全不知道它内部如何决策的 Agent 是危险的。

解决方案 ： 引入可观测性（Observability）工具 。这就是 LangChain 生态中 LangSmith 的价值所在。

• 追踪（Tracing） ：LangSmith 可以记录每一次 LLM 调用、每一次工具执行、每一次状态转换。你能看到一个完整的“轨迹图”，精确知道 Agent 每一步做了什么、输入输出是什么、耗时多久。
• 调试与评估 ：基于追踪数据，你可以回放失败案例，分析是工具问题、提示词问题还是模型问题。你还可以定义评估函数（如答案准确性、工具调用效率）来批量评估 Agent 的表现。
• 没有 LangSmith 的替代方案 ：如果你不想用云服务，至少要在代码中实现详细的日志记录，将每轮循环的 Thought, Action, Observation 打印到日志文件或结构化存储中。没有可观测性，优化 Agent 就像蒙眼开车。

5. LangChain 与 LangGraph：如何选择与搭配使用？

随着 LangChain 1.0 和 LangGraph 1.0 的发布，很多人困惑两者该如何选择。简单来说，它们是不同层次、互为补充的工具。

特性	LangChain	LangGraph
定位	高阶应用框架	底层编排运行时
核心抽象	Chain, Agent, Retriever 等开箱即用的组件	Graph（图），Node（节点），Edge（边）
使用方式	声明式。通过组合预构建模块快速搭建应用。	命令式。通过定义状态图和节点函数来精细控制流程。
状态管理	封装在组件内部（如 AgentExecutor ），相对简单。	显式、强类型的状态对象（State），可完全自定义。
适用场景	快速原型、标准化任务（如RAG、简单Agent）。	复杂、长周期、有状态、需要自定义流程的 Agent 工作流。
类比	像 Django/Spring Boot，提供快速开发 Web 应用的全套组件。	像 Celery/Airflow，专注于复杂任务流程的编排与调度。

如何选择？

• 如果你是新手，或者想快速实现一个标准化的 Agent（比如我们刚才建的研究助手） ，直接从 langchain.agents 模块的 create_agent 或 create_react_agent 开始。它们底层已经使用了 LangGraph，但你无需关心细节。
• 如果你的任务流程非常复杂 ，比如需要多个 Agent 协作、有严格的分支判断、需要持久化检查点、或流程本身就是一个有向无环图（DAG），那么你应该直接使用 LangGraph 。它给你最大的灵活性和控制力。

一个常见的搭配模式是 ：使用 LangChain 提供的现成工具（Tools）、记忆（Memory）和模型集成（LLM），然后用 LangGraph 来编排它们，构建自定义的 Agent 工作流。 create_agent 这个高阶 API 本身就是这种模式的产品——它用 LangGraph 实现了 ReAct 循环，但对外提供了简单的接口。

6. 从项目到生产：构建一个企业级金融问答机器人

为了将上述所有点串联起来，我们以一个更接近生产的项目为例：“金融大模型问答机器人”。这个项目能清晰地展示如何将 LangChain 的各个模块用于解决实际问题。

项目目标 ：构建一个能回答专业金融问题的智能助手，答案需基于权威的金融知识库，并能追溯来源。

技术栈设计 ：

• LLM ：Qwen（通义千问）系列模型，兼顾性能与成本。通过其 API 或本地部署的版本调用。
• 核心框架 ：LangChain（用于组件集成） + LangGraph（用于编排复杂问答工作流）。
• 知识检索 ：RAG（检索增强生成）技术。使用 LangChain 的 Vectorstore （如 Chroma, FAISS）和 Retriever 来建立和管理本地金融知识库。
• 长期记忆 ：使用 SQLite 数据库存储重要的用户交互历史或知识片段，通过 LangChain 的 SQLiteMemory 或自定义 Memory 类接入。
• 服务化 ：使用 FastAPI 将 Agent 封装成 RESTful API，供前端或其他系统调用。
• 高级优化（可选） ：对专属金融数据使用 LoRA/SFT 进行高效微调；使用 PPO/DPO 进行人类偏好对齐；对模型进行量化以降低部署资源消耗。

项目实现关键步骤 ：

1. 知识库构建（Indexing） ：

   • 收集金融研报、法规文档、公司年报等文本。
   • 使用 LangChain 的 TextLoader 、 RecursiveCharacterTextSplitter 进行文档加载和切分。
   • 使用嵌入模型（如 text-embedding-3-small 或 BGE ）将文本块转换为向量。
   • 将向量存入向量数据库（如 Chroma），建立索引。这部分对应 langchain.indexes 相关操作。

2. 智能体工作流设计（Orchestration with LangGraph） ：

   • 节点1：问题理解与路由 ：判断用户问题是“通用对话”还是“专业金融问答”。如果是后者，进入 RAG 流程。
   • 节点2：知识检索 ：从向量数据库中检索与问题最相关的几个文本片段。
   • 节点3：答案生成 ：将问题、检索到的上下文（作为参考）一起构建提示词，发送给 Qwen LLM 生成答案。提示词中严格要求模型基于上下文回答，并注明来源。
   • 节点4：答案验证与后处理 ：可增加一个验证节点，检查答案是否与检索上下文矛盾，或进行格式化。
   • 用 LangGraph 的 StateGraph 定义这些节点和流转边，形成一个稳固的工作流。

3. 记忆与状态管理 ：

   • 使用 ConversationBufferWindowMemory 保存最近几轮对话，使机器人有短期上下文。
   • 将用户高频询问的核心知识点或定制化信息，通过自定义逻辑存入 SQLite 数据库，实现长期记忆。

4. 服务封装与部署 ：

   • 用 FastAPI 创建一个 /ask 接口，接收用户问题。
   • 在接口处理函数中，初始化 LangGraph 工作流，传入问题，执行并获得答案。
   • 返回包含答案和引用来源的 JSON 数据。
   • 使用 Docker 容器化应用，便于部署和扩展。

项目业绩与衡量 ： 对于这样一个 Agent 系统，传统的“功能测试通过”标准不再适用。你需要建立新的评估体系：

• 答案准确性 ：人工或通过规则抽查答案是否基于给定知识库，有无幻觉。
• 检索相关性 ：评估检索到的上下文片段与问题的匹配度。
• 工具调用效率 ：平均每次问答的迭代次数、工具调用耗时。
• 用户满意度 ：通过反馈机制收集评分。
• 可观测性 ：100% 的请求轨迹被 LangSmith 记录，便于故障排查和性能分析。

最后的建议 ：开始你的第一个 Agent 项目时，不要追求大而全。从一个有明确边界的小功能开始（比如我们做的研究助手），跑通整个流程，理解 ReAct 循环、工具、记忆如何协作。然后，再逐步引入更复杂的组件，如 RAG、LangGraph 工作流、外部 API 集成等。在这个过程中， 可观测性（日志和追踪）是你的眼睛，最大迭代次数和异常处理是你的安全网 。先让 Agent 可靠地跑起来，再让它变得更聪明。

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