4、LangChain核心概念：Chain、Agent、Tool、Memory、Retriever等组件及其在LLM应用中的作用

在vLLM与LangChain的集成开发中，理解LangChain的五大核心抽象——Chain（链）、Agent（代理）、Tool（工具）、Memory（记忆）、Retriever（检索器）——是构建生产级LLM应用的基石。这些组件并非孤立存在，而是通过标准化的接口协议（如Runnable协议）相互协作，形成从“模型调用”到“复杂任务自动化”的完整能力梯度。本章将逐一剖析每个组件的核心原理、典型应用场景、实战案例与常见误区，并重点说明它们如何与vLLM的高性能推理引擎协同工作。

上图展示了五大组件在LLM应用中的协作关系。可以看到，vLLM作为高性能推理引擎位于架构中心，所有组件最终都通过标准化的Runnable接口与LLM交互。Chain提供确定性的流程编排，Agent负责动态决策，Memory管理对话状态，Retriever注入外部知识，Tool扩展模型的行为能力。下面我们逐一深入剖析每个组件的核心原理与实战要点。

4.1 Chain（链）：确定性流程编排的核心

4.1.1 核心原理：从单次调用到多步流水线

Chain的本质是将LLM调用、提示词模板、输入输出解析以及其他组件（如检索器、记忆）组合成一个可复用的处理流水线。在LangChain中，所有Chain都实现了Runnable协议，这意味着它们支持统一的invoke()、batch()、stream()和ainvoke()等异步方法。这种标准化设计使得Chain可以像乐高积木一样自由组合——一个Chain的输出可以直接作为另一个Chain的输入。

最基础的Chain是LLMChain，它封装了“提示词模板 + LLM + 输出解析器”的最小单元。而SequentialChain则允许将多个LLMChain串联，前一个的输出作为后一个的输入。更高级的RouterChain可以根据输入内容动态选择不同的处理路径，实现条件分支逻辑。

4.1.2 实战案例：构建一个多步骤文档分析Chain

假设我们需要构建一个“合同审查助手”，要求：先提取合同关键条款，再根据条款进行风险分析，最后生成审查报告。这是一个典型的多步骤任务，适合用SequentialChain实现。

from langchain.chains import LLMChain, SequentialChain
from langchain.prompts import PromptTemplate
from langchain_community.llms import VLLM

# 初始化vLLM引擎
llm = VLLM(
    model="Qwen/Qwen2.5-7B-Instruct",
    tensor_parallel_size=1,
    max_model_len=8192,
    trust_remote_code=True
)

# 步骤1：提取关键条款
extract_prompt = PromptTemplate(
    input_variables=["contract_text"],
    template="""请从以下合同中提取关键条款（付款条件、违约责任、保密义务），
以JSON格式输出。合同内容：{contract_text}"""
)
extract_chain = LLMChain(llm=llm, prompt=extract_prompt, output_key="clauses")

# 步骤2：风险分析
risk_prompt = PromptTemplate(
    input_variables=["clauses"],
    template="""基于以下条款进行风险分析，指出潜在法律风险点：
{clauses}"""
)
risk_chain = LLMChain(llm=llm, prompt=risk_prompt, output_key="risk_analysis")

# 步骤3：生成报告
report_prompt = PromptTemplate(
    input_variables=["risk_analysis"],
    template="""将风险分析整理为正式审查报告，包含风险等级和修改建议：
{risk_analysis}"""
)
report_chain = LLMChain(llm=llm, prompt=report_prompt, output_key="report")

# 组合为顺序链
full_chain = SequentialChain(
    chains=[extract_chain, risk_chain, report_chain],
    input_variables=["contract_text"],
    output_variables=["report"],
    verbose=True
)

# 执行
result = full_chain.invoke({"contract_text": "甲方应于收到发票后30日内支付..."})
print(result["report"])

这个案例展示了Chain的核心价值：将复杂任务分解为可管理的步骤，每步的输出结构清晰，便于调试和复用。在实际部署中，我们可以将extract_chain和risk_chain的LLM实例配置为不同的vLLM引擎（如一个用7B模型做提取，一个用13B模型做分析），实现异构模型编排。

4.1.3 常见误区与复盘

4.2 Agent（代理）与Tool（工具）：动态决策与行动扩展

4.2.1 核心原理：ReAct范式与工具注册机制

Agent突破了Chain的固定流程限制，允许LLM在运行时动态决定下一步操作。最经典的实现是ReAct（Reasoning + Acting）范式：LLM在每一轮循环中输出“思考（Thought）→ 行动（Action）→ 观察（Observation）”，直到得出最终答案。AgentExecutor负责维护这个循环，并处理工具调用的异常、重试和终止条件。

Tool是Agent的行动接口。在LangChain中，定义一个工具只需使用@tool装饰器，并声明函数签名和docstring——LangChain会自动从docstring中提取工具描述，从类型注解中生成参数Schema。Agent通过分析用户问题、工具描述和参数Schema，决定调用哪个工具以及传入什么参数。

