企业官网建设流程全解析

最近好几个朋友问我同一个问题：我想在自己写的脚本里接一个大模型做对话，直接用 requests 发 POST 不是挺简单吗，为什么大家都在说 LangChain，它到底解决了什么？

这个问题问得很实在。如果你只是临时跑通一个 API，那 requests 确实够用。但只要你打算把这个对话功能做成一个真正能用的项目——要支持多轮历史、要换模型服务商、要把输出整理成结构化数据、要做流式输出——你很快就会发现自己写的是一堆重复且容易出错的胶水代码。LangChain 的价值不在于魔法，而在于它把大模型 API 调用这件事抽象成了几条稳定的概念和接口，让你把精力放在"对话怎么组织"，而不是"请求报文怎么拼"。

这篇文章我就以"利用 LangChain 调用大模型 API 实现简单对话"为例，从为什么套框架、核心抽象是什么、最小代码怎么写、踩过哪些坑、怎么扩展成可用对话这几个维度，完整拆一遍。适合刚接触 LangChain、想在真实项目里用它的人参考，也适合正好在纠结"到底该不该用框架"的技术选型者。

1. 明明 requests 就能发请求，为什么还要套一个 LangChain？

1.1 裸调 API 的真实体验

先看一个很多人都会写的"裸调"版本。假设某家大模型服务商提供一个对话补全接口，我们用 requests 发一条用户消息并打印回复：

import requests import json url = "https://api.example.com/v1/chat/completions" api_key = "sk-xxxxxxxx" headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" } payload = { "model": "some-chat-model", "messages": [ {"role": "system", "content": "你是一个乐于助人的助手。"}, {"role": "user", "content": "用一句话介绍Python"} ], "temperature": 0.7 } resp = requests.post(url, headers=headers, json=payload, timeout=15) data = resp.json() print(data["choices"][0]["message"]["content"])

这段代码能跑通吗？能。但它把很多判断都写死了：模型名硬编码、API Key 直接出现在代码里、返回结构完全依赖这家服务商的 JSON 字段。一旦你要换一家服务商，或者想加入对话上下文，代码就要马上膨胀。

我见过不少项目就是这么起步的。一开始只是一个小脚本，后来要支持多轮对话，于是你手动维护一个messages_history列表，每轮把历史塞进去；再后来要限制 token 长度，你又要手动裁剪历史消息；再后来想流式输出，你开始研究stream=True时返回的 SSE 数据流怎么解析。等这些全做完，这段代码已经和业务逻辑纠缠在一起，换模型供应商等于重构。

这其实就是引入 LangChain 的第一层动机：抽象掉琐碎协议。

1.2 LangChain 到底管了哪些"脏活累活"

LangChain 不是把它说得越玄乎越好，它本质上做了几件非常具体的事情：

第一，统一的模型接口。不管后端是哪家服务商，对 LangChain 来说，模型就是一个可以被实例化、可以被调用的对象。初始化时把模型名、密钥、温度传进去，后续调用方法几乎一样。换服务商时，很多业务代码不用动。

第二，统一的消息 Schema。裸调用时每家 API 的消息字段名可能略有差异，有的用role，有的用speaker。LangChain 定义了SystemMessage、HumanMessage、AIMessage三个类型，在代码里通过这些类构造消息，再交给后端适配器转换成对应协议的报文。你的业务逻辑只和这三种类型打交道。

第三，可组合的管线能力。对话流程往往不是"发一条消息、拿一条回复"这么简单。你可能会先让模型给用户的问题做分类，再根据分类走不同的提示词；你可能会把用户输入先处理后拼进提示词；你可能会同时跑多个模型任务再汇总。LangChain 的链（Chain）和 LCEL（LangChain Expression Language）让这类组合可以用非常直白的管道式写法实现。

第四，周边配套。Token 统计、流式输出、输出解析器、回调日志、重试机制，这些在大模型应用里迟早会用到的东西，它已经替你封装好了。

我做了一张表，对比裸调 API 和 LangChain 在常见需求上的表现，应该更直观：

很明显，单次请求场景里 LangChain 反而是多余的；但只要需求往深处走，它省下的是你在协议和边界处理上的大量重复劳动。

1.3 什么情况下确实不需要 LangChain

说实话，我并不是无脑推荐所有项目都上 LangChain。以下场景我觉得裸调用反而更轻松：

