LangChain 和 LlamaIndex 有什么区别？开发 RAG 和 Agent 应该怎么选？

知识点详解：比较框架，要沿着同一个任务走一遍

它们看待应用的起点不同，但能力不是互斥的

咱们假设要做一个内部助手：员工询问报销规则，助手先查制度 PDF；发现需要申请时，再调用业务工具创建申请草稿。

这个任务可以拆成两部分。第一部分是把 PDF 变成能够检索的信息；第二部分是根据问题选择检索或业务工具，并把结果交给用户。

LlamaIndex 的核心概念围绕数据、索引、检索和查询展开；LangChain 的概览则直接介绍模型与 Agent 等应用能力。不过，这只是各自常见的组织入口，不是功能边界。两边都有检索组件，也都有 Agent 能力。

因此，面试中可以说“侧重点不同”，不要说“只能做某一种应用”。

先看资料怎样进去，再看答案怎样出来

对于这个报销助手，选型不能停留在“支持 PDF”这四个字。需要继续问：

• PDF 是文本文件还是扫描件？表格能否被保留下来？
• 制度更新后，旧内容怎样替换？
• 检索结果能否带回文件名、章节和页码？
• 不同员工能否只看到自己有权限的资料？

框架提供读取器或连接器，并不等于这些问题已经解决。扫描件可能需要 OCR；权限过滤需要贯穿存储与检索；资料更新也需要自己的记录和删除机制。

可以用两份有版本差异的制度文件做小验证。要求两个实现都回答同一个问题，并展示引用来源。先比较资料接入和检索调试是否省事，再讨论框架抽象是否舒服。否则，一个“快速跑通”的演示，很容易掩盖后续维护工作。

工具编排也要用同一组条件比较

接下来让助手创建申请草稿。这里新增的要求是：参数缺失要补问，创建前需要确认，接口超时不能重复创建。

此时，检索组件再丰富，也不能替代应用侧的执行控制。我们要看框架如何表示工具参数，怎样保存执行状态，能不能记录每次工具请求，以及如何接入人工确认和恢复机制。

LangChain 的 Agent 在当前架构中建立在 LangGraph 之上，但安装 LangChain 不等于业务已经拥有完整的审批、鉴权和幂等设计。LlamaIndex 的相关工作流能力也需要应用配置和业务代码配合。选型应比较实际要使用的组件，而不是把框架全部功能清单直接当成项目成品。

哪个更省事，用一个小闭环判断

可以先做同样的最小验证：导入资料、回答带引用的问题、创建申请草稿、模拟一次超时，再追踪整个过程。

要比较的工作	具体检查
数据接入	文件处理、元数据和更新是否容易控制
检索调整	分块、过滤、重排能否独立替换
执行管理	工具调用、确认、错误恢复是否清楚
调试维护	日志能否说明问题出在哪一段
团队成本	是否引入难以维护的额外抽象

这里没有一个适合所有项目的冠军。如果团队已有稳定的检索服务，用 LangChain 接入这个服务可能更简单；如果主要工作是不断整理文档和调整检索，LlamaIndex 的数据抽象可能更顺手。

也可以组合使用，但最好通过清楚的接口组合。例如把检索服务暴露为一个工具，而不是让两个框架的内部对象在业务代码里互相穿透。否则，版本升级时会同时承受两套抽象的变化。

面试官继续追问

RAG 效果差，是不是换框架就能解决？

不一定。先区分是没有检索到相关内容，还是模型没有正确使用内容。资料质量、分块方式、过滤条件和评测样本都可能影响结果。换框架只能解决它确实造成的问题。

为什么不直接用模型 SDK？

如果需求只是调用模型，再接一个稳定的检索接口，直接用 SDK 完全可以。框架的价值在于减少重复集成和执行管理工作；当这些抽象没有带来收益时，就不必为了“技术栈完整”引入它。

原型选对了，生产环境就可以沿用吗？

还要增加权限、更新、恢复、监控和并发测试。原型证明的是主路径能跑通，不能证明长期运行和故障处理已经可靠。

面试速记卡

• 能力边界：两者都能做 RAG 和 Agent，不是互斥分类。
• LangChain：从模型、工具与应用执行组织组件。
• LlamaIndex：数据接入、索引和检索抽象值得重点考察。
• 选型方法：同一任务、同一资料、同一失败条件做比较。
• 组合原则：通过稳定接口协作，避免内部抽象相互穿透。