LangChain 跑通 Demo 容易，上线后因为权限和日志崩溃，这才是 AI…

聊《LangChain火了之后，为什么团队反而更关心维护成本？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

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

摘要： 很多人以为 LangChain 的终点是写出一个能聊天的 Agent，但实际上，真正的分水岭在于它能否在生产环境中存活。本文复盘从 Jupyter Notebook 到企业级应用的跨越，重点讨论在忽略权限控制和可观测性后，那些看似炫酷的 Agent 是如何因为“失控”而变成技术负债的。

---

目录

1. 从“能跑”到“敢用”：LangChain 的真实困境
2. 核心组件的取舍：为什么我们不需要所有功能
3. Prompt 与 Chain：不仅是拼接，更是逻辑约束
4. 工具调用：权限校验比 Token 生成更重要
5. 实战复盘：当 Agent 开始“自作主张”
6. 总结：给 Java 后端转 AI 的几点硬建议

---

从“能跑”到“敢用”：LangChain 的真实困境

前两个月，我带团队做了一个内部的知识检索问答系统。最初在 Jupyter Notebook 里，一切都很美好：导入 LangChain，加载向量数据库，写几行 Prompt，加上一个搜索工具，Agent 回答得头头是道。老板看了挺满意，觉得这就是所谓的“AI 提效”。

但当我们试图把它封装成微服务，接入现有的 RBAC（基于角色的访问控制）系统时，噩梦开始了。

LangChain 本身并没有内置完善的权限隔离机制。默认情况下，如果你的 Prompt 里嵌入了用户 ID，或者你在 Tool 里直接调用了底层 API，它不会自动去检查“这个用户是否有权查看这份文档”。更可怕的是可观测性。在 Notebook 里，你可以盯着控制台看 LLM 的思考过程；但在生产环境，当并发上来时，你根本不知道 Agent 到底走了哪条 Chain，哪个 Tool 失败了，还是 Token 耗尽了。

很多开发者卡在 ImportError 或者 KeyError 上，觉得这是 LangChain 的问题。其实不是，LangChain 是一个框架，不是一个安全沙箱。 它把原子能力拆解得很细，但把这些原子组合成可靠应用的责任，完全交还给了开发者。这也是为什么我现在强调：Demo 跑通只是入场券，权限与可观测才是 Agent 上线的生死线。

核心组件的取舍：为什么我们不需要所有功能

LangChain 的生态极其庞大，LCEL (LangChain Expression Language)、Memory、Callbacks、Tracers... 刚上手时，大家恨不得把所有东西都用上。

我的建议是：做减法。

如果你只是在做一个简单的 RAG 问答，不需要引入复杂的 Memory 模块。为什么？因为大多数企业级应用的对话状态需要由上层业务系统（如 Spring Boot）管理，而不是由 LangChain 临时变量管理。一旦会话断开或迁移服务器，本地内存里的 Chat History 就没了，这会导致严重的用户体验问题。

同样的，不要为了“炫技”去写自定义的 Chain，除非标准组件无法满足逻辑需求。保持组件的单一职责，方便后续的单元测试和 Mock。

Prompt 与 Chain：不仅是拼接，更是逻辑约束

在实战中，我发现最大的坑不在于 Prompt 写得不够优雅，而在于没有对输出进行结构化约束。

早期我们直接用 StringOutputParser()，结果当大模型偶尔输出乱码或 JSON 格式错误时，整个流程直接崩溃。后来我们改用 Pydantic 或 TypedDict 来强制定义输出格式，配合 JsonOutputParser()，稳定性提升了不止一个档次。

看一个简单的 LCEL 写法，注意这里并没有使用复杂的 Chain 类，而是利用管道操作符 |：

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

# 1. 定义模型，务必设置 temperature=0 以保证确定性
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# 2. 构建 Prompt，注意这里的 {input} 是动态注入的
prompt = ChatPromptTemplate.from_template("""
你是一个专业的技术支持助手。
请根据以下用户问题回答问题。
如果问题涉及敏感操作（如删除数据），请务必拒绝并提示风险。

用户问题: {question}
上下文: {context}

回答:
""")

# 3. 使用 LCEL 构建 Chain

# 这种方式比传统的 RunnableSequence 更易读，且天然支持并行处理
chain = prompt | llm | StrOutputParser()

# 4. 调用
response = chain.invoke({
    "question": "帮我删除用户表中的所有记录",
    "context": "..."
})
print(response)

