Agent框架选型指南：从控制流归属到LangGraph与AgentScope实践

1. 选型之前先问自己：谁在掌控下一步

聊 Agent 框架选型，绕不开一个最根本的问题：你的 Agent 下一步动作，到底由谁决定？这个问题听起来抽象，但它直接决定了你该用 LangChain、LangGraph、AgentScope，还是干脆自己撸一套轻量循环。我见过太多团队一上来就对比功能列表，结果选了个"全能型"框架，写到一半发现它的控制流跟自己的业务逻辑根本拧着来，最后推倒重来。

先把概念对齐一下。所谓 Agent，本质就是一个能自主决策、调用工具、根据反馈调整行为的程序循环。而"下一步由谁决定"这个问题，拆开来看有三个层次：决策权在模型手里、在代码手里、还是在两者的混合编排里。这三种模式对应着完全不同的框架设计哲学，也对应着完全不同的适用场景。

举个生活化的类比。你可以把 Agent 想象成一个外卖配送系统。第一种模式是"骑手自己看着办"——你只告诉他"把这单送到"，路线、顺序、遇到堵车怎么绕，全由他现场判断。第二种模式是"调度中心派单"——每一步去哪、送哪家，都由后台系统按固定规则算好，骑手只负责执行。第三种是"骑手加调度协同"——系统给大方向，骑手根据实时路况微调，遇到异常再上报。

这三种模式没有绝对优劣，但选错了框架，就像让一个只会按固定路线跑的骑手去处理需要临场应变的复杂订单，或者反过来，让一个自由发挥的骑手去跑要求严格时效的标准化配送，都会出问题。

我在实际项目里踩过最典型的一个坑，就是早期用 LangChain 的 AgentExecutor 做一个多步骤数据处理任务。当时觉得它开箱即用，工具一注册就能跑。结果业务方要求"如果第一步的数据校验失败，必须回退到上一步重新拉取，而不是直接报错终止"。AgentExecutor 的默认循环是线性的，模型决定调哪个工具就调哪个，代码层面很难插入这种"条件回退"逻辑。最后我们不得不把整个流程拆成多个独立的 Chain，用外部状态机来串，等于把框架的 Agent 能力架空了。

这个经历让我明白一件事：框架的选择，本质上是在选择"控制流的归属权"。你愿意把多少决策权交给模型，愿意在代码里写多少硬逻辑，这个比例决定了你该往哪个方向选。

2. 三种控制流模式，对应三类框架的底层逻辑

2.1 模型主导型：ReAct 循环与它的适用边界

模型主导型的核心思想很简单：给模型一套工具描述，让它自己决定调用顺序，观察结果后再决定下一步，直到它认为任务完成。这就是经典的 ReAct（Reasoning + Acting）模式。LangChain 早期的 Agent、AutoGPT 这类项目，走的都是这条路。

它的代码骨架大致是这样：

while not done: thought = model.think(context) action = model.choose_action(thought, tools) observation = execute(action) context.append(observation)

看起来很美，但实际用起来有几个硬伤。第一，循环终止条件不可控。模型可能陷入"我再查一下"的死循环，或者过早认为任务完成。第二，错误恢复能力弱。如果某个工具调用失败，模型未必能正确理解错误信息并调整策略，尤其是错误信息比较技术化的时候。第三，成本不可预测。每一步都要调用模型，步数一多，token 消耗直线上升。

那它适合什么场景？我的经验是：探索性任务、步骤数少、容错率高的场景。比如让 Agent 帮你从几个网页里找某个信息，或者根据用户模糊需求推荐几个选项。这类任务本身就没有严格的步骤要求，模型自由发挥反而更灵活。

不适合的场景也很明确：有严格顺序依赖、需要精确回退、涉及资金或不可逆操作的流程。你不可能让模型自己决定"要不要给用户退款"，这种决策必须由代码逻辑兜底。

2.2 代码主导型：状态机与工作流的确定性优势

代码主导型的思路完全反过来：流程的每一步由开发者预先定义好，模型只在特定节点做"选择题"或"填空题"。LangGraph 是这类框架的代表，它把 Agent 建模成一张状态图（State Graph），节点是处理步骤，边是转移条件。

LangGraph 的核心抽象是三个东西：State（共享状态）、Node（处理函数）、Edge（转移逻辑）。你可以定义一个状态字典，每个节点读取状态、执行操作、写回状态，然后由条件边决定下一步走哪个节点。模型的作用被限制在节点内部，比如"根据用户意图分类，决定走退款分支还是咨询分支"。

