完整题目
请列举当前主流的Agent开发框架（如LangChain、LlamaIndex等），并对比说明它们的核心功能、技术定位以及在RAG和Agent系统构建中的典型应用场景。
本文目录
主流Agent框架对比
1. LangChain —— 通用编排框架
核心定位：LLM应用的全流程编排与工具集成
- 核心能力：Chain/Agent抽象、工具调用（Tool Calling）、记忆管理、多模型路由
- 技术特点：LCEL（LangChain Expression Language）支持流式、异步、并行执行
- Agent场景：ReAct、Plan-and-Execute、Self-Ask等推理模式的标准化实现
- RAG角色：提供
RetrievalQA、ConversationalRetrievalChain等高层封装，但检索本身依赖外部
2. LlamaIndex —— 数据检索框架
核心定位：LLM与外部数据的高效连接
- 核心能力：多源数据索引（100+ loaders）、高级检索策略（路由、融合、重排序）、查询引擎
- 技术特点：索引类型丰富（Vector/Tree/Keyword/Composable），支持递归检索、子问题分解
- RAG场景：企业知识库、文档问答的首选，检索精度和效率优化深入
- Agent集成：提供
OpenAIAgent、ReActAgent，但Agent能力相对轻量
3. 其他重要框架
| 框架 | 特色定位 |
|---|---|
| AutoGen | 多Agent对话编排，适合复杂协作场景 |
| CrewAI | 角色扮演型Agent团队，强调任务委托 |
| Semantic Kernel | 微软生态，企业级规划器（Planner） |
| Haystack | 工业级NLP流水线，偏重RAG Pipeline |
典型协作模式
数据层：LlamaIndex（索引+检索）
↓
编排层：LangChain（Agent决策+工具调用）
↓
模型层：OpenAI/Claude/本地模型场景示例：企业智能客服
- LlamaIndex构建产品手册的向量索引+关键词索引混合检索
- LangChain Agent判断用户意图，决定直接回答/检索知识库/转人工/调用订单API
选型建议
| 场景 | 推荐方案 |
|---|---|
| 纯RAG应用 | LlamaIndex为主 |
| 复杂Agent工作流 | LangChain + AutoGen |
| 已有数据基础设施 | LlamaIndex检索 + 自研Agent |
| 快速原型验证 | LangChain（生态最成熟） |
学习建议
建议从官方文档入手，动手搭建简单项目，理解各框架的模块设计与适用场景，重点掌握LangChain的链式结构与LlamaIndex的数据索引机制。
换一种问法，检查是否真正理解
场景切入
假设我们要做一个企业智能客服，需要从产品手册里检索信息，还要调用订单API、判断是否转人工。你会怎么选框架？LangChain和LlamaIndex各自负责什么，怎么配合？
层层追问
现在做Agent开发，常用的框架有哪些？……LangChain和LlamaIndex你更倾向哪个？……那如果我要做一个RAG知识库问答，LlamaIndex有什么独到之处？LangChain在Agent场景下又强在哪？
直球架构
直接说一下你熟悉的Agent开发框架，对比LangChain和LlamaIndex的核心定位、功能差异，以及它们在RAG和Agent系统构建中分别适合什么样的场景。
练习口述回答 · 约4分钟
- 一句话定位：面试官问框架对比，本质是问选型能力
- LangChain vs LlamaIndex：一个偏编排，一个偏检索，边界划分
- 真实业务场景：企业智能客服，两者协作的完整链条
- 落地风险：检索质量、模型幻觉、系统复杂度
- 工程师判断收尾：我更倾向以检索为中心，编排轻量化
面试官问[[Agent]]框架对比，我觉得本质上不是考你背几个框架名字，而是看你面对真实业务场景时有没有选型能力。说白了，框架只是工具，关键是你知道什么场景该用哪个，以及它们怎么配合。
我先说两个最主流的。LangChain和LlamaIndex，很多人把它们放一起比，但我更倾向于把它们看成上下游关系。LangChain的定位是通用编排框架，它擅长的是把LLM调用、工具调用、记忆管理这些东西串成一条工作流。比如[[ReAct]]模式、Plan-and-Execute，LangChain都给你封装好了，你直接用就行。但它的检索能力其实不强，它依赖外部[[向量库]]，自己只做高层封装，比如RetrievalQA这些。
LlamaIndex正好反过来，它的核心就是数据检索。它支持100多种数据源加载，索引类型特别丰富，有向量索引、树索引、关键词索引，还能组合索引。它的检索策略也很深，比如[[Hybrid Search]]、[[Rerank]]、子问题分解这些。所以纯[[RAG]]场景，LlamaIndex是首选，检索精度和效率都优化得很到位。但它的Agent能力相对轻量，虽然也有OpenAIAgent，但复杂决策还是得靠LangChain。
那真实业务里怎么用呢？我举个例子，企业智能客服。比如用户问“我买的商品降价了，能退差价吗？”这个场景，你会需要两个能力：一个是检索产品手册里的退换货政策，另一个是调用订单API查用户订单状态。LlamaIndex负责建索引，把产品手册切分成段落，同时用关键词索引和向量索引做混合检索，这样用户说“降价”能匹配到政策，说“退差价”也能匹配。然后LangChain Agent来做决策，它判断用户意图：如果直接能回答，就从LlamaIndex检索结果里取；如果需要查订单，就调订单API；如果问题复杂，再转人工。这样两个框架配合，一个管数据，一个管流程，各司其职。
这里有个坑，就是落地时你得注意前提。LlamaIndex检索质量好不好，取决于你的[[Chunk]]策略和[[Embedding]]模型。如果文档结构复杂，比如条款里有很多例外情况，简单切分就会漏信息。我一般会用[[Parent Document]]的方式，先把大块文档索引起来，检索时先找小片段，再回溯到父文档，这样上下文完整。另外，[[Hallucination]]风险也很高，Agent如果调错API或者检索结果不相关，就会乱回答。所以上线前我会做一套回放测试，拿历史对话去测，看召回率和回答准确率，不达标就调参数。
还有一个点值得注意，就是多Agent协作。比如客服场景里，可能需要一个Agent专门处理退款，另一个处理物流查询，它们之间怎么通信、怎么避免冲突，这个LangChain和AutoGen都在做，但还没有特别成熟的方案。我自己试过用LangGraph定义状态机来协调，但复杂度上来了，维护成本也高。