1. 选型之前先问自己谁在掌控下一步聊 Agent 框架选型绕不开一个最根本的问题你的 Agent 下一步动作到底由谁决定这个问题听起来抽象但它直接决定了你该用 LangChain、LangGraph、AgentScope还是干脆自己撸一套轻量循环。我见过太多团队一上来就对比功能列表结果选了个全能型框架写到一半发现它的控制流跟自己的业务逻辑根本拧着来最后推倒重来。先把概念对齐一下。所谓 Agent本质就是一个能自主决策、调用工具、根据反馈调整行为的程序循环。而下一步由谁决定这个问题拆开来看有三个层次决策权在模型手里、在代码手里、还是在两者的混合编排里。这三种模式对应着完全不同的框架设计哲学也对应着完全不同的适用场景。举个生活化的类比。你可以把 Agent 想象成一个外卖配送系统。第一种模式是骑手自己看着办——你只告诉他把这单送到路线、顺序、遇到堵车怎么绕全由他现场判断。第二种模式是调度中心派单——每一步去哪、送哪家都由后台系统按固定规则算好骑手只负责执行。第三种是骑手加调度协同——系统给大方向骑手根据实时路况微调遇到异常再上报。这三种模式没有绝对优劣但选错了框架就像让一个只会按固定路线跑的骑手去处理需要临场应变的复杂订单或者反过来让一个自由发挥的骑手去跑要求严格时效的标准化配送都会出问题。我在实际项目里踩过最典型的一个坑就是早期用 LangChain 的 AgentExecutor 做一个多步骤数据处理任务。当时觉得它开箱即用工具一注册就能跑。结果业务方要求如果第一步的数据校验失败必须回退到上一步重新拉取而不是直接报错终止。AgentExecutor 的默认循环是线性的模型决定调哪个工具就调哪个代码层面很难插入这种条件回退逻辑。最后我们不得不把整个流程拆成多个独立的 Chain用外部状态机来串等于把框架的 Agent 能力架空了。这个经历让我明白一件事框架的选择本质上是在选择控制流的归属权。你愿意把多少决策权交给模型愿意在代码里写多少硬逻辑这个比例决定了你该往哪个方向选。2. 三种控制流模式对应三类框架的底层逻辑2.1 模型主导型ReAct 循环与它的适用边界模型主导型的核心思想很简单给模型一套工具描述让它自己决定调用顺序观察结果后再决定下一步直到它认为任务完成。这就是经典的 ReActReasoning 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 中文教程这类词高频出现说明大量新手正在涌入而且卡在入门阶段。langgraphlangchain 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. 一张对照表把选型维度摊开讲光讲概念容易飘我整理了一张对照表把几个主流框架在关键维度上的表现列出来。需要说明的是这只是基于我个人使用经验的判断具体项目还得结合实际情况。维度LangChainLangGraphAgentScope自研轻量循环控制流归属模型主导为主代码主导混合编排完全自定义学习曲线中等抽象多较陡概念多中等文档待完善低但需自己造轮子状态管理弱靠 Memory强内置 Checkpointer中有 Memory 模块完全自己实现多 Agent 支持有限支持但偏重单图原生支持自己设计调试体验一般链路长好图结构清晰一般消息流复杂取决于自己适合场景快速原型、简单链复杂流程、需回退多角色协作需求极简或极特殊生产成熟度高生态大较高迭代快中偏研究看团队能力这张表里我想特别强调状态管理这一行。状态管理是 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 框架选型本质是在回答你信任模型到什么程度。信任度高选模型主导型信任度低选代码主导型想折中选混合编排型。想清楚这个问题选型就不再纠结了。如果你现在正卡在选型阶段我的建议是先别急着对比功能拿一张纸写下你的业务流程标出哪些步骤必须确定、哪些步骤可以灵活。写完之后答案往往就自己浮现出来了。 
长河君 · 2026/10/25 8:29:17 · 阅读 1.2k Agent框架选型指南：从控制流归属到LangGraph与AgentScope实践
1. 选型之前先问自己谁在掌控下一步聊 Agent 框架选型绕不开一个最根本的问题你的 Agent 下一步动作到底由谁决定这个问题听起来抽象但它直接决定了你该用 LangChain、LangGraph、AgentScope还是干脆自己撸一套轻量循环。我见过太多团队一上来就对比功能列表结果选了个全能型框架写到一半发现它的控制流跟自己的业务逻辑根本拧着来最后推倒重来。先把概念对齐一下。所谓 Agent本质就是一个能自主决策、调用工具、根据反馈调整行为的程序循环。而下一步由谁决定这个问题拆开来看有三个层次决策权在模型手里、在代码手里、还是在两者的混合编排里。这三种模式对应着完全不同的框架设计哲学也对应着完全不同的适用场景。举个生活化的类比。你可以把 Agent 想象成一个外卖配送系统。第一种模式是骑手自己看着办——你只告诉他把这单送到路线、顺序、遇到堵车怎么绕全由他现场判断。第二种模式是调度中心派单——每一步去哪、送哪家都由后台系统按固定规则算好骑手只负责执行。第三种是骑手加调度协同——系统给大方向骑手根据实时路况微调遇到异常再上报。这三种模式没有绝对优劣但选错了框架就像让一个只会按固定路线跑的骑手去处理需要临场应变的复杂订单或者反过来让一个自由发挥的骑手去跑要求严格时效的标准化配送都会出问题。我在实际项目里踩过最典型的一个坑就是早期用 LangChain 的 AgentExecutor 做一个多步骤数据处理任务。当时觉得它开箱即用工具一注册就能跑。结果业务方要求如果第一步的数据校验失败必须回退到上一步重新拉取而不是直接报错终止。AgentExecutor 的默认循环是线性的模型决定调哪个工具就调哪个代码层面很难插入这种条件回退逻辑。最后我们不得不把整个流程拆成多个独立的 Chain用外部状态机来串等于把框架的 Agent 能力架空了。这个经历让我明白一件事框架的选择本质上是在选择控制流的归属权。你愿意把多少决策权交给模型愿意在代码里写多少硬逻辑这个比例决定了你该往哪个方向选。2. 三种控制流模式对应三类框架的底层逻辑2.1 模型主导型ReAct 循环与它的适用边界模型主导型的核心思想很简单给模型一套工具描述让它自己决定调用顺序观察结果后再决定下一步直到它认为任务完成。这就是经典的 ReActReasoning 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 中文教程这类词高频出现说明大量新手正在涌入而且卡在入门阶段。langgraphlangchain 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. 一张对照表把选型维度摊开讲光讲概念容易飘我整理了一张对照表把几个主流框架在关键维度上的表现列出来。需要说明的是这只是基于我个人使用经验的判断具体项目还得结合实际情况。维度LangChainLangGraphAgentScope自研轻量循环控制流归属模型主导为主代码主导混合编排完全自定义学习曲线中等抽象多较陡概念多中等文档待完善低但需自己造轮子状态管理弱靠 Memory强内置 Checkpointer中有 Memory 模块完全自己实现多 Agent 支持有限支持但偏重单图原生支持自己设计调试体验一般链路长好图结构清晰一般消息流复杂取决于自己适合场景快速原型、简单链复杂流程、需回退多角色协作需求极简或极特殊生产成熟度高生态大较高迭代快中偏研究看团队能力这张表里我想特别强调状态管理这一行。状态管理是 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 框架选型本质是在回答你信任模型到什么程度。信任度高选模型主导型信任度低选代码主导型想折中选混合编排型。想清楚这个问题选型就不再纠结了。如果你现在正卡在选型阶段我的建议是先别急着对比功能拿一张纸写下你的业务流程标出哪些步骤必须确定、哪些步骤可以灵活。写完之后答案往往就自己浮现出来了。