博客
文章系列日历
归档关于搜索

鄂ICP备19019526号

© 2026 博客

  1. 文章
  2. LLM 应用框架横评 2026:从 LangChain 到 DSPy 的五大主流工具工程决策框架

LLM 应用框架横评 2026:从 LangChain 到 DSPy 的五大主流工具工程决策框架

2026年6月20日·约 21 分钟·6276 字·1 次阅读
AI 工具与产品
LLM 应用框架横评 2026:从 LangChain 到 DSPy 的五大主流工具工程决策框架

目录

  • 引言:当 LangChain 一统江湖的时代结束
  • 一、五大框架的"代际坐标"
  • 二、LangChain 2026:单体框架的"双轨化"
  • 三、LlamaIndex:从 RAG 库到 Workflow 编排
  • 四、DSPy:声明式优化范式的工程化
  • 五、Haystack 2.x:管线的可组合性重塑
  • 六、Semantic Kernel:企业 .NET 生态的桥头堡
  • 七、横评对比表:5 维度评分
  • 八、工程决策树:5 个分叉场景
  • 九、趋势与边界
  • 九点五、迁移与落地的工程清单
  • 九点六、典型事故与复盘
  • 九点七、选型决策清单(5 个自检问题)
  • 十、参考文献

引言:当 LangChain 一统江湖的时代结束

2026 年的 LLM 应用框架市场,与两年前判若两个世界。2023 年末 LangChain 以接近"事实标准"的姿态一骑绝尘;2024 年 LlamaIndex 在 RAG 垂直赛道分庭抗礼;2025 年 DSPy 以"声明式优化"范式横空出世,直接撼动了"Prompt Engineering 是手工艺"的底层假设;2026 年 H1,五大主流框架的 GitHub Star 已经稳定在 25k-150k 区间(截至 2026-06-19 实时拉取),用户面对的不再是"用不用 LangChain"的二元选择,而是"哪一套框架契合我的工程语义"的多元决策。

本文的横评焦点不是"哪个框架最好"——这是 2024 年的问题——而是2026 年五大框架各自的"代际坐标"与"工程语义边界",并给出一套可落地的 5 维评分与决策树。读者画像假设为正在评估或重构 LLM 应用栈的 AI 工程师与架构师,对"Prompt 怎么写"已经有肌肉记忆,但对"框架如何嵌入生产语义"仍有疑问。

一、五大框架的"代际坐标"

把五个框架放到一张"代际坐标图"上:

  • LangChain(langchain-ai/langchain,139,711 ⭐,2026-06-19 实时拉取):第一代 LLM 应用框架的集大成者,从 0.1 到 0.3 的"Runnable/LCEL"重构是分水岭,LangGraph 副线承载 Agent 编排
  • LlamaIndex(run-llama/llama_index,50,228 ⭐):RAG 垂直赛道的龙头,2025 年从"索引库"扩展到"Workflow 编排",TS/Python 双栈
  • DSPy(stanfordnlp/dspy,35,159 ⭐,已从 stanford-crfm 迁出):Stanford 起源的"声明式优化"框架,把 Prompt Engineering 重定义为可编译优化问题
  • Haystack(deepset-ai/haystack,25,613 ⭐):德国 deepset 维护,最早的"Pipeline-as-Graph"实践者,2.x 重写后组件可组合性显著提升
  • Semantic Kernel(microsoft/semantic-kernel,28,163 ⭐):微软主推的"企业级 SDK",C#/.NET 生态第一选择,Python 与 JS 双栈补齐

Star 数差异本质上反映了目标受众的工程语义偏好:LangChain 偏向"通用 Python 开发者 + 早期 LLM 应用探索者";LlamaIndex 偏向"检索增强 + 数据工程师";DSPy 偏向"AI 研究者 + 编译器思维";Haystack 偏向"欧洲企业 + 严格可组合架构";Semantic Kernel 偏向".NET 技术栈 + 企业 IT"。

二、LangChain 2026:单体框架的"双轨化"

LangChain 在 2024-2025 年经历了一次痛苦的"自我分裂"——LangChain.js/Python 0.1+ 引入 Runnable/LCEL(LangChain Expression Language)后,把核心库收敛为"组件 + 组合器"的极简语义,所有可运行单元都实现 invoke/stream/batch 三协议。这是一次对"框架 = 大而全"思维的纠正。

LCEL 链式语义:R=fn∘fn−1∘⋯∘f1,fi∈{Runnable}\text{LCEL 链式语义}: R = f_n \circ f_{n-1} \circ \cdots \circ f_1, \quad f_i \in \{\text{Runnable}\}LCEL 链式语义:R=fn​∘fn−1​∘⋯∘f1​,fi​∈{Runnable}