• 你只需要一次性调用，比如写个脚本批量翻译几句话；
• 你的项目只用一家服务商，且明确未来不会换；
• 你只需要最简单的 text completion，不需要 Chat 结构；
• 你的老板或客户要求依赖尽可能少，要能在内部环境里快速部署。

在这些场景里，强行引入 LangChain 只会多一层抽象、多一点排查成本。

那什么情况下应该一开始就用 LangChain？我的判断标准是：你已经能预见到这个对话功能会不断加需求，比如要多轮、要工具调用、要做 Agent、要让模型走复杂的决策流程。大模型应用开发最怕的不是一开始功能少，而是技术债堆到后面推翻重来。LangChain 至少在"组织对话逻辑"这件事上给了你一个比较稳的骨架。

2. 先弄懂 LangChain 的三个核心抽象：模型、消息、链

很多人第一次看 LangChain 文档会觉得乱，因为它概念太多了。但做"简单对话"这件事，你只需要吃透三个东西：模型（Model）、消息（Message）、链（Chain）。

2.1 模型层：LLM 和 ChatModel 是两种不同的东西

LangChain 把模型分成两大类：LLM和ChatModel。名字有点绕，但区别很直观。

LLM对应的是早期那种"文本补全"接口：你给它一段字符串，它返回一段字符串作为续写。它没有系统消息的概念，也不区分用户和助手，纯粹是"前文预测后文"的玩法。

ChatModel对应的是现在主流的对话接口：输入是一组带角色的消息，输出是一条助手消息。当前能做"对话"的大模型基本都属于这一类。所以你现在用 LangChain 做对话，遇到的类通常都是 Chat 开头的。

在实际代码里，你会先实例化一个具体的模型对象。比如最常用的ChatOpenAI类，这些年已经独立到了langchain-openai包里：

from langchain_openai import ChatOpenAI model = ChatOpenAI( model="some-chat-model", temperature=0.7, max_tokens=1024, timeout=30, )

这里有两个参数需要理解，而不是直接抄：

temperature控制随机性，取值范围一般是 0 到 1 或 0 到 2，取决于服务商。它就像厨师做菜时放盐的手感：数值高，模型发挥更大胆，回答更多样；数值低，模型更保守、更愿意重复稳妥的表达。如果你要模型做代码修正、格式转换这类精确任务，建议调低，比如 0 到 0.3；如果做头脑风暴、写文案，可以把温度调高。

max_tokens限制的是单次回答的最大 token 数，不是字符数。中文一般一个字可能对应 1 到 2 个 token。设太小，回答会被截断；设太大，可能浪费费用。我的习惯是先给一个保守值，比如 1024，跑通了再按需调。

2.2 消息层：System、Human、AI 三种消息的三方角色

LangChain 的消息类型就是对话角色的结构化表达。你只需要记住三种：

SystemMessage是系统指令，相当于你给模型设定身份和行为准则。它不参与"对话记忆"，但会一直影响模型的回答。比如你告诉系统"你是一名耐心的数学老师，每次回答先给思路再给答案"，那么后续每轮用户提问，模型都会带着这个设定来回答。

HumanMessage是用户输入，每一轮用户说了什么，就应该记录为一条 HumanMessage。

AIMessage是模型的回复。它有两个作用：一是让你拿到模型输出；二是当你做多轮对话时，历史中的模型回答也要以 AIMessage 的形式拼回给模型，模型才知道自己之前说过什么。

用一个生活类比来理解：SystemMessage 是新员工入职时发的岗位说明书，HumanMessage 是客户提出的问题，AIMessage 是你上一次给客户做出的答复。一个靠谱的客服要既记得岗位要求，又记得客户说过什么、自己承诺过什么，才能继续服务。

在 LangChain 里构造这三种消息非常简单：

from langchain_core.messages import SystemMessage, HumanMessage, AIMessage messages = [ SystemMessage(content="你是一名资深的技术博客编辑，擅长把复杂问题讲清楚。"), HumanMessage(content="请解释什么是 API。"), AIMessage(content="API 是应用程序之间交互的接口约定，就像餐厅的菜单……"), HumanMessage(content="那我在浏览器里访问网页算不算调用 API？"), ]

2.3 链层：从旧的 LLMChain 到 LCEL 的进化逻辑

有了模型和消息，一次最简单的调用其实已经能完成了：把消息列表传给模型对象，让它返回一条 AIMessage。这在 LangChain 里也是合法的用法，不需要创建任何链。

不过实际业务里，我们的输入往往不是已经构造好的消息列表，而是一段用户原始文本，需要先套一个提示词模板，再交给模型。这就有必要用到链。

