Appearance
Q134 · LangChain 和 LlamaIndex 在 Agent 开发中的作用是什么？
一家电商把退货规则存成政策文档。顾客问：“签收后 7 天能退吗？”客服系统必须找到当前生效的规则，再回答“可以申请退货”，并指出依据。它不能只凭模型记忆回答，也不能把旧版政策当成现行政策。如果顾客接着问“我的订单 A17 能退吗”，系统还可能需要查订单的真实签收时间。
LangChain 和 LlamaIndex 都是帮助开发者组合模型、数据和工具的开源框架生态。LangChain 当前官方入口强调用模型、工具、提示与中间件组合 Agent，并提供基于 LangGraph 的 Agent 执行；LlamaIndex 当前官方入口强调从私有数据构建检索、查询和 Agent，也提供工具及工作流。两者有明显重叠，不能简单说“LangChain 负责 Agent，LlamaIndex 只负责知识库”。本文以 2026 年 9 月 26 日的 Python 官方文档为依据说明概念，具体导入路径和接口应在项目锁定的版本文档中再次核对。LangChain overview · LlamaIndex Framework 文档首页
先认识术语
| 术语 | 直白解释 | 客服例子 |
|---|---|---|
| 大语言模型（LLM） | 根据输入生成文字或工具调用请求的模型；它本身没有自动访问企业政策的权限 | 起草对顾客的回答 |
| Agent | 在应用给定的边界内，能根据任务决定是否调用可用工具、读取结果再继续的程序结构 | 决定要不要查政策、查订单，再回复 |
| 工具 | 程序给 Agent 暴露的一项可执行能力，有明确输入和输出 | 搜政策、查订单 A17 |
| 知识库 | 企业维护的业务资料集合，不等于模型参数 | 退货政策 V3 文档 |
| 文档摄取 | 把原始资料读取、清洗并拆成可用片段 | 读取政策文件，保留版本与生效日期 |
| 索引 | 为资料建立方便查找的结构 | 按政策片段建立可搜索记录 |
| 检索器 | 接受问题，返回相关资料片段的组件 | 找到“签收后 7 天可申请退货”的条款 |
| 查询引擎 | 在检索基础上组织查询和回答的组件；具体行为由配置决定 | 根据政策片段回答退货规则 |
| RAG（检索增强生成） | 先取出当前相关资料，再让模型参考这些资料生成回答 | 先查 V3，再回答顾客 |
| 来源引用 | 回答中保留证据的出处，供人核对 | “依据政策 V3 第 2 条” |
| 编排 | 规定多个步骤和工具怎样连接、何时运行的程序结构 | 先检索，再检查版本，再组织回答 |
| LangGraph | LangChain 生态中用于更细控制执行状态与流程的图运行框架 | 想明确写出“查不到→转人工”的分支时可用 |
| Workflow | 一种显式组织执行步骤、事件与控制流的机制；两边生态均有相关能力，但 API 不同 | 固定先验权限、再检索、再审核回复 |
“查询引擎”是 LlamaIndex 文档中的常见组件名；LangChain 也能实现“检索加回答”这件事，只是组件名称和组装方式不同。相反，“Agent”也不是 LangChain 的专属能力；LlamaIndex 当前文档明确提供 Agent 和工具。LlamaIndex：Introduction to RAG · LlamaIndex：Agents
两者分别给开发者提供什么
LangChain 的常见入口是围绕应用执行来组装能力。 开发者选择模型，定义“搜索政策”和“查询订单”这样的工具，写清工具说明与 Agent 指令，再创建能在模型和工具之间往返的 Agent。当前 Python 官方文档以 create_agent 作为轻量且可配置的 Agent 入口，工具可由 Python 可调用对象或 LangChain 工具提供；这个 Agent 建在 LangGraph 原语之上。需要更细的状态、人工确认和固定分支时，可以直接使用 LangGraph，而不是以为一个高层 Agent 构造函数自动满足所有业务控制要求。LangChain：Overview · LangChain：Agents
这不表示 LangChain 不碰数据。它的生态包含文档加载、文本拆分、嵌入模型、向量存储和检索等组件；官方 RAG 教程展示把文档转成可搜索片段，再让 Agent 用检索工具取证。这里“嵌入”是把文本映射成可比较的数值表示，“向量存储”保存这些表示与原文关联；它们只是检索的可选实现，政策检索也可结合关键词或数据库过滤。LangChain 生态的 RAG 示例
LlamaIndex 的常见入口是先把数据变成可查询的知识，再接到应用。 当前文档展示了读取文档、建立 VectorStoreIndex、由索引得到查询引擎的入门路径；也提供 retriever、Agent、QueryEngineTool 等组件。VectorStoreIndex 是一种向量索引组件名，不等于独立的向量数据库产品；具体存储可以按项目配置。QueryEngineTool 则是把一个查询能力包装成 Agent 可选择的工具。例如政策查询可以成为“查询退货政策”的工具，Agent 在需要时调用它；查订单也可以作为另一个业务工具。LlamaIndex Framework 入门 · LlamaIndex：Agent tools · LlamaIndex：Agents
LlamaIndex 也能做编排。其官方文档在 Agent 之外提供 Workflows，用于更明确地控制事件和步骤；当前文档导航还包含人机交互、状态维护和多 Agent 模式。不能把它停留在早期“只负责建索引”的印象里。同样，LangChain 也不应被说成“只能写链”。LlamaIndex：Workflows · LangChain：Overview
同一个客服问题，两条技术路线
先固定业务事实，避免换了框架却换了答案：政策 V3 是当前生效版本；其第 2 条写“签收后 7 天内可申请退货”；“可申请”不等于系统已经批准，也不代表所有商品无条件可退。 本轮顾客只问一般规则，没有提供订单号。无论采用哪套框架，期望回答都是“签收后 7 天内可以申请退货，是否获批还要按适用条件审核；依据政策 V3 第 2 条”。文中的政策是教学假设，不是现实商家的规定。
路线 A：用 LangChain 组装客服 Agent
- 准备政策资料。 读取 V3 文件，拆成能检索的小段，给片段保留政策版本、条款号和生效时间。检索条件应排除已过期的 V1、V2；否则检索相关度高也可能取出失效条款。
- 定义政策搜索工具。 它接收一个问题，例如“签收后 7 天内退货规则”，返回相关原文及来源标识。工具返回“没找到”也应是可区分的结果，不要伪造一个肯定答案。LangChain Agent 的工具接口让模型能按需要调用这种能力。LangChain：Agents 与工具
- 让 Agent 处理顾客问题。 应用只给它允许的工具；它调用政策搜索，读到 V3 第 2 条，形成带来源的答复。若它试图在没有来源时回答“当然能退”，应用层的规则应阻止这种无依据肯定句，并让它说明无法核实。
- 处理后续订单问题。 如果顾客改问“A17 能退吗”，先确认有权限访问该订单，再通过独立的订单查询工具取得签收日期和商品状态；结合政策判断是否能申请。调用业务系统这一步不是检索政策文档能替代的。
这里“读取文档→建索引”可用 LangChain 自身的数据组件，也可接现成检索服务；它不要求 LlamaIndex 必须参与。Agent 决定调用哪个工具是一种实现选择；如果业务规定“每条政策问答都必须检索”，更可靠的方式是由程序先强制检索，再交给模型组织回答，不能只靠提示词期待模型每次自觉搜索。
路线 B：用 LlamaIndex 构建知识入口并运行 Agent
- 准备同一份 V3。 用其文档读取和索引组件摄取政策，同时保留条款与版本元数据；从索引建立只查询当前政策的检索器或查询引擎。官方 RAG 文档把摄取、索引、查询列为基础步骤。LlamaIndex：Introduction to RAG
- 把政策查询变成工具。 用 QueryEngineTool 或同类工具包装“查退货政策”的查询能力，向 Agent 说明输入是顾客的政策问题，输出应包含相关依据。官方 Agents 文档把普通 Python 函数和 QueryEngineTool 都列为工具形式。LlamaIndex：Agent tools
- 让 Agent 回答同一个问题。 Agent 根据顾客问题调用政策查询工具，拿到 V3 第 2 条，再生成相同的“可申请退货”答复；应用仍需检查引用是否真的对应取回的 V3 条款。LlamaIndex 的 Agent 当前文档描述了“模型给出工具调用→执行工具→把结果放回对话→再决定回答或继续调用”的循环。LlamaIndex：Agents
- 订单个案也需业务工具。 对 A17，同样要接有权限约束的订单 API，不能因为查询引擎能回答文档问题就认为它知道某笔订单的实时状态。若希望固定“先鉴权、再查订单、再比对政策”的顺序，可把这部分写成显式工作流。
两条路线的区别主要体现在你首先复用哪组组件、团队熟悉哪套接口、检索复杂度与控制流要求。同一输入、同一政策与同一业务约束下，不应因为框架名字不同而得出相反的业务结论。
图上 LangChain 的“政策检索→搜索工具”，表示把检索能力包装给 Agent 使用，不是强制检索两次；LlamaIndex 的“文档索引→查询工具”表示先建立知识入口，再把查询能力给 Agent。图省略了版本过滤、权限和失败处理，这些仍由应用实现。
按同一维度比较，怎样选
| 维度 | LangChain 生态可怎样做 | LlamaIndex 生态可怎样做 | 真正该问的问题 |
|---|---|---|---|
| Agent 与工具调用 | 当前 create_agent 组装模型、工具、提示和中间件；底层基于 LangGraph | 提供 FunctionAgent 等 Agent 和普通函数、QueryEngineTool 等工具 | 当前任务是否需要模型自主挑选工具？ |
| 文档到答案 | 可加载、拆分、建立检索，再作为工具或固定步骤使用 | 文档摄取、索引、检索器和查询引擎是常见组织方式 | 政策文档的版本、条款、引用能否稳定保留？ |
| 流程控制 | 高层 Agent 可快速起步；复杂固定分支可下沉 LangGraph | 可使用 Agent，也可用 Workflows 显式组织步骤 | 鉴权、人工审批、失败回退能否由代码控制？ |
| 外部业务数据 | 自定义工具查询订单 API | 自定义工具查询订单 API | 谁授权、怎样限制订单读取范围？ |
| 组合成本 | 需要适配另一框架的输入、输出和追踪 | 同样需要适配和维护 | 两套抽象一起用是否比只用一套更简单？ |
这些是当前文档呈现的常见起点，不是两套框架能力的排他清单。选型可从最小闭环试做：同一批政策问题，测检索到正确现行条款的比例、最终答案对条款的忠实度、无结果时能否拒绝猜测、一次问答的耗时与费用；再看团队已有代码和可维护性。不要凭“某框架理论上能做”就跳过业务验收。LangChain 官方入口 · LlamaIndex 官方入口
什么时候可以组合，什么时候没必要
一种可行组合是：团队已有 LangChain Agent 和订单工具，同时政策文件复杂、已有基于 LlamaIndex 的文档索引与查询服务。把这个查询服务包装成 Agent 的一个“只读政策搜索工具”，保留其原始文档 ID、版本和条款号；LangChain 负责选择何时调用政策工具与订单工具，LlamaIndex 负责其下方的知识检索。反过来，也可以让 LlamaIndex Agent 调用团队已有的独立搜索服务。组合的界面是清楚的输入、输出、权限与错误语义，不要求两个框架的内部对象必须直接混用。
若只是回答“签收后 7 天能否申请退货”这类规则清楚的问题，固定的“检索当前政策→引用回答”流程可能比 Agent 自由选择工具更短、更便宜，也更容易测试。接入两套框架会增加依赖版本、调试路径和对象转换成本；只有当现有组件能实际减少数据接入或业务编排工作时，组合才有价值。两边官方文档都持续演进，项目应锁定依赖版本并验证当时的 API，而不是照抄旧教程里的类名。LangChain 官方文档 · LlamaIndex 官方文档
失败时要检查哪一层
检索到旧政策。 顾客问 7 天退货，搜索结果却来自已过期 V1。无论框架怎样搭，应该在摄取与查询时保存并过滤版本、生效时间；答复前确认引用的确是 V3。向量相似度高不能取代版本规则。
Agent 没调用检索就自信回答。 模型记忆里可能有其他商家的退货政策。若业务要求每次有证据，就让应用强制检索或检查工具轨迹与引用，不满足时说明“暂时无法核实”，而不是把 Agent 输出当作已验证事实。
查订单越权。 顾客提供 A17 不等于他有权读取 A17。订单工具必须用已验证的登录身份做鉴权，按租户和用户范围读取；框架提供工具调用接口，不负责替业务决定授权规则。
工具超时或无结果。 政策查询失败时，不要把空结果变成“7 天内肯定能退”；应重试受控次数、展示待核实或转人工。记录检索请求、政策版本、工具结果和最终答复，才能判断错误来自数据、检索、Agent 决策还是回答生成。只看最终一句话，很难定位是哪一层出错。
面试中怎样回答
“LangChain 和 LlamaIndex 都能用于 Agent 开发，也都能接检索和外部工具。LangChain 当前常用 create_agent 把模型、工具和提示组合起来，复杂流程可以下沉到 LangGraph；LlamaIndex 常从文档摄取、索引和查询入手，再把查询引擎包装成 Agent 工具，也有自己的 Agent 与 Workflows。比如客服回答退货政策，两条路线都可以先取现行 V3 条款，再给出带来源的‘7 天内可申请’答复；若问具体订单，还要另接受权限约束的订单工具。选型看现有组件、检索复杂度和流程控制要求，必要时把 LlamaIndex 的知识查询服务接成 LangChain Agent 的工具。框架不会替我们保证政策版本、权限和引用正确。”
若追问“LlamaIndex 是不是只做 RAG”，应答“它也提供 Agent、工具和工作流”；若追问“LangChain 是不是不适合知识库”，应答“它也有文档与检索组件。两者的常见入口不同，但能力重叠，应在同一业务测试集里比较”。若追问“用了 Agent 是否一定更好”，应答“简单固定问答可先用确定流程，Agent 的工具选择循环只有在任务确实需要动态决策时才值得付出额外成本”。
官方资料
- LangChain overview、Agents、RAG 示例：当前 Agent 入口、工具和检索组合。
- LlamaIndex Framework、Introduction to RAG、Agents、Agent tools：文档到查询、Agent 与工具的当前定位。
- LlamaIndex Workflows：显式编排入口。