LangChain 框架开发指南：从 LCEL 到 Agent 实战

LangChain 是目前构建大模型应用最流行的开源框架之一，官方定位是"Agent + 可配置编排层"：模型（Model）负责推理，周边的一切——提示词、工具、中间件——由框架帮你组合。它的核心价值在于统一了不同模型厂商的接口，让你写一遍代码就能在 OpenAI、Anthropic、Google、Ollama 等之间切换，并提供了构建链（Chain）和 Agent 所需的基础设施。

一、统一模型接口：一次编写，多厂商运行

LangChain 把聊天模型、嵌入模型、图像模型等抽象成统一接口。例如 create_agent 接受一个模型标识字符串，底层自动路由到对应厂商：

from langchain.agents import create_agent

def get_weather(city: str) -> str:
    """Get weather for a given city."""
    return f"It's always sunny in {city}!"

agent = create_agent(
    model="openai:gpt-5.5",
    tools=[get_weather],
    system_prompt="You are a helpful assistant",
)

切换厂商时只需改模型标识，例如换成 anthropic:claude-sonnet-4-6 或 ollama:llama3。这对业务影响很大：当某家模型涨价或限流时，应用可以快速切换，而不是重写调用逻辑。

二、LCEL：用管道符组合链

LCEL（LangChain Expression Language）是框架的声明式组合语法，用 | 把组件串成管道。例如"提示模板 → 模型 → 输出解析器"：

from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

prompt = ChatPromptTemplate.from_template("用一句话总结：{topic}")
chain = prompt | model | StrOutputParser()
print(chain.invoke({"topic": "RAG"}))

LCEL 的优势在于：链是普通对象，可以嵌套、并行、异步调用，并且天然支持流式输出和自动重试。业务逻辑越复杂，"组合优于写死"的好处越明显。

三、工具调用：让模型能"动手"

Agent 与普通对话最大的区别是能调用工具。工具可以是任意 Python 函数，用 @tool 装饰器声明参数描述，框架会把工具 schema 交给模型，模型在需要时返回调用请求，再由框架执行并把结果回传给模型。

from langchain.tools import tool

@tool
def search_docs(query: str) -> str:
    """Search the knowledge base and return matching chunks."""
    return run_search(query)

工具是 Agent 能力的边界：接入数据库、邮件、支付、搜索等 API，模型就能完成真正的工作。工具设计的关键是"描述要清晰、入参要简单、失败要优雅"。更系统的 Agent 开发方法见 AI Agent 开发入门。

四、记忆：让对话有上下文

多轮对话需要记忆。LangChain 提供会话历史管理能力，可以把历史消息注入提示词，也可以结合向量检索做长期记忆。实际开发中注意两点：

短期记忆控制窗口：历史消息过多会挤占上下文并抬高成本，通常做截断或摘要。
长期记忆用检索：把历史沉淀为向量并检索相关片段，比全量塞入更可控，这正是 RAG 的思路，见 RAG 检索增强生成实现指南。

五、Agent 开发：模型 + 编排层

官方把 Agent 定义为"模型 + 编排层"（Agent = Model + Harness）。create_agent 是最小可用编排层，你可以通过中间件逐步叠加：重试、护栏、路由、工具策略等，只组合当前场景需要的部分。

框架家族里还有两个重要成员：

LangGraph：底层图编排框架，适合需要"确定性流程 + Agent 分支"的复杂应用，支持持久化、人工介入（human-in-the-loop）。
LangSmith：可观测与评估平台，记录每次调用的完整追踪（提示词、工具调用、状态转换、延迟），用于定位失败和评测质量。

三者分工：Deep Agents 偏"开箱即用"，LangChain 偏"高度可定制"，LangGraph 偏"底层编排"。

六、落地建议

先本地跑通：用本地部署 Ollama 指南在本机跑一个小模型做开发调试，省成本且不依赖外网。
尽早接可观测：从第一个版本就开启 LangSmith 追踪，后期定位 Agent 行为问题会省大量时间。
工具越少越可控：每个 Agent 的工具数量控制在必要范围，工具太多会让模型"选择困难"并增加出错面。
输出必须校验：对工具结果和模型输出做格式与安全校验，尤其是面向用户的场景。

七、一个最小示例：把 LCEL 链升级成 Agent

光看概念容易飘，用同一个「客服机器人」把前面所有抽象串起来。第一版是纯链：提示模板 → 模型 → 输出，能回答常见问题，但没有能力查订单。升级成 Agent 后，给模型加一个 query_order 工具，用户问「我的订单到哪了」时，模型自动调用工具，拿到结果后再组织回答。

from langchain.agents import create_agent, tool

@tool
def query_order(order_id: str) -> str:
    """Look up the shipping status of an order by its ID."""
    return fetch_status(order_id)

agent = create_agent(
    model="openai:gpt-5.5",
    tools=[query_order],
    system_prompt="你是电商客服，只能依据工具返回的事实回答。",
)

reply = agent.invoke({"input": "订单 20260808-001 到哪了？"})
print(reply)

这个例子里几乎没有新概念，只是把「工具调用」和「编排」加进了原来的链。实际项目里用同样的思路逐步叠加：先做 RAG 检索知识库，再加订单、退款等业务工具，最后用 LangGraph 把退款审批这类需要人工确认的流程变成显式状态机。每加一层都保持「链可单独测试、工具可独立复用」，复杂度就不会失控。

常见问题

LCEL 和 LangGraph 怎么选？ 判断标准是「流程是否固定」：请求-响应的对话、工具调用用 LCEL 足够；需要多步审批、分支重试、跨会话持久化时再上 LangGraph。

一个 Agent 应该配几个工具？ 经验值是 3-6 个。太少发挥不了 Agent 的价值，太多会让模型频繁误选，还扩大攻击面。工具描述要写清楚「什么时候用、不做什么」。

记忆放提示词里还是向量库里？ 最近 5-10 轮对话放提示词，长期事实（用户偏好、历史订单）检索出来再放提示词，两者结合通常比单一方案效果好。

多厂商切换真的无痛吗？ 模型标识切换是无痛的，但不同厂商的工具调用格式和系统提示词风格有差异，建议为每家厂商单独写提示词模板，而不是一套提示词走天下。

16IDC 观察

对建站团队来说，LangChain 是"把 AI 能力嵌入产品"的捷径：无论是 AI 相关的客服机器人、内容生成还是数据分析，先用 LangChain 统一模型接入，再按需叠加 RAG、工具与 Agent，能显著降低多模型切换和多服务编排的复杂度。框架本身是开源免费的基础设施，你真正需要投入的是数据质量、提示工程和评估体系。

原文来源：https://docs.langchain.com/oss/python/langchain/overview

LangChain 框架开发指南：从 LCEL 到 Agent 实战