LangChain 1.0 和 Milvus：如何构建具有真正长期记忆功能的生产就绪型 Agents

LangChain 是一个流行的开源框架，用于开发由大型语言模型（LLMs）驱动的应用程序。它为构建推理和工具使用 Agents、将模型与外部数据连接以及管理交互流提供了模块化工具包。

随着LangChain 1.0 的发布，该框架向更便于生产的架构迈进了一步。新版本用标准化的 ReAct 循环（推理→工具调用→观察→决策）取代了早期基于链的设计，并引入了中间件来管理执行、控制和安全。

然而，仅有推理是不够的。Agents 还需要存储、调用和重用信息的能力。这正是开源向量数据库Milvus 可以发挥重要作用的地方。Milvus 提供了一个可扩展的高性能存储层，使 Agents 能够通过语义相似性高效地存储、搜索和检索信息。

在本篇文章中，我们将探讨 LangChain 1.0 如何更新 Agents 架构，以及集成 Milvus 如何帮助 Agents 超越推理--为实际用例实现持久、智能的内存。

基于链的设计为何失败

在早期（0.x 版），LangChain 的架构以 Chains 为中心。每个 Chain 都定义了一个固定的序列，并附带预制模板，使 LLM 的协调变得简单而快速。这种设计非常适合快速构建原型。但随着 LLM 生态系统的发展和实际用例的日益复杂，这种架构开始出现裂缝。

1.缺乏灵活性

LangChain 的早期版本提供了模块化流水线，如 SimpleSequentialChain 或 LLMChain，每个流水线都遵循固定的线性流程--提示创建 → 模型调用 → 输出处理。这种设计对于简单和可预测的任务非常有效，而且易于快速建立原型。

然而，随着应用程序变得越来越动态，这些僵化的模板开始让人感觉受到限制。当业务逻辑不再整齐地符合预定义的序列时，您就会面临两种令人不满意的选择：强迫您的逻辑符合框架，或者直接调用 LLM API 以完全绕过框架。

2.缺乏生产级控制

在演示中运行良好的功能在生产中往往会被破坏。链并不包含大规模、持久性或敏感应用程序所需的保障措施。常见问题包括

• 上下文溢出：冗长的对话可能超过令牌限制，导致崩溃或无声截断。

• 敏感数据泄漏：个人身份信息（如电子邮件或 ID）可能会无意中发送到第三方模型。

• 无监督操作符：Agents 可能会在未经人工批准的情况下删除数据或发送电子邮件。

3.缺乏跨模型兼容性

每个 LLM 提供商--OpenAI、Anthropic 和许多中国模型--都执行自己的推理和工具调用协议。每次更换提供商，都必须重写集成层：提示模板、适配器和响应解析器。这种重复性的工作拖慢了开发速度，也让实验变得非常痛苦。

LangChain 1.0：全功能 ReAct 代理

当 LangChain 团队分析了数百个生产级 Agents 实施方案后，有一个观点非常突出：几乎所有成功的 Agents 都自然而然地采用了ReAct（"推理 + 行动"）模式。

无论是在多 Agents 系统中，还是在执行深度推理的单个 Agents 中，都会出现相同的控制循环：在简短的推理步骤与有针对性的工具调用之间交替进行，然后将观察结果反馈到后续决策中，直至 Agents 能够提供最终答案。

LangChain 1.0 将 ReAct 循环置于其架构的核心位置，使其成为构建可靠、可解释和可投入生产的 Agents 的默认架构。

为了支持从简单的 Agents 到复杂的编排，LangChain 1.0 采用了分层设计，将易用性与精确控制相结合：

• 标准场景：从 create_agent() 函数开始--这是一个简洁、标准化的 ReAct 循环，可处理推理和工具调用。

• 扩展方案：添加中间件，获得精细控制。中间件可让你检查或修改代理内部发生的事情，例如，添加 PII 检测、人工审批检查点、自动重试或监控钩子。

• 复杂场景：对于有状态的工作流或多代理协调，可使用 LangGraph，这是一种基于图形的执行引擎，可对逻辑流、依赖关系和执行状态进行精确控制。

