2025年10月LangChain和LangGraph同步发布了1.0版本。这件事在技术圈没有引起太大轰动。大多数人甚至没注意到。但如果你在关注AI Agent的开发框架这个时间点值得停下来想一想。LangChain从2022年底诞生到现在不过三年多。三年时间一个框架从0到1.0迭代了三个完整的版本。2023年火的是Chain和RAG2024年大家在聊Agent Workflow2025年开始谈的是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。推理加行动。交替进行。这个图看起来简单但背后的工程复杂度不低。第一步推理ReasoningLLM收到用户请求后不是直接回答。它先“想”一下这个任务需要什么信息我手头有什么工具第一步该做什么LangChain通过System Prompt把“思考格式”固定下来。典型的ReAct Prompt长这样Thought: 我应该先查一下天气 Action: 天气查询工具 Action Input: 北京 Observation: 北京今天25度晴 Thought: 我现在知道天气了可以回答了 Final Answer: 北京今天25度晴天Thought是推理过程Action是决定调用哪个工具Observation是工具返回的结果。这三步循环往复直到Thought认为可以给出Final Answer。第二步工具调用Tool CallingLangChain把工具抽象成一个统一接口。任何工具只要实现这个接口Agent就能调用它。工具可以是任何东西一个API调用查天气、发邮件一个数据库查询一段Python代码执行一个向量检索甚至是另一个AgentLangChain 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( modelopenai:gpt-4, tools[search], system_prompt你是一个 helpful 的助手 )就这么几行。背后是LangGraph在跑整个ReAct循环。第三步循环终止循环不能无限跑下去。LangChain通过几种机制控制max_iterations最大循环次数模型自己判断任务完成Final Answer超时控制Agent的四大核心组件LangChain的Agent架构包含四个关键部分LLM负责理解任务、做决策、生成输出。是“大脑”。Agent负责调度。决定“现在该用哪个工具”“下一步做什么”。是“调度员”。Tool负责执行具体操作。查天气、算数学、调API。是“工具箱”。Memory负责记住东西。短期记忆记住当前对话长期记忆跨会话存储。是“记忆体”。Agent LLM做决策 Tools干实事 Memory记状态 循环跑到完。四、动手造一个从零构建你的第一个Agent理论说完了。我们来写代码。场景做一个“智能研究助手”。给它一个问题它能自己去搜索、整理、给出答案。第一步安装pip install langchain openai tavily-pythonTavily是一个专门给AI用的搜索引擎API。第二步定义工具from langchain.tools import tool from tavily import TavilyClient tavily TavilyClient(api_keyyour-key) tool def web_search(query: str) - str: 搜索网络信息输入是搜索词输出是搜索结果摘要 results tavily.search(queryquery, max_results3) return \n.join([r[content] for r in results[results]])第三步创建Agentfrom langchain.agents import create_agent from langchain_openai import ChatOpenAI llm ChatOpenAI(modelgpt-4) agent create_agent( modelllm, 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( modelllm, tools[web_search], max_iterations5 # 最多跑5轮 )问题2工具调用会失败API超时、返回格式异常、权限不足——工具调用有无数种失败方式。解决方案在工具层面做异常处理和重试。不要把异常抛给AgentAgent处理不了。问题3上下文爆炸每次循环都要把“历史对话工具调用结果”塞回上下文。跑几轮之后token数可能爆炸。LangGraph通过“状态管理”来解决这个问题——不是每次都把全部历史塞进去而是维护一个状态树。问题4不知道Agent在干什么这是最致命的问题。Agent是非确定性的。你不知道它下一次调用会选哪个工具、会走哪条路径。解决方案可观测性。LangSmith可以追踪每一个决策、每一次工具调用。没有可观测性的Agent上线就是赌博。选型建议LangChain还是LangGraphLangChain 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来“自主决策”的如果有你敢让它自己跑吗如果不敢差的是什么
)
 服务器专用 ESXi 9 全套官方定制资源详解 + 完整部署升级教程)
