前言

很多开发者上手 Agent 项目会直接照搬 LangChain 全家桶，忽略框架带来的冗余抽象与调试难题。本文划分三层选型方案，对比三款主流开发框架定位，给出分场景落地判断标准，适合开发选型面试与项目技术评估。

面试里框架相关问题通常出现在最后几题，考察的不是你会不会用某个库，而是你有没有做过技术选型、有没有踩过坑之后形成的判断力。这个问题没有标准答案，但有几个关键的判断维度值得说清楚。

三个主流选手

当前 Agent 开发里三个出场率最高的框架各盯一个方向。

LangChain 盯的是通用 Agent 编排。它把 LLM、工具、记忆、链式调用抽象成统一接口，一套代码能在 OpenAI、Claude、本地模型之间切来切去。但也是最重的一个，模块多，抽象层叠，出问题的时候排查链路很长。

LlamaIndex 盯的是数据。它的核心能力是索引构建、检索、查询引擎，适合做 RAG 和对大量文档做问答的场景。如果你的项目里数据检索是主要需求，LlamaIndex 比 LangChain 更专注。

semantic-kernel 是微软出的，思路不太一样。它侧重把 LLM 能力和传统软件工程对接，用 Plugin 的方式封装能力，更适合已有代码库的企业场景。如果你的团队里 .NET 或者微软生态的东西比较多，这是个自然的选项。

这三个框架的共同思路是用预制的抽象帮你在不同 LLM 之间切换，同时让工具调用、链式逻辑不要每次都从零写。但也是这种抽象层次，在项目规模不大或者需求偏离框架预设路径的时候，变成了负担。

框架到底给了你什么

框架的核心价值有三件事。

第一是屏蔽 LLM 差异。你用 OpenAI 的 API、用 Claude、用本地部署的模型，框架帮你抹平调用接口的细节。听起来简单，实际项目里换模型是常事，没有这层抽象每次换都是改代码。

第二是链式编排。把一个复杂任务拆成多个步骤，框架帮你管理这些步骤之间的输入输出流转。不用你自己维护一个调度器和一个状态对象。

第三是社区生态。预设的 prompt 模板、工具集成、文档、踩坑经验，这些在你从零开始的时候能省掉大量时间。

但框架的代价也在这里。LangChain 那种"为了抽象而抽象"的设计，有时候一个简单的 LLM 调用要绕四五层。出 bug 的时候，一个 TypeError 追溯到第七层才找到根因，排查体验很糟糕。

什么场景下框架在拖后腿

直接说结论：任务简单、LLM 调用链路短的场景，框架的收益远小于成本。

比如你需要的就是调一次 LLM，拿到结果后做一次工具调用，完事。这种场景下用 LangChain 引入的抽象层比你的业务逻辑还多。手搓几十行代码，清晰可控，响应链路也短。

还有一个情况是框架跟不上你的需求。LangChain 更新节奏很快但版本兼容经常出问题，0.1 到 0.2 的升级能把你的生产代码炸掉。如果你的 Agent 逻辑高度定制、和框架预设路径偏差太大，硬套框架的结果就是大量时间花在 hack 框架上，而不是写业务逻辑。

半框架方案：LangGraph 的思路

LangGraph 走了一条中间路线。它不给你预制"Agent 应该长什么样"，它给你的是一个有状态的图执行引擎。你把任务定义成节点和图，节点之间通过 State 传递数据，边上的条件路由决定下一步走到哪个节点。

这个设计的好处是你依然掌控 Agent 的核心逻辑——prompt 怎么写、工具怎么调、记忆放在哪——这些是你说了算的。框架只帮你做它擅长的那一块：状态管理、节点调度、条件路由。

实际场景里这个模式很好用。用一个极简的 Agent 基类自己定义核心循环，复杂到需要多节点协调时再用 LangGraph 的图机制。不要一上来就想"我要不要用 LangChain"——先想"我的 Agent 循环长什么样"，需要什么补什么。

通用的选型建议

把决策简化成三个层级，从简到繁。

第一层：需求简单，链路短，手搓最直接。几十行代码，没有任何框架依赖，出了 bug 一眼看到底。

第二层：需要多节点协调。用类似 LangGraph 的半框架方案。核心逻辑你控制，状态流转和节点调度框架帮你做。

第三层：大型项目，需要大量开箱即用的集成。考虑 LangChain 或 LlamaIndex，但想清楚自己要的是哪一块——只是链路编排就要那一块，只是文档检索就要检索模块，不要因为"项目大"就把全家桶全引进来。

关键在于先确定自己的 Agent 循环结构，再决定引入什么层次的外部依赖。框架不应该先于设计做决定。

还有一个原则：框架应该解决的是工程问题（调度、状态、抽象），不是业务问题（prompt 设计、工具选择、循环逻辑）。如果你的框架在教你怎么写 prompt，它越位了。

面试怎么答

这个问题的得分点在方案分层和具体判断标准，不在站队。

不要一开口就是"LangChain 好"或者"什么都自己写最灵活"。要说三层的选型逻辑——简单手搓，多节点半框架，大项目全框架——然后落在"先确定自己的 Agent 循环需要什么，再匹配对应层次的工具"。

如果能随口提一句 LangGraph 的图执行引擎思路和它跟 LangChain 的区别，面试官就知道你是真的做过选型，不是看了几篇评测文章。

还有一个经常被问的：如果选择手搓，怎么保证代码质量？答案是 Agent 核心循环其实就四五十行——基础循环、工具调用、结果处理。这几行代码可测可审，不会失控。真正复杂的是 prompt 设计和工具选择，那些不管用不用框架都得自己搞定。

结语

Agent 开发没有万能框架，先梳理自身业务循环逻辑，再匹配对应工具；简单业务手写代码更轻量化，复杂多节点场景优先选用 LangGraph，大型 RAG 项目再考虑完整框架。