大模型API编排框架的工程化对比：LangChain、LlamaIndex与自建编排器
一、编排框架选择的代价：选错了，半年后改不动
AI生活工具的技术架构中，API编排框架的选择是"做了就难改"的决策。它影响到后续所有功能的开发方式——Prompt管理、工具调用、记忆系统、流式响应——每个新功能都基于编排框架提供的抽象层构建。选错框架意味着要么忍受持续的摩擦，要么付出重构的代价。
以下对比基于在三个AI生活工具（日记润色、食谱生成、情绪分析）中使用三种方案的经验：LangChain（链式抽象+丰富生态）、LlamaIndex（数据索引+RAG核心能力）、自建编排器（零抽象层+完全控制）。
二、三种方案的架构理念对比
LangChain的核心抽象是Chain——将多个操作串联为流水线。LlamaIndex的核心抽象是索引——围绕文档检索构建RAG能力。自建编排器不使用任何框架抽象，直接通过HTTP调用API。
三、关键维度的实测对比
在三个AI生活工具项目中的对比数据：
| 维度 | LangChain | LlamaIndex | 自建编排器 |
|---|---|---|---|
| 入门学习曲线（天） | 7 | 4 | 2 |
| RAG实现代码量 | 120行 | 45行 | 280行 |
| 自定义Agent灵活性 | 中（Chain抽象有时限制） | 低（偏向检索场景） | 高（完全自由） |
| Prompt调试难度 | 高（多层抽象隐藏调用链） | 中 | 低（直接可见调用链） |
| 依赖库数量 | 47 | 18 | 3（openai+httpx+tenacity） |
| 包体积 | 380MB | 120MB | 8MB |
| 版本升级兼容性风险 | 高（频繁breaking change） | 中 | 低（API直接升级） |
| 适合团队规模 | 3人以上标准项目 | 1-3人RAG项目 | 1-2人强控制项目 |
LangChain的优势在生态丰富——200+LLM提供商、大量现成的Chain和Tool实现。代价是调试困难：当一条Chain产生错误输出时，追溯哪个环节出了问题需要理解LangChain内部的Callback系统。在日记润色工具中，一个"摘要→润色→格式化"的三步Chain因LangChain版本从0.1升级到0.2而完全失效，修复时间比用原生API重写还长。
LlamaIndex是RAG场景的最佳选择——45行代码完成文档加载、切分、嵌入索引和查询的全流程，这是其他方案无法比拟的效率。但一旦场景超出RAG（如需要Agent推理、工具调用），LlamaIndex就力不从心。
四、选择决策的关键信号
选择LangChain的信号：团队3人以上需要标准化开发流程、项目涉及多种LLM提供商切换、需要现成的Agent和Tool实现。警惕信号：如果你发现自己花更多时间在阅读LangChain文档和调试抽象层而非编写业务逻辑，说明LangChain的复杂度超出了项目需求。
选择LlamaIndex的信号：项目的核心是RAG（检索增强生成），对其他AI模式（Agent、Chain）需求较低。警惕信号：当项目开始需要多步推理和工具调用时，LlamaIndex的短板会越来越明显。
选择自建编排器的信号：团队对LLM API有深入理解、项目不需要切换LLM提供商、追求最小化依赖。警惕信号：当自建的Prompt管理、重试逻辑、工具调用系统开始膨胀到2000+行时，说明应该引入框架管理复杂度。
五、总结
本次三种编排框架的对比核心结论：
LlamaIndex是纯RAG场景的最优选择：45行代码完成全流程，18个依赖库，没有不必要的抽象层。不是RAG场景不要选。
LangChain的生态优势与调试代价同存：47个依赖库+丰富的Chain/Tool生态，但版本升级兼容性风险和抽象层调试成本不可忽视。
自建编排器在控制力和维护成本的持续博弈：2天入门、完全控制调用链，但当代码膨胀到2000+行时需重新评估。
决策应基于项目核心模式而非"名气"：RAG项目选LlamaIndex，Agent/Chain项目选LangChain，API调用为主的简单项目用自建。
不选择也是选择：半年后改框架的代价远大于初期多花的评估时间。
