LangChain、LlamaIndex 和自研编排层应该怎么选？
简化版
LangChain 更偏通用链路编排和 Agent 生态，LlamaIndex 更偏数据连接、索引和 RAG 工作流，自研编排层更适合稳定业务流程和强可控生产系统。选择时看团队成熟度、RAG 复杂度、工具链稳定性、可观测和长期维护成本。
详细版
- 框架能加速原型，但也会引入抽象层和版本变动成本。
- RAG 以数据连接、索引、检索、重排为主时，LlamaIndex 往往更顺手。
- 多工具、多 Agent、多步骤编排时，LangChain 生态更丰富。
- 生产系统常把核心链路固化为自研轻量编排，只保留框架里的局部能力。
- 面试回答要能说明“用框架”和“不用框架”的边界。
完整版教学
易错点：框架不是 LLMOps 本身，框架只是帮你组织调用；质量、权限、监控和评测仍要自己负责。
一、这题真正考什么
易错点：框架不是 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、文档节点或回调类型渗透到领域层。
七、常见误区与追问
- 误区：用了 LangChain 就等于有了 Agent 能力。 框架只提供组件与编排抽象，是否让模型动态决策取决于应用代码和权限边界。
- 误区：LlamaIndex 只能做简单向量检索。 它还包含摄取、索引、路由、结构化数据与检索后处理等能力，但仍需按版本核对具体实现。
- 误区：自研一定比框架更可靠。 自研减少黑盒却增加测试、观测、兼容和维护负担，可靠性来自工程能力而非所有权。
- 追问：生产中为什么常做框架瘦身？ 减少隐式重试和多层回调，只保留稳定组件，使链路、延迟和故障归因更清楚。
- 追问：如何迁移掉框架里的某个组件？ 先定义独立接口和契约测试，用影子流量对比新旧实现，再按路由逐步切换。
- 追问：框架选型要看哪些非功能指标？ 看可观测性、版本兼容、扩展点、异步与流式支持、序列化安全、社区维护和退出成本。
八、加强记忆
把选型记成“三问”：是不是重 RAG，是否要快速试多工具，核心链路是否要求强可控。框架帮你快，自研帮你稳，成熟系统常常两者混用。