当前位置：首页 > news >正文

001、开篇：为什么是LangChain？大模型应用开发范式变革

news 2026/5/7 23:31:54

001、开篇：为什么是LangChain？大模型应用开发范式变革

昨天深夜调试一个对话场景，被大模型的输出格式折腾得够呛。需求很简单：从用户消息里提取时间、地点、事件三个字段，返回结构化的JSON。我对着API文档写了二十多行提示词，测试时却发现模型偶尔会把地点塞进事件描述里，偶尔又返回纯文本而非JSON。凌晨三点盯着屏幕，突然意识到问题不在模型——我们正在用写自然语言提示的方式，去解决一个本应属于工程架构的问题。

这就是LangChain要回答的核心命题。

大模型应用的“手工作坊”阶段

早期的大模型应用开发像极了手工作坊。每个开发者都在重复发明轮子：写一堆字符串模板拼接提示词，手动维护对话历史，用正则表达式从模型输出里抠数据，自己实现重试逻辑和超时控制。代码里散落着各种f-string和json.loads()，业务逻辑和模型调用搅在一起。

最头疼的是状态管理。多轮对话要维护上下文窗口，流式输出要处理字符拼接，工具调用要解析模型思考过程。上个月我接手一个项目，光是对话历史管理就发现了三种不同的实现方式——有的用列表存消息，有的用字符串拼接，有的甚至每次请求都重新构造整个历史。

# 别这样写（我踩过的坑）history=""formsginchat_history:history+=f"{msg['role']}:{msg['content']}\n"prompt=f"{history}user:{new_input}\nassistant:"# 当对话超过10轮时，prompt长度爆炸，API直接拒绝# 而且模型开始“失忆”，忘记最早的对话内容

LangChain带来的工程化视角

LangChain本质上是一套设计模式。它把大模型应用拆解成几个核心抽象：链（Chain）处理调用序列，记忆（Memory）管理对话状态，检索器（Retriever）连接外部数据，工具（Tools）扩展模型能力。这些抽象不是凭空创造的，而是从无数真实项目中提炼出来的通用模式。

第一次看到LCEL（LangChain Expression Language）时，我有点抵触——又是个新DSL？但实际用下来发现，它解决的是管道组合的脏活累活。以前写一个检索增强生成（RAG）流程，要手动处理文档加载、分块、向量化、检索、提示构造、模型调用、输出解析。现在可以像搭积木：

# 这写法就舒服多了chain=(load_qa_chain(llm)|retriever|prompt_template|llm|output_parser)# 每个组件可单独测试，可替换，可监控

更重要的是标准化。团队协作时，新人能快速理解代码结构；系统监控时，可以统一收集链的调用指标；版本升级时，替换底层模型而不必重写业务逻辑。这些工程收益在项目规模扩大后尤其明显。

范式变革：从提示词工程到应用工程

大模型开发正在经历从“提示词工程”到“应用工程”的转变。早期我们关注如何写出更好的提示词，现在要思考的是：如何设计可维护的应用架构？如何保证系统的可靠性？如何集成现有业务系统？

上周帮朋友review代码，他的智能客服项目里有个经典问题：用户问“订单状态”，模型需要先调用查询接口获取数据，再生成回复。原始实现里，工具调用逻辑和回复生成逻辑混在一起，错误处理极其复杂。用LangChain的Agent重构后，模型自己决定何时调用工具，代码清晰了不止一倍。

# 以前要自己判断什么时候查数据库if"订单"inuser_queryand"状态"inuser_query:order_id=extract_order_id(user_query)# 脆弱的正则提取data=query_order(order_id)prompt=build_order_prompt(data)response=llm(prompt)# 现在定义工具，让模型自己决定tools=[order_query_tool]agent=create_react_agent(llm,tools)# 模型会自己思考：“用户要订单状态，我需要先调用order_query_tool”