不再搞Chain 设计的LangChain 1.0，与LangGraph有哪些区别？

ZILLIZ 2025-11-04

927

不再搞Chain 设计的LangChain 1.0 ，如何结合Milvus打造生产级agent

最近，被广大开发者又爱又恨的LangChain ，迎来了重大改版：

专门为agent落地打造的LangChain 1.0版本终于来了！！！

简单来说，其改动主要在于：通过放弃早期的Chain 设计，引入标准化 ReAct 循环（推理→工具调用→观察→判断）和 Middleware 机制，简化agent开发流程、统一标准。

那么改版的LangChain 怎么用，如何结合Milvus落地生产，本文将重点解读。

01 LangChain 为何改版？

Chain 设计不适用agent时代

过去，LangChain 0.x 版本的优点是能让开发者快速构建Agent 原型。但同时也存在三个核心问题：

1、僵化的 Chain 设计

预构建的 Chain（如SimpleSequentialChain
、LLMChain
）在标准场景下很方便，但一旦业务逻辑偏离模板，开发者就会陷入两难——要么被迫接受框架的全部设计，要么放弃框架直接操作原始 LLM 调用。

2、缺少生产级控制

上下文溢出：长对话导致 Token 超限，系统崩溃
敏感信息泄露：PII 数据（邮箱、身份证）直接发送给第三方模型
高风险操作：Agent 在无人工确认的情况下删除数据、发送邮件

这些问题在 Demo 阶段难以暴露，但上线后每一个都可能致命。

3、模型切换的重复工作

OpenAI、Anthropic、国产模型的接口差异（Reasoning 格式、Tool Calling 协议）迫使开发者在每次切换时重写适配代码。

而针对以上问题，LangChain 1.0选择放弃早期的Chain 设计，引入标准化 ReAct 循环（推理→工具调用→观察→判断，create_agent
函数 10 行代码就能构建生产级 Agent）和 Middleware 机制（注入 PII 检测、人工审批、自动重试），简化agent开发流程、统一模型接入等标准。

02 LangChain 1.0 的核心设计
All-in ReAct Agent

LangChain 团队在分析大量生产环境的 Agent 后发现：绝大多数成功案例都收敛到了 ReAct 模式。

无论是多 Agent 协作的 Supervisor 架构，还是需要深度推理的复杂场景，核心循环都是：

推理 → 工具调用 → 观察结果 → 判断是否完成

既然绝大多数问题都能用 ReAct 解决，为什么不把这个模式做到极致？因此1.0的第一个核心改版就是引入标准化 ReAct 循环。

LangChain 1.0 的分层策略：

标准场景：用create_agent
一个函数搞定（标准 ReAct 循环）
扩展场景：通过 Middleware 机制扩展（PII 检测、人工审批、自动重试）
复杂场景：用 LangGraph 精确控制（复杂状态机、多 Agent 编排）

这种渐进式设计让开发者可以从最简单的方案开始，按需增加复杂度。

1. create_agent 函数：简化的 Agent 构建接口

LangChain 1.0 的核心突破在于将 Agent 构建的复杂性压缩到一个函数中。create_agent
不再要求开发者手动编排状态管理、错误处理和流式输出 —— 这些生产级能力现在由底层 LangGraph 运行时自动提供。

三个参数，一个运行时：

模型（m
odel
）：支持字符串标识符或实例化对象
工具（tools
）：赋予 Agent 执行能力的函数列表
系统提示（system_prompt
）：定义 Agent 的角色和行为准则

底层自动继承 LangGraph 的持久化状态、中断恢复和流式处理能力，将过去需要数百行代码实现的 Agent 循环浓缩为声明式 API。


from langchain.agents import create_agent
agent = create_agent(
    model="openai:gpt-4o",
    tools=[get_weather, query_database],
    system_prompt="你是一个专业的客服助手,帮助用户查询天气和订单信息。"
)
result = agent.invoke({
    "messages": [{"role": "user", "content": "上海今天天气怎么样?"}]
})
在此基础上，通过内置中间件（Middleware）机制，开发者可以在不破坏核心循环的前提下注入人机协作审批、对话摘要压缩、PII 数据脱敏等生产级能力