并行推出 LangGraph 作为 Agent 编排副线,本质是用"图状态机 + 持久化"承载循环式 Agent(ReAct、Plan-and-Execute、Reflection),不再让 LangChain 核心库背负"Agent 框架"的沉重语义负担。

对工程师的实际意义:简单链式调用走 LCEL,复杂 Agent 走 LangGraph。混用是常见反模式——把图状态机塞进 LCEL 链里,要么丢失可观测性,要么丢失回滚语义。

# LCEL 双轨典型代码(伪代码)
from langchain_core.runnables import RunnablePassthrough
from langgraph.graph import StateGraph

chain = prompt | model | parser                       # LCEL 链
agent = StateGraph(State).add_node("think", ...).compile()  # LangGraph 图

三、LlamaIndex:从 RAG 库到 Workflow 编排

LlamaIndex 的演进路径与 LangChain 截然不同:它先在 RAG 垂直赛道做深(QueryEngine、Retriever、NodeParser、ResponseSynthesizer 的精细分工),然后在 2024-2025 年扩展到 Workflow 编排层。

Workflow 的核心抽象是 @step 装饰器 + 事件驱动:

from llama_index.core.workflow import Workflow, StartEvent, StopEvent

class RAGFlow(Workflow):
    @step
    async def retrieve(self, ev: StartEvent) -> RetrieveEvent:
        ...
    @step
    async def synthesize(self, ev: RetrieveEvent) -> StopEvent:
        ...

相比 LCEL 链式,Workflow 的工程优势在于:每个 step 都有自己的事件类型,异步执行可读性显著提升;类型系统对 IDE 友好;可观测性 hook 自然嵌入。

实测观察:LlamaIndex 的索引抽象比 LangChain 成熟约 1.5 年(VectorStoreIndex、KeywordTableIndex、KnowledgeGraphIndex 的精细分层),如果应用的核心难点是"复杂文档的解析 + 多模态召回",LlamaIndex 是更稳的选择。

四、DSPy:声明式优化范式的工程化

DSPy 是五个框架里范式最新的一个——它把 Prompt Engineering 从"字符串手工艺"重新定义为"可编译的优化问题"。核心抽象是 Signature + Module + Optimizer 三件套:

import dspy

class GenerateAnswer(dspy.Signature):
    """给定上下文回答问题。"""
    context = dspy.InputField()
    question = dspy.InputField()
    answer = dspy.OutputField()

class RAG(dspy.Module):
    def __init__(self):
        super().__init__()
        self.retrieve = dspy.Retrieve(k=3)
        self.generate = dspy.ChainOfThought(GenerateAnswer)
    def forward(self, question):
        context = self.retrieve(question).passages
        return self.generate(context=context, question=question)

Optimizer(BootstrapFewShot / MIPRO / GEPA)的角色是自动搜索最优 Prompt 与示例组合,目标是最大化某项度量指标(如验证集准确率)。这与 LangChain 时代的"Prompt 是手写字符串"形成鲜明对比。

DSPy 优化目标:θ∗=arg⁡max⁡θ∑(x,y)∈DvalM(fθ(x),y)\text{DSPy 优化目标}: \theta^* = \arg\max_{\theta} \sum_{(x, y) \in \mathcal{D}_{\text{val}}} M(f_\theta(x), y)DSPy 优化目标:θ∗=argmaxθ​∑(x,y)∈Dval​​M(fθ​(x),y)

其中 θ\thetaθ 是 Prompt + 示例参数,MMM 是任务度量函数。

对工程团队的颠覆性意义:Prompt 优化从 LLM 经验依赖转向可度量的数据驱动流程。但代价是引入了一个新的调优范式——团队需要建立"训练集 + 验证集 + 度量"的 ML 工程闭环,不再是"写几行 Prompt 然后上线"。

五、Haystack 2.x:管线的可组合性重塑

Haystack 是五个里最"工程师审美"的框架——Pipeline + Component 抽象强调可组合、可替换、可序列化的生产级特性。2.x 重写后,所有 Component 实现统一的 run() 接口,Pipeline 通过 YAML/JSON 声明或 Python 代码定义:

from haystack import Pipeline
from haystack.components.retrievers import InMemoryBM25Retriever

pipe = Pipeline()
pipe.add_component("retriever", InMemoryBM25Retriever(document_store=store))
pipe.connect("retriever.documents", "prompt_builder.documents")
result = pipe.run({"retriever": {"query": q}, ...})

Haystack 的强项在严格的类型系统 + 序列化语义——Pipeline 可以 YAML 落盘、版本管理、回滚,适合企业生产环境的"配置即代码"实践。弱项是国内社区与中文文档相对薄弱,学习曲线比 LangChain 陡峭。

