这两年做AI应用，十个人里有八个都在纠结同一个问题：LangGraph、AutoGen、CrewAI、Semantic Kernel到底该选哪个？网上的对比帖刷了一遍又一遍，跑完demo感觉都差不多，一到生产环境就集体翻车。我跟人聊完一圈后发现，大多数人选型之前有个关键问题没想清楚，导致后面所有对比都是在给自己找心理安慰：你的业务流程里，下一步到底由谁决定？

这个问题想清楚了，Agent框架选型基本就定了一大半。因为框架不是什么黑科技，它本质上是一套编排机制，用来回答“先干什么、再干什么、遇到分支走哪边、出错找谁”的。你连决策权都不知道该押在谁身上，框架的编排哲学跟你的业务天然就是拧着的，后面再强的性能、再全的生态都帮你兜不住。

所以这篇不打算再给你贴一堆框架的功能清单。我会从一个很窄但很关键的切口讲起——“下一步由谁决定”，把主流框架背后的编排哲学拆开，再给你一套可以直接拿去用的选型核查清单。全程基于我自己实际项目和踩坑的体会，不说虚的。

1. 先把矛盾摆开：Agent选型的真正分水岭

1.1 “下一步由谁决定”到底是什么问题

所有Agent应用，无论包装成“智能助手”、“自主Agent”还是“多智能体系统”，底层都是同一个循环：接收状态、做出决策、执行行动、更新状态，再进下一轮。这个循环最核心的地方，就是“决策”这个动作发生在哪一层。

说得更直白一点：一次对话进来，接下来是调用工具、回复用户、继续追问、还是转交给另外一个智能体？这个“接下来”的选择，一共只有四种可能的主导者：你的代码、大模型、用户本人、或者一套规则引擎。我把这四种情况叫决策权模型。不同的决策权模型，背后是完全不同的编排需求，而这个需求恰恰是Agent框架之间最大的差异所在。

很多人选框架时看的是“支持多少模型、支不支持流式输出、能不能断点续跑”，这些固然重要，但它们属于功能细节。真正决定你项目成败的，是框架允不允许你在它上面精确表达“这一步由谁拍板、走到什么时候停”。比如你的业务里有一步必须人工审批，那框架支不支持挂起整个Agent循环、等人确认再恢复，这就是硬门槛。再比如你的流程要求每一步都严格按顺序走，那框架的并发自动执行能力反而可能变成负担。

我见过一个特别典型的翻车案例：有人做客服工单系统，选了对话特别自由的框架，两个Agent在群里你一言我一语，结果工单状态被来回改了好几次，用户收到三封内容矛盾的回复邮件。问题出在哪？不是模型不行，是把“下一句话该怎么回”这个决策权交给了对话本身，而业务上明明应该由状态机（代码）来决定。

1.2 四种决策权模型，对应四种不同的框架需求

我把四种模型先摆出来，后面几节会逐个展开。

第一种是代码决策。流程是写死的，大模型只负责其中某一段的文本生成或结构化提取，走到下一步的条件由if-else、状态标记、数据库里的值来决定。比如“先查订单状态，再判断是否需要升级人工”，这个判断完全可以由代码完成。这种场景下，老实说很多所谓Agent框架是用不上的，一个普通的流程编排工具、甚至直接写Python函数就行。

第二种是大模型决策。系统把当前状态丢给大模型，让模型自己决定调用哪个工具、要不要再问一句、还是直接输出答案。这就是大家常说的“自主Agent”。LangGraph、AutoGen、OpenAI Agents SDK这些框架，主要就是在帮这种模型兜底——提供工具调用的协议、循环控制、状态管理、以及多智能体之间的对话和转交机制。

第三种是用户决策。也就是人在回路中的HITL场景。常见于审核、审批、敏感操作放行这类环节：系统把事情做到一半，必须停下来等用户确认。比如生成一段营销文案后需要人工确认才能群发，或者AI写好代码补丁后需要工程师批准才能提交。能支持这种模式的框架，一般需要有暂停/恢复机制，而不是傻乎乎的无人值守全自动。

