之前写过一篇关于《从框架到智能体，一文看懂LangChain五兄弟的秘密》文章，这里先跟大家道个歉，里面确实有些东西说的有歧义，而今天则系统的对LangChain最新的v1.0生态进行解读。
之前使用LangChain v0.x版本时，大家可能都有这种感觉，虽然其功能强大，但是概念繁杂、框架整体臃肿、乱、学习曲线杂。而LangChain自2022年底发布以来，将近3年的时间里，版本号一直也没说直接上升到1.x，始终停留在0.x版本，这本身就说明了，其快速发展中保持了谨慎的态度。而此次直接跃迁至v1.0，真正意义上的第一个正式大版本，其意义不言而喻，并且其官方也声明了，在v2.0到来之前，不会再引入一些破坏性的颠覆功能特性，所以大家是时候，将老版本的代码，进行重构和升级了。
首先，LangChain v1.0解决的第一个问题是统一性。它对框架进行了一次彻底的重构与瘦身，目的不是为了引入更多的功能，而是重塑开发者的体验。它废弃了老版本中冗余API，统一了接口，新版本中使得框架变得更为轻量、直观且容易维护。
其背后的核心思想是抽象层设计，引入了Runnable Interface作为统一入口点，所有可执行组件实现了Runnable协议，可被例如‘.invoke’和‘.stream’调用。
result = model.invoke("请帮我生成一段关于AI未来的简短总结。")pv = chat_prompt.invoke({"topic": "LangChain 的核心理念"})result = agent.invoke({"messages": [HumanMessage(content="请计算3乘以5的结果是多少？")]})for chunk in model.stream("请用一句话总结人工智能的意义："):print(chunk.content, end="")for chunk in graph.stream(inputs, stream_mode="custom"):print(chunk)
其次，更强化了智能体的理念。从早期的链式思维，升级为以智能体为核心，建立在LangGraph强大编排能力之上，封装了智能体的编程接口（'create_agent'与'create_deep_agent'）来创建智能体，而并没有延用LangGraph的命名。因为在LangChain v1.0中，已经将LangGraph下沉为底层框架了，再加上有重要新特性中间件的加持，我们大多数场景下，无需再使用底层LangGraph API了。
agent = create_agent(model=llm,tools=[calculate, get_info],system_prompt="你是一位专业的智能助理，拥有计算和信息查询的能力。请根据用户需求，自主选择最合适的工具进行处理。",)agent = create_deep_agent(model=llm,tools=[internet_search],system_prompt=research_instructions,)
https://docs.langchain.com/oss/python/langchain/middleware/built-in
# 会话摘要中间件：极低阈值，快速触发middleware = SummarizationMiddleware(model=summ_llm,max_tokens_before_summary=30, # 累计上下文估算到阈值30时触发，把早期消息压缩成摘要。messages_to_keep=5, # 摘要后仍保留的最近N条原文summary_prompt="用20个字以内概括要点。", # 自定义“如何摘要”的提示词（不设则用默认）)agent = create_agent(model=llm,tools=[],system_prompt="只用一句极短中文回答，且不超过30个字。", # 只用“极简短句”回答middleware=[middleware],)
最后关于Deep Agents再说一个实现要点吧，是我个人在真实使用时的感受。它虽然进行了高度封装，开箱即用，我们进行一些简单配置（例如配置模型、工具、子智能体、存储体系等）就可以使用，但是对于提示词编写的要求极高，提示词一定要明确定义出每一个步骤，所以反而最后优化系统提示词，花了很长时间，尤其复杂智能体下，想让系统每一次都按照提示词的指示去做，尤其稳定性，这绝对是一个挑战。简单的场景这一点请忽略，简单场景我测试时稳定性还是挺高的。当然，这一点，也跟模型的能力有关。
# 创建并返回 Deep Agentagent = create_deep_agent( model=model, tools=[internet_search], system_prompt=DEEP_RESEARCH_SYSTEM_PROMPT, backend=backend_factory, store=store, subagents=subagents, interrupt_on=interrupt_on, checkpointer=checkpointer,)
当然，LangChain v1.0中还有很多新特性，上面只列举了我认为重要的一些，还有很多，大家可以通过LangChain官网左侧文档目录就可以看出来，我就不过多说明了。
oh，对了，突然想起来，在使用LangSmith平台调试的时候，原LangGraph Studio改名为LangSmith Studio了，这个之前还真没注意。所以，LangChain哈哈，真是分的清楚，要调试，就在LangSmith上，怕还用LangGraph Studio误会，直接改为了LangSmith Studio，除此之外，官方也不建议再用LangServe了，以后慢慢就被废弃掉了。
最后，从我个人角度来聊聊，如果要老项目重构或迁移为LangChain v1.0版本，应该关注哪些重点。（注意，只提供需要考虑哪些重点，不作为迁移指南使用）以下建议仅供参考：
1）、分析代码现状，明确你代码用的是哪个LangChain生态包版本，又或是混用langgraph+老agent等方式。所以需要分析现有代码写法，尤其LangChain众多老版本中，API众多，写法肯定各异。最后还需注意，最后Python版本可能也需要升级，因为v1.0移除了对Python 3.9的支持，Python版本需>= 3.10，影响范围可想而知。
2）、明确LangChain v1.0全家桶的核心变更，评估想要迁移的具体写法。例如新的`create_agent()`成为标准入口，取代`langgraph.prebuilt.create_react_agent`或`initialize_agent`等接口。同时还需确认是否保留旧特性，如果需要，可以通过`langchain-classic`和`langchain-legacy`兼容旧组件。
3）、依据场景不同，评估是否需要重构。有些高级的复杂模块，例如Deep Research这类业务，我就推荐使用Deep Agent搞定了。还有些业务，是否需要拆分，使用子智能体或子图的方式实现。
最后，我个人建议，与其考虑迁移到LangChain v1.0版本，真不如直接就重构吧，因为LangChain v1.0版本变化太大了。整体流程肯定是：你需要先全面了解LangChain v1.0的新特性，然后分析自己项目的业务与代码现状，进行重要度、复杂度、重构风险与重构成本等评估，制定重构业务或技术点的优先级。等全方位进行整体评估后，制定重构计划，再进行具体重构作业，而并不简单的告诉开发者说，出LangChain新版本了，你们给系统升级下吧，没那么简单。
-----
今天就写到这了，希望对大家有所帮助。
