LangChain、LlamaIndex 和自研编排层应该怎么选？

简化版

LangChain 更偏通用链路编排和 Agent 生态，LlamaIndex 更偏数据连接、索引和 RAG 工作流，自研编排层更适合稳定业务流程和强可控生产系统。选择时看团队成熟度、RAG 复杂度、工具链稳定性、可观测和长期维护成本。

详细版

框架能加速原型，但也会引入抽象层和版本变动成本。
RAG 以数据连接、索引、检索、重排为主时，LlamaIndex 往往更顺手。
多工具、多 Agent、多步骤编排时，LangChain 生态更丰富。
生产系统常把核心链路固化为自研轻量编排，只保留框架里的局部能力。
面试回答要能说明“用框架”和“不用框架”的边界。

完整版教学

易错点：框架不是 LLMOps 本身，框架只是帮你组织调用；质量、权限、监控和评测仍要自己负责。

一、选型首先看需要掌控哪些边界

框架选型看的是控制面边界：是否容易替换模型与存储、能否观察每个步骤、异常语义是否清楚，以及升级会不会破坏核心链路。LangChain 偏通用编排，LlamaIndex 偏数据与检索，自研提供控制但需要承担全部治理成本。

这些生态的能力会随版本快速变化，不能把某个组件清单当永久结论。更稳的比较方法是拿同一条业务链路做原型，检查契约、性能、可观测性和退出成本。

二、核心原理和工程边界

LLM 编排框架解决的是“如何把模型、检索、工具、状态和回调串起来”的问题。它们提供标准组件和生态插件，但生产应用的核心风险在于业务边界、版本锁定、异常恢复和可观测。如果业务路径很稳定，自研有限状态机或 DAG 往往更透明。

三、带数字的工程算例

一个知识库问答 demo 可能 2 天用框架搭好；但如果线上有 30 个工具、5 种用户角色、3 个模型供应商和严格审计要求，框架默认抽象可能遮住关键控制点，自研编排反而更容易定位问题。

选择收益 = 原型速度 + 生态能力 - 抽象成本 - 版本风险 - 调试成本
RAG 重数据管道 => LlamaIndex 倾向更强
多工具工作流 => LangChain 倾向更强；稳定核心链路 => 自研更强

四、典型链路怎么跑

可以把这类问题拆成下面的链路来理解：

需求拆解
   |
是否以 RAG 数据管道为核心？
   | yes -> 评估 LlamaIndex
   | no
是否多 Agent/多工具快速实验？
   | yes -> 评估 LangChain
   | no -> 轻量自研编排

五、方案对比和选择标准

方案	优势	代价
LangChain	生态广、Agent 组件多	抽象复杂、版本变化快
LlamaIndex	数据连接和索引友好	非 RAG 流程不一定轻
自研编排	可控、可观测、稳定	前期开发成本更高
混合使用	吸收生态能力	边界设计要清楚

六、上线后最容易出问题的地方

不要让业务核心链路被黑盒 callback 淹没，否则线上排障很痛苦。
框架升级要有回归评测，prompt、retriever 和 parser 的细小变化都可能影响答案。
生产代码要把业务接口与框架对象隔离，避免 Prompt、文档节点或回调类型渗透到领域层。

七、怎样做可退出的 Bake-off

选一条包含检索、一次工具调用、流式输出和失败恢复的代表链路，用候选框架分别实现。固定模型与数据，比较开发时间、额外延迟、Trace 完整性、异常可控性、升级破坏和测试难度。

领域层只依赖自定义接口，例如 Retriever、ModelClient 和 ToolExecutor；框架对象不穿透边界。这样即使最后选择框架，也能用契约测试逐个替换组件，避免被某次版本升级锁死。

八、常见误区与追问

误区：用了 LangChain 就等于有了 Agent 能力。 框架只提供组件与编排抽象，是否让模型动态决策取决于应用代码和权限边界。
误区：LlamaIndex 只能做简单向量检索。 它还包含摄取、索引、路由、结构化数据与检索后处理等能力，但仍需按版本核对具体实现。
误区：自研一定比框架更可靠。 自研减少黑盒却增加测试、观测、兼容和维护负担，可靠性来自工程能力而非所有权。
追问：生产中为什么常做框架瘦身？ 减少隐式重试和多层回调，只保留稳定组件，使链路、延迟和故障归因更清楚。
追问：如何迁移掉框架里的某个组件？ 先定义独立接口和契约测试，用影子流量对比新旧实现，再按路由逐步切换。
追问：框架选型要看哪些非功能指标？ 看可观测性、版本兼容、扩展点、异步与流式支持、序列化安全、社区维护和退出成本。

九、加强记忆

把选型记成“三问”：是不是重 RAG，是否要快速试多工具，核心链路是否要求强可控。框架帮你快，自研帮你稳，成熟系统常常两者混用。

项目实战落地

项目里怎么做的

《AI Agentic RAG高级企业知识库平台》的技术主线是 LangChain 1.x + LangGraph，但不是每一环都交给框架，按「框架覆盖得好不好」逐项决定：

环节	用什么	原因
对话模型、向量模型	`langchain-openai` 的 `ChatOpenAI`、`OpenAIEmbeddings`	百炼兼容 OpenAI 协议，换 `base_url` 和 `api_key` 就能用，不需要专门的 SDK
Agentic 链路	LangGraph 状态图	检索、相关性判断、改写和兜底之间有条件边和环，由状态决定下一步
重排	httpx 调 DashScope 原生接口，再包装成 LangChain 组件	百炼的重排不在 OpenAI 兼容模式下，官方也没有 LangChain 集成
评测指标	自己实现，四个指标不到两百行	主流评测库没有迁移到 LangChain 1.x，装上去 import 都过不了

ai_model_config 表里的 protocol 字段决定调用走哪条路径：「OpenAI兼容」走 langchain-openai，「DashScope原生」走 httpx。重排组件怎么包装，见「RAG 中为什么需要 Reranker？Bi-Encoder 和 Cross-Encoder 有什么区别？」。

《AI Agent智能会议纪要辅助系统》也是同样的分法：纪要生成、说话人匹配、纪要自检三处文本模型调用统一走 LangChain 的 ChatOpenAI；音视频转写是「上传音频、提交异步任务、轮询结果」的专用接口，LangChain 不覆盖，直接用 HTTPX 发请求。

为什么这样取舍

评测自己写。 除了装不上，项目教程还给了两条理由：自己实现的代码只依赖对话模型接口，不会因为评测库改 API 而跑不通；每个分数怎么算出来的都看得见。
不为一个库降级整套栈。 LangChain 1.x + LangGraph 是整个项目的主线，评测库不兼容时换掉的是评测库，而不是把主线降级。
覆盖不到的接口直接调 HTTP。 转写和重排都是服务商的专用接口，框架没有现成封装，就按服务商的接口直接发请求；重排要接进检索链路，所以再包一层 LangChain 的标准组件，转写只在自己的服务里用，不需要这一层。

面试官还会追问

重排组件继承的抽象基类要求实现同步方法，项目里的同步方法为什么直接抛 NotImplementedError？
批量评测为什么默认只跑 20 条用例？一轮评测的 Token 主要花在哪里？

学完《AI Agentic RAG高级企业知识库平台》，上面这些追问你都会迎刃而解。

简化版

详细版