早期版本的 LangChain 把这种方式封装成LLMChain，写法是：

from langchain.prompts import PromptTemplate from langchain.chains import LLMChain prompt = PromptTemplate.from_template("请用三句话介绍{topic}") chain = LLMChain(llm=model, prompt=prompt) result = chain.invoke({"topic": "LangChain"})

这个写法现在依然能搜到很多教程，但在 LangChain 0.1 之后，它已经不是主流了。更推荐的是 LCEL（LangChain Expression Language）。LCEL 用管道符把各个组件串起来，像 Linux 命令行里command1 | command2一样，前一个环节的输出自动成为后一个环节的输入。

上面那条链用 LCEL 写法是：

from langchain_core.prompts import PromptTemplate prompt = PromptTemplate.from_template("请用三句话介绍{topic}") chain = prompt | model result = chain.invoke({"topic": "LangChain"})

LCEL 相比旧式链有几个实际好处：默认支持流式输出，你可以在生成过程中逐步拿到文字；天然支持并行组合和异步调用；链本身是一个可被继续拼接的组件，可以嵌入更大的流程里。这也是为什么新项目我更推荐直接从 LCEL 入手。

LCEL 对象背后统一实现了一套Runnable协议，核心方法就三个：

• invoke(input)：单次运行，传入一个输入字典或消息列表，返回单个结果；
• batch([input1, input2, ...])：批量运行，一次性处理多条输入；
• stream(input)：流式运行，按生成进度逐个产出数据块。

你可以把 Runnable 想象成一个带标准插口的电器。不管里面是提示词、模型还是整条链，都遵循同一套插口标准。这也是为什么外面拼接的逻辑可以做到相对稳定。

3. 搭一个最小可用的对话工程，少走我的弯路

这一节直接进入实战。我会给两个版本：一个是不建链、直接组织消息的最简调用；另一个是用提示词模板加 LCEL 的组合调用。两者都很常用，第一个让你理解本质，第二个更贴近真实业务。

3.1 环境准备与依赖版本

建议用 Python 3.9 以上版本，建一个干净的虚拟环境，别直接往全局环境里装。因为 LangChain 生态的依赖很多，版本冲突是家常便饭，虚拟环境能帮你隔离掉大部分问题。

python -m venv .venv source .venv/bin/activate # Windows 下是 .venv\Scripts\activate

然后安装依赖。我以当前主流的接入方式为例：

pip install langchain langchain-openai python-dotenv

这里有个很多人忽略的细节：langchain-openai这个名字看着像只是给某一家服务商用的，但它实现了 OpenAI 兼容协议，而目前市面上不少模型服务商都提供兼容接口。所以即使你用的不是那家原厂 API，也可能只需要修改 base_url 就能接入。你可以理解为这是 LangChain 生态里最通用的一条接入通道。

API Key 千万不要硬编码在代码里。我见过有人把 Key 发到同事群里，结果被扫到了，账单瞬间飙升。正确做法是放在.env文件里，让python-dotenv在启动时加载：

# .env OPENAI_API_KEY=sk-your-key-here OPENAI_BASE_URL=https://api.example.com/v1 OPENAI_MODEL_NAME=some-chat-model

然后写一个独立的配置文件或直接加载：

import os from dotenv import load_dotenv load_dotenv() api_key = os.getenv("OPENAI_API_KEY") base_url = os.getenv("OPENAI_BASE_URL") model_name = os.getenv("OPENAI_MODEL_NAME")

把 Key 放在.env里，再把.env写进.gitignore，这样就算仓库被别人 clone，密钥也不会泄露。

3.2 第一种用法：不建链，直接组织消息调用

理解 LangChain 本质的最好方式，就是暂时忘掉链，直接用消息列表调模型。代码如下：

from dotenv import load_dotenv from langchain_openai import ChatOpenAI from langchain_core.messages import SystemMessage, HumanMessage load_dotenv() model = ChatOpenAI(model=os.getenv("OPENAI_MODEL_NAME")) messages = [ SystemMessage(content="你是一名简洁的技术顾问，回答尽量控制在三句话以内。"), HumanMessage(content="什么是面向对象编程？"), ] resp = model.invoke(messages) print(type(resp)) # <class 'langchain_core.messages.ai.AIMessage'> print(resp.content) # 实际回复内容