第四种是规则与模型混合决策。这是目前生产环境用得最多，也最不容易翻车的形态。规则负责把大方向框住，模型负责在规则留出来的空间里自由发挥。比如先按告警级别过滤，只有高危告警才进入Agent诊断流程，诊断结果再经过正则和schema校验，不合法就重来。这种场景需要框架同时具备显式的条件分支能力和模型调用的灵活性，LangGraph这样的图编排框架就特别合适。

一句话总结：选型不是选“哪个框架更聪明”，而是选“哪个框架允许你把决策权放在正确的位置上”。

2. 决策权决定编排范式，而不是框架功能表

2.1 代码决策：干脆别用Agent框架

这不是开玩笑。很多项目确实不需要Agent框架，尤其是当你的流程足够确定、步骤够固定的时候，用重型框架反而给自己添麻烦。

我接手过一个供应链消息解析的模块，需求很简单：邮件进来，提取订单号和到货日期，然后写进数据库，如果信息缺失就回一封邮件让客户补。最初团队用了CrewAI，把解析、校验、回复各写成一个Agent，折腾了两周。后来我把它拆成纯Python：一封邮件进来，直接调用GPT-4o做信息提取，返回JSON schema，代码里判断必填字段是否齐全，不齐全走补件回复，齐全写库。整个模块不到200行，跑了大半年，没有一次是因为框架本身出问题的。

这类项目里，大模型只是管线里的一个函数，它不参与流程控制，不需要自己决定调用什么工具。真正的流程控制逻辑写在代码里，稳定、可测、可单步调试。这时候引入编排框架，等于给直路硬拐几个弯。

那什么时候才需要框架？当你发现流程开始有多个分支、有循环、有跨多轮的状态累积、有并行任务和汇总，代码开始变得混乱，状态变量散落得到处都是，你才需要框架帮你显式管理图结构和状态。这个判断标准非常实际：不是“我用了大模型所以要用Agent框架”，而是“我的流程复杂到代码已经管不住了”。

2.2 LLM决策：自主循环与多智能体协作是主场

如果你的业务确实需要模型来频繁地决定下一步动作，那就要接受一个事实：系统的行为不是完全可预测的，你需要框架提供结构性约束来兜底。

以LangGraph为例，你写一个节点让模型“判断当前意图”，模型吐出结果后，后续走哪条边，其实是由你的路由函数决定的。路由函数读模型返回的结构化字段，比如{"action": "call_tool", "tool_name": "get_weather"}，然后再决定调用哪个具体工具。这里的决策链是“模型提出建议，代码最终下达指令”。这套设计的好处是，模型的自由度被限定在一个可控的决策空间里，它不能凭空跳出你的图去调用没登记的工具。

AutoGen则是完全另一种哲学。多智能体之间通过对话来完成协作，框架不预设流程，谁接话、说什么，大多是模型自组织的。在GroupChat模式下，GroupChatManager负责决定下一个发言的Agent，而这个选择本身也常常是模型生成的。这让AutoGen非常擅长开放式的探索型任务，比如头脑风暴、通用助手场景。但也正因为这样，它的控制力天然就弱一些，你很难精确预定对话顺序。

这里的实操经验是：如果你要求Agent的行为在一个明确的边界内收敛，选靠近代码控制的框架；如果你更看重开放性和灵活性，可以选对话驱动、自主性强的框架。两种没有高下之分，只取决于你的决策权该押在哪边。

2.3 用户决策：人在回路是硬需求

被AI“自作主张”教育过几次之后，你会发现用户决策这种模式才是企业应用里最刚需的。

我做过一个合同审核助手。原方案里，Agent读完合同条款，自动生成审核结论，然后直接推给业务方。上线第三天就出事：一份合同里有个很隐晦的违约条款，Agent的结论是“建议接受”，但按照业务规则，这类条款必须法务复核。因为流程里没有设置“法务审批”这个决策点，系统直接走了绿灯。

后来改成：Agent生成审核结论后，如果风险等级是低，走自动放行；如果是中或高，Agent循环在这里暂停，生成一份待办，等法务在界面上点“同意”或“打回”。打回之后Agent要根据补充意见重新跑一遍。这个“暂停-等待-恢复”的能力，就是HITL的精髓，不是什么花哨功能，而是实打实的可靠性兜底。