现在，让我们来分解使 Agents 开发更简单、更安全、跨模型更一致的三个关键组件。

1.创建代理（create_agent()）：构建代理的更简单方法

LangChain 1.0 的一个关键突破在于它如何将构建代理的复杂性降低到一个函数 - create_agent()。您不再需要手动处理状态管理、错误处理或流输出。LangGraph 运行时会自动管理这些生产级功能。

只需三个参数，您就能启动一个功能齐全的 Agents：

• model- 模型标识符（字符串）或实例化模型对象。

• tools- 赋予 Agents 功能的函数列表。

• system_prompt- 定义 Agents 角色、语气和行为的指令。

在引擎盖下，create_agent() 按标准的代理循环运行--调用一个模型，让它选择要执行的工具，并在不再需要工具时完成：

它还继承了 LangGraph 内置的状态持久性、中断恢复和流功能。过去需要数百行协调代码才能完成的任务，现在只需通过一个声明式 API 即可完成。

from langchain.agents import create_agent
agent = create_agent(
    model="openai:gpt-4o",
    tools=[get_weather, query_database],
    system_prompt="You are a customer service assistant who helps users check the weather and order information."
)
result = agent.invoke({
    "messages": [{"role": "user", "content": "What’s the weather like in Shanghai today?"}]
})

2.中间件：生产就绪控制的可组合层

中间件是将 LangChain 从原型推向生产的关键桥梁。它在 Agents 的执行循环中的战略点上提供钩子，使您可以添加自定义逻辑，而无需重写核心 ReAct 流程。

Agents 的主循环遵循三步决策流程--模型 → 工具 → 终止：

LangChain 1.0 为常见模式提供了一些预构建的中间件。下面是四个例子。

• PII 检测：任何处理敏感用户数据的应用程序

from langchain.agents import create_agent
from langchain.agents.middleware import PIIMiddleware
agent = create_agent(
model=“gpt-4o”,
tools=[],  # Add tools as needed
middleware=[
# Redact emails in user input
PIIMiddleware(“email”, strategy=“redact”, apply_to_input=True),
# Mask credit cards (show last 4 digits)
PIIMiddleware(“credit_card”, strategy=“mask”, apply_to_input=True),
# Custom PII type with regex
PIIMiddleware(
“api_key”,
detector=r"sk-[a-zA-Z0-9]{32}",
strategy=“block”,  # Raise error if detected
),
],
)

• 总结：在接近令牌限制时自动总结对话历史。

from langchain.agents import create_agent
from langchain.agents.middleware import SummarizationMiddleware
agent = create_agent(
model=“gpt-4o”,
tools=[weather_tool, calculator_tool],
middleware=[
SummarizationMiddleware(
model=“gpt-4o-mini”,  #Summarize using a cheaper model  
max_tokens_before_summary=4000,  # Trigger summarization at 4000 tokens
messages_to_keep=20,  # Keep last 20 messages after summary
),
],
)

• 工具重试：自动重试失败的工具调用，并可配置指数式延迟。

from langchain.agents import create_agent
from langchain.agents.middleware import ToolRetryMiddleware
agent = create_agent(
    model="gpt-4o",
    tools=[search_tool, database_tool],
    middleware=[
        ToolRetryMiddleware(
            max_retries=3,  # Retry up to 3 times
            backoff_factor=2.0,  # Exponential backoff multiplier
            initial_delay=1.0,  # Start with 1 second delay
            max_delay=60.0,  # Cap delays at 60 seconds
            jitter=True,  # Add random jitter to avoid thundering herd (±25%)
    ),
],

)

• 自定义中间件

除了官方预构建的中间件选项外，您还可以使用基于装饰器或基于类的方式创建自定义中间件。

例如，下面的代码段展示了如何在执行前记录模型调用：

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"About to call model with {len(state['messages'])} messages")
    return None  # Returning None means the normal flow continues
agent = create_agent(
    model="openai:gpt-4o",
    tools=[...],
    middleware=[log_before_model],
)

