Home
Blog
LangChain 1.0 與 Milvus：如何以真正的長期記憶建立生產就緒的代理程式

LangChain 1.0 與 Milvus：如何以真正的長期記憶建立生產就緒的代理程式

Tutorials

December 19, 2025

Min Yin

LangChain 是一個流行的開放源碼框架，用於開發由大型語言模型 (LLM) 驅動的應用程式。它提供了一個模組化的工具包，用來建立推理和使用工具的代理、連結模型與外部資料，以及管理互動流。

隨著LangChain 1.0 的推出，該架構朝著更適合生產的架構邁進了一步。新版本以標準的 ReAct 環路 (Reason → Tool Call → Observe → Decide) 取代早期以 Chain 為基礎的設計，並引入中間件 (Middleware) 來管理執行、控制與安全。

然而，光是推理還不夠。代理也需要儲存、召回和重複使用資訊的能力。這正是開放原始碼向量資料庫Milvus 可以發揮重要作用的地方。Milvus 提供可擴充的高效能記憶層，讓代理能夠透過語意相似性有效地儲存、搜尋和擷取資訊。

在這篇文章中，我們將探討 LangChain 1.0 如何更新代理體架構，以及整合 Milvus 如何幫助代理體超越推理 - 為實際世界的使用案例實現持久、智慧的記憶體。

基於 Chain 的設計為何失敗

在早期（0.x 版本），LangChain 的架構以 Chains 為中心。每個 Chain 定義了一個固定的順序，並附有預先建立的範本，讓 LLM 的協調變得簡單又快速。這種設計非常適合快速建立原型。但隨著 LLM 生態系統的演進，以及實際使用案例的複雜性，此架構開始出現裂縫。

1.缺乏彈性

LangChain 的早期版本提供了模組化的管道，例如 SimpleSequentialChain 或 LLMChain，每個管道都遵循固定、線性的流程 - 提示建立 → 模型呼叫 → 輸出處理。這種設計對於簡單且可預測的任務非常有效，而且容易快速建立原型。

然而，當應用程式變得越來越動態時，這些僵化的範本就開始有了限制感。當業務邏輯不再整齊地符合預先定義的順序時，您會有兩個不滿意的選擇：強制您的邏輯符合框架，或是直接呼叫 LLM API 來完全繞過框架。

2.缺乏生產級的控制

在示範中運作良好的東西，在生產中卻經常失敗。Chains 並未包含大型、持久性或敏感應用程式所需的保障措施。常見的問題包括

上下文溢出：冗長的對話可能會超出代幣限制，導致當機或無聲截斷。
敏感資料洩漏：個人識別資訊 (如電子郵件或 ID) 可能會在不經意的情況下傳送至第三方模型。
無監督作業：代理可能會在未經人工核准的情況下刪除資料或傳送電子郵件。

3.缺乏跨模型相容性

每個 LLM 供應商-OpenAI、Anthropic 和許多中國模型-都有自己的推理和工具呼叫協定。每次轉換提供者，都必須重寫整合層：提示範本、適配器和回應解析器。這種重複性的工作拖慢了開發速度，也讓實驗變得很痛苦。

LangChain 1.0：All-in ReAct 代理程式

當 LangChain 團隊分析了數百個生產級的代理實作時，有一個洞察力非常突出：幾乎所有成功的代理都自然而然地向ReAct (「推理 + 行動」) 模式靠攏。

無論是在多代理系統中，或是在執行深入推理的單一代理中，都會出現相同的控制循環：在簡短的推理步驟與目標工具呼叫之間交替進行，然後將觀察結果納入後續決策中，直到代理能夠提供最終答案為止。

LangChain 1.0 將 ReAct 環路置於其架構的核心，以這個經過驗證的結構為基礎，使其成為建立可靠、可解釋且可生產的代理程式的預設結構。

為了支援從簡單的代理到複雜的協調，LangChain 1.0 採用了分層設計，結合了易用性與精確的控制：

標準方案：從 create_agent() 函式開始 - 一個簡潔、標準化的 ReAct 環路，可處理推理與工具呼叫。
延伸方案：新增中間件（Middleware）以獲得細緻的控制。中介軟體可讓您檢查或修改代理程式內部發生的事情 - 例如，新增 PII 檢測、人為核准檢查點、自動重試或監控鉤。
複雜的情境：對於有狀態的工作流程或多代理程式協調，可使用 LangGraph，這是一個以圖表為基礎的執行引擎，可精確控制邏輯流程、相依性和執行狀態。

現在，讓我們來分解讓代理程式開發更簡單、更安全、跨模型更一致的三個關鍵元件。

1.create_agent()：建立代理的更簡單方法

LangChain 1.0 的一個關鍵突破是它如何將建立代理的複雜性降低到單一函數 - create_agent()。您不再需要手動處理狀態管理、錯誤處理或串流輸出。這些生產級的功能現在都由 LangGraph runtime 底下自動管理。