这段代码看似简单，但有几个关键点：
1. Temperature 设为 0：对于工具调用和结构化输出，随机性越大，Bug 越多。
2. Prompt 中的防御性指令：显式告诉模型遇到敏感操作要拒绝。这比事后拦截要便宜得多。
3. LCEL 的可组合性：你可以随时在中间插入 RunnableLambda 来做日志记录或异常捕获，而不必重写整个流程。

工具调用：权限校验比 Token 生成更重要

这是 most critical 的部分。LangChain 的 Tool 机制非常强大，可以让 Agent 执行代码、查询数据库、调用 API。但谁来决定 Agent 能调用哪个 Tool？

默认情况下，如果你把一个“删除用户”的 Tool 暴露给 Agent，它可能会真的去删库，尤其是当用户通过 Prompt 注入攻击（Prompt Injection）诱导模型时。

我们需要在 Tool 层面加上装饰器或前置校验。例如，使用 FastAPI 或 Spring 的拦截器思想，在 LangChain 的 Tool 执行前，检查当前会话的用户角色。

下面是一个模拟的权限校验 Tool 包装器示例：

from langchain_core.tools import tool
from functools import wraps

def secure_tool(role_required="viewer"):
    def decorator(func):
        @wraps(func)
        @tool
        def wrapper(*args, **kwargs):
            # 假设 args[0] 是 LangChain 的 RunnableConfig，其中包含 metadata
            config = kwargs.get('config', {})
            metadata = config.get('configurable', {}).get('metadata', {})

            current_user_role = metadata.get('user_role')

            if current_user_role != role_required:
                return f"权限不足：需要 {role_required} 角色，当前为 {current_user_role}"

            return func(*args, **kwargs)
        return wrapper
    return decorator

# 使用示例
@secure_tool(role_required="admin")
def delete_record(record_id: str) -> str:
    """Delete a specific record from the database."""
    # 实际数据库操作
    return f"Record {record_id} deleted."

这段代码展示了如何在 Tool 级别嵌入逻辑。虽然 LangChain 官方推荐用 RunnableConfig 传递上下文，但在生产环境中，建议将用户身份校验逻辑下沉到执行引擎层，或者使用更严格的 Sandbox 机制。

实战复盘：当 Agent 开始“自作主张”

上个月，我们的一个客服 Agent 上线后，出现了一个诡异的现象：它偶尔会向用户承诺“我可以为您退款 50%”。

排查日志发现，这是因为在 Chain 中，我们接入了一个“查询订单状态”的工具和一个“计算折扣”的工具。模型在没有明确权限指令的情况下，自行拼接了这两个工具的结果，生成了幻觉般的承诺。

解决这个问题的办法只有两个：
1. 缩短 Tool 链：不要让模型自由决定调用多少个工具。使用 Agentic Workflow（如 LangGraph）明确定义状态流转，限制最大调用步数。
2. 增加后置校验：在 LLM 输出给用户之前，加一层规则引擎或轻量级的 NLI（自然语言推理）模型，检测是否包含违规承诺。

此外，可观测性不能省。我们接入了 LangSmith 或自建的 OpenTelemetry 追踪。现在，每次 Agent 的执行路径、Token 消耗、Tool 返回结果都清晰可见。当问题发生时，我们能精准定位是哪一步的 Prompt 出了问题，或者是哪个 Tool 返回了脏数据。

总结：给 Java 后端转 AI 的几点硬建议

从 Java 后端转向 AI 应用开发，最大的障碍往往不是语法，而是思维模式的转变。

1. 不要迷信 LLM 的智能：它更像是一个概率性的文本处理器。你需要像设计数据库 Schema 一样设计你的 Prompt 和 Output Schema。
2. 工程化大于算法：在团队中，那个能把权限、日志、重试机制、熔断降级做得最好的人，往往比那个 Prompt 写得最花哨的人更有价值。
3. 拥抱确定性：尽可能减少 LLM 的决策空间。能用规则引擎解决的，不用 LLM；能用结构化输出解决的，不开放自由文本。
4. 关注成本：每一次 Tool Call 都是金钱。优化 Chain 的长度，缓存重复的向量查询，监控 Token 的使用率。

LangChain 只是一个起点。真正的 AI 应用，是在无数个“如果模型错了怎么办”的假设中，构建起来的坚固堡垒。希望这篇复盘能帮你避开那些 Demo 阶段看不见的坑。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。