from langgraph.graph import StateGraph, END def classify_intent(state): intent = model.classify(state["user_input"]) return {"intent": intent} def handle_refund(state): # 硬编码的退款逻辑 return {"result": process_refund(state["order_id"])} graph = StateGraph(State) graph.add_node("classify", classify_intent) graph.add_node("refund", handle_refund) graph.add_conditional_edges("classify", lambda s: "refund" if s["intent"] == "refund" else "consult")

这种模式的好处是确定性极强。每一步走到哪、什么条件下回退、异常怎么处理，全在代码里写死，测试和调试都容易。缺点是灵活性差，遇到预设之外的情况，要么报错，要么需要开发者新增分支。

我一般建议：业务流程清晰、合规要求高、需要审计追踪的场景，优先考虑代码主导型。比如客服工单处理、订单状态流转、审批流程自动化。这些场景里，"下一步由谁决定"的答案应该是"由业务规则决定，模型只负责理解输入"。

2.3 混合编排型：AgentScope 这类框架的折中思路

混合编排型试图在两者之间找平衡：大框架由代码控制，局部决策交给模型。AgentScope 是这方面比较有代表性的框架，它强调多 Agent 协作和消息传递机制，每个 Agent 有自己的行为逻辑，Agent 之间通过消息驱动。

它的设计哲学是"分布式协作"：你可以定义多个角色 Agent（比如一个负责检索、一个负责总结、一个负责审核），它们各自独立运行，通过消息队列通信。控制流不是单一的循环，而是多个 Agent 的并发协作。模型在每个 Agent 内部做决策，但 Agent 之间的交互规则由代码定义。

这种模式适合复杂任务分解、多角色协作的场景。比如一个研究助手系统：检索 Agent 负责找资料，分析 Agent 负责提炼观点，写作 Agent 负责成文，审核 Agent 负责检查事实。每个 Agent 可以独立优化，整体流程又可控。

但它的复杂度也最高。多 Agent 通信带来的调试难度、状态同步问题、死锁风险，都是实际落地时要面对的。我的建议是：除非任务确实需要多角色分工，否则不要为了"架构好看"而引入多 Agent。单 Agent 加状态机能解决的问题，别上多 Agent。

3. 从热词看真实需求：大家在搜什么，说明在踩什么坑

把热搜词摊开看，其实能读出很多信息。"langchain 入门""langchain 中文教程"这类词高频出现，说明大量新手正在涌入，而且卡在入门阶段。"langgraph""langchain langgraph"并列出现，说明很多人在从 LangChain 往 LangGraph 迁移，遇到了衔接问题。"agent 框架如 langchain、dify、crewai 等，哪个好"这种问法，暴露的是选型焦虑——大家不知道该按什么标准选。

还有几个词很有意思："agent 记忆""agent 安全""agent 架构"。这三个词分别对应 Agent 落地的三大难点：记忆管理、安全边界、架构设计。记忆管理涉及短期上下文和长期知识库的配合，安全边界涉及工具调用的权限控制，架构设计涉及单 Agent 还是多 Agent、同步还是异步。

我特别想聊聊"agent 记忆"这个点。很多人以为记忆就是"把历史对话塞进 context"，但实际做起来远没那么简单。短期记忆要考虑 token 窗口限制，长期记忆要考虑检索相关性和写入时机。LangGraph 提供了 checkpointer 机制来做状态持久化，AgentScope 有专门的 memory 模块，但用哪个、怎么配，还是得看你的业务对"记住什么、记多久、怎么取"的具体要求。

另一个值得说的是"agent 安全"。当 Agent 能调用工具、能执行代码、能访问外部系统时，安全就不是可选项而是必选项。我见过一个案例：某团队做的 Agent 能执行 shell 命令，结果模型被诱导执行了删除操作。后来他们加了工具白名单和参数校验，才把风险控制住。选框架时一定要看它的工具调用有没有权限控制机制，有没有沙箱隔离能力。

4. 一张对照表，把选型维度摊开讲

光讲概念容易飘，我整理了一张对照表，把几个主流框架在关键维度上的表现列出来。需要说明的是，这只是基于我个人使用经验的判断，具体项目还得结合实际情况。

这张表里我想特别强调"状态管理"这一行。状态管理是 Agent 框架的分水岭。简单任务不需要复杂状态，但一旦涉及多轮交互、条件分支、断点续跑，状态管理的能力就直接决定你能不能做下去。LangGraph 的 Checkpointer 允许你在任意节点保存和恢复状态，这对长流程任务非常关键。而 LangChain 的 Memory 更偏向对话历史，做流程状态管理就力不从心。