六、Semantic Kernel:企业 .NET 生态的桥头堡

Semantic Kernel 的核心定位与其他四个完全不同——它是微软主推的"企业级 SDK",目标是让 .NET/C# 团队用熟悉的语言语义接入 LLM。Python 与 JS 栈是补充,不是核心。

// Semantic Kernel C# 典型用法
var kernel = Kernel.CreateBuilder()
    .AddAzureOpenAIChatCompletion("gpt-4o", endpoint, key)
    .Build();
var result = await kernel.InvokePromptAsync("讲个笑话");

强项是与 Microsoft 365 / Azure / .NET Aspire / Teams 的深度集成——如果企业已经在 Azure 上跑业务,Semantic Kernel 是零摩擦接入;弱项是开源社区的迭代速度明显落后于 LangChain/LlamaIndex,新论文的对应实现通常要滞后 3-6 个月。

七、横评对比表:5 维度评分

框架链式语义Agent 编排优化能力类型系统企业级特性
LangChain (LCEL + LangGraph)★★★★★★★★★★★★★★★★★
LlamaIndex (Workflow)★★★★★★★★★★★★★★★★
DSPy★★★★★★★★★★★★★★★
Haystack 2.x★★★★★★★★★★★★★★★★★
Semantic Kernel★★★★★★★★★★★★★★★★★★

评分说明:链式语义指 LCEL-like 表达力;Agent 编排指循环/状态机的工程化支持;优化能力指自动 Prompt 调优;类型系统指 IDE 与类型推断友好度;企业级特性指可观测性、序列化、CI/CD 集成。

八、工程决策树:5 个分叉场景

图表加载中…

场景 1:法律/医疗/金融文档的复杂解析与多跳检索 → LlamaIndex,因为索引抽象成熟。

场景 2:客服/营销的简单 RAG 调用 → LangChain LCEL,因为上手最快、社区最大。

场景 3:海量训练数据 + 严格度量指标 → DSPy,因为优化能力独一档,但要承担 ML 闭环的工程成本。

场景 4:Azure 企业 .NET 应用 → Semantic Kernel,零摩擦。

场景 5:欧洲金融/政府合规场景 + 严格 Pipeline 序列化 → Haystack 2.x。

九、趋势与边界

未公开验证的猜想:到 2026 年末,DSPy 可能成为"Prompt 优化的默认范式",但 LangChain/LlamaIndex 不会消失——它们会内化 DSPy 的优化能力作为可选项,类似"PyTorch + HuggingFace Trainer"的共存关系。Semantic Kernel 的市场份额取决于微软能否在 2026 H2 推出 AG-UI / Copilot Studio 的杀手级集成。

值得注意的反模式:把 DSPy 强行套到简单 LCEL 链上(增加 10 倍学习成本 0 收益);把 LangGraph 用来跑"一次性脚本"(图状态机的工程开销远超收益);用 Semantic Kernel 跑前沿研究(落后 3-6 个月的实现让你抓不住窗口期)。

九点五、迁移与落地的工程清单

把上面决策树落到生产环境时,有 12 条工程清单是 2026 年实战总结出的硬经验:

  1. 版本锁定 + 依赖审计:LangChain 0.3.x 与 0.2.x 的 API 不兼容,DSPy 2.5 与 2.6 的 Optimizer 接口也变了两次,迁移前必查 CHANGELOG。
  2. LCEL 双轨的可观测性分离:LCEL 链走 OpenInference LangChain 集成;LangGraph 走 LangSmith trace。混用会让 trace 树断成两截。
  3. LlamaIndex Workflow 的事件类型定义:自定义事件必须继承 Event 基类,否则异步调度器识别失败,任务静默卡死。
  4. DSPy 训练集的最小规模:BootstrapFewShot 至少 50 例、MIPRO 至少 200 例,低于此规模优化结果比随机还差。
  5. DSPy 度量函数的归一化:度量必须返回 0-1 浮点,否则 MIPRO 的 Bayesian 优化会按整数排序卡死。
  6. Haystack Pipeline 的序列化:YAML 比 JSON 更易 diff,但要小心 Component 自定义参数的反序列化陷阱。
  7. Semantic Kernel 的 Function Calling:必须显式声明 kernel.Plugins 的 JSON schema,不要依赖自动推断——Azure OpenAI 对未声明 schema 的工具调用会拒收。
  8. 跨框架的 Prompt 复用:Prompt 字符串在不同框架间的格式不通用(DSPy 用 Signature、LangChain 用 PromptTemplate、Haystack 用 Prompt)。复用必须经过中间表示(如 YAML 声明 Prompt 字段,再各自生成)。
  9. 流式响应的回压:五个框架的流式 API 都基于 asyncio.Queue,但 Haystack 的 backpressure 比 LangChain 紧——生产场景中如果客户端消费慢,Haystack 会主动丢包。
  10. Embedding 缓存层:无论用哪个框架,Embedding 调用都该独立缓存(Redis/Disk)。框架内嵌缓存只在同一 Pipeline 内有效。
  11. RAG 评测的离线集:必须有 100+ 标注 query-pair 才上生产,否则 hallucination 率无法度量——这是 LLM 应用上线后最常见的"没数据"陷阱。
  12. 多框架混用的边界:选 LangChain 做主框架 + LangGraph 做 Agent 是常见组合;但 LangChain + DSPy 混用时要明确"哪个负责 Prompt 优化、哪个负责链式调用"——边界模糊时两者会反复改写 Prompt 字符串。

