2025年10月，LangChain和LangGraph同步发布了1.0版本。

这件事在技术圈没有引起太大轰动。大多数人甚至没注意到。

但如果你在关注AI Agent的开发框架，这个时间点值得停下来想一想。

LangChain从2022年底诞生，到现在不过三年多。三年时间，一个框架从0到1.0，迭代了三个完整的版本。2023年火的是Chain和RAG，2024年大家在聊Agent Workflow，2025年开始谈的是Long-Horizon Agents和Agent Harness。

变化的不是版本号。变化的是整个AI应用开发的底层逻辑。

红杉资本在那篇刷屏的文章里说了一句话：如果说过去的AI是Talkers的时代，那么2026年则是Doers的元年。

从对话到行动。从回答问题到完成任务。

很多人已经开始感觉到：AI不再只是一个聊天窗口了。它在写代码、查日志、调API、跑流程。它开始像人一样“干活”了。

但问题也来了。你喊了半年AI Agent，真正自己动手写过几行？

目录

一、从“对话”到“行动”：范式切换已经发生

二、为什么需要框架：裸调大模型不够了

三、核心机制：Agent到底怎么工作的

四、动手造一个：从零构建你的第一个Agent

五、工程落地：别把Agent当玩具

六、最后一个问题

一、从“对话”到“行动”：范式切换已经发生
先看三个信号。

第一个信号来自LangChain创始人Harrison Chase。他在2026年初接受红杉访谈时说了一句话：Long-Horizon Agents终于开始真正work了。

什么叫“真正work”？让一个LLM在循环里运行、自主决定下一步做什么——这个想法AutoGPT在2023年就实现了。但当时模型不够好，围绕模型的脚手架也不够成熟。现在模型强了，大家也知道什么样的Harness是好的了。

第二个信号来自LangChain的版本演进。2023年的LangChain主打Chaining——把多个LLM调用串起来。2024年的LangGraph主打Orchestration——带状态、带持久化的运行时。2025年的deepagents主打Harness——包含规划、文件系统、子Agent编排的完整套件。

从Chain到Graph到Harness，三层迭代背后只有一个逻辑：AI正在从“回答问题”走向“完成任务”。

第三个信号更直接。ServiceNow用LangGraph做多Agent协调，覆盖了整个客户成功旅程。Build.inc用LangGraph把一个原本需要4周的人工流程压缩到75分钟。Cisco在一个2万人的组织里用LangChain搭建了Agentic AI平台。

这些不是demo。是生产环境。是真金白银。

AI Agent不是“更聪明的聊天机器人”，是“能自己干活的数字员工”。

二、为什么需要框架：裸调大模型不够了
有人会说：我直接调API不就行了吗？为什么要用LangChain？

这个问题问得好。LangChain创始人也经常被问到同一个问题：“模型越来越强了，还需要框架吗？”

他的回答是：Agent是围绕模型构建的系统，框架不会消失，只是需要跟着模型一起进化。

核心原因有三个。

第一，裸调无法处理“循环”。
你给大模型发一个请求，它给你一个回复。这是单轮。但Agent需要的是：发请求→收到回复（可能要调用工具）→执行工具→把结果塞回上下文→再发请求→再收到回复……直到任务完成。

这个循环你自己写也能写。但状态管理、中断恢复、超时处理、循环终止条件——每一件都是脏活累活。

第二，裸调无法处理“长任务”。
Long-Horizon Agents的核心特征是“能持续运行很长时间”。一个Deep Research任务可能要跑几分钟甚至几十分钟。中间可能涉及几十次工具调用、多次上下文切换、甚至需要人工介入。

自己实现一套持久化执行引擎？成本太高了。

第三，裸调无法处理“可观测性”。
Agent是非确定性的。你没法像读代码一样推断它会怎么走。唯一能知道它“到底在干什么”的方式，是让它跑起来、看trace。

LangSmith做的就是这件事——追踪每一个决策、每一次工具调用、每一轮循环。自己从头造一个可观测性平台？不现实。

框架的价值不在于“让AI更聪明”，在于把重复的工程问题标准化。

框架不生产智能，框架生产确定性——在非确定性的AI之上。

三、核心机制：Agent到底怎么工作的
理解了“为什么需要框架”，我们来看“框架到底做了什么”。

LangChain Agent的核心运行机制可以归结为一个词：ReAct循环。

ReAct = Reasoning + Acting。推理加行动。交替进行。

flowchart TD
A[用户输入任务] --> B[LLM推理: 思考下一步]
B --> C{决策}
C -->|需要工具| D[选择工具 + 生成参数]
D --> E[执行工具调用]
E --> F[观察结果 Observation]
F --> B
C -->|任务完成| G[生成最终答案]
这个图看起来简单，但背后的工程复杂度不低。

第一步：推理（Reasoning）
LLM收到用户请求后，不是直接回答。它先“想”一下：这个任务需要什么信息？我手头有什么工具？第一步该做什么？

LangChain通过System Prompt把“思考格式”固定下来。典型的ReAct Prompt长这样：

Thought: 我应该先查一下天气
Action: 天气查询工具
Action Input: 北京
Observation: 北京今天25度，晴
Thought: 我现在知道天气了，可以回答了
Final Answer: 北京今天25度，晴天
Thought是推理过程，Action是决定调用哪个工具，Observation是工具返回的结果。这三步循环往复，直到Thought认为可以给出Final Answer。

第二步：工具调用（Tool Calling）
LangChain把工具抽象成一个统一接口。任何工具只要实现这个接口，Agent就能调用它。

工具可以是任何东西：

