从决策权看Agent框架选型：先想清楚下一步由谁决定

选 Agent 框架最容易踩的坑不是框架本身不够好而是团队在讨论阶段就讨论错了方向。我见过太多次这种会有人在白板上画框、画线、写LangGraph 好生态全支持状态图对面马上接AutoGen 多角色对话更灵活然后一群人开始比 GitHub Star、比社区活跃度争论一两个小时最后各写各的。每次我都会让讨论停一下换个问题你的系统里下一步要做什么到底由谁决定这个问题一旦想清楚框架选型往往就水落石出。这篇东西不是框架的完整评测更不是某个框架的教程。我想分享的是一套从决策权出发的 Agent 框架选型思路外加我在真实项目里踩过的坑。适合谁看准备上 Agent 项目的工程师、要拍板技术方案的架构师以及被框架太多不知道怎么选困扰的技术负责人。1. 选Agent框架先想清楚下一步由谁决定1.1 一个案例把问题逼出来先说一个我实际做过的客服工单系统。需求听起来很简单收到用户邮件判断意图回复或者转人工。团队有人提议用 Agent 框架理由是现在不都这么做吗。我让他们先别急把流程拆开邮件进来以后先做垃圾邮件过滤这是一个规则判断代码写死就行然后解析发件人信息、提取关键词这也是确定性的到了意图识别问题开始不一样——这条邮件到底是投诉、咨询还是退款模型说了算识别完以后要不要转人工公司定了条规则高价值客户或者模型置信度低于 0.6强制转人工最后回复内容生成出来是自动发出去还是先让人扫一眼又要看客户等级。拆完以后答案已经清楚了这个系统里下一步由谁决定在每个节点都不一样。有的节点由代码决定有的由模型决定有的由人决定。搞清楚这一点再回头看框架你会发现大多数框架其实都在回答同一个问题它默认把决策权交给你、交给模型还是交给用户。1.2 决策权分三种编排模式也要分三种我在项目里习惯把决策权分成三类跟代码、模型、人一一对应。第一类确定性逻辑说了算。流程是预先定义好的A 做完做 B条件满足走 C不满足走 D。这是传统软件工程最擅长的事用普通函数、消息队列、工作流引擎都能写。这一类决策的特点是可预测同样的输入永远走同样的路径。第二类模型说了算。大模型在每一步通过推理决定调哪个工具、拆成几个子任务、要不要继续。这类决策最大的特点是不可预测同一个输入今天可能走三条工具调用明天可能走五条甚至可能跑偏。这就是 ReAct 模式的本质——模型根据当前上下文自己决定下一步行动。第三类人说了算。系统运行到某个关键节点停下等人工审核、批准、补充信息再继续。这不是简单的人在线兜底而是业务上的硬性要求该签字的地方必须签字。三种决策权对应三种不同的编排模式这是框架选型的第一层判断维度。你先想清楚自己的系统里哪一类决策占主导再去看框架比对着 feature list 选要靠谱得多。1.3 为什么市面上的框架对比总是不够用市面上大多数 Agent 框架对比比的都是 token 消耗、响应速度、调试体验、生态丰富度。这些指标不是没用但它们是第二层、第三层的问题。第一层问题是这个框架的编排哲学是什么它默认的控制流长什么样打个比方选车的时候如果只比百公里加速和内饰可能选出一辆根本装不下全家行李的车。框架也一样LangGraph 的控制流是显式有向图AutoGen 的控制流是动态对话LlamaIndex Workflows 的控制流是事件驱动CrewAI 的控制流是预设角色加层级管理。它们对下一步由谁决定有自己的默认答案和扩展方式。如果你要的是强控制、审批节点、可审计流程却选了一个默认开放对话、模型自由决定下一步的框架后面每个环节都会别扭而且越到生产越痛苦。反过来说如果项目本身就是要探索开放式问题让它自己发散你非要用强约束的图编排框架去框死它那也是互相折磨。搞清楚自己的决策权分布等于把选型坐标系的 X 轴定下来了。2. 决策权图谱三种编排模式与真实混合形态2.1 代码决策确定性编排先聊最不性感但最常见的情况。任务流程是固定的数据清洗后做字段映射然后调用一次模型再根据结果走分支最后写库。这种流程里没有模型自己决定要不要调工具的空间你也不需要框架给你一个自主循环。普通函数加一个 if/else 就完成了顶多用一个轻量级工作流库把步骤管理起来。这个阶段我见过最典型的问题是团队为了上 Agent 框架而把简单流程复杂化。几个固定步骤的管道任务硬要用状态机框架搞出十几个节点维护成本暴涨。所以我的建议是如果整个流程里没有分支会依赖模型自主判断你根本不需要 Agent 框架——别把架构选型变成 KPI。2.2 模型决策自主循环当任务本身没有固定路径要靠模型动态规划时就进入了模型决策区。典型场景是自主编程助手读需求、改代码、跑单测、看报错、再改代码这个循环的执行次数不确定什么时候停下模型要想测试结果也在起作用。这里的核心控制点有三个循环的跳入条件、循环的跳出条件、每一步调用的工具集合。跳入条件一般由需求触发跳出条件最理想的是外部验证通过比如测试通过、用户确认、任务完成度达到阈值只有极少数情况才允许模型自行判断我完成了。框架在这个区域的价值是有没有提供机制让你优雅地表达模型可以决定要不要继续调工具、调什么工具这件事同时给你留好终止条件和降级出口。2.3 人工决策人在回路人工决策在业务系统里最常见但写技术博客的人经常忽略它。内容审核要人工确认大额交易要人工批准生成的重要外发文件要人工签字。这种场景对框架的要求很直接能暂停、能持久化、能恢复。暂停意味着 Agent 在一个中间状态停住等待外部输入持久化意味着进程崩了、服务重启了状态还在恢复意味着人给完意见以后流程能接着往下走而不是从头重来。这个能力在框架里通常叫 interrupt、suspend 或者 human-in-the-loop。如果框架不支持你就得靠业务系统自己做状态存储等于把流程引擎的活外包给数据库表非常痛苦。2.4 混合编排真实系统的常态用我开头那个客服系统来总结节点 A 过滤垃圾邮件是代码决策节点 B 意图识别是模型决策节点 C 是否转人工是规则决策但规则里掺着模型输出的置信度节点 D 是否发送是人工决策。真实系统几乎永远是混杂的问题只在于不同决策类型占的比例。这意味着选框架时不要只看它对单一决策类型支持得多好要看它对混合编排的支持能力能不能在一个图里既有代码条件分支又有模型决定的边还能在关键节点上暂停等人工这个维度直接决定了框架的容错度和工程化上限。3. 主流Agent框架的默认答案谁的编排理念更适合你3.1 LangGraph把决策权显式画在图里LangGraph 是我目前最常用的框架核心思路是状态图StateGraph。你定义节点节点之间用边连接边可以是常规边走完一个节点必然进下一个也可以是条件边走哪条分支由自定义函数决定这个函数里可以读模型输出、读业务数据、读规则结果。所以 LangGraph 对下一步由谁决定的答案是你来定。代码写死的部分由代码定模型参与的部分由条件边里的逻辑定人工参与的部分用 interrupt 把图挂起。它不像早期 LangChain 的 AgentExecutor 那样把决策权隐含在一个自动循环里而是把所有控制权都交回给你。代价是你的心智负担变高要理解状态如何流转、checkpointer 怎么保存、replay 怎么用设计不好很容易把图画得又大又乱。我在生产项目里用 LangGraph 做内容审核流水线分支逻辑很直观先模型分类分类结果进条件边置信度低于阈值走人工节点人工节点 interrupt 等审核审核反馈后走 post 处理。这套落地很顺因为它的模型和我的决策权分布恰好一致。3.2 AutoGen让对话决定下一步AutoGen 的理念是 conversation-driven。多个 Agent 互相发消息你来我往就像一群人开讨论会。谁先说、说什么、谁接话由对话机制决定什么时候散会由终止条件决定比如某个 Agent 说任务完成或者达到最大轮次。这个模式下下一步由谁决定不是预先画好的而是在对话过程中动态涌现的。这种模式优势是探索性强适合研究型任务让一个 Agent 出方案另一个 Agent 挑毛病第三个 Agent 做整合来回几轮可能产出单模型做不出来的结果。但同样的特性放到生产环境就变成问题流程比较难预判每一步不可复现对话轮次多了以后 token 成本失控排查问题也要沿着消息记录一条条捋。AutoGen 也提供 GroupChatManager 这类角色来约束对话走向但整体上它默认把更多决策空间让给了模型。3.3 CrewAI角色分工下的流程控制CrewAI 把 Agent 包装成角色每个角色有职责、目标和背景故事多个角色组成一个 Crew按顺序或层级方式执行任务。顺序模式下人把任务列表排好每个任务指定给某个角色跑流程是相对确定的层级模式下会有一个 Manager Agent 负责拆解任务、分配任务、汇总结果这部分权力给了模型。用决策权的语言来说CrewAI 的默认答案偏人定流程模型演角色manager 在局部做动态分配。它的抽象非常友好新人上手快因为你不需要设计状态图只要声明角色和任务。但代价是精细控制不如图编排框架如果你需要环节 A 的结果大于阈值才允许角色 B 发言否则直接走人工表达起来就没有 LangGraph 那么自然。3.4 LlamaIndex Workflows用事件信号驱动决策LlamaIndex 的 Workflows 走的是事件驱动路线。你用装饰器把函数声明成一个 stepstep 之间通过 Event 通信一个 step 处理完负责 emit 一个事件框架根据事件路由到下一个 step。每个 step 内部既可以是纯代码也可以调 LLM微博的写法很轻量。这里有个很巧妙的点事件本身就是决策结果。代码决定下一步就 emit 一个明确的事件名模型决定下一步就让它输出一个结构化结果你把这个结果翻译成事件类型。这种设计比 LangGraph 的图更松散一点比 AutoGen 的对话更可控一点很适合 RAG 管线、文档处理这类以数据和内容为中心的任务。不过 event-driven 的隐式路由会带来一个问题事件类型多了以后全局的路由关系要自己去梳理不如一张图直观。3.5 Semantic Kernel 与工作流引擎企业级编排的备选微软的 Semantic Kernel 在企业环境里更受欢迎它的编排态度偏克制插件化、模板化LLM 调用尽量收敛在明确的功能边界里。它不鼓励把核心业务流全交给模型自由编排而是让开发者在 Kernel 周围组织确定性代码再用模型做局部决策。如果你的团队有严格的审计、合规和可测试性要求这种模型做助手、代码做主人的思路会少很多麻烦。还有一类容易被忽略的方案是通用工作流引擎比如 Temporal、Prefect。它们本来不做 Agent 编排但长任务执行、超时重试、人工等待审批这些能力做得比 Agent 框架成熟得多。我的实际做法是核心执行用 Temporal 管状态和重试Agent 框架只在每个需要智能决策的步骤里被调用。这种流程引擎兜底、Agent 框架负责智能节点的组合在严肃业务里非常稳。3.6 一张表看懂主流框架的决策模型框架默认决策权编排模型最合适的场景主要短板LangGraph开发者显式控制状态图 条件边 interrupt强控制、混合决策、生产流程学习曲线陡状态设计复杂AutoGen动态对话涌现多 Agent 消息循环研究探索、多角色讨论生产可控性弱流程难预判CrewAI人定流程 角色执行顺序/层级角色协作快速原型、角色化任务精细控制不如图编排LlamaIndex Workflows事件信号驱动step 事件路由RAG 管线、文档处理复杂路由难梳理Semantic Kernel代码主导 LLM 辅助插件化 目标调用企业合规、强审计需求Agent 灵活性受限工作流引擎Temporal/Prefect流程定义 人工信号持久化执行 审批长任务、审批、高可靠无原生 LLM 决策抽象这张表不是打分表而是给你一张默认答案清单。你的系统偏哪一列就去哪一行里找参考。4. 实操选型清单几个关键问题锁定框架范围4.1 先画一张决策路径图在打开任何框架文档之前我会先做一件事把核心业务流程画出来每个节点写清楚两件事——这个节点做什么以及做完以后下一步由谁决定。这一步不花半小时但能救你后面几个月。画的时候用最简单的记号就行。方框是任务节点箭头是流转箭头上的标注写决策主体CODE 表示代码决定LLM 表示模型决定HUMAN 表示人工决定。如果箭头是LLM 判断 规则兜底就标成 HYBRID 并补一句兜底条件。画完以后数一下全流程里有几个 LLM 决策点几个 HUMAN 决策点决策点之间有没有循环我画过的最典型的一个助手项目最后的路径图是用户请求进来意图判断是 LLM 决策参数提取是 LLM 决策但参数合法吗是代码决策是否确认执行是人工决策执行结果是否重试是代码决策。这个项目最终选了 LangGraph就是因为图里有两个需要挂起等人工的位置而它正好有 interrupt 机制匹配度很高。4.2 六个问题锁定框架范围画完路径图我会让团队回答六个问题。全部答完框架范围基本就锁定了。第一个问题工作流是闭合的还是开放的闭合意味着路径有限且可枚举开放意味着模型可能不断开辟新路径。闭合偏 LangGraph、Workflows开放偏 AutoGen 或自研循环。第二个问题流程里会出现下一步我也拿不准的节点吗如果存在这种节点你必须给模型决策权但同时要想清楚兜底。框架就得支持动态工具调用和终止条件。第三个问题你有没有审计和可观测性要求有的话优先看那些状态模型清晰、决策路径可导出的框架。AutoGen 的对话流能审计但审计起来很累。第四个问题人工审批的等待时间多长如果等一天框架必须支持持久化状态和重启恢复光有内存里的 interrupt 是不够的。Temporal 加 LangGraph 的组合在这里会明显胜过纯 Agent 框架。第五个问题团队里谁会长期维护如果团队不熟状态图却熟 Python 函数LlamaIndex Workflows 或者 CrewAI 的接受度会高很多。第六个问题你愿意为框架写多少胶水代码所有框架都不会完全匹配你的决策路径预留 20% 到 30% 的胶水代码是常态谁的模式贴近你的业务谁的胶水就少。4.3 生产环境还要看的三个点决策模型匹配之后还要从生产视角过一遍。第一个是 trace。Agent 跑的每一步都应该能拉出来看包括决策输入、模型输出、工具返回、token 消耗。LangGraph 生态有 LangSmith自研方案就自己定义 trace 结构但反正不能没有。第二个是状态持久化。人审可能等很久进程重启以后流程要能恢复。LangGraph 有 checkpointerTemporal 有 durable execution它们解决了同一个问题流程不会因为服务抖动而丢。第三个是成本控制。模型决策的次数直接决定账单。我习惯在框架层面对模型决策次数做全局配额比如单任务最多 15 次 LLM 调用超出就降级转人工。这个配额不是写完代码再想的最好在选型阶段就确定它要能通过配置控制。5. 落地避坑Agent框架选型后的常见问题5.1 把决策权全交给 LLM循环失控与 token 黑洞我最早期的一个项目为了让 Agent 显得智能让模型在一个循环里反复自测自己写代码、自己跑、报错就自己改没有外部验证也没有迭代上限。看起来很美实际跑起来就是灾难——模型陷入同一个 bug 改来改去prompt 越来越长token 越烧越多最后把任务当成完成了但交付的东西根本不能看。后来我加的看门狗有三层第一层是硬性迭代上限超过就断第二层是外部验证器比如单测必须真实跑过才允许进入下一阶段第三层是异常降级发现连续 N 次修改都没改变测试结果就转人工介入。这些都是为了回答什么时候停下来——答案不能只靠模型自觉业务逻辑必须接管兜底。5.2 为流程而流程过度编排的真实现场另一个反面是过度编排。我见过团队接手一个只有三个固定步骤的翻译任务SSR 要求上 LangGraph 建图画了十几个节点包括错误恢复、回退、多级缓存写了一个多月。上线之后的复杂度和故障率远超普通函数版本最后整个模块被删掉重写。判断是不是过度编排我有个土办法数决策点。如果你的真实流程里只有一个 LLM 决策点其余全是顺序执行用函数加 if/else 就够了。图编排、状态机、对话框架解决的是决策点密集且互相影响的问题不是所有任务都需要。5.3 可观测性给每个决策点建立日志档案LLM 的问题和普通代码不一样同一个 bug代码是稳定复现的LLM 可能是概率性出现而且上一次复现时的输入输出已经不可见了。所以所有关键决策点必须留日志而且要留结构化日志。我在项目里用的决策日志结构大致长这样{ node_id: intent_classification, decision_maker: llm, model: gpt-4o, prompt_version: v3, input_snapshot: 用户消息摘要, output: COMPLAINT, logprobs: 0.82, token_usage: 1250, next_action: route_to_human_review, timestamp: 2025-06-01T10:30:00Z }这样每一条决策都有据可查。排查一个事故的时候你把决策日志按时间轴拉出来很快就知道是哪个节点的模型判断出了问题还是规则分支设计错了而不是面对着一堆非结构化的聊天记录猜。5.4 换框架的姿势把流程资产和执行引擎解耦框架一定会迭代团队也会换框架这不是失败是常态。想让自己不被动核心思路是把流程定义和执行引擎分开。流程定义是你业务决策路径的语义化描述最好独立成配置或 DSL执行引擎管状态、调度、工具调用。分开以后换框架等于换一台发动机车身和内饰还是你的。我在两个项目里验证过这个思路。一个项目从 AutoGen 迁到 LangGraph流程定义文件几乎没改只重写了引擎适配层一周完成切换。还有一个项目更极端生产环境直接把脚本引擎和 Agent 引擎并存通过配置决定某个任务走哪条路灰度切流量零停服。能做到这样靠的就是当初没有把决策逻辑焊死在某个框架的 API 里。我自己选型的原则已经越来越简单先数一遍系统里的决策点看每个决策点由谁决定再去找对这类决策节点支持得最顺手的框架。框架是执行器决策模型才是灵魂。先想清楚下一步由谁决定后面每一步都会省很多力气。