主流Agent框架优缺点与场景怎么选?

这道题其实不是在问这两个框架的API差异，而是背后透出的一个选择：当你要搭一个[[Agent]]应用，你到底需要什么程度的编排和检索能力。我理解核心就是场景匹配，没有哪个框架能通吃。

先说LangChain。它的核心抽象是Chain，就是把LLM调用、工具执行、数据处理串成一条流水线。设计上很灵活，Agent走的是[[ReAct]]循环，让LLM自己决定下一步调什么工具。所以它特别适合多步骤的复杂工作流，比如先搜资料、再分析、最后生成报告这种。而且生态特别丰富，集成了两百多种工具和数据源，原型验证上手很快。

但这里有个坑。LangChain的Chain太抽象了，调试起来很痛苦，经常出现一个黑盒一样的Chain，出了问题你得一层层拆。而且性能开销大，到了生产环境你必须大量裁剪，不然延迟和成本都扛不住。所以我的感觉是，LangChain更适合快速验证想法，真要上线，你得把它当参考实现，自己重写精简版。

再来说LlamaIndex。它的核心是Index，各种索引结构，比如向量、树、关键词、图。它天然是为[[RAG]]设计的，Query Engine封装了检索加合成的标准流程。所以如果你要做企业知识库问答，或者结构化数据查询，LlamaIndex非常顺手。它的检索策略很丰富，RAG效果容易调优，而且它和LangChain可以互操作，通过一个工具包装就能把LlamaIndex的检索能力当工具给LangChain用。

但LlamaIndex的Agent能力相对薄弱，复杂规划得外挂别的框架。说白了，它擅长的是“查得准”，不是“想得深”。所以选型上，如果场景偏RAG，LlamaIndex是首选；如果场景偏复杂Agent工作流，LangChain更合适。

举个例子你就明白了。比如电商客服场景，用户问“我买了个商品，满减政策没生效，订单还异常了，怎么办”。这个场景里，你需要先查订单状态、再查满减规则、然后判断是否冲突、最后生成回答。这就涉及多个工具调用和逻辑判断，LangChain的Agent就派上用场了。但如果只是纯知识库问答，比如员工问“公司年假政策是什么”，LlamaIndex直接索引公司SOP文档，检索出来合成回答，又快又准。而实际落地时，往往是两个一起上：LlamaIndex负责检索知识，LangChain负责编排任务流。

上线我会特别关注几个风险。一个是性能，LangChain的抽象层在低延迟场景下必须拆掉，不然每次推理都过一遍Chain，延迟翻倍。另一个是调试，一定要加日志和中间结果输出，不然出了问题根本不知道是检索错了还是LLM理解错了。还有一个前提是，你的数据质量得过关，如果文档本身混乱，再好的检索框架也救不了。

所以我的倾向是，把LangChain和LlamaIndex当成工具箱，而不是框架。真正生产时，我会用它们的底层能力，但自己写一个轻量的编排层，控制好抽象粒度。

另外，最近[[Agentic RAG]]的概念很火，就是让Agent自己决定什么时候去检索、检索什么、怎么用检索结果。这个方向其实模糊了LangChain和LlamaIndex的边界，也引出了一个新的权衡：到底该让LLM多思考，还是让检索流程更确定。这块我也有一些实践观察。