这段代码里，model.invoke(messages)的返回值不是一个普通字符串，而是一个AIMessage对象。你主要关心它的content属性，但对象上还有很多元数据，比如 token 用量、响应 ID 等。这样设计是有意的：在复杂的链式流程里，下游可能需要同时访问回复内容和附带数据。

我第一次跑通这个例子时，最大的感受是：原来 LangChain 内部已经把messages列表转换成了服务商 API 需要的 JSON 结构，我不用再关心role字段的字符串拼写。这看起来只是省了一行，但在多轮对话时会省掉大量容易出错的手工组装。

3.3 第二种用法：用提示词模板与 LCEL 组装一条对话链

直接传消息虽然简单，但真实项目里用户输入往往不能被直接当成人话塞给模型。我们通常要给模型一套稳定的提示词框架。比如做一个"美食推荐助手"，希望模型始终记住它是美食推荐者，并且按固定格式输出。这时用PromptTemplate更合适。

from langchain_core.prompts import PromptTemplate from langchain_openai import ChatOpenAI model = ChatOpenAI(model=os.getenv("OPENAI_MODEL_NAME")) prompt = PromptTemplate.from_template( "你是一位美食推荐助手。用户会告诉你口味偏好，请按以下格式推荐：\n" "菜品名：xxx\n理由：xxx\n推荐指数：x/5\n\n" "用户需求：{user_input}" ) chain = prompt | model resp = chain.invoke({"user_input": "我喜欢吃辣的，一个人在成都出差，推荐三道菜"}) print(resp.content)

注意chain.invoke传入的是一个字典，键名要和模板里的变量名{user_input}对应。如果键名和变量名不一致，LangChain 会立即抛出错误，这是新手最常踩的坑之一。

LCEL 管道prompt | model的逻辑是：先执行 prompt，把输入的字典渲染成完整文本或消息列表，再把结果传给 model 执行。整个过程像一条小流水线，清晰且容易扩展。

如果你接下来想接流式输出，这个链也支持直接改调stream：

for chunk in chain.stream({"user_input": "我喜欢吃酸的，推荐一道开胃菜"}): if chunk.content: print(chunk.content, end="", flush=True)

到这里，一个"能用"的简单对话已经完成了。但真实项目里跑起来会遇到各种稀奇古怪的问题，下一章专门讲排查链路。

4. 第一次运行就翻车？把这套排查链路记下来

老实说，我很少见别人第一次写 LangChain 代码就一路绿灯。它的报错信息有时候很长，长得让人慌张。但大多数问题其实可以按特征快速归类。

4.1 报错分类与快速定位表

我把实际过程中高频出现的错误类型整理成了一张表，你可以直接对照查找：

注意，错误信息往往很长，但决定性信息通常在前几行或错误码里。别被中间一长串堆栈吓到，先看第一行最关键的部分。

4.2 踩坑实录：pydantic 版本冲突把我卡了一下午

给你讲一个我真实经历过的案例，也是 LangChain 项目里非常典型的问题。有一次我在一个存量项目里接入 LangChain，环境里已经装了一个比较新的 pydantic 2.x。我执行from langchain_openai import ChatOpenAI时没报错，但一实例化就抛出一个非常长的ValidationError，说某个字段校验失败，底层原因是某个传递链的字段描述对不上。

我一开始以为是代码写得不对，反复对照文档，把参数删了又加，就是不行。后来我用pip check检查依赖冲突，果然发现langchain-core需要 pydantic 版本范围和现存版本有冲突。LangChain 0.1 之后的版本都在向 pydantic 2.x 迁移，但很多旧依赖还是按 1.x 写的，两套校验逻辑混在一起，就会出现难以理解的字段校验报错。

解决办法是在项目里统一锁定版本范围，比如：

pip install "langchain>=0.3,<0.4" "langchain-core>=0.3,<0.4" "pydantic>=2.8,<3"

之后再运行，问题消失。

这个坑给你的启发是：LangChain 生态迭代太快，直接装最新版不一定稳妥。记录项目依赖时，不仅要记录直接安装的包，还要关注langchain-core、langchain-openai、pydantic之间的版本三方匹配。我自己的习惯是用requirements.txt固定到具体小版本，而不是写>=的宽松范围。

4.3 三层排查法：API 通了，LangChain 才会通

当 LangChain 调大模型 API 失败时，我会按三层来定位，而不是在 LangChain 这一个层面死磕。

第一层：API 本身是否可用。先用最简单的工具直接请求，绕开 LangChain。比如用 curl 测试你配置的 base_url 是否真实有效：