选框架的时候要特别留意：它有没有interrupt机制，能不能把Agent的循环挂起，把状态存下来，人处理完再恢复执行。LangGraph的interrupt、LangChain的HumanApprovalCallbackHandler、Semantic Kernel里的Function Approval这些都是干这个的。没有这种能力，你只能自己拿数据库手动存状态，绕很远的路。

2.4 混合决策：规则加推理的可控编排

最后一种，也是我认为最能打的一种：把决策权分到不同层级。宏观流程走代码和规则，微观推理交给大模型。

举一个运维告警处理的例子。告警进来，先用规则引擎做一级过滤：已知告警类型、已知处理预案、命中就自动执行，根本不进Agent；只有规则处理不了的高危告警，才带着上下文进入Agent循环。Agent负责做诊断推理、调取监控接口、尝试定位，但它拿到的工具是白名单；诊断完输出结构化建议，再由代码跑一遍schema校验，不合法就退回重生成。最后生成的处理工单，还要在提交前做一次人工确认。

这种形态下，Agent只是这个流程里的一个“高智商模块”，而不是整个系统的负责人。框架要能支持这种混合编排：有显式分支、有条件跳转、有工具白名单、有状态持久化，还要能插进人工确认。这套东西用LangGraph或者带条件边的编排引擎做，非常顺手。它没有把所有决策权都交给大模型，所以系统的行为边界是可控的，风险自然小得多。

3. 主流框架的编排哲学拆解

3.1 LangGraph：把控制权画成一张图

LangGraph是目前把“控制权显式化”做得最极致的框架之一。你在代码里定义节点和边，编译成一张图，运行时状态沿着图流动，每走到一个节点，就执行对应的逻辑或者调用一次模型。

我自己用下来的最大感受是：它逼着你把决策想清楚。你写从节点A到节点B的边，可以走普通边，也可以走条件边。条件边上的路由函数，是纯代码，它读当前状态，返回一个字符串，决定下一步去哪个节点。哪怕这个读取的状态字段是模型生成的，最终拍板走哪条路的还是你的路由逻辑。这种设计对工程化非常友好，因为每个分支都可以单独测试、单独追踪。

它的状态管理和持久化也很强。每个步骤都有状态对象，支持在不同节点之间传递和更新，还能做checkpoint保存，中断后可以从某个节点恢复。这正好支撑上一节说的HITL场景：Agent跑到审批节点，把状态存下来，人工处理完，再从同一个节点继续。

缺点也不是没有。图结构对简单任务来说偏重，你得写不少样板代码。而且图一旦复杂起来，分支多了之后调试起来看图都会头晕。我的建议是保持图的精神：图只是骨架，真正的业务逻辑还是要拆到节点内部的函数里，别让图本身承载太多逻辑。

3.2 AutoGen：让对话决定流程走向

AutoGen是微软开源的多智能体框架，它走的完全是另一条路：把编排搭在“对话”之上。Agent之间互相发消息，整个流程就是一段多角色、多轮次的会话。

在这种设计里，决策权天然倾向大模型。比如你有一个UserProxy负责提需求，有一个Assistant负责解答和调用工具。UserProxy把问题发出来，Assistant回复，这个回复本身可能就是一个“下一步动作”的决策：询问澄清、调用工具、还是给出最终回答。而GroupChat模式下，下一个谁发言，通常也是由LLM选出来的发言人来决定的。

这种开放性让AutoGen特别适合做探索性任务，比如研究助手、通用编程辅助、以及需要多角度讨论的场景。你给它一个开放的问题，它能自己组织好几个Agent轮番上场。但它对流程确定性的支撑就弱得多，如果你需要精确的步骤、严格的顺序、固定的审批节点，用它就得花很多额外精力去限制对话行为。

我的建议是：如果你想快速验证“多Agent互相讨论能不能解决我的问题”，AutoGen非常合适；如果这个讨论结果要被写进正式业务系统，并且要跟现有系统做严格的交互，那就要慎重，它带来的不可预测性可能比你预想的要大。

