LangChain 实战指南：用真实问题串起路线-优快云博客

聊《LangChain 实战指南：一次新的项目切入》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

最近圈子里有个很明显的趋势：大家聊大模型应用，不再盯着“Prompt 怎么写更聪明”，而是开始焦虑“权限怎么控”、“日志怎么存”、“出错了怎么回滚”。

这其实是好事。说明我们终于从“玩具阶段”进入了“工程阶段”。

我之前带过一个内部知识库项目，初期为了赶进度，直接扔给 LLM 一堆 PDF，跑通 Demo 就交差了。结果上线第一天，用户问了一个敏感问题，模型顺着逻辑“幻觉”出了一个不该说的答案，而且因为没做日志审计，事后根本查不到是谁、在什么时间、问了什么。

那次教训让我意识到：对于小团队或者个人开发者来说，LangChain 的核心价值不仅仅是串联模型，更是提供一套标准化的工程脚手架，让你在处理权限、追踪、重试这些脏活累活时有据可依。

今天这篇，我不讲那些花哨的 Agent 架构，咱们从一个最简单的实战切入，看看如何在资源有限的情况下，避免过度设计，快速搭建一个可用、可观测的 AI 应用骨架。

LangChain 能解决什么问题

文章插图 1

很多人觉得 LangChain 太重了，动辄几百行代码才能跑个 Hello World。其实不然。

LangChain 解决的根本痛点是非结构化数据到结构化结果的映射成本，以及调用外部工具时的状态管理。

如果你只是简单地问一句“今天天气怎么样”，直接用 API 调用就行，不需要 LangChain。但一旦涉及：
1. 上下文保持：比如多轮对话，你需要记住之前的意图。
2. 工具路由：根据用户问题，决定是去查数据库、调 API 还是反问用户。
3. 标准化输出：让不同模型的输出格式统一，方便下游处理。

这时候，LangChain 提供的 Chain 和 Tool 抽象就显得很有必要。它不是为了炫技，而是为了让你在后续加日志、加权限校验时，不用重写整个业务逻辑。

核心组件：少即是多

文章插图 2

在学习 LangChain 时，千万别被 LCEL (LangChain Expression Language) 的复杂语法吓到。对于一个实战项目，你只需要掌握三个核心组件的交互：

Model：LLM 本身。
Prompt：输入的结构化指令。
Chain：连接 Model 和 Prompt 的执行逻辑。

其他的如 Memory（记忆）、VectorStore（向量存储），在项目初期完全可以后置。先让链路跑通，再考虑持久化。

优快云资料领取方式

Prompt 与 Chain：让模型听话

Prompt 工程是玄学，但 Chain 是科学。

在我的实践中，我发现很多初学者喜欢在一个巨大的 Prompt 里塞入所有规则。这样做不仅难以调试，而且一旦模型上下文窗口受限，效果会急剧下降。

我的建议是：拆分 Chain。

比如，做一个“员工报销助手”。
1. 第一步：提取用户自然语言中的关键信息（金额、类别、时间）。这一步用简单的 LLMChain 配合 JSON 格式输出。
2. 第二步：校验提取的信息是否符合公司规定（比如餐饮类不能超 200 元）。这一步用纯 Python 逻辑，不要交给 LLM 做判断。
3. 第三步：生成最终回复。

这样设计的好处是，如果第二步校验失败，你可以直接拦截，无需消耗昂贵的 LLM Token，也避免了模型产生“我违反了规定但我假装合规”的幻觉。

下面是一个使用 LCEL 构建简单提取 Chain 的代码示例，注意这里没有引入复杂的 Agent，只是最基础的链式调用：

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

# 1. 定义 Prompt，强调输出格式为 JSON 以便后续程序解析
template = """
你是一个智能报销助手。请从用户的输入中提取以下字段：
- amount: 金额，浮点数
- category: 类别，字符串，只能是['餐饮', '交通', '住宿', '办公用品']之一
- date: 日期，YYYY-MM-DD 格式

如果用户未提供完整信息，请在对应字段填 null。

用户输入: {user_input}
"""