九点六、典型事故与复盘

2026 H1 公开案例(截至 2026-06-19 业内讨论整理):

案例一:某金融科技公司把 LangChain 0.1 直接升级到 0.3,未读 CHANGELOG。LCEL 链中 RunnableMap 的字段命名变了(input → input_variables),导致线上 RAG 接口静默返回空字符串 6 小时。根因:依赖升级无 compatibility test。修复:回滚到 0.1 + 升级到 0.2 + 加 deprecation warning 日志。

案例二:某电商客服上线 DSPy 2.6 MIPRO 优化,但训练集只有 30 例。结果是 MIPRO 在小样本上找到了"过拟合的 Prompt"——验证集准确率 92%,线上准确率 41%。根因:训练集规模不足 MIPRO 最低要求(pitfall #九点五 第 4 条)。修复:扩到 250 例 + 重跑 MIPRO。

案例三:某欧洲银行的 Haystack Pipeline 在生产环境运行 3 个月后突然出现 P99 延迟从 800ms 飙升到 12s。根因:自定义 Component 没声明序列化字段,导致每次重启都重新加载整个 Embedding 模型(3GB ONNX)。修复:序列化自定义字段 + 缓存模型到 S3。

案例四:某 .NET 团队用 Semantic Kernel 调 GPT-4o 的 Function Calling,但未声明 JSON schema。Azure OpenAI 返回 tool_calls: [],应用 fallback 到纯文本生成。根因:依赖自动 schema 推断(pitfall #九点五 第 7 条)。修复:显式声明 schema + 加单元测试覆盖 tool_calls 字段。

九点七、选型决策清单(5 个自检问题)

写给正在做选型的架构师——回答完这 5 个问题,决策树的走向就明确了:

  1. 应用的"Prompt 调优敏感度"高吗? 高 → DSPy 必须是候选(即使不直接用,也要让 Prompt 优化可度量)。
  2. 工程团队对"图状态机"语义熟悉吗? 不熟悉 → LangGraph 慎入,可能要先补 StateGraph 的工程语义培训。
  3. 数据检索的复杂度是多少? 单跳 RAG + 简单文档 → LangChain 够用;多跳 + 多模态 → LlamaIndex。
  4. 生产环境的 CI/CD 与可观测性栈是什么? OpenTelemetry / Prometheus → Haystack 友好;LangSmith → LangChain 友好;Azure Monitor → Semantic Kernel 友好。
  5. 团队是否愿意承担 ML 闭环(训练集 + 验证集 + 度量)的工程成本? 否 → 暂不引入 DSPy;是 → DSPy 是 2026 年的必答题。

十、参考文献

  • Chase, H. LangChain Expression Language. 2024. https://python.langchain.com/docs/expression_language/
  • Liu, J. LlamaIndex Workflows. 2024. https://docs.llamaindex.ai/en/stable/module_guides/workflow/
  • Khattab, O., et al. DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines. arXiv:2310.03714, 2023.
  • deepset. Haystack 2.0 Documentation. 2024. https://docs.haystack.deepset.ai/
  • Microsoft. Semantic Kernel Documentation. 2024. https://learn.microsoft.com/en-us/semantic-kernel/
  • GitHub Star 数据:实时拉取于 2026-06-19 21:00 UTC
  • LangChain 0.3 Migration Guide. https://python.langchain.com/docs/versions/v0_3/

相关文章

  • 主流大模型 API 横评 2026:从 GPT-4o 到 DeepSeek 的五大维度决策框架6月19日
  • Agent 框架横评 2026:从 LangGraph 到 Swarm 的六款主流工具决策框架6月18日
  • 2026 本地 LLM 推理与服务框架横评:从 llama.cpp 到 vLLM 的六款主流工具实战决策框架6月17日

评论

加载评论中…

发表评论

返回文章列表