3.3 CrewAI：角色任务小队和经理

CrewAI的思路是把Agent当成团队成员，每个Agent有明确的角色、目标和背景故事，比如“资深文案”、“数据分析师”、“运营审核官”。多个Agent组成一个Crew，去执行一系列任务。

它有两种主要流程模式。Sequential模式是代码说了算，任务按固定顺序执行，这个Agent干完交给下一个，流程是确定的。Hierarchical模式则是加了一个Manager Agent，由这个经理来规划任务、给团队成员分配工作、审查结果。注意，经理的规划也是模型生成的，所以这种模式下决策权倾向于大模型。任务怎么拆解、分给谁、怎么验收，都取决于经理Agent当时的推理输出。

如果你要做的是“一组人协作出一份完整作品”这样的任务，比如内容生产小队、营销活动策划，CrewAI的这套角色扮演体验很顺。角色分开管理，每个Agent的工具和职责边界很清楚。它的新版还加入了Flows，允许你用显式的事件流来做编排，相当于向代码决策靠拢，算是对它早期缺乏细粒度控制的一种补强。

经验之谈：CrewAI适合任务边界相对清楚、协作角色可以预定义的项目。如果任务是高度动态的，角色、分工经常变，那你用它可以，但要把Manager Agent的行为约束好，不然团队运行靠猜，出问题都不知道找谁。

3.4 Semantic Kernel与OpenAI Agents SDK：企业集成与控制权转交

这两者虽然来自不同阵营，但在编排思路上都值得单独拿出来讲。

Semantic Kernel是微软的企业向框架，重度面向.NET和Azure生态。它的核心抽象是Kernel、Plugin、Function。你在Kernel里注册一堆函数，通过AI来调用它们完成用户任务。早期它有个Planner组件，试图让模型自动规划整个流程，后来逐渐淡出，转向function calling的标准路径。

它给我最大的印象是企业集成做得深：认证、配置、日志、策略都能跟企业基础设施对接。而且它对人在回路支持明确，在工具调用前可以插入审批逻辑，属于“代码把关、模型执行”的稳妥路子。如果你是.NET技术栈，或者要把Agent能力嵌进现有的企业应用，它比那些纯Python社区框架更顺手。

OpenAI Agents SDK的核心设计是Handoff机制，也就是“控制权转交”。一个Agent在处理过程中，如果判断该由另一个Agent来处理更合适，可以直接发起转交，把对话控制权连同上下文一起交给对方。这个转交动作由模型决策，但SDK提供了明确的协议和追踪机制，你能看到控制权在哪个Agent之间跳转。它对构建“多专家路由”型应用很合适，比如做一个企业服务台，首席Agent判断问题类型，转交给IT支持Agent或者HR Agent。

这套框架还提供了Session状态管理和Tracing，适合需要把多Agent对话落地到正式产品里的场景。它唯一的短板是生态相对年轻，自定义能力和LangGraph相比还差一些，但如果你主要在OpenAI栈上做开发，它会是更省心的选择。

3.5 框架对比速查表

这张表不是为了让你直接照抄结论。它真正的用途是帮你在预选框架之前，先看看这个框架把决策权默认押到了哪里。如果它的默认倾向跟你的业务流程拧着，你用起来就会浑身难受。

4. 实操：拿“决策权清单”过一遍你的场景

4.1 选型前先问自己6个问题

与其在框架仓库的star数之间反复横跳，不如先花二十分钟回答下面这几个问题。答完，选型范围基本就锁定了一半。

第一，这个流程里有哪些步骤是绝对不允许被AI省略或改变的？拿出货单、发给用户、写入关键数据库，这些动作如果出了错，代价有多大？代价高，就必须把决策权放在代码或用户手里。

第二，流程的分支是已知还是未知？如果所有分支都能列出来，那就是状态机可以解决的问题，代码决策足够；如果分支千变万化、根本列不完，那才需要大模型参与决策。

第三，用户是否需要在流程中间介入？如果要，选型时就必须考校框架的中间挂起和恢复能力，这一条最关键。很多框架官网上不会把它写在首页，你得去翻文档。