prompt = ChatPromptTemplate.from_template(template)

# 2. 初始化模型
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)

# 3. 构建 Chain: Prompt -> LLM -> 输出解析
chain = prompt | llm | StrOutputParser()

# 4. 调用
result = chain.invoke({"user_input": "上周三我买了两盒咖啡，花了50块"})
print(result)

# 预期输出类似: {"amount": 50.0, "category": "餐饮", "date": "2023-10-25"}

注意 | 操作符，这是 LCEL 的精髓，它让 Chain 变得像管道一样清晰，方便我们在中间插入日志记录或异常处理钩子。

工具调用：克制地使用

现在很流行写 Agent，让模型自己决定调用什么工具。但对于小项目，我建议前期慎用全自动 Agent。

为什么？因为 Agent 的路由逻辑是不透明的。当模型调用错误工具导致报错时，调试成本极高。

更好的做法是：显式定义工具，但限制模型的选择范围。

比如，你的应用只有两个功能：查余额、查订单。你只需要定义这两个 Tool，并在 System Prompt 中明确告诉模型：“你只能使用提供的工具，如果用户问天气，请直接拒绝。”

这种“窄通道”设计，虽然牺牲了一点灵活性，但极大地提高了系统的稳定性和可预测性。这也是我在后续加入权限控制和日志审计的基础——因为只有知道模型一定会调用哪些接口，我才能在入口处统一做鉴权。

项目实战：从 Demo 到可维护服务

回到开头提到的那个痛点：权限和日志。

在 LangChain 中，我们可以通过自定义 RunnablePassthrough 或者封装一层中间件来解决。

假设我们要实现一个简单的“数据查询助手”，我们需要确保：
1. 用户只能查自己部门的数据。
2. 所有查询必须记录日志。

我们可以这样做：

from langchain_core.runnables import RunnableLambda

# 模拟权限校验函数
def check_auth(user_id, query):
    # 实际项目中这里会查数据库验证 user_id 是否有权限
    if "敏感数据" in query:
        raise PermissionError("无权访问敏感数据")
    return True

# 模拟日志记录函数
def log_query(user_id, query, result):
    print(f"[{user_id}] Query: {query} | Result Length: {len(result)}")

# 将权限校验嵌入 Chain
auth_chain = RunnableLambda(lambda x: check_auth(x.get("user_id"), x.get("input")))

# 完整的处理链
full_chain = auth_chain | prompt | llm | StrOutputParser() | RunnableLambda(
    lambda res: log_query(x.get("user_id"), x.get("input"), res) or res
)

# 调用时需传入额外参数
try:
    output = full_chain.invoke({
        "user_id": "user_123",
        "input": "帮我查一下部门预算",
        "category": "finance"
    })
except PermissionError as e:
    print(e)

这段代码看似简单，但包含了工程化的关键要素：输入校验前置、输出后处理后置。

在实际项目中，我会把 check_auth 和 log_query 替换为真实的数据库操作和 ELK 日志接口。通过这种方式，你不需要修改核心的 LLM 调用逻辑，就能无缝接入企业级的安全监控体系。

总结

LangChain 不是一个银弹，它只是一个帮你规范“Prompt 管理”和“模型调用流程”的工具库。

对于想要快速上手 AI 应用的开发者，我的建议是：
1. 先跑通 LCEL 管道：理解数据是如何从 Input 流向 Output 的。
2. 拒绝过度 Agent 化：能用规则判断的，不要交给模型；能固定调用的，不要做成动态路由。
3. 尽早引入工程化约束：在写第一行 Prompt 之前，就想好日志存哪里、权限谁管、异常怎么处理。

大模型应用的竞争壁垒，从来不是模型本身有多聪明，而是你能否把这些聪明的“黑盒”，封装成稳定、可控、可审计的“白盒”服务。

希望这篇基于实战的梳理，能帮你在接下来的项目中少走一些弯路。如果有具体的踩坑经历，欢迎在评论区交流。