只需三個參數，您就可以啟動一個功能完整的代理：

model-模型識別符 (字串) 或實體化模型物件。
tools- 提供代理能力的功能清單。
system_prompt- 定義代理程式角色、語調和行為的指令。

在引擎蓋下，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 從原型帶到生產的關鍵橋梁。它在代理的執行迴圈中的策略點揭露鉤子，讓您可以在不重寫核心 ReAct 程序的情況下，新增自訂的邏輯。

代理的主要迴圈遵循三個步驟的決策流程 - 模型 → 工具 → 終止：

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.結構化的輸出：標準化的資料處理方式

在傳統的代理程式開發中，結構化的輸出一直都很難管理。每個模型提供者都有不同的處理方式 - 例如，OpenAI 提供原生的結構化輸出 API，而其他提供者僅透過工具呼叫間接支援結構化回應。這通常意味著要為每個提供者撰寫客製化的適配器，增加了額外的工作，也讓維護工作變得更加痛苦。

在 LangChain 1.0 中，結構化的輸出是直接透過 create_agent() 中的 response_format 參數來處理的。您只需要定義一次您的資料模式。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 會直接使用提供者內建的模式執行。由於模型本身可保證輸出格式，因此此方法可提供最高等級的可靠性與一致性。

2.工具呼叫策略：對於不支援原生結構化輸出的模型，LangChain 使用工具調用來達到相同的結果。

您不需要擔心使用的是哪一種策略 - 框架會偵測模型的能力並自動適應。這個抽象讓您可以在不同的模型提供者之間自由切換，而不需要改變您的商業邏輯。

Milvus 如何增強代理程式記憶體

對於生產級的代理程式，真正的效能瓶頸往往不是推理引擎，而是記憶體系統。在 LangChain 1.0 中，向量資料庫充當代理的外部記憶體，透過語意檢索提供長期記憶。

Milvus是當今最成熟的開放原始碼向量資料庫之一，專為 AI 應用程式中的大規模向量搜尋而設計。它與 LangChain 原生整合，因此您不需要手動處理向量化、索引管理或相似性搜尋。langchain_milvus 套件將 Milvus 包裝成標準的 VectorStore 介面，讓您只需要幾行程式碼就能將它連接到您的代理。

藉由這樣的方式，Milvus 解決了在建立可擴充與可靠的代理記憶體系統時所面臨的三項主要挑戰：

1.從龐大的知識庫中快速檢索

當代理需要處理數以千計的文件、過去的對話或產品手冊時，簡單的關鍵字搜尋是不夠的。Milvus 使用向量相似性搜尋，即使查詢使用不同的措辭，也能在幾毫秒內找到語義相關的資訊。這可讓您的代理根據意義回憶知識，而不僅僅是精確的文字匹配。

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 會保留它們。每個對話、工具呼叫和推理步驟都可以向量化儲存，以供長期參考。當需要時，代理可以透過語意搜尋快速擷取相關記憶，實現跨會話的真正連續性。

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.多模式內容的統一管理

現代代理處理的不只是文字，他們還與圖像、音訊和視訊互動。Milvus 支援多向量儲存和動態模式，讓您可以在單一系統中管理多種模式的嵌入內容。這可為多模態代理提供統一的記憶體基礎，讓不同類型的資料進行一致的檢索。

# 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 vs. LangGraph：如何為您的代理選擇合適的版本

升級到 LangChain 1.0 是建立生產級代理的必要步驟 - 但這並不表示它永遠是每個使用個案的唯一或最佳選擇。選擇正確的框架決定了您能多快地將這些功能結合到一個可運作、可維護的系統中。

事實上，LangChain 1.0 和 LangGraph 1.0 可以視為同一層疊的一部分，是設計來共同運作而非互相取代的：LangChain 可協助您快速建立標準的代理，而 LangGraph 則可讓您針對複雜的工作流程進行精細的控制。換句話說，LangChain 可協助您快速行動，而 LangGraph 則可協助您深入瞭解。

以下是兩者在技術定位上的快速比較：

尺寸	LangChain 1.0	LangChain 1.0
抽象層級	高階抽象，專為標準代理情境設計	低階協調框架，專為複雜的工作流程設計
核心能力	標準 ReAct 環路 (Reason → Tool Call → Observation → Response)	自訂狀態機器和複雜的分支邏輯 (StateGraph + Conditional Routing)
擴充機制	生產級功能的中介軟體	節點、邊緣和狀態轉換的手動管理
基本實作	節點、邊緣和狀態轉換的手動管理	內建持久性與復原功能的原生運行時
典型使用案例	80% 的標準代理情境	多代理協作與長時間運作的工作流程協調
學習曲線	只需 ~10 行代碼即可建立一個代理程式	需要瞭解狀態圖和節點協調