4.2.2 实战案例：构建一个数据库查询Agent

场景：用户需要查询公司销售数据，但LLM无法直接访问数据库。我们创建一个Agent，配备两个工具：get_sales_by_region（按地区查询销售额）和get_top_products（查询热销产品）。

from langchain.agents import AgentExecutor, create_react_agent
from langchain.tools import tool
from langchain_core.prompts import PromptTemplate
import sqlite3

@tool
def get_sales_by_region(region: str, year: int) -> str:
    """查询指定地区、指定年份的销售总额。region为地区名，year为年份。"""
    conn = sqlite3.connect("sales.db")
    cursor = conn.cursor()
    cursor.execute(
        "SELECT SUM(amount) FROM sales WHERE region=? AND year=?",
        (region, year)
    )
    result = cursor.fetchone()[0]
    conn.close()
    return f"{region}地区{year}年销售额: {result}元"

@tool
def get_top_products(limit: int = 5) -> str:
    """查询销量最高的前N个产品。limit为返回数量，默认5。"""
    conn = sqlite3.connect("sales.db")
    cursor = conn.cursor()
    cursor.execute(
        "SELECT product_name, SUM(quantity) as total FROM sales GROUP BY product_name ORDER BY total DESC LIMIT ?",
        (limit,)
    )
    rows = cursor.fetchall()
    conn.close()
    return "\n".join([f"{name}: {qty}件" for name, qty in rows])

# 创建Agent
tools = [get_sales_by_region, get_top_products]
prompt = PromptTemplate.from_template("""你是一个销售数据分析助手。请根据用户问题调用工具获取数据。
可用工具：{tools}
工具名称：{tool_names}
对话历史：{chat_history}
用户问题：{input}
请按以下格式输出：
Thought: 分析需要什么数据
Action: 工具名称
Action Input: 工具参数JSON
Observation: 工具返回结果
...（循环）
Thought: 我已获得足够信息
Final Answer: 最终回答""")

agent = create_react_agent(llm=llm, tools=tools, prompt=prompt)
agent_executor = AgentExecutor(
    agent=agent,
    tools=tools,
    max_iterations=5,  # 防止无限循环
    early_stopping_method="generate",  # 达到最大迭代时强制生成答案
    handle_parsing_errors=True  # 容错处理
)

# 执行查询
response = agent_executor.invoke({
    "input": "2024年华东地区销售额是多少？顺便推荐3个热销产品",
    "chat_history": []
})
print(response["output"])

这个案例中，Agent会先调用get_sales_by_region获取销售额，再调用get_top_products获取产品推荐。整个过程由LLM自主决策，无需人工干预。关键参数max_iterations和early_stopping_method是防止Agent陷入死循环的保险丝。

4.2.3 常见误区与调优建议

• 工具描述不清晰：Agent依赖工具描述做决策。描述应包含“功能、适用场景、参数含义、返回值格式”。例如，不要写“查询数据”，而应写“查询指定地区、年份的销售总额，返回字符串格式的金额”。
• 参数Schema不严格：如果工具参数没有类型注解，Agent可能传入错误类型。务必使用int、str等基础类型，复杂结构使用Pydantic模型。
• 忽略错误处理：工具可能抛异常（如数据库连接失败）。在工具内部捕获异常并返回友好错误信息，Agent才能根据错误调整策略。
• 过度依赖Agent：如果任务流程固定，使用Chain更稳定、更快。Agent适合需要动态决策的场景，但会引入额外的推理延迟和不确定性。

4.3 Memory（记忆）：对话状态的持久化与管理

4.3.1 核心原理：从无状态到有状态的跨越

LLM本身是无状态的——每次调用都是独立的。Memory组件为应用提供了状态管理能力，使得多轮对话能够引用历史信息。LangChain提供了多种Memory实现，从简单的ConversationBufferMemory（存储全部历史）到ConversationSummaryMemory（用摘要压缩历史），再到VectorStoreRetrieverMemory（基于向量检索相关历史）。

Memory的核心机制是在每次LLM调用前，将历史消息注入到Prompt中。注入方式有两种：一是直接拼接在系统提示词后，二是通过messages参数传入ChatModel。后者更灵活，可以区分系统消息、用户消息和助手消息。

4.3.2 实战案例：带记忆的客服机器人

场景：一个技术支持客服机器人，需要记住用户之前报告的问题和已尝试的解决方案。

from langchain.memory import ConversationSummaryBufferMemory
from langchain.chains import ConversationChain

# 使用摘要+缓冲混合记忆
memory = ConversationSummaryBufferMemory(
    llm=llm,  # 用于生成摘要的LLM，可复用主LLM
    max_token_limit=2000,  # 超过此Token数时触发摘要
    return_messages=True,
    memory_key="history",
    output_key="response"
)

