第三篇编排框架的架构哲学——LangGraph vs AutoGen vs CrewAI vs LlamaIndex Workflows本篇核心问题选错编排框架的代价不是难用而是架构不匹配。一句话回答编排框架的本质是调度隐喻的选择——图、对话流、角色流、事件驱动。隐喻决定了你能表达什么并发、什么状态、什么恢复语义。先选隐喻再选框架最后才看生态与上手成本。3.1 四种调度隐喻图、对话流、角色流、事件驱动所有编排框架在最底层都做同一件事决定下一个 LLM/工具调用由谁执行、带着什么状态、何时结束。差别在于用什么心智模型来表达这个决定。隐喻核心抽象控制流表达状态表达并发表达恢复语义代表图Graph节点 边条件边、循环全局状态State reducer节点并行 / Sendcheckpoint 回放LangGraph对话流ConversationAgent 消息发言权分配谁下一句说共享消息历史GroupChat 内并发会话恢复AutoGen角色流Role/Pipeline角色 任务流水线顺序/层级委派任务输入输出链按任务切分并行任务级重试CrewAI事件驱动Event-driven事件 step事件派发、step 触发Context显式状态对象step 天然异步并发事件重放LlamaIndex Workflows四种隐喻不是互斥的技术路线而是四种最容易表达的系统形态图最容易表达确定性骨架中的局部自适应workflow agent 节点见第一篇 1.4。对话流最容易表达多角色协商但也最容易掩盖控制流谁说下一句由发言选择器决定调试困难。角色流最容易表达分工明确的流水线类比人类团队研究员→写手→编辑。事件驱动最容易表达异步、长时、多触发源的系统CI 触发、多渠道输入、人机混合。选型的第一个问题不是哪个功能强而是我的任务控制流在哪种隐喻下写起来最自然、读起来最清楚。3.2 LangGraphStateGraph 与消息传递3.2.1 核心抽象LangGraphLangChain 团队2024把 Agent 应用建模为持久化的状态图fromlanggraph.graphimportStateGraph,START,ENDclassState(TypedDict):task:strplan:list[str]findings:list[str]done:booldefplanner(state:State):...defresearcher(state:State):...defreviewer(state:State):...gStateGraph(State)g.add_node(planner,planner)g.add_node(researcher,researcher)g.add_node(reviewer,reviewer)g.add_edge(START,planner)g.add_edge(planner,researcher)g.add_conditional_edges(reviewer,route,{pass:END,fail:researcher})appg.compile(checkpointerMemorySaver())# 或 SqliteSaver / PostgresSaver关键构件State全局状态对象字段通过reducer合并默认覆盖Annotated[list, add]表示追加。这是状态管理的显式声明——同一个字段谁能改、怎么合并写在类型上。节点node普通函数接收 state 返回增量。节点内可以调用 LLM、工具、子图。边edge普通边与条件边按 state 路由。循环是允许的这正是 Agent 回路的表达。Checkpointer每步后持久化状态快照支持时间旅行回到任意 checkpoint 重放、断点续跑、人工介入interrupt。Send API运行时动态派生并行分支map-reduce 形态用于不确定数量的并行子任务。子图subgraph分层组织子图有自己的 state可复用。3.2.2 架构含义LangGraph 的隐含立场是Agent 应用首先是一个状态机模型只是其中的决策器。它适合控制流需要可审计每步状态可快照、可 diff需要人工介入interrupt 恢复是内建能力需要长时任务持久化 checkpointer 支持跨进程续跑需要把确定性代码与模型决策混编节点是普通函数不强依赖 LLM。代价作者综合学习曲线集中在 state 设计与 reducer 语义上state 设计不良会导致合并冲突或状态膨胀。一切皆图会让简单任务过度设计单步 RAG 用 LangGraph 是杀鸡用牛刀。调试需要工具链LangSmith 等可观测平台配合否则图内错误难定位。3.3 AutoGenGroupChat 与三层架构3.3.1 核心抽象AutoGenMicrosoft2023arXiv:2308.08155从多 Agent 对话出发ConversableAgent能收发消息、调用工具、执行代码的 Agent 基类。两个内置角色AssistantAgent生成、UserProxyAgent代表人类/执行代码。GroupChat多个 Agent 的共享会话由speaker selection机制决定下一个发言者round-robin / random / LLM 选择 / 自定义。GroupChatManager管理发言顺序、消息广播、终止条件。AutoGen 的分层0.4 版本重构后大致是Core消息传递、Agent 运行时、事件驱动 API └─ AgentChat高层GroupChat、Swarm、团队模式 └─ Extensions / Studio工具、代码执行器、可视化低代码3.3.2 架构含义AutoGen 的隐含立场是协作即对话。它把多 Agent 协作中最难的部分——“谁接着做什么”——交给了对话协议与发言选择器。它适合探索性协作研究、头脑风暴、辩论multi-agent debateDu et al., 2023, arXiv:2305.14325人机混合UserProxyAgent 天然支持人类插入代码执行场景内置代码执行与安全隔离选项。代价作者综合控制流隐式化GroupChat 的下一发言者由选择器决定系统行为难以预测调试困难这是对话隐喻的固有问题。状态即消息历史长会话上下文管理需要自行处理。死循环与空转对话风险Agent 互相确认而不推进需要明确终止协议与预算。AutoGen 最有价值的遗产是把多 Agent 协作产品化为几个简单概念Conversable、GroupChat、speaker selection。但生产系统使用它时通常会用自定义 speaker 选择器把控制流重新显式化——否则系统行为的不确定性会超过模型能力带来的收益。3.4 CrewAI角色分工与任务流水线3.4.1 核心抽象CrewAI2024以人类团队为隐喻researcherAgent(roleSenior Research Analyst,goalFind credible facts about X,backstory...,tools[search,fetch],llm...)writerAgent(roleTechnical Writer,...)reviewerAgent(roleFact Checker,...)t1Task(descriptionResearch X and produce bullet points,expected_output10 bullet points with sources,agentresearcher)t2Task(descriptionWrite the report,agentwriter,context[t1])t3Task(descriptionVerify claims,agentreviewer,context[t2])crewCrew(agents[researcher,writer,reviewer],tasks[t1,t2,t3],processProcess.sequential)# 或 Process.hierarchicalresultcrew.kickoff(inputs{topic:...})关键构件Agentrole / goal / backstory / tools / allow_delegation / memory 设置。角色提示由框架拼装。Taskdescription / expected_output / context / agent。expected_output是一个小而重要的设计——它强制任务产出可校验的形态。Crew Processsequential任务按序、前序输出注入 context或hierarchicalmanager Agent 分派与验收。Flows后期加入用装饰器表达的事件驱动工作流把 Crew 嵌入确定性代码路径解决纯角色流不可控的问题。memory / knowledge短期、长期、实体记忆与知识检索的集成。3.4.2 架构含义CrewAI 的隐含立场是分工清晰的流水线最高效角色提示role/goal/backstory本身就是行为调优手段。它适合内容生产、研究报告、营销素材等分工天然清晰的任务快速原型概念即代码researcher → writer → reviewer 直接映射团队希望少写编排代码、多写角色定义。代价作者综合角色提示的效果方差大backstory 带来的收益不稳定且难以评估归因。流水线隐喻的表达力有限复杂条件分支、循环修复、并行汇合需要用 Flows 补齐此时 CrewAI 的角色抽象与工作流抽象需要混合使用。多 Agent 默认姿态即便单 Agent 可解的任务CrewAI 的概念体系也倾向拆成多角色容易低估协调成本第四篇 4.5 的协调债务在这里是隐性成本。3.5 LlamaIndex WorkflowsRAG 深度集成3.5.1 核心抽象LlamaIndex WorkflowsLlamaIndex2024是事件驱动的编排层fromllama_index.core.workflowimportWorkflow,step,StartEvent,StopEvent,ContextclassRAGWorkflow(Workflow):stepasyncdefretrieve(self,ctx:Context,ev:StartEvent)-QueryEvent:nodesawaitindex.retrieve(ev.query)awaitctx.set(nodes,nodes)returnQueryEvent(queryev.query)stepasyncdefsynthesize(self,ctx:Context,ev:QueryEvent)-StopEvent:nodesawaitctx.get(nodes)returnStopEvent(result...)关键构件step事件驱动的处理函数声明输入事件类型与输出事件类型类型匹配即触发。Event自定义事件类型step 可同时派发多个事件并行与收集多个事件汇合。Context显式状态对象get/set跨 step 共享。与 RAG 栈的原生集成索引、检索器、查询引擎、评测器、文档处理管道都是同一生态的一等公民。3.5.2 架构含义LlamaIndex Workflows 的隐含立场是Agent 系统的主干是数据/检索管道Agent 是管道中的处理节点。它适合知识密集型应用企业 RAG、文档流水线、评测流水线需要复杂异步并发多路检索、多候选生成、并行评估已在 LlamaIndex 生态内、希望检索与编排无缝衔接。代价作者综合对工具驱动的行动类任务编码、运维没有 LangGraph 那样的状态机/恢复语义人工介入、断点续跑需自行实现。事件图的可读性依赖命名与文档step 间的事件契约一旦混乱系统行为变得隐式与 AutoGen 的问题同源只是形态不同。3.6 状态管理与容错对比能力LangGraphAutoGenCrewAILlamaIndex Workflows状态模型显式 State reducer共享消息历史任务 context 链Context 对象持久化内建 checkpointer多种后端需自行持久化会话会话/记忆可选持久化需自行持久化断点续跑内建checkpoint 恢复需自行实现任务级重试为主需自行实现人工介入内建 interruptUserProxy 天然支持任务交接点自定义时间旅行/重放支持回到 checkpoint需自行实现不支持事件重放可实现并行表达Send API / 并行节点GroupChat 内并发任务切分step 异步并发动态分支条件边 循环speaker 选择器hierarchical 委派事件路由失败重试节点级策略自定义任务级step 级可观测性LangSmith 集成日志/Studio日志需接第三方主要隐喻状态图对话角色流水线事件流作者综合的三条读表结论状态持久化与恢复是最大的分水岭。LangGraph 把它当作内建能力其他框架多需自行补齐。若你的任务长时、昂贵、需人工介入这一列比好不好用重要得多。控制流显式度递减排序图 事件 角色流水线 对话。显式度越高越容易测试与审计越低越依赖运行时调试。容错不是框架单点能力真正需要的是检测 → 重试 → 恢复 → 上报的完整链路框架只提供钩子retry policy、错误事件策略仍需自建。3.7 选型决策矩阵任务确定性 × 协作复杂度 × 部署约束 × 技术栈3.7.1 四轴决策模型轴 1任务确定性控制流能否提前写死高确定性 → 事件驱动 / 角色流水线简单、便宜低确定性 → 图 / 对话保留模型决策权轴 2协作复杂度是否真的多 Agent单 Agent 工具 → 用图的单循环或直接自建循环框架价值有限2–5 个明确角色 → 角色流水线或图中的多节点动态团队/协商 → 对话流或图 Send轴 3部署约束长时任务、需审计、需恢复 → 图 持久化 checkpointer低延迟交互 → 轻量事件驱动或自建强合规数据驻留、审批→ 需自建治理层第五篇任何框架都不自带轴 4技术栈与团队Python RAG 生态 → LlamaIndexPython LangChain 生态 / 需要细粒度控制 → LangGraph.NET/Python Microsoft 生态 → AutoGen快速原型、内容生产 → CrewAIGo/TS 主栈、自研 harness → 直接自建循环 MCP第七篇两条路径都是自建3.7.2 决策矩阵速查场景首选备选避免单 Agent 编码助手自建循环 MCPLangGraphCrewAI 多角色企业 RAG 问答含多路检索LlamaIndex WorkflowsLangGraphAutoGen GroupChat长时研究任务需断点续跑LangGraph自建 持久化无持久化的框架多角色内容生产线CrewAIFlows 包裹LangGraph纯 GroupChat探索性多 Agent 辩论/评审AutoGenLangGraph Send单一隐喻硬套强合规审批流自建 策略引擎LangGraph interrupt全自主 GroupChat低延迟交互式产品自建轻循环事件驱动重型多 Agent3.7.3 三个反模式反模式 1为 demo 选框架为生产换架构。原型期最快上手的隐喻通常是对话/角色未必是生产期需要的隐喻通常是图/事件 持久化。迁移成本被系统性低估。反模式 2用框架抽象掩盖控制回路。不知道自己的循环在哪、终止条件在哪、状态在哪只是跑起来了一个 Crew。出了问题无法归因到第一篇的五要素。作者综合框架是表达工具不是理解替代品。反模式 3用多 Agent 解决上下文问题。上下文放不下 → 拆成三个 Agent是常见做法但它引入跨 Agent 一致性问题第四篇。正确顺序是先尝试上下文压缩/检索第二篇再考虑任务拆分。本篇判断可执行清单先选调度隐喻图/对话/角色/事件再选框架把我的控制流在哪种隐喻下最清楚作为第一问。状态管理是分水岭长时/高价值任务必须有持久化、断点续跑、时间旅行或等价能力。控制流显式度是可调试性的代理指标越隐式对话选择器越依赖运行时日志与评估。框架只提供钩子容错策略自建检测、重试、恢复、上报四段链路要完整。四个轴一起看任务确定性 × 协作复杂度 × 部署约束 × 技术栈任一轴不匹配都会在生产期付出代价。警惕三个反模式demo 驱动选型、抽象掩盖回路、用多 Agent 解决上下文问题。本篇参考文献Wu et al.,AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, 2023. arXiv:2308.08155Du et al.,Improving Factuality and Reasoning in Language Models through Multiagent Debate, 2023. arXiv:2305.14325Hong et al.,MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework, 2023. arXiv:2308.00352Khattab et al.,DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines, 2023. arXiv:2310.03714LangGraph 官方文档, 访问时间 2026 年 10 月. langchain-ai.github.io/langgraphAutoGen 官方文档, 访问时间 2026 年 10 月. microsoft.github.io/autogenCrewAI 官方文档, 访问时间 2026 年 10 月. docs.crewai.comLlamaIndex Workflows 官方文档, 访问时间 2026 年 10 月. docs.llamaindex.ai