2. Middleware 机制：可组合的生产级能力层

Middleware 是 LangChain 1.0 从原型到生产的核心桥梁。它在 Agent 执行循环的战略节点暴露钩子函数，让开发者无需重写核心循环即可注入自定义逻辑 —— 这种设计类似于 Web 服务器中间件的对称处理模式。

中间件的执行流程：

Agent 的核心循环遵循“模型→工具→终止”的三步决策模式

以下是几个典型的生产级中间件示例：

（1）PII Detection：敏感信息检测与处理


from langchain.agents import create_agent
from langchain.agents.middleware import PIIMiddleware
agent = create_agent(
    model="openai:gpt-4o",
    tools=[...],
    middleware=[
        # 脱敏邮箱地址
        PIIMiddleware("email", strategy="redact", apply_to_input=True),
        # 掩码信用卡号（显示后4位）
        PIIMiddleware("credit_card", strategy="mask", apply_to_input=True),
        # 自定义正则检测API密钥,发现后阻断
        PIIMiddleware(
            "api_key",
            detector=r"sk-[a-zA-Z0-9]{32}",
            strategy="block",  # 检测到后抛出错误
        ),
    ],
)

（2）Summarization：自动管理上下文长度


from langchain.agents import create_agent
from langchain.agents.middleware import SummarizationMiddleware
agent = create_agent(
    model="openai:gpt-4o",
    tools=[...],
    middleware=[
        SummarizationMiddleware(
            model="openai:gpt-4o-mini",  # 使用更便宜的模型总结
            max_tokens_before_summary=4000,  # 触发阈值
            messages_to_keep=20  # 保留最近20条消息不总结
        )
    ],
)

（3）Tool Retry：工具调用失败自动重试


from langchain.agents import create_agent
from langchain.agents.middleware import ToolRetryMiddleware
agent = create_agent(
    model="openai:gpt-4o",
    tools=[search_tool, database_tool],
    middleware=[
        ToolRetryMiddleware(
            max_retries=3,           # 最多重试3次
            backoff_factor=2.0,      # 指数退避倍数
            initial_delay=1.0,       # 初始延迟1秒
            max_delay=60.0,          # 最大延迟60秒
            jitter=True,             # 添加随机抖动(±25%)
        ),
    ],
)

（4）自定义中间件：

除了官方提供的预构建中间件，开发者可以通过装饰器或类继承的方式创建自定义中间件。例如，记录模型调用日志：


from langchain.agents.middleware import before_model
from langchain.agents.middleware import AgentState
from langgraph.runtime import Runtime
@before_model
def log_before_model(state: AgentState, runtime: Runtime) -> dict | None:
    print(f"即将调用模型,当前消息数: {len(state['messages'])}")
    return None  # 返回None表示继续正常流程
agent = create_agent(
    model="openai:gpt-4o",
    tools=[...],
    middleware=[log_before_model],
)

中间件机制将生产级能力（安全合规、错误处理、性能优化）从业务逻辑中解耦，让开发者可以像搭积木一样组合这些能力。

3. Structured Output:标准化的结构化输出机制

LangChain 1.0 引入了统一的结构化输出机制，解决了模型供应商之间输出格式不一致的问题。

核心问题：传统 Agent 开发中，不同模型供应商对结构化数据的支持方式各不相同。OpenAI 有 Native Structured Output API，而其他模型只能通过 Tool Calling 模拟，开发者需要针对不同供应商编写适配代码。

LangChain 的解决方案：通过create_agent
的response_format
参数，开发者只需定义一次数据 Schema，框架自动选择最优策略：


from langchain.agents import create_agent
from pydantic import BaseModel, Field
class WeatherReport(BaseModel):
    location: str = Field(description="城市名称")
    temperature: float = Field(description="温度(摄氏度)")
    condition: str = Field(description="天气状况")
agent = create_agent(
    model="openai:gpt-4o",
    tools=[get_weather],
    response_format=WeatherReport  # 直接传入Pydantic模型
)
result = agent.invoke({"role": "user", "content": "上海今天天气怎么样?"})
weather_data = result['structured_response']  # 获取结构化数据
print(f"{weather_data.location}: {weather_data.temperature}°C, {weather_data.condition}")