3.结构化输出：处理数据的标准化方法

在传统 Agents 开发中，结构化输出一直是难以管理的问题。每个模型提供商的处理方式都不尽相同，例如，OpenAI 提供了本地结构化输出 API，而其他提供商只能通过工具调用间接支持结构化响应。这往往意味着要为每个提供商编写自定义适配器，从而增加了额外的工作，使维护工作变得更加痛苦。

在 LangChain 1.0 中，结构化输出可通过 create_agent() 中的 response_format 参数直接处理。 您只需定义一次数据 Schema。LangChain 会根据您使用的模型自动选择最佳执行策略，无需额外设置或特定于供应商的代码。

from langchain.agents import create_agent
from pydantic import BaseModel, Field
class WeatherReport(BaseModel):
    location: str = Field(description="City name")
    temperature: float = Field(description="Temperature (°C)")
    condition: str = Field(description="Weather condition")
agent = create_agent(
    model="openai:gpt-4o",
    tools=[get_weather],
    response_format=WeatherReport  # Use the Pydantic model as the response schema
)
result = agent.invoke({"role": "user", "content": "What’s the weather like in Shanghai today??"})
weather_data = result['structured_response']  # Retrieve the structured response
print(f"{weather_data.location}: {weather_data.temperature}°C, {weather_data.condition}")

LangChain 支持两种结构化输出策略：

1.提供商策略：一些模型提供商通过其 API 本机支持结构化输出（例如 OpenAI 和 Grok）。如果有这样的支持，LangChain 会直接使用提供商的内置 Schema 执行。这种方法提供了最高级别的可靠性和一致性，因为模型本身就能保证输出格式。

2.工具调用策略：对于不支持本地结构化输出的模型，LangChain 使用工具调用来实现相同的结果。

你无需担心使用的是哪种策略--框架会检测模型的能力并自动适应。这种抽象性可让你在不同的模型提供者之间自由切换，而无需改变你的业务逻辑。

Milvus 如何增强代理内存

对于生产级 Agents 而言，真正的性能瓶颈往往不是推理引擎，而是内存系统。在 LangChain 1.0 中，向量数据库充当了 Agents 的外部存储器，通过语义检索提供长期记忆。

Milvus是当今最成熟的开源向量数据库之一，专为人工智能应用中的大规模向量搜索而设计。它与 LangChain 原生集成，因此您无需手动处理向量、索引管理或相似性搜索。langchain_milvus 软件包将 Milvus 包装成标准的 VectorStore 接口，只需几行代码就能将其连接到 Agents。

通过这样做，Milvus 解决了构建可扩展且可靠的 Agents 内存系统中的三大难题：

1.从海量知识库中快速检索

当 Agents 需要处理成千上万的文档、过去的对话或产品手册时，简单的关键词搜索是远远不够的。Milvus 使用向量相似性搜索，能在几毫秒内找到语义相关的信息--即使查询使用了不同的措辞。这样，您的 Agents 就能根据意义调用知识，而不仅仅是精确的文本匹配。

from langchain.agents import create_agent
from langchain_milvus import Milvus
from langchain_openai import OpenAIEmbeddings
# Initialize the vector database as a knowledge base
vectorstore = Milvus(
    embedding=OpenAIEmbeddings(),  
    collection_name="company_knowledge",
    connection_args={"uri": "http://localhost:19530"}  #
)
# Convert the retriever into a Tool for the Agent
agent = create_agent(
    model="openai:gpt-4o",
    tools=[vectorstore.as_retriever().as_tool(
        name="knowledge_search",
        description="Search the company knowledge base to answer professional questions"
    )],
    system_prompt="You can retrieve information from the knowledge base to answer questions."
)

2.持久的长期记忆

