LangChain vs 直接调 API：什么时候该用框架？
用了三篇介绍 LangChain，这篇反过来问一个问题：什么时候不该用 LangChain？
这个问题很重要。框架是工具，不是信仰。选错了工具，轻则浪费时间，重则项目翻车。
一、直接调 API 的写法长什么样
先看看不用 LangChain 怎么做。假设你想让 GPT 回答一个简单问题：
import openai
response = openai.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "帮我写一封邮件"}]
)
print(response.choices[0].message.content)
三段代码，搞定。简单直接，没有任何多余的东西。
如果想加点提示词模板，自己写：
template = "你是一个专业{persona}，请用{tone}的语气回答：{question}"
prompt = template.format(persona="HR", tone="友好", question="如何请假？")
如果想连调两次模型（先翻译再润色），也是自己写：
translation = openai.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": f"翻译：{text}"}]
)
refined = openai.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": f"润色：{translation.choices[0].message.content}"}]
)
代码量不大，逻辑清晰。对于简单任务，这就是最优解。
二、什么时候直接调 API 更合适
以下几种场景，我建议直接调 API，不用框架：
1. 单次调用就能搞定的任务
如果你的需求就是问一个问题、生成一段文字、翻译一句话，直接调 API 最快。引入 LangChain 反而增加复杂度，杀鸡用牛刀。
实际经验：我做了一个每日新闻摘要工具，每次就是调一次 API、生成一段摘要。用 LangChain 重写后代码量翻了三倍，维护成本更高了，但功能没有任何区别。后来我果断删掉了 LangChain 依赖，回到直接调 API。
2. 对延迟极度敏感的场景
LangChain 的每一层抽象都带来额外的函数调用和对象创建开销。对于实时对话、高频调用等对延迟敏感的场景，这些开销不可忽视。
根据我的测试，同样的请求，LangChain 的调用耗时比直接调 API 多 50-100 毫秒。如果你的服务要求 P99 延迟在 200 毫秒以内，这 100 毫秒可能就是合格和不合格的区别。
3. 团队对 OpenAI API 已经非常熟悉
如果团队所有人都很熟悉 OpenAI 的 API 文档，而且项目只用到 OpenAI 一家模型，LangChain 的统一接口价值不大。你熟悉的 API 比陌生的框架抽象更高效。
4. 需要深度定制模型调用逻辑
LangChain 的抽象层在某些场景下会成为限制。比如你想精细控制 token 使用策略、实现自定义的重试逻辑、或者在模型调用前后做复杂的审计日志，直接调 API 更灵活。
我自己踩过一个坑：LangChain 的 rate limiter 实现和我们的需求不匹配，想改源码才发现 LangChain 的 LLM 抽象层把 rate limit 逻辑封装得很深。最后只能绕过 LangChain，直接调 API 自己实现 rate limiting。
三、什么时候该用 LangChain
以下几种场景，LangChain 的价值非常明显：
1. 需要多步骤编排的任务
当你需要把多个 AI 调用串起来，中间穿插文本处理、条件判断、结果汇总时，LangChain 的 Chain 和 LCEL 能大幅简化代码。
实际经验：我搭过一个内容生成管线，需要 7 步：文本清洗、翻译、摘要、标题生成、配图描述、排版、质量检查。用直接调 API 的方式写，代码有 400 多行，逻辑嵌套很深，改一个步骤要动一片。用 LangChain 重写后，7 步就是 7 个 Chain 用管道符串起来，总共 60 行代码，每步独立修改互不影响。
# 用 LCEL 定义 7 步管线，清晰且可维护
chain = (
clean_text | translate | summarize
| generate_headlines | describe_image | layout | quality_check
)
2. 需要接入知识库（RAG）
如果你的 AI 需要回答不在训练数据里的问题，就得用 RAG。自己实现 RAG 管线至少要写：文档加载、文本切分、向量化、向量数据库操作、相似度检索、把检索结果塞进提示词。这些胶水代码至少 500 行。
LangChain 把 RAG 管线的每一步都封装成了现成组件。我用 LangChain 搭了一个 500 篇文档的知识库问答系统，核心代码不到 100 行。
3. 需要切换或组合多个模型
实际项目中经常需要同时使用不同模型。比如用 GPT-4o 做复杂推理，用 GPT-4o-mini 做简单分类，用开源模型处理敏感数据。每个模型的 API 格式、认证方式、参数命名都不一样。
LangChain 统一了所有模型的调用接口，切换模型只需要改一个配置。这个价值在模型选型阶段特别明显——你可以快速对比不同模型的效果，不用每次改一堆代码。
4. 需要 Agent 能力
如果你的任务需要 AI 自主决策、动态调用工具、根据中间结果调整策略，LangChain 的 Agent 几乎是唯一选择。自己实现 Agent 循环非常复杂，而且很容易踩坑。
5. 团队协作和代码维护
LangChain 提供了标准化的抽象和模式。新成员接手代码时，看到 Chain、Agent、Retriever 这些概念就能快速理解代码结构。如果每个人各自调 API 的方式不一样，代码风格千差万别，维护成本极高。
四、一个简单的判断框架
遇到一个新任务时，我会这样判断：
第一步：这个任务需要多步骤编排吗？如果需要，倾向用 LangChain。
第二步：需要接入外部数据源吗？如果需要 RAG，强烈建议用 LangChain。
第三步：需要切换多个模型吗？如果需要，LangChain 的统一接口能省很多事。
第四步：团队有几个人？人越多，LangChain 的标准化价值越大。两个人的小脚本不需要框架，十个人的项目需要。
如果以上四步的答案都是"不需要"，直接调 API。
用一张图总结：
单次调用？ ──是──→ 直接调 API
│
否
↓
多步骤编排？ ──是──→ 用 LangChain
│
否
↓
需要 RAG？ ──是──→ 强烈建议 LangChain
│
否
↓
多模型切换？ ──是──→ 用 LangChain
│
否
↓
团队 > 5 人？ ──是──→ 用 LangChain
│
否
↓
直接调 API
五、混合使用也是一种选择
实际项目中，混合使用往往是最优解。比如核心业务逻辑用 LangChain 编排，性能敏感的部分直接调 API 绕过框架。或者原型阶段直接调 API 快速验证，确认需求后再用 LangChain 重构。
我自己现在的做法是：简单任务直接调 API，复杂管线用 LangChain 编排，性能关键路径绕过框架。不追求技术一致性，只追求效率和可维护性的平衡。
总结
LangChain 是工具，不是信仰。它的价值在于标准化和简化，但标准化本身也有成本。理解什么时候用、什么时候不用，比盲目追框架更有价值。
一句话总结：如果你的 AI 任务简单到一次 API 调用就能搞定，就别用框架。如果你的任务复杂到需要自己写一堆胶水代码，LangChain 就值得认真考虑。
系列文章：