Agent框架选型指南：从控制流决策权看LangChain、LangGraph与AgentScope

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 机制就是为这个场景设计的，它能把图的执行状态持久化，中断后可以从断点恢复，这个能力在选型时值得重点关注。

把这三个维度画成一张表，选型思路就清晰多了：

实际项目里，这三者往往是混合的。外层用代码决策保证主干流程可控，某个节点内部让模型自由发挥，关键节点插入人工确认。选框架的时候，就要看它能不能同时支持这三种模式，以及切换起来顺不顺手。

3. 主流框架逐个拆：它们各自把决策权放在了哪

3.1 LangChain：工具箱很全，但控制流偏“放养”

LangChain 最大的价值其实是它的生态——各种 LLM 接口、向量库、文档加载器、工具封装，几乎你能想到的都有现成实现。入门做原型特别快，几行代码就能跑起来一个能调工具的 Agent。但它的传统 AgentExecutor 走的是模型决策路线，控制流偏“放养”，流程一复杂就容易失控。

我早期用 LangChain 做过一个多步骤数据处理 Agent，模型经常在“先清洗还是先过滤”之间反复横跳，加了大量提示词约束才勉强稳定。后来 LangChain 推出了 LCEL（LangChain 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 管流程，两者配合使用。框架之间不是互斥的，关键是别让控制流失控。

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 常见问题速查表

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，跑一遍，感受一下写起来顺不顺手、调试方不方便。纸上对比一百个特性，不如亲手写一遍来得实在。框架好不好用，手指头比脑子更清楚。