1. 选型之前先问自己一句下一步到底谁说了算Agent 框架这两年火得离谱LangChain、LangGraph、AgentScope、CrewAI、Dify 一个接一个往外冒每隔几周就有新东西刷屏。我身边不少做后端、做算法、甚至做产品的朋友都来问同一个问题到底该选哪个说实话这个问题本身就问偏了。框架不是选最强的而是选最贴合你业务控制流的。而控制流的核心就一句话——下一步由谁决定。这句话听起来抽象落到代码里其实特别具体。你写一个 Agent用户丢进来一句“帮我查一下上个月的销售数据做个同比分析再生成一份周报”接下来会发生什么是先调数据库查询工具还是先让模型规划任务查完数据之后是直接进分析节点还是要根据数据是否为空走不同分支分析完是自动生成报告还是停下来等人工确认这一连串“下一步做什么”的决策权可能落在三个不同的地方模型自己、你的代码、或者人。谁掌握这个决策权直接决定了你该用哪一类框架。我见过太多团队一上来就冲着 LangChain 去结果发现自己的业务其实是固定流程硬套一个“让模型自由发挥”的框架最后调试到怀疑人生。也见过有人用纯 if-else 写了个状态机业务稍微复杂一点就维护不动回头再想迁到图结构框架重构成本高得吓人。所以选型这件事真的不是看 GitHub star 数而是先把自己的控制流想清楚。这篇文章我想把这件事彻底讲透。从“下一步由谁决定”这个第一性原理出发拆解不同框架背后的设计哲学给出可落地的选型判断表再配上我实际踩过的坑和调试技巧。不管你是刚入门 Agent 开发的新手还是已经用过 LangChain 想升级到 LangGraph 的老手或者是在评估 AgentScope 这类多智能体框架的架构师应该都能从中找到对自己有用的部分。核心关键词就几个Agent、框架、LangChain、LangGraph、AgentScope但我会把它们放在真实的决策场景里讲而不是干巴巴地列特性。2. 把“下一步由谁决定”拆成三个维度2.1 维度一模型决策——让 LLM 自己规划路径模型决策的意思是你把工具列表丢给 LLM让它自己决定调用哪个工具、按什么顺序调、什么时候停下来。这是最“Agent 味”的模式也是 LangChain 早期 AgentExecutor 和 AutoGPT 那一类项目的核心思路。它的优势很明显灵活。用户问什么奇怪的问题模型可能自己组合出一套你没预设过的工具调用链处理开放域任务时特别爽。但代价也很直接。第一不可预测。同样的输入模型可能这次调 A 再调 B下次直接调 B甚至漏调某个关键工具。第二难调试。出了问题你很难定位是提示词写得不好、工具描述不清楚还是模型本身能力不够。第三成本不可控。模型可能陷入循环反复调用同一个工具token 烧得飞快。我实测过一个简单的查询任务用纯模型决策的 Agent平均要 4 到 6 轮才收敛而固定流程只需要 2 轮。所以模型决策适合什么场景适合探索型、开放域、步骤不固定的任务。比如“帮我调研一下某个技术方案的优缺点”这种任务你没法预先写死流程让模型自己规划反而更合理。但如果你的任务是“查订单→判断状态→发通知”这种流程明确的用模型决策就是杀鸡用牛刀还容易出乱子。2.2 维度二代码决策——用图或状态机写死路径代码决策的意思是下一步走哪条路由你写的代码逻辑决定模型只负责在某个节点内部做它擅长的事比如理解意图、生成文本、抽取信息。LangGraph 就是这一类框架的典型代表它把 Agent 建模成一张有向图节点是具体的处理步骤边是转移条件。AgentScope 在编排层面也提供了类似的结构化控制能力。这种模式的好处是可控、可测、可观测。每个节点做什么是明确的分支条件是你写的出问题能精确定位到某个节点。而且因为流程固定token 消耗和延迟都可预测。坏处是灵活性差遇到没预设过的路径就抓瞎。不过对于绝大多数生产环境的业务来说这恰恰是优点而不是缺点——生产系统要的就是稳定和可预测。我个人的经验是80% 的所谓 Agent 应用其实用代码决策就够了。真正需要模型自由规划的可能只有 20%。很多团队被“Agent 要自主”这个概念带偏了硬要把固定流程做成自主 Agent结果稳定性一塌糊涂。LangGraph 之所以这两年越来越火就是因为它承认了这个现实大部分场景需要的是“可控的智能”而不是“完全自主的智能”。2.3 维度三人决策——Human-in-the-loop 的介入点人决策的意思是在某些关键节点流程暂停等人来确认或选择然后再继续。这在 LangGraph 里叫interrupt在 AgentScope 里也有类似的机制。典型场景包括涉及资金操作需要人工审批、生成的内容需要人工审核、多个方案需要人来拍板。这个维度经常被忽略但在真实业务里极其重要。我做过一个合同审核的 Agent模型抽取条款、比对风险点都没问题但最后“是否通过”这个决策必须由法务来点。如果框架不支持中断和恢复你就得自己在外层包一层状态管理麻烦得很。LangGraph 的 checkpointer 机制就是为这个场景设计的它能把图的执行状态持久化中断后可以从断点恢复这个能力在选型时值得重点关注。把这三个维度画成一张表选型思路就清晰多了决策主体典型框架适合场景主要风险模型决策LangChain AgentExecutor、AutoGPT 类开放域调研、步骤不固定不可预测、难调试、成本高代码决策LangGraph、AgentScope 编排层固定流程、生产业务灵活性差、需预设路径人决策LangGraph interrupt、AgentScope 中断审批、审核、关键决策需要状态持久化支持实际项目里这三者往往是混合的。外层用代码决策保证主干流程可控某个节点内部让模型自由发挥关键节点插入人工确认。选框架的时候就要看它能不能同时支持这三种模式以及切换起来顺不顺手。3. 主流框架逐个拆它们各自把决策权放在了哪3.1 LangChain工具箱很全但控制流偏“放养”LangChain 最大的价值其实是它的生态——各种 LLM 接口、向量库、文档加载器、工具封装几乎你能想到的都有现成实现。入门做原型特别快几行代码就能跑起来一个能调工具的 Agent。但它的传统 AgentExecutor 走的是模型决策路线控制流偏“放养”流程一复杂就容易失控。我早期用 LangChain 做过一个多步骤数据处理 Agent模型经常在“先清洗还是先过滤”之间反复横跳加了大量提示词约束才勉强稳定。后来 LangChain 推出了 LCELLangChain Expression Language用管道符把步骤串起来控制流清晰了不少但它本质上还是线性链遇到需要条件分支和循环的场景就力不从心。所以我的判断是LangChain 适合做工具集成层和快速原型不适合做复杂控制流的生产系统。你可以用它封装工具、管理提示词但主干流程建议交给 LangGraph。3.2 LangGraph把控制流画成图代码决策的主场LangGraph 是我目前做生产级 Agent 的首选。它的核心抽象就三个State状态、Node节点、Edge边。State 是一个共享的数据结构所有节点读写它Node 是具体的处理函数Edge 定义节点之间怎么跳转可以是固定的也可以是根据 State 动态判断的条件边。这个模型特别贴合“代码决策”的思路你想让流程怎么走就怎么画边。它最让我满意的几个能力第一条件边让分支逻辑显式化不用藏在提示词里第二checkpointer支持状态持久化中断恢复、人工介入、失败重试都好做第三流式输出和可观测性做得比较到位调试时能看到每个节点的输入输出。我做过一个需要人工审核的流程用 LangGraph 的 interrupt 机制在审核节点暂停审核完从断点继续整个状态管理框架帮你搞定省了大量胶水代码。当然它也有门槛。图的概念对新手来说需要适应State 的设计要提前想清楚不然写到后面容易乱。而且它的生态还在快速迭代API 偶尔有 breaking change升级时要留神。但总体而言如果你的业务有明确流程又需要一定智能LangGraph 是目前最平衡的选择。3.3 AgentScope多智能体协作和分布式编排的选手AgentScope 的定位和前两者不太一样它更强调多智能体协作和分布式部署。如果你要做的是多个 Agent 互相对话、分工协作完成一个任务比如一个负责调研、一个负责写作、一个负责审核AgentScope 的消息传递和角色管理机制会比较顺手。它在编排层面也支持结构化控制同时提供了容错和分布式的能力适合规模稍大的系统。不过多智能体这件事我的态度比较谨慎。很多所谓的多智能体需求其实单智能体加几个工具就能解决硬拆成多个 Agent 反而增加了通信开销和不确定性。真正需要多智能体的场景通常是角色职责差异大、需要并行处理、或者需要模拟多方交互比如辩论、谈判。选 AgentScope 之前先想清楚你是不是真的需要多个 Agent还是只是想要多个功能模块。3.4 一张选型对照表帮你快速定位框架决策权倾向核心优势最适合的场景上手难度LangChain模型决策为主生态全、工具多、原型快快速验证、工具集成低LangGraph代码决策为主控制流清晰、可中断、可观测生产流程、需人工介入中AgentScope混合、偏多智能体多 Agent 协作、分布式多角色协作、大规模中高这张表不是让你二选一而是帮你判断主战场在哪。实际项目里我经常是 LangChain 管工具、LangGraph 管流程两者配合使用。框架之间不是互斥的关键是别让控制流失控。4. 从需求到选型一套可复用的判断流程4.1 第一步画出你的任务流程图选型之前先拿张纸把任务流程画出来。用户输入进来之后经过哪些步骤每个步骤的下一步由什么决定。画的时候问自己三个问题这个步骤的下一步是固定的吗需要根据中间结果分支吗需要人介入吗把这三个问题的答案标在流程图上你就能看出哪些环节是代码决策、哪些是模型决策、哪些是人决策。我一般会用一个简单的标记法固定步骤画实线箭头条件分支画菱形模型自由发挥的环节画个云朵人工介入画个人形。画完之后如果整张图大部分是实线和菱形说明你该用 LangGraph 这类图框架如果云朵特别多说明你需要 LangChain 这类模型决策能力强的如果人形多那中断恢复能力就是硬指标。4.2 第二步评估状态复杂度状态复杂度决定了你对框架状态管理能力的要求。简单任务状态就是几个变量随便存哪都行。但复杂任务状态可能包含对话历史、工具调用记录、中间结果、用户上下文等等而且需要在节点之间传递、持久化、恢复。这时候框架的 State 设计和 checkpointer 能力就至关重要。LangGraph 的 State 是显式定义的你可以用 TypedDict 或 Pydantic 模型描述每个节点声明自己读写哪些字段清晰但需要设计。AgentScope 的消息机制则更偏向对话式状态。我的经验是状态字段超过 5 个、或者需要跨会话持久化就一定要选状态管理能力强的框架否则后期维护会很痛苦。4.3 第三步确认可观测性和调试需求Agent 系统最头疼的就是调试。模型决策的路径不确定出了问题你根本不知道是哪一步歪了。所以选型时一定要看框架的可观测性能不能看到每个节点的输入输出能不能追踪工具调用能不能回放执行过程LangGraph 配合 LangSmith 在这方面做得比较成熟AgentScope 也有自己的日志和追踪机制。我踩过的一个坑是早期用纯 LangChain Agent出问题只能靠打印日志模型为什么调这个工具、为什么不调那个完全靠猜。后来迁到 LangGraph每个节点的输入输出都清清楚楚调试效率提升了好几倍。所以如果你的项目会长期维护可观测性应该是选型的硬指标而不是加分项。4.4 第四步考虑团队技术栈和运维成本最后别忘了现实因素。团队熟悉 Python 还是 Java有没有现成的部署运维体系LangChain 和 LangGraph 都是 Python 生态AgentScope 也是 Python 为主。如果团队是 Java 背景可能要考虑 Spring AI 这类方案或者用 Python 服务化的方式集成。运维方面分布式部署、监控、扩缩容这些能力不同框架支持程度不一样规模大了之后这些会变成主要成本。我的建议是选型时把“三个月后谁来维护”这个问题想清楚。选一个团队能 hold 住的框架比选一个理论上最强但没人会用的框架强得多。5. 实操中的坑与调试技巧5.1 模型决策失控怎么给 LLM 套上缰绳用模型决策模式最常见的坑就是模型不按套路出牌。我遇到过的典型情况该调工具的时候不调不该调的时候乱调同一个工具反复调调完工具不总结直接又调下一个。解决思路有几个层次。第一层是提示词约束。把工具描述写清楚明确告诉模型什么时候用、什么时候不用给出正反例。第二层是工具设计。工具名和参数要语义清晰别让模型猜。第三层是加护栏。比如限制最大迭代次数超过就强制停止或者用 LangGraph 把模型决策包在一个节点里外面用代码控制循环次数。我一般会设一个 max_iterations实测 5 到 8 次能覆盖大部分任务超过基本就是模型卡住了。5.2 状态污染节点之间数据串了怎么办用图框架时State 是共享的多个节点读写同一个 State很容易出现数据污染。比如节点 A 往 State 里写了个临时变量节点 B 误以为那是最终结果。解决办法是给 State 字段起清晰的名字区分输入、中间态、输出并且在节点函数里明确声明读写范围。LangGraph 支持给 State 定义 reducer控制多个节点同时写一个字段时怎么合并这个机制用好了能避免很多并发写入的问题。5.3 中断恢复失败checkpointer 配置的细节LangGraph 的 interrupt 机制很好用但配置不对就会出问题。最常见的坑是没有正确配置 checkpointer导致中断后状态丢失恢复时从头开始。另一个坑是中断点前后的状态不一致比如中断前修改了 State 但没持久化。我的做法是在中断节点之前确保所有需要保留的状态都已经写入 State并且 checkpointer 用的是持久化后端比如数据库而不是内存。内存 checkpointer 只适合本地调试生产环境一定要换持久化的。5.4 常见问题速查表问题现象可能原因排查方向解决思路模型反复调同一工具提示词不清、工具描述模糊看调用日志加迭代上限、优化工具描述流程走错分支条件判断逻辑有误检查条件边函数打印 State 确认判断依据中断后恢复异常checkpointer 未持久化检查存储后端换数据库存储、确认状态写入多 Agent 通信死锁消息循环等待看消息队列加超时、明确角色职责token 消耗过高上下文过长、循环调用统计每轮 token裁剪历史、限制迭代5.5 几个我踩过的独家坑第一个坑是过早引入多智能体。我做过一个项目一开始就设计了三个 Agent 互相协作结果通信开销巨大调试极其困难。后来改成单 Agent 加多个工具效果反而更好代码量还少了一半。教训是能用单 Agent 解决就别上多 Agent。第二个坑是把提示词当代码写。模型决策模式下很多人把复杂逻辑全塞进提示词几百行的 prompt改一处崩一片。正确做法是把能代码化的逻辑代码化提示词只负责模型真正擅长的语义理解和生成。第三个坑是忽略成本监控。Agent 系统 token 消耗可能比普通 LLM 调用高一个数量级不监控的话月底账单会吓你一跳。建议从第一天就加上 token 统计和成本告警。6. 不同规模项目的选型建议6.1 个人项目和小型原型先跑起来再说如果你是自己做 side project或者团队里快速验证一个想法别纠结太多LangChain 起步最快。它的生态能让你几小时内跑通一个能用的 Agent工具、模型、向量库都是现成的。这个阶段的目标是验证想法不是追求架构完美。等原型跑通了发现控制流复杂了再考虑迁到 LangGraph。6.2 中型生产项目LangGraph 打底LangChain 补工具这是我目前最推荐的组合。用 LangGraph 定义主干流程保证可控可观测用 LangChain 的生态封装工具和模型调用省去重复造轮子。关键节点用 interrupt 支持人工介入State 用持久化 checkpointer。这套组合我用了几个项目稳定性和开发效率都比较满意。6.3 大型多角色系统评估 AgentScope 或自研编排如果你的系统确实需要多个 Agent 协作角色多、交互复杂、还要分布式部署那可以认真评估 AgentScope。但我要提醒的是多智能体系统的复杂度是非线性增长的两个 Agent 还好五个 Agent 的交互组合就爆炸了。上之前一定要想清楚是不是真的需要能不能用更简单的方案替代。很多时候一个编排层加多个功能模块比多个自主 Agent 更靠谱。6.4 选型不是一次性的要留好迁移余地最后说个心态问题。框架这东西迭代太快今天选的不一定三年后还合适。所以架构上要把业务逻辑和框架解耦核心的处理逻辑写成独立的函数或类框架只负责编排。这样将来换框架改的是编排层业务代码不用动。我见过太多项目把业务逻辑写死在框架的节点里想迁移时欲哭无泪。7. 回到那个问题下一步由谁决定绕了一大圈其实选型的答案一直藏在你的业务里。下一步由模型决定你就需要模型决策能力强的框架下一步由代码决定你就需要图或状态机框架下一步由人决定你就需要中断恢复能力强的框架。大部分真实系统是三者混合所以选型时要看框架能不能灵活支持这三种模式以及切换成本高不高。我个人的体会是新手容易高估模型决策的价值低估代码决策的稳定性。做了几个项目之后你会发现把不确定的部分交给模型把确定的部分交给代码把关键的部分交给人这个分工才是 Agent 系统稳定的关键。框架只是工具想清楚控制流工具自然就选对了。最后分享一个小技巧选型纠结的时候拿你业务里最复杂的那条流程用候选框架各写一个最小 demo跑一遍感受一下写起来顺不顺手、调试方不方便。纸上对比一百个特性不如亲手写一遍来得实在。框架好不好用手指头比脑子更清楚。