两种实现策略：

（1）Provider Strategy：当模型原生支持结构化输出（如 OpenAI、Grok）时，LangChain 自动使用 API 级别的 schema enforcement，可靠性最高

（2）Tool Strategy：对于不支持原生结构化输出的模型，LangChain 将 Schema 转换为 Tool Calling，通过工具调用机制实现相同效果

开发者无需关心底层策略选择，框架根据模型能力自动适配。这种抽象让你可以在不同供应商之间自由切换，而业务代码保持不变。

4.向量数据库与 Agent 记忆系统的集成

生产级 Agent 的能力上限，往往不在推理引擎，而在记忆系统。LangChain 1.0 将向量数据库作为 Agent 的外部海马体，通过语义检索赋予 Agent 长期记忆能力，Milvus是其最重要的生态组成之一。

为什么选择 Milvus？

Milvus 是目前最成熟的开源向量数据库之一，专为 AI 应用的大规模向量检索而设计。它在 LangChain 生态中拥有原生集成，无需手动实现向量化、索引管理和相似度计算——langchain_milvus
包已将其封装为标准的VectorStore
接口。

Milvus 解决 Agent 的三个关键记忆问题

问题一：海量知识的快速检索

假设 Agent 需要处理成千上万份文档、历史对话、产品手册时，关键词搜索已经不够用。Milvus 通过向量相似度搜索，在毫秒级找到语义最相关的内容——即使用户换了说法。


from langchain.agents import create_agent
from langchain_milvus import Milvus
from langchain_openai import OpenAIEmbeddings
# 初始化向量数据库作为知识库
vectorstore = Milvus(
    embedding=OpenAIEmbeddings(),  
    collection_name="company_knowledge",
    connection_args={"uri": "http://localhost:19530"}  #
)
# 将检索器转为Tool供Agent使用
agent = create_agent(
    model="openai:gpt-4o",
    tools=[vectorstore.as_retriever().as_tool(
        name="knowledge_search",
        description="搜索公司知识库以回答专业问题"
    )],
    system_prompt="你可以从知识库中检索信息来回答问题。"
)

问题二：长期记忆的持久化

Middleware 的SummarizationMiddleware
可以压缩对话历史，但那些被总结掉的细节去哪了？ Milvus 将每一轮对话、每一次工具调用的结果向量化存储，构建 Agent 的长期记忆。需要时，通过语义检索快速唤醒相关记忆。

记忆持久化模式：


from langchain_milvus import Milvus
from langchain.agents import create_agent
from langchain.agents.middleware import SummarizationMiddleware
from langgraph.checkpoint.memory import InMemorySaver
# 长期记忆存储(Milvus)
long_term_memory = Milvus.from_documents(
    documents=[],  # 初始为空,运行时动态写入
    embedding=OpenAIEmbeddings(),
    connection_args={"uri": "./agent_memory.db"}
)
# 短期记忆管理(LangGraph Checkpointer + Summarization)
agent = create_agent(
    model="openai:gpt-4o",
    tools=[long_term_memory.as_retriever().as_tool(
        name="recall_memory",
        description="检索Agent的历史记忆和过往经验"
    )],
    checkpointer=InMemorySaver(),  # 短期记忆
    middleware=[
        SummarizationMiddleware(
            model="openai:gpt-4o-mini",
            max_tokens_before_summary=4000  # 超过阈值时总结并存入Milvus
        )
    ]
)

问题三：多模态内容的统一管理

现代 Agent 要处理文本、图片、音频、视频。Milvus 的多向量支持和动态 Schema23，让你在同一个系统中管理不同模态的向量，为多模态 Agent 提供统一的记忆底座。

元数据过滤检索：


# 按来源过滤检索(例如:只检索医疗报告)
vectorstore.similarity_search(
    query="患者的血压指标是多少?",
    k=3,
    expr="source == 'medical_reports' AND modality == 'text'"  # Milvus标量过滤
)