一个API调用（查天气、发邮件）
一个数据库查询
一段Python代码执行
一个向量检索
甚至是另一个Agent
LangChain 1.0的create_agent函数，核心就是帮你把“模型+工具+提示词”组装成一个可运行的循环。

from langchain.agents import create_agent
from langchain.tools import tool

@tool
def search(query: str) -> str:
“”“搜索信息”“”
return f"搜索结果: {query}"

agent = create_agent(
model=“openai:gpt-4”,
tools=[search],
system_prompt=“你是一个 helpful 的助手”
)
就这么几行。背后是LangGraph在跑整个ReAct循环。

第三步：循环终止
循环不能无限跑下去。LangChain通过几种机制控制：

max_iterations：最大循环次数
模型自己判断任务完成（Final Answer）
超时控制
Agent的四大核心组件

LangChain的Agent架构包含四个关键部分：

flowchart LR
A[LLM 大脑] --> B[Agent 调度员]
B --> C[Tool 工具箱]
B --> D[Memory 记忆]
C --> E[外部系统]
D --> F[对话历史/状态]
LLM：负责理解任务、做决策、生成输出。是“大脑”。

Agent：负责调度。决定“现在该用哪个工具”“下一步做什么”。是“调度员”。

Tool：负责执行具体操作。查天气、算数学、调API。是“工具箱”。

Memory：负责记住东西。短期记忆记住当前对话，长期记忆跨会话存储。是“记忆体”。

Agent = LLM做决策 + Tools干实事 + Memory记状态 + 循环跑到完。

四、动手造一个：从零构建你的第一个Agent
理论说完了。我们来写代码。

场景：做一个“智能研究助手”。给它一个问题，它能自己去搜索、整理、给出答案。

第一步：安装
pip install langchain openai tavily-python
Tavily是一个专门给AI用的搜索引擎API。

第二步：定义工具
from langchain.tools import tool
from tavily import TavilyClient

tavily = TavilyClient(api_key=“your-key”)

@tool
def web_search(query: str) -> str:
“”“搜索网络信息，输入是搜索词，输出是搜索结果摘要”“”
results = tavily.search(query=query, max_results=3)
return “\n”.join([r[“content”] for r in results[“results”]])
第三步：创建Agent
from langchain.agents import create_agent
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model=“gpt-4”)

agent = create_agent(
model=llm,
tools=[web_search],
system_prompt=“你是一个研究助手。用户提问时，先搜索再回答。”
)
第四步：运行
result = agent.invoke({
“messages”: [{“role”: “user”, “content”: “LangChain 1.0有什么新特性？”}]
})
print(result[“messages”][-1].content)
这个Agent会：

收到问题
LLM推理：需要搜索
调用web_search工具
拿到搜索结果
LLM再次推理：信息够了，可以回答
输出最终答案
整个过程自动完成。你只写了一件事：告诉Agent它有什么工具。

关键洞察

这个例子看起来简单，但它的本质是把“怎么做”的决策权交给了模型。

传统编程：你写if 需要搜索 then 调用搜索API。 Agent编程：你告诉模型“你有搜索工具”，模型自己决定什么时候用。

这就是从“指令式”到“目标导向”的转变。

五、工程落地：别把Agent当玩具
写一个demoAgent很简单。让一个Agent在生产环境稳定运行，是另一回事。

问题1：循环可能永远跑不完
Agent在循环里做决策。如果模型一直认为“还需要再调一次工具”，循环就不会停。

解决方案：设置max_iterations。到次数强制终止。

agent = create_agent(
model=llm,
tools=[web_search],
max_iterations=5 # 最多跑5轮
)
问题2：工具调用会失败
API超时、返回格式异常、权限不足——工具调用有无数种失败方式。

解决方案：在工具层面做异常处理和重试。不要把异常抛给Agent，Agent处理不了。

问题3：上下文爆炸
每次循环都要把“历史对话+工具调用结果”塞回上下文。跑几轮之后token数可能爆炸。

LangGraph通过“状态管理”来解决这个问题——不是每次都把全部历史塞进去，而是维护一个状态树。

问题4：不知道Agent在干什么
这是最致命的问题。Agent是非确定性的。你不知道它下一次调用会选哪个工具、会走哪条路径。

解决方案：可观测性。LangSmith可以追踪每一个决策、每一次工具调用。没有可观测性的Agent，上线就是赌博。

选型建议：LangChain还是LangGraph？

LangChain 1.0和LangGraph 1.0定位不同：

LangChain：开箱即用。适合快速构建、标准化场景。
LangGraph：底层运行时。适合需要精细控制、复杂状态管理、长时运行的生产级Agent。
实际项目中两者经常搭配使用——LangChain的create_agent底层就是跑在LangGraph上的。

六、最后一个问题
三个月前，我帮一个团队做Agent架构评审。他们的技术负责人问了我一个问题：

“我们花了两周用LangChain搭了一个Agent，效果还行。但我不知道该怎么衡量它‘好不好’。”

这个问题比任何技术问题都难回答。

传统软件有明确的衡量标准：功能跑通了吗？性能达标了吗？Bug修完了吗？

Agent没有“跑通”这个概念。同样一个问题，今天可能3轮循环搞定，明天可能跑8轮还答不对。模型在变、工具在变、输入在变——你没法用“一次通过”来定义“好”。

那什么能定义“好”？

LangChain创始人Harrison Chase给了一个方向：Traces正在成为新的“Source of Truth”。不是你写了什么代码，而是Agent实际跑了什么轨迹。

这意味着一件事：在Agent时代，工程质量不是靠“写对代码”保证的，是靠“持续观测和迭代”保证的。

最后一个问题给你：

你现在的系统里，有没有哪个环节是可以交给Agent来“自主决策”的？如果有，你敢让它自己跑吗？如果不敢，差的是什么？