LLM 应用开发框架选型决策 2026:从 LangChain 到 Coze
把 LangChain 1.0 + LangGraph / LlamaIndex / Vercel AI SDK / Dify / Coze 六个框架放在同一张八维度评分表里,给读者一张可落地的二维选型图——团队画像 × 项目阶段,三个月内交付企业级 LLM 应用。
约 27 分钟阅读7,962 字9 次阅读博主
把 LangChain 1.0 + LangGraph / LlamaIndex / Vercel AI SDK / Dify / Coze 六个框架放在同一张八维度评分表里,给读者一张可落地的二维选型图——团队画像 × 项目阶段,三个月内交付企业级 LLM 应用。
2025 年下半年到 2026 年上半年，LLM 应用开发框架市场经历了一轮剧烈洗牌。LangChain 在 2025 年 10 月发布 1.0 正式版（LangChain v1.0）并把 agent runtime 重命名为 LangGraph，Vercel AI SDK 从前端 React 生态强势渗透到通用后端，Dify 和 Coze 在国内中后台应用市场占据了可观的份额，LlamaIndex 则持续在 RAG 数据抽象层巩固自己护城河。据 Lonae 平台站内统计，截至 2026 年 09 月 30 日，"智能体与 AI 应用开发" tag 下 14 天内累计发布 13 篇文章，几乎覆盖了评估、成本、可观测性、latency、灾备、护栏安全、缓存、长上下文压缩、多轮对话等所有"应用工程化"主题——但横评框架选型这个角度仍然 0 命中。这说明读者在踩过各种坑之后，开始出现一种"我现在用的框架到底是不是合适"的不确定感。这种感觉背后，是当前框架生态位正在快速分化的事实。
很多团队的现状是这样的：项目早期用 LangChain 0.x 起步，三条链拼起来跑通 demo，进入生产之后发现 LCEL 的表达式语法反而成了 debug 障碍；或者团队用了 Dify 在周会里画工作流截图给非技术 stakeholder 看，但真正接入企业 SSO、审计日志、合规扫描的时候才发现低代码平台的扩展点不够用；又或者用 LangGraph 写了状态机，被 graph node 之间的 fan-out / fan-in 折磨得怀疑人生；再或者用 Vercel AI SDK 写完前端 demo 后，需要把后端独立部署，发现 streaming 协议和 Edge runtime 绑死，迁移到 Node.js 自建服务又是一轮重写。这些不是某个框架"不好"，而是它们的设计哲学、适用场景、扩展边界本来就有差异——选错不是技术债，选错是认知债。
本文试图回答一个具体问题：如果你今天要启动一个 LLM 应用项目，团队 3-10 人，需要在三个月内交付给企业内网或者公网用户使用，应该选哪一套框架？本文给出八维评估模型和三层决策树，从框架的类型安全、流式能力、RAG 抽象、Agent 抽象、部署形态、可观测性、成本控制、扩展点八个维度横评六个主流框架（LangChain 1.0 + LangGraph、LlamaIndex、Vercel AI SDK、Dify、Coze），并在最后一节给出从原型到生产的六个月迁移路线图。
本文不打算做"LangChain vs LlamaIndex"的二元比较——那已经过时了——也不打算列"Top 10 LLM 框架排行榜"。我们聚焦的是应用架构师的决策这一件事：给定你的团队构成、部署目标、技术债承受度，哪条路径的迁移成本最低、可控性最高。
先把决策形式化。我们把"LLM 应用开发框架"看作一个三元组 (A, D, E)：A 是抽象能力（你能用多短的代码表达多复杂的能力），D 是部署形态（你的代码跑在哪儿，Edge / Node.js / 浏览器 / 低代码平台 worker），E 是扩展点（你要定制的时候能改什么，改的代价多大）。这个三元组的乘积是"工程熵"——工程熵越大，迁移成本越高、控制力越低。
在每个维度上我们给出一个 0-5 的评分（5 为最好）。类型安全：0 表示运行时任意 string 拼接，5 表示端到端 TypeScript / Python type-safe schema 校验、tool call 字段级校验。流式能力：0 表示仅支持非流式阻塞调用，5 表示原生支持 SSE、WebStream、stream-to-tool-call 双工。RAG 抽象：0 表示没有 RAG 原语，5 表示从 chunking / embedding / rerank / citation 全链路有官方抽象。Agent 抽象：0 表示需要手写 ReAct loop，5 表示有 typed graph / state machine runtime。部署形态：0 表示必须 SaaS 化部署，5 表示可本地 / Edge / 嵌入式 / 自建 server 全场景覆盖。可观测性：0 表示黑盒，5 表示原生 trace span + token cost + quality eval。成本：0 表示闭源付费 SDK、per-call 收费，5 表示开源、可自托管、零额外开销。扩展点：0 表示配置面板固化、无法插入自定义逻辑，5 表示所有节点可替换。
把这八维评分画成雷达图，你就能立刻看出每个框架的"擅长区域"和"短板区域"。LangChain 1.0 + LangGraph 的雷达图是均衡偏 agent 一侧的椭圆——抽象能力强、Agent 抽象满分、可观测性高，但部署形态略扣分（LangServe 的 SaaS 倾向）；LlamaIndex 的雷达图是 RAG 一侧单点突出的非对称形——RAG 抽象 5 分满分但 Agent 抽象只有 3 分；Vercel AI SDK 是流式 + 部署两翼展开的机翼形——流式 5 分、部署形态 5 分（Edge runtime 跨平台），但 RAG 抽象只有 2 分；Dify 和 Coze 是部署形态 + 成本低两轴突出的折翼——非技术 stakeholder 友好但类型安全和扩展点都偏低。
接下来是三层决策树。第一层是"团队是否有专职前端工程师"：有 → Vercel AI SDK / Coze 作为前端对话 UI 候选；没有 → Dify / LangGraph backend-first。第二层是"项目是否需要 RAG 作为核心能力"：需要且数据规模 < 10 万 chunk → LlamaIndex 单独使用；需要且规模 > 10 万 chunk → LlamaIndex 作为索引层 + LangGraph 作为编排层组合；不需要 RAG，纯 agentic 工作流 → LangGraph / CrewAI / AutoGen。第三层是"是否必须私有化部署"：必须私有化 → 自建 LangChain + LangGraph 或 LlamaIndex + 自建编排层；可接受 SaaS → Coze / Dify 公有云。
把八维评分乘三层决策树的结果是一张"二维选型表"——行是团队画像，列是项目画像，格子里是推荐的框架组合。这张表比任何"Top 10 列表"都更可操作，因为它把"什么团队在什么场景下选什么"具体到了可决策粒度。
LangChain 在 2025 年 10 月发布 1.0 正式版（LangChain v1.0 release，2025-10），把原本 chainable 的 LCEL 语法升级为 type-safe 的表达式组合器，同时把 agent runtime 重命名为 LangGraph 并独立发布（LangGraph 0.6+，2025-12）。这次重命名背后是一个根本性转向：LangChain 不再是"链"，而是"组合式抽象"；LangGraph 才是"agent runtime"。理解这个区分是用好 LangChain 生态的前提。
LangChain 1.0 的核心抽象是 Runnable 和 RunnableSequence。Runnable 是任何"输入 X 输出 Y"的可执行单元，RunnableSequence 是把多个 Runnable 用 | 操作符串起来。在 TypeScript SDK 里，这个串起来的过程是 type-safe 的——每个 step 的输入类型是上一个 step 的输出类型，TypeScript 编译器会强制检查。举个具体例子：
import { ChatOpenAI } from "@langchain/openai";
import { StringOutputParser } from "@langchain/core/output_parsers";
import { ChatPromptTemplate } from "@langchain/core/prompts";
const prompt = ChatPromptTemplate.fromMessages([
["system", "你是一名金融分析师"],
["user", "{query}"],
]);
const model = new ChatOpenAI({ model: "gpt-4o-mini", temperature: 0 });
const parser = new StringOutputParser();
const chain = prompt.pipe(model).pipe(parser);
// ^? Runnable<string, string> ← TypeScript 自动推导
const result = await chain.invoke({ query: "分析 AAPL 财报" });
这段代码的 type 信息从 ChatPromptTemplate（输入 {query: string}）流到 ChatOpenAI（输出 AIMessage）再流到 StringOutputParser（输出 string）。任何类型不匹配都会在编译期被 TypeScript 拦截。这是 LangChain 0.x 时代不具备的能力——0.x 用 Chain.call() 接受 any 返回 any，运行时才发现 schema 不对。这是 1.0 的最大改进。
LangGraph 解决的是"agent 的状态机"问题。Agent 不是"prompt + tool + loop"三件套那么简单——真实的 agent 有 checkpoints（断点续跑）、human-in-the-loop（人在中间审批）、branching（分支回滚）、parallel fan-out（并行调用多个 sub-agent）。LangGraph 用 StateGraph 把这些能力形式化为一个有向图：节点是函数、边是状态转移、条件边是基于 state 判断的分支。TypedDict 定义状态 schema，每个节点读写状态，编译期就能检查 graph 是否合法。
import { StateGraph, Annotation } from "@langchain/langgraph";
const State = Annotation.Root({
query: Annotation<string>(),
draft: Annotation<string>(),
critique: Annotation<string>(),
revision_count: Annotation<number>(),
});
const workflow = new StateGraph(State)
.addNode("draft", draftNode)
.addNode("critique", critiqueNode)
.addNode("revise", reviseNode)
.addEdge("__start__", "draft")
.addEdge("draft", "critique")
.addConditionalEdges("critique", needsRevision, {
yes: "revise",
no: "__end__",
})
.addEdge("revise", "critique")
.compile();
这段代码定义了一个"写作-批评-修订"循环 agent。addConditionalEdges 的第二个参数是 (state) => "yes" | "no" 的判断函数，返回 yes 走向 revise，返回 no 走向结束。这是 LangGraph 最强大的特性——状态机的拓扑本身可以是 typed 的。
但 LangChain + LangGraph 不是没有短板。第一个短板是部署形态：LangServe 主要面向 Python 生态（FastAPI 风格），TypeScript 端虽有 LangServe.js 但社区维护滞后；Edge runtime 部署需要手写 adapter（Vercel / Cloudflare Workers 都有官方示例但需要自己集成 streaming）。第二个短板是文档爆炸：Runnable / RunnableSequence / RunnableMap / RunnableParallel / RunnableLambda / RunnableWithFallbacks 这一组抽象对新人极度不友好，新人花一周时间才能理解为什么不能直接 chain.invoke(input)，而要先 await chain.stream(input)。第三个短板是版本碎片化：LangChain 0.x → 1.0 的迁移文档厚达 200 多页，社区里 60% 的教程仍然基于 0.x 写。
LlamaIndex（最新稳定版 0.12.x，2026-Q2）的设计哲学和 LangChain 根本不同。LangChain 是"LLM 应用通用框架"，LlamaIndex 是"LLM 与私有数据之间的胶水"。LlamaIndex 的创始人 jerryjliu 在多次访谈中强调过：LlamaIndex 的核心命题是"如何让 LLM 看到你的数据"——chunk、embed、index、retrieve、rerank、cite 是它的六步核心抽象。
LlamaIndex 的 RAG 抽象是当前所有框架里最完整的。从数据源开始，LlamaIndex 提供 200+ 种 loader（PDF、Notion、Slack、PostgreSQL、S3、Confluence、Jira），把异构数据统一成 Document 对象；接着是 NodeParser 把 Document 切成 chunk（SentenceSplitter、TokenTextSplitter、HierarchicalNodeParser、SemanticSplitter 四种内置策略，外加自定义）；然后是 embedding（OpenAI、Cohere、HuggingFace、BGE、自定义）；再然后是 index（VectorStoreIndex、SummaryIndex、KnowledgeGraphIndex、MultiModalIndex 四种结构）；最后是 query engine 和 retriever 层（QueryEngine、RetrieverQueryEngine、SubQuestionQueryEngine、CitationQueryEngine 等十几种）。这条 pipeline 比 LangChain 的相应模块至少详细 3 倍，这是 LlamaIndex 在 RAG 方向上的护城河。
举个具体的 RAG 应用例子：用 LlamaIndex 做带引用的财报问答：
from llama_index.core import (
VectorStoreIndex,
SimpleDirectoryReader,
CitationQueryEngine,
)
documents = SimpleDirectoryReader("./filings").load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = CitationQueryEngine.from_args(
index,
similarity_top_k=3,
citation_chunk_size=512,
)
response = query_engine.query("2026 Q2 营收同比增长了多少？")
print(response.response)
print(response.cited_text) # ← 引用的原文片段
response.cited_text 自动包含引用片段和它在哪个 chunk，这是 CitationQueryEngine 内置能力。LangChain 要做到这一步需要自己写 custom retriever + post-processing，代码量是 LlamaIndex 的 3-4 倍。
LlamaIndex 的另一个杀手锏是 Workflows（0.11+ 引入，2026-Q1）。Workflows 是 LangGraph 的 LlamaIndex 等价物——用 @step 装饰器把函数声明为图节点，用 Context 维护状态，用事件机制做 human-in-the-loop。和 LangGraph 的区别是 LlamaIndex 的 Workflows 默认假设"数据流"是第一公民（更适合 RAG pipeline），而 LangGraph 默认假设"控制流"是第一公民（更适合纯 agentic loop）。
LlamaIndex 的短板在哪里？Agent 抽象弱。LlamaIndex 早期版本（0.6 之前）尝试过 FunctionAgent 和 ReActAgent，但 0.10 之后官方明确把 agent 能力下放到 LlamaIndex Workflows，不再主推专用 agent 类。这意味着如果你想要一个"调用工具 + 多步推理 + 反思"的复杂 agent，LlamaIndex 不是首选——你得自己用 Workflows 拼。第二个短板是部署形态：LlamaIndex 主要面向 Python 服务端（FastAPI / Django），没有针对 Edge / 浏览器 / 移动端的优化方案。第三个短板是TypeScript SDK 滞后：TS 端只有核心子集，RAG 高级功能（CitationQueryEngine、SubQuestionQueryEngine）只在 Python 端完整。
Vercel AI SDK（5.x，2026-Q3）是 React / Next.js 生态里事实标准的 LLM 集成方案。它的设计哲学非常明确：前端工程师写 LLM 应用的最短路径。从 useChat hook 到 stream-to-ui primitives，整个 SDK 是为前端工程师的思维方式优化的。
useChat 是 Vercel AI SDK 的招牌 hook：
"use client";
import { useChat } from "@ai-sdk/react";
export default function ChatPage() {
const { messages, input, handleInputChange, handleSubmit } = useChat({
api: "/api/chat",
});
return (
<div>
{messages.map(m => (
<div key={m.id}>{m.role}: {m.content}</div>
))}
<form onSubmit={handleSubmit}>
<input value={input} onChange={handleInputChange} />
</form>
</div>
);
}
七行代码就是一个完整的流式聊天 UI。这不是"前端封装 LLM 调用"那么简单——useChat 内部处理了 SSE 流解析、消息状态管理、自动滚动、中断请求、tool call 渲染（m.toolInvocations）、file attachment、错误重试等十几个细节。前端工程师不需要懂 streaming protocol，不需要懂 React state management，不需要懂 tool call schema——他们只需要 useChat。
Vercel AI SDK 5.x 引入的 tool call 流式渲染是杀手锏。传统 LLM 应用里，tool call 通常是阻塞的——模型先输出完整的 tool_call payload，前端收到再渲染"调用中"。5.x 的 stream-to-tool 让 tool call 在模型生成过程中就开始 stream 到前端，用户看到的是一个逐步填充的进度条：
{m.toolInvocations?.map((invocation, i) => (
<div key={i}>
{invocation.state === "partial-call" && "🔍 搜索中..."}
{invocation.state === "call" && `📞 调用 ${invocation.toolName}`}
{invocation.state === "result" && `✅ 结果：${invocation.result}`}
</div>
))}
这种 UX 在 LangChain / LlamaIndex 里都需要手写 SSE 中间件 + 客户端状态机，代码量是 Vercel AI SDK 的 5-10 倍。
Vercel AI SDK 的部署形态是它最被低估的优势。Vercel AI SDK 不是只能在 Vercel 平台跑——它的 runtime adapter 支持 Node.js、Edge runtime（Cloudflare Workers、Vercel Edge、Deno Deploy）、浏览器（WebLLM、WebGPU）三大场景。@ai-sdk/openai 在 Edge 上跑得飞快（首字延迟 < 100ms），原因是 SDK 把 stream parser 写成了 Web Streams API 标准接口，Edge runtime 原生支持。同样的代码，部署到 Cloudflare Workers 和部署到 Node.js 只需要改 runtime 标志。
Vercel AI SDK 的短板同样明显。RAG 抽象弱——SDK 只提供基础的 embed / embedMany 函数，没有 chunking、indexing、retrieval 这些高级抽象；想要复杂 RAG pipeline 仍然要回到 LangChain / LlamaIndex。Agent 抽象弱——5.x 引入了 createAgent 但只是 function calling 的薄层，没有 LangGraph 那种状态机能力。后端不是主场——虽然 SDK 的 server 部分（/api/chat route handler）可以独立部署到任意 Node.js 运行时，但官方最佳实践仍然是 Vercel / Next.js，离开这个生态需要更多胶水代码。
Dify（1.x 系列，2026-Q3 当前最新）和 Coze（字节跳动，2025-Q4 公测、2026 全面开放）是中文 LLM 应用市场的两个低代码平台代表。它们的设计哲学和 LangChain / LlamaIndex / Vercel AI SDK 的"代码优先"路径相反——是**"可视化工作流优先，代码作为可选插件"**。
Dify 的核心抽象是"应用 + 工作流 + 知识库 + 工具"四件套。应用是顶层容器（chatbot / agent / workflow / completion 四种类型），工作流是画布上的节点图（开始 → LLM → 条件分支 → 工具调用 → 回复用户），知识库是 RAG 数据源的可视化管理界面，工具是外部 API 集成的配置面板。整条 pipeline 在 UI 上拖拽完成，不需要写代码。Coze 的核心抽象类似，但额外引入了"bot-as-product"的产品化路径——bot 本身可以被发布到飞书 / 抖音 / 网页 widget，比 Dify 更偏向终端用户产品。
低代码平台的优势是显而易见的。非技术 stakeholder 友好——产品经理、运营、销售都能在画布上理解流程，这是和 stakeholder 沟通的最有效方式。企业集成快——Dify 内置 SSO、RBAC、审计日志、对接企业内部 IM 是最常见的选择。模板复用——Dify / Coze 都有模板市场，常见场景（客服、文档问答、营销文案）开箱即用。迭代速度快——非工程化变更（比如改 prompt、改知识库、加工具）不需要走代码 review 流程。
但低代码平台的工程取舍也是显著的。类型安全几乎为零——prompt 节点的内容是字符串，工具节点的入参是 JSON schema 但运行时不做 TypeScript 校验，复杂链路上一个字段名拼错 debug 一整天。扩展点有限——Dify 提供"代码节点"让你写 Python / JavaScript，但代码节点的环境是受限沙箱（没有外部网络、有限的 stdlib、不能 import 自定义模块），超出沙箱能力的逻辑写不进去。Coze 的扩展点更受限——主要是 webhook + 插件机制，自定义逻辑只能通过外部服务编排实现。可观测性弱——Dify 提供 trace 但只覆盖节点粒度，token cost 统计粗糙，quality eval 几乎没有；Coze 的可观测性更弱，主要靠平台日志。性能天花板——Dify 的工作流引擎是 Python asyncio，单条 trace 串行执行（除非显式开 parallel 节点），复杂 agent 在 Dify 上跑起来比 LangGraph 慢 2-5 倍。
低代码平台的另一个隐藏取舍是厂商绑定。Dify 是开源的（GitHub 12 万 star，2026-09 数据未公开验证但仓库活跃），可以私有化部署；Coze 是闭源的（截至 2026-09 没有公开的私有化部署方案）。如果团队对数据合规要求高、可接受自己运维 → Dify 自托管；如果可接受 SaaS 数据 → Coze 公有云更省心。
回到我们最开始的三元组 (A, D, E)：A 是抽象能力、D 是部署形态、E 是扩展点。在三元组的二维投影上画出"团队规模"和"项目阶段"两个轴，可以得到一张二维选型表：
横轴是项目阶段（原型期 / 内部工具期 / 产品期 / 规模化期），纵轴是团队规模（1-3 人 / 4-10 人 / 11-30 人 / 30 人以上）。格子里填推荐的框架组合。
1-3 人原型期（产品验证、Demo 周、月度 hackathon）：推荐 Vercel AI SDK + Dify / Coze。理由：Vercel AI SDK 让前端工程师在 1-2 天内搭出可交互 demo，Dify / Coze 让非工程 stakeholder 能自己改 prompt 和知识库。抽象能力不是瓶颈，速度是瓶颈。
4-10 人内部工具期（企业内网应用、运营 dashboard、内部知识库）：推荐 LangChain 1.0 + LangGraph + LlamaIndex（数据层）。理由：内部工具对 type safety 和可观测性要求高（出错要能 debug、性能要可量化），但不需要 Edge / 移动端部署，LangGraph + LlamaIndex 的组合刚好满足。Vercel AI SDK 作为前端 UI 层（Dify / Coze 退场，因为代码量上来之后低代码平台的扩展点不够用了）。
11-30 人产品期（SaaS 产品、企业级商用）：推荐 LangChain 1.0 + LangGraph + 自建 RAG 层（基于 LlamaIndex 二次开发或基于 LangChain 自建）+ Vercel AI SDK 前端。理由：产品期需要全栈控制，类型安全、性能、可观测性、成本四项都要拉满。低代码平台完全退场（产品期的定制需求超出沙箱能力）。LangChain 作为主框架、LangGraph 作为 agent runtime、LlamaIndex 的索引层作为 RAG 引擎、Vercel AI SDK 作为前端 streaming 抽象。
30 人以上规模化期（多产品线、多租户、跨国团队）：推荐自建框架 + 选择性使用上述框架作为组件。理由：规模化期几乎所有"通用框架"的抽象都会被产品特殊性击穿——你需要的是把 LangChain / LlamaIndex / Vercel AI SDK 的核心组件（streaming、chunking、retrieval）抽出来，自己包一层产品专属框架。这个阶段 LangChain 仍是底层依赖（大量 import），但顶层 API 是自己团队的。OpenAI / Anthropic 的官方 SDK 反而更重要，因为直接调模型 API 比过框架更可控。
技术债维度是另一个轴。一个常见误区是"我先用 Dify 跑通 demo，再迁移到 LangChain"——这个迁移的成本远高于预期，原因是 Dify 的工作流节点图和 LangGraph 的 Python 代码之间没有自动转换工具，每一个节点都要人工翻译。真实可行的迁移路径是"代码优先 + 低代码做 UI"：用 LangChain + LangGraph 写核心逻辑，Dify / Coze 只作为非技术 stakeholder 看到的"前端"。但这条路径需要额外的 API gateway 层（Dify 调用 LangGraph 部署的服务），复杂度反而上升。
把上面七节的形式化结论落到工程实践，给应用架构师一份可直接执行的清单。
清单 1（评估期）：项目启动的第一周做一次"框架试运行"——三个候选框架各花 2 天搭最小可用版本（一个能跑通 streaming chat 的 demo），记录每个 demo 的代码行数（LOC）、依赖数、首次流式延迟（TTFT）、二次 prompt 修改时间。这四个数字是后续选型的硬数据。
清单 2（选型期）：把八维评分做成雷达图贴在团队 wiki 上，每个维度给出 0-5 分的评分依据（不是凭感觉）。三个候选框架的雷达图并排展示，让团队投票。
清单 3（原型期）：用 Vercel AI SDK 在两天内搭出可交互 demo，用于 stakeholder 演示和产品验证。不要在这个阶段引入 LangGraph——LangGraph 的学习曲线会让原型的迭代速度下降 50%。
清单 4（数据层选型）：如果 RAG 是核心能力（项目 80% 的请求涉及私有数据），LlamaIndex 是默认选择；如果 RAG 是次要能力，LangChain 的 VectorStoreQAChain 就够了。LlamaIndex 的 CitationQueryEngine 在需要引用的场景（法律、医疗、金融）几乎不可替代。
清单 5（Agent 抽象）：复杂 agent（多步推理、reflection、branching）走 LangGraph，简单 agent（单步 function calling）走 LangChain Runnable。不要用 LangGraph 实现简单 agent——LangGraph 的图拓扑声明对单步 agent 是过度抽象。
清单 6（部署）：Vercel AI SDK → Vercel / Cloudflare Workers（边缘）；LangChain / LangGraph → FastAPI + Docker + K8s；Dify → 自托管 Docker Compose 或 SaaS；LlamaIndex → 同 LangChain 部署路径。混部时要明确 streaming 协议边界（SSE / WebStream / 自定义 JSON-RPC）。
清单 7（可观测性）：LangSmith 是 LangChain 生态的最佳搭档（虽然 LangSmith 也支持其他框架，但和 LangChain 的 integration 最深）；Arize Phoenix 是 LangGraph / LlamaIndex 生态的最佳搭档（开源、对 OpenTelemetry 原生支持）；Vercel AI SDK 适合 Langfuse 或 Helicone。
清单 8（成本控制）：所有框架都要在 gateway 层做 token counting + budget alert（无论框架内部如何实现，gateway 层必须有兜底）。LangChain 的 getUsageMetadataCallback、Vercel AI SDK 的 onUsage、LlamaIndex 的 TokenCountingHandler 是三个常用方案。
清单 9（扩展点保留）：项目第一天就保留一个"换框架"的 escape hatch——核心逻辑封装在自己的 LLMClient 接口后面，框架只是这个接口的实现。这样万一选错了，迁移成本从"重写"降到"换一个实现"。
常见误区 1："LangChain 是 LLM 框架的唯一选择"——这是 2023 年的认知。2026 年的真实情况是 LangChain 在 agent runtime 方向让位给了 LangGraph，在前端 streaming 方向让位给了 Vercel AI SDK，在 RAG 方向让位给了 LlamaIndex。LangChain 的 1.0 升级本质是一次"去中心化"——它承认自己不再是"唯一框架"，而是"组合式抽象的提供者"。
常见误区 2："低代码平台能搞定企业应用"——Dify 和 Coze 在原型期和内部工具期表现出色，但产品期几乎一定会超出沙箱能力。过度依赖低代码平台的技术债会让团队在产品期付出 3-5 倍的迁移成本。
常见误区 3："框架越新越好"——Vercel AI SDK 5.x 的 stream-to-tool-call 是新特性，但稳定性还在打磨；LangChain 1.0 的 type-safe 升级看起来美好，但 200 多页迁移文档说明生态仍在迁移期；LlamaIndex 0.12.x 的 Workflows 还在 alpha 边缘。新特性值得跟进，但不要在生产环境第一时间采用——等 6 个月社区踩坑完毕再用。
最后给应用架构师一条可执行的迁移路径。假设你的项目从今天开始启动，目标是 6 个月后进入产品期：
第 1-2 周（原型期）：Vercel AI SDK + 单一 prompt 模板。目标：搭出可交互 demo、让 stakeholder 看到效果。不引入任何复杂框架、不引入知识库、不引入 tool calling。
第 3-6 周（内部工具期）：迁移到 LangChain 1.0（或保留 Vercel AI SDK 作为前端）+ LlamaIndex 作为 RAG 层（如果需要）。目标：支持企业 SSO、对接内部知识库、加入可观测性（LangSmith 或 Phoenix）。这一阶段的 type safety 是核心需求——所有 prompt 都用 ChatPromptTemplate、所有 tool call 都用 JSON Schema 校验。
第 7-14 周（产品期）：引入 LangGraph 作为复杂 agent runtime（如果业务需要），搭建 CI/CD + staging/production 环境，引入 quality eval pipeline（golden set + LLM-as-judge）。这一阶段开始关注 latency budget（TTFT < 800ms、TBT < 200ms）、cost budget（per-request < $0.05）、error rate budget（< 1%）。
第 15-20 周（规模化前夜）：把 LangChain / LangGraph / LlamaIndex 的核心组件抽出来，包一层产品专属的 LLMClient 接口。这一步是为规模化期做准备——未来要换模型（GPT-4 → Claude → 自托管模型）、换框架（LangChain → 自建）、换部署形态（Vercel → 自建 K8s）都能在接口层完成。
第 21-24 周（规模化期）：选择性使用框架——直接调模型 API 替代 LangChain 的部分抽象、用 LangGraph 作为子模块嵌入自己的框架、用 LlamaIndex 的 CitationQueryEngine 作为引用模块。规模化期的核心不是"用什么框架"，而是"如何让自己不被框架绑死"。
这条六个月路径不是普适的——30 人以上团队的并行项目需要更复杂的协调——但对 4-10 人小团队的 LLM 应用项目是合理的。关键经验是：每个阶段只引入当前阶段需要的复杂度。原型期不要上 LangGraph，产品期不要保留 Dify，规模化期不要"全栈 LangChain"。复杂度是负债，不是资产。
最后的最后：无论选哪个框架，真正决定项目成败的是数据治理、prompt 版本化、quality eval、cost monitoring 这四件基础设施，不是框架本身。框架只是脚手架，拆掉脚手架之后大楼还立着，才是工程。
一句话摘要：2026 年 LLM 应用框架的选型已从"哪个最好"转向"哪个最匹配团队画像 + 项目阶段"——用八维评分 × 三层决策树的二维表选框架，用九件落地清单 + 三条避坑指南执行落地，用六个月的迁移路线图从原型走到规模化。
Conversation
0 条