curl https://api.example.com/v1/chat/completions \ -H "Authorization: Bearer sk-your-key" \ -H "Content-Type: application/json" \ -d '{"model":"some-chat-model","messages":[{"role":"user","content":"你好"}]}'

如果这一步就失败，基本可以确定问题在 API 的服务地址、鉴权、模型名或网络环境，跟 LangChain 没关系。这一层排查能帮你避免在框架里瞎找。

第二层：LangChain 的模型配置是否正确。如果第一步是通的，再检查代码里ChatOpenAI的base_url、model、api_key三要素是否和 curl 请求完全一致。这里最容易出错的是默认值覆盖：某些参数没显式传，走了内置默认 base_url，结果请求发到了一个你没有账号权限的地址。

第三层：提示词和消息结构是否正确。走到这一层，API 网络和配置都没问题了，剩下的就是模型返回的内容不对，或者报上下文相关错误。此时要检查是不是系统提示词太复杂、消息顺序是否合理、历史消息是否过长。

这个方法看起来不起眼，但能直接砍掉 80% 的调试时间。我在团队里带人排查 LangChain 问题时，总是先问一句：curl 能通过吗？很多人其实没试过这一步就直接在代码层面上瞎改。

5. 从"简单对话"到"还能用的对话"：记忆、流式与结构化输出

跑通最小例子只是第一步。真实项目里，用户几乎一定会问"为什么模型不记得我之前说了什么"。这就是多轮对话和历史消息的问题。接下来我把三个最实用的扩展依次说清楚，每个都有完整代码。

5.1 让对话记住上文：历史消息的注入方式

大模型本身没有记忆，所谓"多轮对话"就是把之前的所有对话内容重新拼进请求里，让模型从上下文中"回忆"起来。LangChain 并不神奇，它只是帮你规范了消息结构。

新版 LangChain 中，我在生产环境更推荐的做法是手动维护历史消息列表，不依赖旧版ConversationBufferMemory。原因很简单：显式的消息列表更容易控制 token 长度，也更方便持久化。

from langchain_core.messages import HumanMessage, AIMessage, SystemMessage history = [] # 持久层可以存到数据库里 def chat_with_history(user_input: str): messages = [ SystemMessage(content="你是一个面试教练，负责帮助用户进行模拟面试。"), *history, HumanMessage(content=user_input), ] resp = model.invoke(messages) history.append(HumanMessage(content=user_input)) history.append(AIMessage(content=resp.content)) return resp.content

这段代码的精髓在于：把历史列表用*history展开放在 System 消息之后、当前用户消息之前。这样模型看到的完整上下文顺序是：系统设定 → 过去的问与答 → 当前问题。

需要注意两点。第一，历史消息必须成对追加，用户输入和模型回复都要存，否则模型看到的对话是残缺的。第二，历史列表不能无限增长。很多服务商的上下文窗口是固定的，比如几万 token，超过就会报错。简单对话可以设置一个最大轮次，超过就丢弃最早的消息：

MAX_HISTORY_ROUNDS = 5 if len(history) > MAX_HISTORY_ROUNDS * 2: history = history[-(MAX_HISTORY_ROUNDS * 2):]

这里的*2是因为每一轮会产生人类消息和 AI 消息两条。

5.2 打字机体验：流式输出

在实际产品里，流式输出几乎是标配。用户等大模型生成完整回答可能要十几秒，如果没有打字机效果，体验会非常煎熬。流式输出的本质是：模型边生成边传送增量内容，客户端可以边接收边显示。

LangChain 的 LCEL 对流式支持很友好，前面也提到过。只要链是基于 Runnable 协议构建的，直接调stream方法即可：

prompt = PromptTemplate.from_template( "你是一位景区导览员，请用三段话介绍这个景点：{spot}" ) chain = prompt | model for chunk in chain.stream({"spot": "黄山"}): print(chunk.content, end="", flush=True)

如果你是做一个网页应用，需要把流式能力暴露给前端，那就不能用简单的 for 循环了。常见的方案是用 WebSocket 或服务端向客户端推送事件。此时 LangChain 的作用是提供异步的astream方法：

async for chunk in chain.astream({"spot": "黄山"}): # 这里把 chunk.content 推给前端 await websocket.send(chunk.content)

需要注意chunk.content有时会是空字符串，尤其是很多服务商在流式响应开头会先返回一些文本格式的 meta 数据。所以收到空字符串时直接跳过，不要把它当成一个空白答案发给前端。

5.3 让模型吐出规规矩矩的数据：结构化输出