还有"调试体验"这一行。Agent 的调试比普通程序难得多，因为模型输出有随机性，同样的输入可能走不同的路径。LangGraph 的图结构让每一步的输入输出都可见，配合 LangSmith 这类追踪工具，排查问题相对容易。而纯 ReAct 循环的调试，往往要靠打印日志一步步看，效率低很多。

5. 我的选型决策树：从需求倒推框架

讲了这么多，落到实操层面，我一般用下面这棵决策树来选型。你可以直接拿去用，也可以根据自己的情况调整。

第一步：问"流程是否可预先定义"。如果业务流程是固定的、步骤明确的，直接排除模型主导型，往 LangGraph 或自研状态机方向走。如果流程本身是探索性的、步骤不固定，才考虑模型主导型。

第二步：问"是否需要多角色协作"。如果任务能拆成几个独立角色，且角色之间有明确的消息交互，考虑 AgentScope 这类多 Agent 框架。如果只是单一任务，别引入多 Agent 的复杂度。

第三步：问"状态是否需要持久化和恢复"。如果任务可能跑很久、可能中断、需要断点续跑，必须选有状态管理能力的框架。LangGraph 的 Checkpointer 是这方面的首选。

第四步：问"团队的技术储备和迭代速度"。如果团队对某个框架已经熟悉，迁移成本要算进去。如果是从零开始，LangGraph 的文档和社区相对成熟，上手会快一些。

第五步：问"是否愿意接受框架的约束"。所有框架都有约束，关键是这些约束跟你的需求冲不冲突。如果框架的默认行为跟你的业务逻辑拧着来，与其硬改框架，不如自研一个轻量循环。

我自己的项目里，大部分场景最后都落在了 LangGraph 或自研状态机上。原因很简单：生产环境要的是确定性，不是灵活性。模型可以在节点内部发挥，但节点之间的流转必须可控。这个原则帮我避开了很多"看起来很美但跑不起来"的坑。

6. 落地时最容易忽略的三件事

选完框架只是开始，真正落地时还有几个坑等着。我挑三个最容易被忽略的说。

第一件：工具描述的质量决定 Agent 的上限。很多人把工具注册进去就完事，工具描述写得含糊不清。模型选工具靠的就是描述，描述不准，模型就选错。我的经验是：工具描述要写清楚"什么时候用、输入是什么、输出是什么、有什么限制"，最好给一两个示例。这比调模型参数管用得多。

第二件：错误处理要分层。工具调用失败、模型输出格式错误、网络超时，这些错误要分开处理。工具失败可以重试，格式错误可以重新提示模型，超时要有兜底。如果所有错误都走同一条路，系统会变得很脆弱。LangGraph 的条件边很适合做这种分层处理，每个节点可以定义自己的错误分支。

第三件：可观测性要提前建。Agent 跑起来之后，你需要知道它每一步在干什么、花了多少 token、走了哪条路径。这些信息如果等到出问题再补，成本会高很多。LangSmith、AgentScope 的日志模块，或者自己埋点，选一个尽早接上。我一般会在项目第一天就把追踪接好，后面省心太多。

7. 一个真实项目的选型复盘

最后分享一个我去年做的项目，把上面的思路串一遍。需求是做一个"合同审核助手"：用户上传合同，Agent 要提取关键条款、比对标准模板、标记风险点、生成审核报告。

一开始我们想用纯 LangChain Agent，让模型自己决定先提取还是先比对。跑了几次发现不行：模型有时候先比对后提取，导致比对时没有结构化数据；有时候提取漏了条款，后面全错。问题就出在"下一步由谁决定"——这种有严格顺序依赖的任务，不该让模型决定顺序。

后来改用 LangGraph，把流程拆成四个节点：提取、比对、标记、生成。提取节点用模型做信息抽取，输出结构化 JSON；比对节点用代码做规则匹配；标记节点用模型判断风险等级；生成节点用模板加模型润色。节点之间的流转由代码控制，提取失败就回退重试，比对不通过就标记异常。

改完之后，稳定性大幅提升。模型只在它擅长的环节发挥作用，流程控制交给代码。这个项目让我更确信一件事：Agent 框架选型，本质是在回答"你信任模型到什么程度"。信任度高，选模型主导型；信任度低，选代码主导型；想折中，选混合编排型。想清楚这个问题，选型就不再纠结了。

如果你现在正卡在选型阶段，我的建议是先别急着对比功能，拿一张纸写下你的业务流程，标出哪些步骤必须确定、哪些步骤可以灵活。写完之后，答案往往就自己浮现出来了。