当对话历史过长时，LangChain 的摘要中间件（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
# Long-term memory storage(Milvus)
long_term_memory = Milvus.from_documents(
    documents=[],  # Initially empty; dynamically updated at runtime
    embedding=OpenAIEmbeddings(),
    connection_args={"uri": "./agent_memory.db"}
)
# Short-term memory management(LangGraph Checkpointer + Summarization)
agent = create_agent(
    model="openai:gpt-4o",
    tools=[long_term_memory.as_retriever().as_tool(
        name="recall_memory",
        description="Retrieve the agent’s historical memories and past experiences"
    )],
    checkpointer=InMemorySaver(),  # Short-term memory
    middleware=[
        SummarizationMiddleware(
            model="openai:gpt-4o-mini",
            max_tokens_before_summary=4000  # When the threshold is exceeded, summarize and store it in Milvus
        )
    ]
)

3.多模态内容的统一管理

现代 Agents 处理的不仅仅是文本，它们还与图像、音频和视频进行交互。Milvus 支持多向量存储和动态 Schema，使您能够在单一系统中管理多种模式的 Embeddings。这为多模态 Agents 提供了统一的存储基础，使不同类型数据的检索保持一致。

# Filter retrievals by source (e.g., search only medical reports)
vectorstore.similarity_search(
    query="What is the patient's blood pressure reading?",
    k=3,
    expr="source == 'medical_reports' AND modality == 'text'"  # Milvus scalar filtering
)

LangChain 与 LangGraph：如何为您的 Agents 选择合适的版本

升级到 LangChain 1.0 是构建生产级 Agents 的重要一步，但这并不意味着它总是每个用例的唯一或最佳选择。选择正确的框架决定了您能多快地将这些功能整合到一个可运行、可维护的系统中。

实际上，LangChain 1.0 和 LangGraph 1.0 可以看作是同一个分层堆栈的一部分，它们旨在协同工作，而不是相互替代：LangChain 可以帮助你快速构建标准 Agents，而 LangGraph 则为复杂的工作流程提供细粒度控制。换句话说，LangChain 可以帮助你快速行动，而 LangGraph 则可以帮助你深入研究。

下面是它们在技术定位上的不同之处的快速比较：

尺寸	LangChain 1.0	LangChain 1.0
抽象级别	高级抽象，专为标准 Agents 场景设计	低级协调框架，专为复杂工作流设计
核心能力	标准 ReAct 循环（原因 → 工具调用 → 观察 → 响应）	自定义状态机和复杂的分支逻辑（状态图 + 条件路由）
扩展机制	用于生产级功能的中间件	人工管理节点、边和状态转换
基础实施	手动管理节点、边和状态转换	具有内置持久性和恢复功能的本地运行时
典型用例	80% 的标准代理方案	多 Agents 协作和长期运行的工作流协调
学习曲线	用 ~10 行代码构建一个代理	需要了解状态图和节点协调

如果您是构建 Agents 的新手，或者希望快速启动并运行一个项目，请从 LangChain 开始。如果您已经知道您的用例需要复杂的协调、多 Agents 协作或长期运行的工作流，那么请直接使用 LangGraph。

这两种框架可以在同一个项目中共存--您可以从简单的 LangChain 开始，当系统需要更多控制和灵活性时再引入 LangGraph。关键是为工作流程的每个部分选择合适的工具。

总结

三年前，LangChain 作为调用 LLMs 的轻量级封装器起步。如今，它已成长为一个完整的生产级框架。

其核心是中间件层提供安全性、合规性和可观察性。LangGraph 增加了持久执行、控制流和状态管理功能。在内存层，Milvus填补了一个关键的空白--提供可扩展、可靠的长期内存，使 Agents 能够检索上下文、对历史进行推理，并随着时间的推移不断改进。

LangChain、LangGraph 和 Milvus 共同构成了现代 Agents 时代的实用工具链--在不牺牲可靠性或性能的前提下，实现了快速原型开发和企业级部署。

准备好为您的 Agents 提供可靠的长期记忆了吗？了解Milvus，看看它如何为生产中的 LangChain 代理提供智能、长期的内存。

有问题或想深入了解任何功能？加入我们的Discord 频道或在GitHub 上提交问题。您还可以通过Milvus Office Hours 预订 20 分钟的一对一课程，以获得见解、指导和问题解答。