第四，Agent的工具调用范围能不能收窄？一个Agent能不能只被允许调用3个工具而不是30个。工具面越窄，模型决策出错的概率越低，这是工程上最容易见效的降风险手段。

第五，流程执行到一半失败，重试的代价是什么？如果重试意味着重新调用一堆模型接口、烧掉一批Token，那你就需要好的状态持久化和断点恢复能力。

第六，团队对不可见行为的容忍底线是什么？如果团队或客户无法接受“AI有自己的想法”，那请你把决策权押在代码和用户上，框架选可控型号；如果你们本来就抱着探索心态，那可以选自主型框架。

4.2 三个典型场景走查与框架结论

第一个场景是智能客服工单系统。典型需求：用户提问，系统判断意图，查订单，回答结果。落到生产环境，退款超过一定金额必须人工审批。这个场景下，普通意图识别可以让模型做，但退款审批节点不能跳过。流程分支是有限的，人工审批是不可省略的。结论很明确：LangGraph。因为它可以显式地把“人工审批”画成一条必经边，审批前挂起，审批后继续。

第二个场景是数据分析助手。用户用自然语言提问，系统生成SQL、执行查询、返回结果。这类流程中，用户是否对查询结果满意、要不要换一个角度继续分析，这个下一步只能由用户决定。更重要的问题是：SQL生成错了、执行了，后果可能很严重。所以建议用带interrupt能力的框架，或者是能对接读写权限控制、查询前需要用户确认的版本。LangGraph和Semantic Kernel都行，纯代码加模型调用的混合方式也可以。

第三个场景是运维告警自动诊断。每天几千条告警，大部分是垃圾，小部分需要处理。如果让Agent全量接管，既不经济也不安全。正确做法是规则引擎先过滤，只把高优先级告警送进Agent做诊断，Agent调用监控API收集指标，输出结论，最后由值班人确认。这种场景本质上是一个带决策门的流水线，L语句级别的代码决策占主导，Agent只做诊断推理。我会选LangGraph，并在入口规则这一层直接用代码过滤。

4.3 选型后的最小落地建议

拿到结论别急着把整个系统都搬上框架。我的经验是分三步走。

第一步，用最朴素的方式把MVP跑通。不用框架，直接用大模型API加普通函数，把流程的核心路径走一遍。这里面如果你的流程有循环、有条件分支、有状态需要跨步骤维持，你会立刻感受到原生代码的痛点在哪。这个痛点，才是框架要解决的真正问题。

第二步，把框架里的“最小可控agent”搭出来。不要一开始就设计十几个节点、七八个Agent。先让一个Agent加两个工具在一个简单流程里跑通，把状态、追踪、错误处理都接好。

第三步，再逐步放开决策权边界。先从代码决策开始，逐步把一些决策点开放给模型；每放开一个决策点，就要配套一个校验和兜底机制。比如让模型选择工具时，一定要用工具schema白名单；让模型生成结构化输出时，一定要用schema校验。这样即使模型耍脾气，你也能在流程上拦住它。

5. 常见问题与排查技巧实录

5.1 问题一：LLM自作主张，结果不可控

典型表现是：明明要求只能查库存，结果模型自己决定去查了运输状态；用户问一句，模型不回话，反而把所有工具挨个调了一遍。根源通常不是模型“不听话”，而是你给它的决策空间太大了。

我的排查顺序是这样的：先看工具的注册列表，超过5个就做分类合并，能收窄就收窄；再看系统提示词里对决策的约束是不是空话，“尽量”“可以”这类词太多，约束力基本为零，改成“当且仅当A成立才执行B”；再看输出协议，让模型先输出决策原因，再用结构化字段决定动作，很多时候模型在生成structured output时收敛度会明显提升。

如果还不行，就在路由函数里加一道代码校验。模型可以建议调用某个工具，但代码要检查当前状态是否符合调用条件。不符合就拒绝，并把这个拒绝信息回传给模型，让它重新决策。这一步等于在模型和行动之间加了一堵“代码墙”，效果立竿见影。

5.2 问题二：死循环，Agent卡住不退出