# 创建对话链
conversation = ConversationChain(
    llm=llm,
    memory=memory,
    verbose=True
)

# 第一轮
resp1 = conversation.predict(input="我的服务器CPU使用率持续100%，怎么排查？")
# 第二轮（模型记得之前的问题）
resp2 = conversation.predict(input="我已经按你说的检查了top命令，发现是java进程占用高")
# 第三轮（模型能关联上下文）
resp3 = conversation.predict(input="那怎么定位是哪个线程？")

# 查看记忆内容
print(memory.load_memory_variables({}))

在这个案例中，ConversationSummaryBufferMemory会在对话超过2000 Token时，自动将早期对话压缩为摘要，保留近期完整消息。这样既控制了Token消耗，又保留了关键历史信息。对于vLLM场景，建议将max_token_limit设置为模型上下文窗口的30%-50%，避免摘要过于频繁或历史丢失。

4.3.3 常见误区与设计原则

4.4 Retriever（检索器）：外部知识的实时注入

4.4.1 核心原理：RAG（检索增强生成）的基石

Retriever解决了LLM知识过时和领域知识缺失的问题。其核心流程是：将用户问题转换为向量，在向量数据库中检索最相似的文档片段，然后将这些片段作为上下文注入Prompt。LangChain的BaseRetriever抽象了“输入查询 → 返回文档列表”的接口，使得任何实现该接口的组件都可以无缝集成到Chain或Agent中。

常见的Retriever类型包括：VectorStoreRetriever（基于向量相似度）、MultiQueryRetriever（生成多个查询变体提高召回率）、EnsembleRetriever（组合多种检索策略）、ContextualCompressionRetriever（压缩检索结果去除冗余）。

4.4.2 实战案例：企业知识库问答系统

场景：构建一个基于内部技术文档的问答系统，支持员工查询运维手册、API文档等。

from langchain_community.vectorstores import FAISS
from langchain_community.embeddings import HuggingFaceEmbeddings
from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import LLMChainExtractor
from langchain.chains import RetrievalQA

# 1. 初始化Embedding模型（独立于vLLM）
embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-large-zh-v1.5")

# 2. 加载向量库（假设已构建）
vectorstore = FAISS.load_local("knowledge_base", embeddings)

# 3. 基础检索器
base_retriever = vectorstore.as_retriever(
    search_type="similarity",
    search_kwargs={"k": 5}
)

# 4. 使用LLM压缩检索结果（去除无关内容）
compressor = LLMChainExtractor.from_llm(llm)
compression_retriever = ContextualCompressionRetriever(
    base_compressor=compressor,
    base_retriever=base_retriever
)

# 5. 构建RAG问答链
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=compression_retriever,
    return_source_documents=True,
    chain_type="stuff"  # 将所有文档一次性注入Prompt
)

# 执行查询
result = qa_chain.invoke({"query": "如何配置vLLM的continuous batching？"})
print(result["result"])
print("参考文档：", [doc.metadata["source"] for doc in result["source_documents"]])

这个案例中，ContextualCompressionRetriever先用LLM对检索到的5篇文档进行压缩，只保留与问题最相关的部分，再注入最终Prompt。这有效控制了Token消耗，并提升了回答质量。在vLLM场景下，压缩步骤会额外消耗一次LLM调用，建议使用较小的模型（如7B）执行压缩，主模型（如13B/70B）负责最终回答。

4.4.3 检索质量调优清单

1. Embedding模型选择：中文场景推荐bge-large-zh-v1.5或m3e-base，英文场景推荐text-embedding-3-large。Embedding模型与LLM解耦，可独立升级。
2. 分块策略：块大小（chunk_size）建议300-500字符，重叠（overlap）50-100字符。过小丢失语义，过大引入噪声。
3. 检索参数：k值（返回文档数）建议3-5。过大增加Token消耗，过小可能遗漏关键信息。
4. 混合检索：结合BM25（关键词）和向量检索，使用EnsembleRetriever提升召回率。
5. 重排序：在检索后使用CrossEncoder重排序，将最相关的文档排在前面。

4.5 组件协同与架构设计模式

4.5.1 典型组合模式

4.5.2 架构设计决策指南

在实际项目中，选择Chain还是Agent是首要决策。以下判断路径可供参考：

• 任务流程是否固定？是→Chain；否→Agent。
• 是否需要外部数据？是→集成Retriever；否→跳过。
• 是否需要多轮上下文？是→集成Memory；否→无状态调用。
• 是否需要调用外部系统？是→定义Tool；否→纯LLM推理。
• 性能要求？低延迟→Chain（确定性）；高灵活→Agent（但延迟增加）。

4.5.3 与vLLM的深度集成最佳实践

1. 模型实例复用：在LangChain中，一个VLLM实例可以被多个Chain、Agent共享。避免为
   ← 上一章 📖 返回目录 下一章 →