做聊天机器人时，我们经常不只是要一段文字，而是需要模型返回可解析的数据结构。举个例子：你做一个"旅游攻略问答"机器人，用户问完问题后，你希望模型除了给文字回复，还顺带返回一个包含推荐景点列表和预算等级的 JSON 对象，供前端直接渲染卡片。

用裸调用的话，你得让模型返回 JSON 字符串，再自己json.loads，然后祈祷模型格式没跑偏。LangChain 提供了结构化输出方案，可以用 Pydantic 定义一个数据类，让模型按类结构返回并自动校验。

from pydantic import BaseModel, Field from langchain_openai import ChatOpenAI class TravelPlan(BaseModel): spot: str = Field(description="推荐的景点名称") reason: str = Field(description="推荐理由") best_time: str = Field(description="最佳游玩时间") model = ChatOpenAI(model=os.getenv("OPENAI_MODEL_NAME")) structured_model = model.with_structured_output(TravelPlan) resp = structured_model.invoke("我在上海，周末想找个周边古镇放松") print(type(resp)) # <class '__main__.TravelPlan'> print(resp.spot, resp.reason, resp.best_time)

with_structured_output在底层会让模型以 JSON 模式输出，再交给 Pydantic 校验。如果模型生成的结果不符合类定义，invoke会抛出校验错误。

这个能力的门槛比前两个稍微高一点：有的模型对 JSON 模式支持较好，有的模型字段对齐能力较弱。遇到解析失败时，建议先给每个字段写好清晰的description，模型会更理解每个字段的含义。另外要提醒的是，结构化输出让模型在格式上消耗一定能力，回答的"文采"可能下降——鱼与熊掌不可兼得，适合稳定性优先的场景。

6. 给刚上手的几个实战心得和边界认知

6.1 我实际使用过程中沉淀的几条保命建议

第一，锁定版本，别追新。LangChain 的接口迭代速度实在太快，今天写的代码，过半年再看可能已经弃用。如果你是在一个长期维护的项目里，一定要把langchain-core、langchain-openai、pydantic的版本精确记录到锁文件中，升级前单独做一轮回归测试。

第二，初始化代码独立成模块。把模型实例、提示词模板、各类链拆到单独的配置文件或模块里，业务代码只引用这些对象，不要散落在各个函数里。这样换模型、调参数时，改动点很集中。我见过太多项目，一个ChatOpenAI(...)配置被复制了七八处，改 temperature 时要全局搜索替换。

第三，善用回调来观测 Token 和耗时。LangChain 支持注册回调处理器，生产调试时非常实用。举个例子统计一次调用的 token 用量：

from langchain_core.callbacks import BaseCallbackHandler class TokenCounter(BaseCallbackHandler): def __init__(self): self.total_tokens = 0 def on_llm_end(self, response, **kwargs): usage = response.llm_output.get("token_usage", {}) self.total_tokens = usage.get("total_tokens", 0) counter = TokenCounter() chain.invoke({"user_input": "你好"}, config={"callbacks": [counter]}) print(counter.total_tokens)

不管是为了成本预估还是调试，这一步很值得做。你就知道一条链跑下来到底花了多少 token，而不是等到月底账单吓一跳。

6.2 我的取舍标准：什么时候该用，什么时候该弃

写了几年大模型应用，我对 LangChain 的心态从最初的"什么都用它"，变成现在的"按需使用、可随时剥离"。它并不是大模型应用的银弹。如果你需要极致的性能控制，比如每一毫秒的延迟都很重要；或者链路非常简单，只做一次翻译；再或者你希望完全掌控每一次请求的报文内容——那自己写函数调用其实更直接。

反过来，如果你的主要矛盾是"快速做一个能对话、能多轮、能接工具、能扩展原型"，LangChain 的抽象会帮你显著提速。我个人的建议是：在项目初期放心用 LangChain 快速验证想法，但要把核心业务逻辑和框架细节隔离开。具体做法是，在所有入口统一使用你自己封装的chat()函数，内部才去调用 LangChain 的链。这样万一哪一天框架成了阻碍，你只需要改写一个函数，而不是全项目动手术。

最后再说一个小技巧：如果你做的是本地调试，尽量让系统提示词一开始就说明"回复保持简短"。很多误会都是因为模型默认回答得太长，导致你以为它理解偏了，其实是温度、max_tokens 和提示词三者在共同起作用。代码报错只是一部分，语言模型对话的质感，更多是在这些细节上一点点调出来的。