这是自主Agent最常见的生产事故。两个Agent互相回复，谁也说服不了谁；或者同一个工具调用失败后，Agent反复重试，把Token烧穿。我第一次跑多Agent协同时，就因为忘了设对话上限，一晚上烧掉了几百万Token的账单。

现在我的做法是全链路加护栏：所有Agent循环都要设最大迭代次数，LangGraph里对应recursion_limit，AutoGen里用max_turns或max_consecutive_auto_reply；所有工具调用失败要做经错终止策略，连续失败两次就换Agent或者直接上报，不要让模型无限重试；还有一个很有用的技巧：给系统提示里写一句“如果你发现自己说的跟上一轮一样，请立即终止并总结现状”，实测下来确实能减少一部分空转。

另外要特别盯住“循环产生的素材”：追踪工具调用次数、对话轮数、Token消耗三个指标，超过阈值立刻告警。没有指标监控的Agent系统，等于裸奔。

5.3 问题三：成本失控，Token比预期烧得快

Agent应用比普通API调用贵很多，因为每个步骤都在调模型，每轮对话还要把所有历史消息重新塞进去，上下文越长，单次成本越贵。很多人在demo阶段感觉不到，一上真实流量就傻眼。

省钱的核心思路不是找便宜的模型，而是减少无谓的决策和上下文膨胀。第一，能走代码判断的就别让模型攒合；第二，做任务分类路由，简单意图用小模型，难的才用大模型；第三，定期压缩或裁剪历史消息，老早之前的对话改成摘要，塞回上下文时用摘要替代原文；第四，给“是否需要进入Agent流程”设规则门槛，很多问题压根不需要Agent介入。

还有一个经验：不要在一个Agent里堆太多历史，把上下文切分成“必要上下文”和“参考上下文”，模型决策时往往只需要前者，后者做成按需检索。这个改动能把大部分Agent应用的成本降下来一半以上。

5.4 问题四：调试困难，黑盒难以复现

普通代码出错给个堆栈就完事，Agent出错你得知道“当时模型看到了什么、做了什么决定、为什么这么决定”。没有完整追踪，所有复现都是碰运气。

所以我建议，框架选型时把可观测性当一等公民。LangGraph配LangSmith，AutoGen配Autogen Studio，Semantic Kernel用Azure的logging链路，OpenAI Agents SDK自带Tracing。如果框架不好接这些，至少要自己写系统日志：把每次模型请求的输入、输出、路由函数的返回值、工具调用的入参出参都打出来。看起来啰嗦，真出事的时候这就是你把押在案子上的摄像头。

我还会做“重放测试”：把线上出问题的那一轮对话日志存下来，离线喂给同一个模型和同样配置，看能不能复现。能复现，问题就在逻辑配置；不能复现，问题多半在上下文随到变化或者外部状态。这两种结论对定位问题完全不一样。所以从第一天起，日志里就必须带上请求ID、Agent名称、节点名称、工具名称这四个最基础的溯源字段。

6. 我踩过坑后留下的几条铁律

框架本身没有绝对的好坏，只有“跟你的决策权模型合不合适”的差别。这几年换过好几套框架，有过凌晨两点盯日志盯到眼花的经历，也有过因为少设一个拦截而给客户发错报告的低级事故。几条铁律说给你听，每一条都是用生产事故换的。

第一，决策权能交给代码就不要交给模型，能留给用户就不要留给系统。这不是保守，而是可靠性工程的基本盘。第二，模型只产出建议，执行必须过代码检查，这句话最好打印出来贴在工位上。第三，Agent系统的复杂度上涨是指数级的，每加一个Agent、每放开一个工具，都要提前想好“它要是犯错了，我怎么发现、怎么止损”。第四，先有日志，再有Agent。这句话请从第一天就记住，因为等你需要的时候，往往已经来不及了。

希望这篇从“下一步由谁决定”切入的选型思路，能帮你少走一些我当年走过的弯路。最后再补一句最实在的技巧：你不需要一步到位把全套框架绷齐。先用一个函数，再升级成一个节点，最后才长成一张图——慢慢来，系统一定会越来越稳。