拓冰网站定制 
引子:选框架其实是选心智模型项目里刚决定要做一个 Agent,团队立刻分成三派。一派要LangGraph:“要能画图、要能中断、要能回放,状态不显示我睡不着觉。”一派要AutoGen:“用对话把角色分工搞清楚,微软背书稳,大不了跑偏了加个终止关键词。”一派干脆不用框架:“200 行就能撸完,加个框架就是加两层抽象,还得学新 API,不值当。”三派吵一下午,谁也说服不了谁。后来我想明白了——这三派其实不是在讨论技术,是在讨论心智模型。• LangGraph 派心里的 Agent 是「状态机」——业务是一张流程图,节点、边、跳转条件,画清楚才踏实• AutoGen 派心里的 Agent 是「群聊」——业务是一群同事在讨论,谁擅长什么各司其职,涌现出结果• 造轮子派心里的 Agent 是「200 行 while 循环」——业务是一个可控的最小闭环,加多余的抽象只会碍事心智模型不一样,框架选型就没法在同一个坐标系里讨论。你要先站上一个坐标系。上一篇讲了怎么把 Agent 的记忆分成 L1-L4 四层——那本质是给框架层选个「壳」。壳选错了,分层再漂亮也套不上去。这一篇要讲的就是那个「壳」——从当下最主流的三个框架里(LangGraph / AutoGen / AgentScope),给出设计取向、三角定位、以及一次真实场景的选型演练。我的路径是:为什么要用框架——先把造轮子派拦下来一分钟三张脸——LangGraph、AutoGen、AgentScope 的一句话画像 最小骨架代码一句话交代 CAMEL——书里第四个框架,不展开的理由三角定位——把书里「两条设计轴」重述成三个顶点一次选型演练——直接照书里习题的三个真实场景 A/B/C 走一遍回到我自己——Ailink 为什么选 LangGraph、OpenClaw 又为什么不用全程主素材是 Datawhale 的 Hello-Agents 第 6 章。所有引用严格标注章节,代码逐字对照原书。一、为什么要用框架:先把造轮子派拦下来一分钟《Hello-Agents》第 6.1.1 节列了四条框架的核心价值,我原封不动摆过来:提升代码复用与开发效率:一个好的框架会提供一个通用的Agent基类或执行器,它封装了智能体运行的核心循环(Agent Loop)。实现核心组件的解耦与可扩展性:模型层、工具层、记忆层分离,更换或升级任何一个组件都变得简单。标准化复杂的状态管理:上下文窗口限制、历史信息持久化、多轮对话状态跟踪等,框架提供一套强大而通用的状态管理机制。简化可观测性与调试过程:通过事件回调机制(Callbacks),在智能体生命周期的关键节点自动触发日志记录或数据上报。—— 引自《Hello-Agents》第 6 章 6.1.1 节这四条足够劝退大部分造轮子党。但我要加一条书里没明说的——新人 onboarding 速度。团队 3 个人以内,你可以造轮子,反正代码全在脑子里。团队一上到 8 人,不用框架,3 个月后没人能看懂彼此的代码。框架的隐性价值不是给能干活的人用的,是给要接手项目的下一个人用的——用标准抽象换未来的人力成本。我给一个自己用的铁律:选框架的时候先问自己一句——“我这个项目未来 6 个月是不是至少要接 3 个功能场景?”是的话选框架,不是的话就用 03 篇讲的那种 500 行小骨架。03 篇教你怎么从零撸一个 Agent,是为了理解。这一篇教你怎么选框架,是为了生产。这两件事不冲突,是先后关系。二、三张脸:LangGraph、AutoGen、AgentScope 的一句话画像《Hello-Agents》第 6.1.2 节给了一张四框架对比表(表 6.1),把 AutoGen、AgentScope、CAMEL、LangGraph 放在一起做多维对比。我在这一篇里砍掉 CAMEL(理由见下一节),留下三个主流框架。一句话画像先摆出来:框架心智模型抽象核心最擅长的场景LangGraph状态机StateGraphTypedDict状态 条件边流程复杂、需要显式控制与回放AutoGen群聊AssistantAgentGroupChat多角色协作、任务由对话涌现AgentScope消息总线MsgHubMsgAgentBase高并发、分布式、生产工程化下面每个展开 500 字左右,包含核心机制、最小骨架代码、优势/代价、2026-09 现状。2.1 LangGraph:把 Agent 建模为「状态机」LangGraph 是 LangChain 生态里独立演化出来的一支,现在已经是 LangChain-AI 组织下的一个独立项目。它的核心一句话——将智能体的执行流程建模为一种状态机(State Machine),并将其表示为有向图(Directed Graph)。在这种范式中,图的**节点(Nodes)代表一个具体的计算步骤(如调用 LLM、执行工具),而边(Edges)**则定义了从一个节点到另一个节点的跳转逻辑。这种设计的革命性之处在于它天然支持循环。—— 引自《Hello-Agents》第 6 章 6.5.1 节三个要素:共享状态、节点、边。看代码最快——这段是原书 6.5.1 节的最小骨架:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdfrom typing import TypedDict, List# 定义全局状态的数据结构class AgentState(TypedDict): messages: List[str] # 对话历史 current_task: str # 当前任务 final_answer: str # 最终答案状态就是一个TypedDict,清晰、可静态检查、可 diff。每个节点是一个读 state → 写 state的普通 Python 函数:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mddef planner_node(state: AgentState) - AgentState: 根据当前任务制定计划,并更新状态。 current_task state[current_task] plan f为任务 {current_task} 生成的计划... state[messages].append(plan) return state真正的杀手锏是条件边——一个函数看当前状态,决定下一步跳哪儿:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdfrom langgraph.graph import StateGraph, ENDworkflow StateGraph(AgentState)workflow.add_node(planner, planner_node)workflow.add_node(executor, executor_node)workflow.set_entry_point(planner)workflow.add_edge(planner, executor)workflow.add_conditional_edges( executor, should_continue, # 一个看 state 返字符串的函数 { continue_to_planner: planner, end_workflow: END })app workflow.compile()add_conditional_edges就是循环、反思、动态路由的入口。写传统的链式调用要靠层层 if,LangGraph 里就一行add_conditional_edges。天然优势:•循环原生支持——Reflection、Plan-Act-Reflect 这类需要再来一次的模式几乎为它量身定做•中断/恢复——搭配checkpointer(比如 PostgresSaver、SqliteSaver)可以断点续跑•人工介入——interrupt_before[human_review]在关键节点主动挂起,让人拍板后再往下走•可观测性——LangGraph Studio(现已随 LangGraph Platform 提供)可以时间旅行、看每步状态天然代价:• 图是显式的——需求变了就得改图,不像 AutoGen 那样调调 prompt 就行• 状态设计要提前想清楚,TypedDict加字段不难,难的是加了字段之后要不要 migrate 已有的 checkpoint• LangChain 生态债——不用 LangChain 也能用 LangGraph,但周边组件(ChatOpenAI、Tavily 之类)几乎都是 LangChain 风格,不小心就得吞下整个 LangChain2026-09 现状:langgraph1.2.12,已经跨过 1.0 稳定线,LangGraph Platform 提供托管持久化、时间旅行、Studio 可视化。API 主线跟原书一致,可以直接照书里的代码上手。2.2 AutoGen:把 Agent 建模为「群聊」AutoGen 是微软出品,原始论文 Wu et al. 2024(COLM),核心一句话——AutoGen 的核心思想是通过对话实现协作。它将多智能体系统抽象为一个由多个可对话智能体组成的群聊。开发者可以定义不同角色(如Coder,ProductManager,Tester),并设定它们之间的交互规则。任务的解决过程,就是这些智能体在群聊中通过自动化消息传递,不断对话、协作、迭代直至最终目标达成的过程。—— 引自《Hello-Agents》第 6 章 6.1.2 节AutoGen 从 0.4 版本起做过一次大重构——从单一继承设计换成了三包组合式架构:•autogen-core:底层消息、模型客户端•autogen-agentchat:高级对话式 Agent API•autogen-ext:各家模型/工具的适配器第 6.2.1 节说以 0.7.4 版本为例——书里锚定的是 2025 中的版本。截止 2026-09-22,PyPI 上的最新版本是autogen-agentchat0.7.5(2025-09-30 发布),API 与书里完全一致。最小骨架分三步——模型客户端、角色定义、组队开跑。第一步:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdfrom autogen_ext.models.openai import OpenAIChatCompletionClientdef create_openai_model_client(): 创建并配置 OpenAI 模型客户端 return OpenAIChatCompletionClient( modelos.getenv(LLM_MODEL_ID, gpt-4o), api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://api.openai.com/v1) )第二步:每个角色就是一个AssistantAgent 一段 System Message。书里那个软件开发团队案例定义了四个角色(产品经理、工程师、代码审查员、用户代理),每个的 System Message 都不到 20 行,就把职责、输出结构、跳转指令都写清楚了。System Message 就是 API——这句话是理解 AutoGen 的钥匙。第三步——组队用RoundRobinGroupChat:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdfrom autogen_agentchat.teams import RoundRobinGroupChatfrom autogen_agentchat.conditions import TextMentionTermination# 定义团队聊天和协作规则team_chat RoundRobinGroupChat( participants[ product_manager, engineer, code_reviewer, user_proxy ], termination_conditionTextMentionTermination(TERMINATE), max_turns20,)三个关键旋钮:参与者顺序决定发言先后、终止条件决定何时停(这里是关键词 “TERMINATE”)、最大轮次是安全阀。剩下的事情——谁说什么、什么时候说完、要不要接下一轮——都是从 System Message 和对话上下文里涌现出来的。天然优势:•多角色分工天然——AutoGen 里多智能体不是加法,是根设计•System Message 就是 API——业务人员或产品经理也能参与 prompt 调优,不用碰代码结构•异步优先架构——0.4 以后全面async/await,并发上限高于同步框架•微软背书 活跃维护——2025-09 还有大版本发布,生态稳天然代价:•对话难预测——RoundRobinGroupChat 是最简单的编排,一旦上Selector Group Chat或 Magentic-One 这类更复杂的编排,行为就更难在离线状态下预演•对可观测性依赖 prompt——每一步为什么这么走藏在 LLM 决策里,不像 LangGraph 的边那样一眼看穿•成本容易失控——群聊里一个消息广播给全体成员,token 消耗随成员数近似平方增长2026-09 现状:autogen-agentchat0.7.5(2025-09-30),三包架构稳定,高阶编排(Magentic-One、GraphFlow、Swarm、Selector Group Chat)已有官方文档。2.3 AgentScope:把 Agent 建模为「消息总线」AgentScope 是阿里巴巴达摩院出品,论文 arXiv:2402.14034(Gao et al. 2024)。核心一句话——AgentScope 是一个专为多智能体应用设计的、功能全面的开发平台。它的核心特点是易用性和工程化。它提供了一套非常友好的编程接口,让开发者可以轻松定义智能体、构建通信网络,并管理整个应用的生命周期。其内置的消息传递机制和对分布式部署的支持,使其非常适合构建和运维复杂、大规模的多智能体系统。—— 引自《Hello-Agents》第 6 章 6.1.2 节AgentScope 跟 AutoGen 都做多智能体,但取的路径不一样——AutoGen 走对话,AgentScope 走消息服务。抽象核心是Msg(消息)AgentBase(智能体基类)MsgHub(消息中心)。一切从Msg开始——这是原书 6.3.1 节的定义:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdfrom agentscope.message import Msg# 消息的标准结构message Msg( nameAlice, # 发送者名称 contentHello, Bob!, # 消息内容 roleuser, # 角色类型 metadata{ # 元数据信息 timestamp: 2024-01-15T10:30:00Z, message_type: text, priority: normal })看到metadata那栏没?这就是它跟 AutoGen 最大的差别——AgentScope 从设计上就把消息当可持久化、可追踪、可分发的一等公民对待,不是普通的 Python 对象。智能体的骨架也一致:继承AgentBase,实现reply:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdfrom agentscope.agents import AgentBaseclassCustomAgent(AgentBase): def__init__(self, name: str, **kwargs): super().__init__(namename, **kwargs) # 智能体初始化逻辑 defreply(self, x: Msg) - Msg: # 智能体的核心响应逻辑 response self.model(x.content) return Msg(nameself.name, contentresponse, roleassistant) defobserve(self, x: Msg) - None: # 智能体的观察逻辑(可选) self.memory.add(x)杀手锏是MsgHub——一个消息中心。协作的核心不是让 Agent A 调用 Agent B,而是在一个 MsgHub 通道里,所有 Agent 都能收到广播:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdasync with MsgHub( self.werewolves, enable_auto_broadcastTrue, announcementawait self.moderator.announce( f狼人们,请讨论今晚的击杀目标。存活玩家:{format_player_list(self.alive_players)} ),) as werewolves_hub: # 讨论阶段 for _ in range(MAX_DISCUSSION_ROUND): for wolf in self.werewolves: await wolf(structured_modelDiscussionModelCN)这段是原书 6.3.2 节三国狼人杀案例里的一个片段——狼人夜间讨论是一个动态创建的私密频道,只有狼人成员能收到消息。用 MsgHub 表达这个业务逻辑天然、干净。天然优势:•位置透明——同一个 Agent 部署在本地进程还是远程服务器,调用代码一样。生产要横向扩展的时候不用改代码•消息持久化——支持 SQLite、MongoDB 作为消息后端,状态可回放、可追踪•结构化输出约束——业务规则通过BaseModel定义,而不是靠 prompt 里的请输出 JSON•异步 并发——fanout_pipeline这类原语可以并行收集多个 Agent 的决策,场景刚需天然代价:•上手曲线更陡——不适应异步 消息驱动的人,会觉得这不像 Python,像 Erlang•过度设计的风险——如果你的业务其实是单机、串行、几个 Agent,用 AgentScope 属于给自行车装涡轮•中文文档更全,英文生态相对小——达摩院背景决定的,如果团队主要基于英文文档做技术选型,要多花时间2026-09 现状:agentscope2.0.8(2026-09-08),已经进入 2.x 大版本,相比原书写作时(1.x)API 有过重构——选型时务必对齐文档版本。arXiv:2402.14034 论文仍是理解设计哲学的最佳入口。三、一句话交代 CAMEL书里第 6.4 节还讲了 CAMEL(Li et al. NeurIPS 2023,arXiv:2303.17760)。核心范式是RolePlayingInception Prompting——为两个智能体设定角色(比如AI 研究员Python 程序员)和共同任务目标,它们在初始提示的引导下自主完成多轮对话,用CAMEL_TASK_DONE标志终止。我在这一篇不展开,只给一个定位判断——CAMEL 的价值主要在研究层面:它在 2023 年证明了两个 LLM 智能体确实可以在弱约束下自主协作,这是一个非常漂亮的学术结果。但从生产工程角度看,它更像是 AutoGen 的极简子集——AutoGen 的 System Message 定角色 RoundRobinGroupChat编排,已经覆盖了 CAMEL RolePlaying 的核心用法,而且支持多于两个智能体、支持更复杂的终止条件、支持更完整的工具集成。想读 CAMEL 完整细节的,翻《Hello-Agents》第 6 章 6.4 节——书里用AI 科普电子书案例讲了完整流程,一个心理学家 一个作家协作写书,是学习 Inception Prompting 的好例子。四、三角定位:两条轴不够,画个三角书里 6.6 小结里给了一个非常有洞见的判断:“涌现式协作’与’显式控制’之间的选择… AgentScope 则揭示了第二个同样重要的维度:工程化。无论我们选择哪种协作范式,要将其从实验原型推向生产应用,都必须面对并发、容错、分布式部署等工程挑战。”—— 引自《Hello-Agents》第 6 章 6.6 节书里给的是两条轴——涌现 vs. 显式(横轴) 工程化(纵轴)。这套在四框架分析里成立,因为 AutoGen 和 CAMEL 都在涌现这一头。这一篇砍掉了 CAMEL,只剩三个框架——两条轴就变成三个顶点更自然。我把它画成一个三角:显式状态机 LangGraph ● / \ / \ / \ / \ / \ ●───────────● AutoGen AgentScope 对话涌现 消息中心 · 工程化三个顶点各自解决的核心问题:•LangGraph → 可控性问题:业务流程复杂,要能中断、能回放、能审计。用图结构显式表达每一步。•AutoGen → 协作性问题:任务需要多个专家角色讨论出结果。用对话作为通用协议,让协作从对话中涌现。•AgentScope → 工程化问题:生产环境要高并发、要分布式、要消息可持久化。用消息中心作为总线。一个实战判断:框架不是选一个用到死,是选一个作为主结构、可能借另一个的组件。举个具体的:LangGraph 里的一个节点内部,完全可以起一个 AutoGen 的小群聊做局部头脑风暴——LangGraph 只关心这个节点吐出什么状态,内部怎么涌现出来的它不管。反过来也成立——AutoGen 的一个角色内部,可以是一个用TypedDict状态管理的确定性小流程。框架的边界不是护城河,是接口。五、一次选型演练:书里的 A/B/C 三个场景《Hello-Agents》第 6 章习题 6 给出了三个真实业务场景,让读者做框架选型。这一节我不当习题,直接当实战演练——每个场景给出我的判断和理由,以及为什么不选另外两个。书里原题这么说:假设你是一家 AI 公司的技术架构师,公司计划开发以下三个智能体产品应用,请为每个应用选择最合适的框架(AutoGen、AgentScope、CAMEL、LangGraph 或不借助框架从零开发),并详细说明理由。—— 引自《Hello-Agents》第 6 章 习题 6三个场景我一个一个来。5.1 场景 A · 智能客服(1000 QPS、7×24、水平扩展)应用 A:智能客服系统,需要处理大量并发用户请求(每秒 1000),要求响应时间低于 2 秒,系统需要 7×24 小时稳定运行,并支持水平扩展。我的选择:AgentScope。理由:这个场景的核心矛盾是吞吐 稳定 分布式。1000 QPS 单机扛不住,必须能横向扩展AgentScope 的 MsgHub 位置透明设计,让同一段业务代码,单机跑 / 多机跑这两件事在开发体验上一致消息持久化(SQLite / MongoDB)对客服场景刚好——用户投诉后能回放整段对话结构化输出约束天然适合分类工单 / 提取意图 / 转人工这种规则明确的场景为什么不选 LangGraph:LangGraph 的TypedDict状态是共享的,单机图能跑得很好,但要跨节点水平扩展,得靠 LangGraph Platform 的托管持久化或者自己接后端。你有能力做这件事,但复杂度不该在选型阶段就压上来——用一个自带分布式基因的框架,比用一个能改造成分布式的框架轻松一个数量级。为什么不选 AutoGen:对话式协作对响应时间 2s的 SLA 不友好。RoundRobinGroupChat 每轮至少要 LLM 一次调用,几个角色轮下来 5-10 秒起。用 AutoGen 做客服的路径应该是AutoGen 编排 尽量少的多轮对话,这时候你就已经在跟框架的设计哲学拧着来了。注意事项:AgentScope 2.0 起 API 有较大重构,书里的代码基于 1.x,选型时务必对齐 2.x 官方文档。5.2 场景 B · 科研写作(研究员 写作,深度协作)应用 B:科研论文辅助写作平台,需要一个研究员智能体和一个写作智能体深度协作,共同完成文献综述、实验设计、数据分析和论文撰写。要求智能体能够进行多轮深度讨论,自主推进任务。我的选择:AutoGen(如果需要严格控流,考虑 AutoGen LangGraph 混合)。理由:多角色深度讨论正是 AutoGen 的甜蜜区。System Message 定义研究员擅长文献综述“写作智能体擅长结构与语言” RoundRobinGroupChat编排论文写作的任务边界模糊——不像客服那种进来一个问题,出去一个答案,而是来回打磨、逐步收敛。这种边界模糊就是涌现式协作的用武之地更进阶的编排可以用 AutoGen v0.4 的Selector Group Chat——让一个 selector agent 决定下一步谁发言,而不是死板轮询进阶混合:如果要严格控流(比如不允许无限讨论、要能中断人工介入),外面套一层 LangGraph——把每一轮研究员写作的群聊作为 LangGraph 的一个节点,让 LangGraph 决定何时开始新一轮、何时结束、何时让人拍板。这就是我前面说的框架的边界不是护城河,是接口。为什么不选 AgentScope:场景是深度、慢速、多轮的协作,不是高并发、低延迟。选 AgentScope 你要多学一套异步范式,收益不明显。别用生产级的锤子敲原型级的钉子。为什么不用纯 LangGraph:纯 LangGraph 做这个场景,你会陷入要给每一种可能的讨论走向都画一条边的困境。任务边界模糊的场景,让对话涌现比让开发者列举更省力。5.3 场景 C · 金融风控审批(6 步流水线、每步分支、可审计)应用 C:金融风控审批系统,需要按照严格的流程处理贷款申请:资料审核 → 风险评估 → 额度计算 → 合规检查 → 人工复核 → 最终决策。每个环节都有明确的判断标准和分支逻辑,要求流程可追溯、可审计。我的选择:LangGraph。理由(这一场景的映射几乎是标准题):6 个业务步骤 → 6 个节点。add_conditional_edges处理资料不全打回补件、风险评估未过直接拒这类分支checkpointerPostgresSaver(...)存整个流程状态——每个申请单一条 checkpoint,断了能续、能回放、能审计interrupt_before[human_review]在人工复核节点主动中断,由复核员在后台拍板,复核完之后.stream(None, config, resumeTrue)继续往下走合规场景要求可解释性—— LangGraph 的图结构本身就是最佳的可解释性表达。给合规部门看一张有向图,比给他们看一段 prompt 靠谱得多为什么不选 AutoGen:业务流程 SLA 明确、每步判断标准明确、不需要涌现,反而怕涌现。合规审计不希望某个 Agent 心血来潮跳过了额度计算这一步。为什么不选 AgentScope:场景在单业务实例内串行(一个申请单一次走完),不需要分布式消息中心。而且 AgentScope 的强项在消息,这个场景强项在状态——不对味。5.4 三个场景对上三个框架的三角顶点回过头看:场景关键约束最优框架三角顶点A · 客服吞吐 分布式AgentScope消息中心 · 工程化B · 科研深度协作 涌现AutoGen对话涌现C · 风控显式流程 可审计LangGraph显式状态机这不是巧合,是设计哲学决定的。框架不是通用工具——每个框架都有它擅长的问题形状。你的任务只是识别你的场景是什么形状,然后落到对应的顶点。六、回到我自己:Ailink 为什么选 LangGraph、OpenClaw 又为什么不用前面五节都在讲书里的东西和业界通用做法。这一节回到我自己两个项目——一正一反,呼应一下前面的选型判据。6.1 Ailink 标准交付 Agent(选了 LangGraph)Ailink 的业务是 SaaS 交付。一个客户从线索接入到最终交接,业务上是固定的 8 阶段流水线——从stage_0_lead(线索接入)到stage_7_handover(最终交接),中间 6 个阶段覆盖需求澄清、合同、部署配置、试运行、培训、验收等环节。这个形状——我打赌你已经看出来了——就是场景 C 的翻版。技术选型的核心决策落在几个点上:LangChain LangGraph 组合:LangChain 用来接模型、工具、prompt 模板,LangGraph 用来把 8 阶段编排成一张 StateGraph。每阶段一个节点,阶段间用add_conditional_edges处理资料不齐打回上一阶段这类分支。PostgresSaver 做持久化:每个客户的交付流程,状态存 PostgreSQL。断了能续——某个阶段执行到一半服务重启,恢复后 Agent 从上次落盘的 checkpoint 接着跑,不用从头再来。interrupt_before[human_confirm]做人工确认:交付流程里有几个必须人工拍板的节点(合同确认、部署配置、验收),在这些节点前 Agent 主动挂起。销售或客户成功在管理后台看到Agent 已停在 X 节点,等待你的确认,拍板后流程继续。四智能体协作:Orchestrator(负责阶段调度) Chat Extractor(从客户对话里抽取结构化字段) GateKeeper(阶段跃迁准入判断) Evidence Collector(证据材料归档)。这四个不是群聊涌现,是 Orchestrator 在特定节点显式调用另外三个 —— 更像 LangGraph 里一个节点调用子图,不是 AutoGen 那种 RoundRobin。四级工具风险分级:所有工具按副作用分四级——READ_ONLY(查客户信息)、WRITE_LOW(生成配置文档、内部备注)、WRITE_HIGH(发邮件、建工单)、WRITE_CRITICAL(签合同、生产环境变更)。WRITE_CRITICAL一律进interrupt_before白名单,配合 48h/96h/144h 超时升级机制。外部集成:通过 MCP 接 Frappe(CRM / Delivery / StockFlow)和飞书;Langfuse 做全链路观测;运行在阿里云 ACK 上。为什么不选 AutoGen:交付流程 SLA 硬约束,合同签字、部署时间都写进了 SOW,不能靠对话涌现出个完成日期。每一步都要能查、能审、能续,不能让某个角色跑偏了 —— 涌现的自由度在这个场景里是负价值。为什么不选 AgentScope:单客户单实例串行处理,不需要 1000 QPS,也不需要分布式。AgentScope 的强项这里用不上。6.2 OpenClaw / 连小维(自建了 Skill 框架)OpenClaw 是我另一段经历——业务是运维排障助手,产品叫连小维。这个场景跟 Ailink 完全反过来:每次问题都不一样——CPU 打满可能是死循环、可能是 GC 抖动、可能是网络重传、可能是磁盘打满。没法预先画一张 8 阶段的图,因为下一步该干什么完全取决于上一步 tool 调用的结果。看到这里你可能会说——“这不就是 AutoGen 那种涌现式协作的场景吗?”半对半错。这个场景需要的不是多角色协作,而是单角色的、极度动态的 tool 调用循环。所以我们最后没用现成框架,自建了一个 Skill-based 框架(LiteLLM Azure GPT-5,五层架构、六个技能、L0-L3 风险分级)。自建的理由主要是三个:业务锁定强——排障有很多领域约束(SRE 手册、企业内部工具链、生产环境风控),不如做一个薄薄的自建框架把这些约束固化进抽象技能是天然抽象——排障的动作是看日志 / 看监控 / 拉线程栈 / 执行诊断脚本,这些不是Agent 角色,是Skill。用 AutoGen 的角色抽象反而拧巴对可审计性要求——生产环境每一个 tool 调用都要落到 Kafka 审计流,自建框架能把这个约束焊死在最底层这跟 03 篇讲的造轮子哲学呼应上了——造轮子不是反框架,是场景真的不匹配现有轮子。这里不用 LangGraph 是因为每步不确定,画不了图,不用 AutoGen 是因为这不是多角色场景,不用 AgentScope 是因为消息中心解决不了排障的动态性。三个都不匹配,自建就成了最优解。6.3 收尾:框架选型的终点不是哪个最好回到全篇开头那个三派吵一下午的场景。看完这一篇,你应该能把那个吵架翻译成一句话——框架选型的终点,不是哪个框架最好,是我的场景需要框架给我什么。三个框架分别给你:•LangGraph:一份流程图——能画、能改、能续、能审计•AutoGen:一群同事——会对话、会分工、会拉扯、会涌现•AgentScope:一个消息总线——能高并发、能分布式、能持久化想清楚场景要哪一个,自然就选出来了。下一篇要讲的是 Agent 之间怎么说话——MCP、A2A、ANP 三种通信协议。框架给了你抽象,协议给了你跨系统协作的语言。这两件事合起来,才是把 Agent 从能演示推到能编入组织架构的完整技术栈。参考文献[1] Wu Q, Bansal G, Zhang J, et al. AutoGen: Enabling next-gen LLM applications via multi-agent conversations. First Conference on Language Modeling (COLM), 2024.[2] Gao D, Li Z, Pan X, et al. AgentScope: A flexible yet robust multi-agent platform. arXiv preprint arXiv:2402.14034, 2024.[3] Li G, Hammoud H, Itani H, et al. CAMEL: Communicative agents for “mind” exploration of large language model society. Advances in Neural Information Processing Systems, 2023, 36: 51991-52008.[4] LangChain. LangGraph. https://github.com/langchain-ai/langgraph, 2024.版本号锚点(2026-09-22 PyPI 数据):•autogen-agentchat0.7.5(2025-09-30 发布)•agentscope2.0.8(2026-09-08 发布,2.x 大版本较原书 1.x 有 API 重构)•langgraph1.2.12(已过 1.0 稳定线,LangGraph Platform 提供托管持久化 / 时间旅行 / Studio 可视化)框架 API 演进较快,请以官方最新文档为准。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 LangGraph、AutoGen、AgentScope:三种框架、两条轴、一次选型演练
引子:选框架其实是选心智模型项目里刚决定要做一个 Agent,团队立刻分成三派。一派要LangGraph:“要能画图、要能中断、要能回放,状态不显示我睡不着觉。”一派要AutoGen:“用对话把角色分工搞清楚,微软背书稳,大不了跑偏了加个终止关键词。”一派干脆不用框架:“200 行就能撸完,加个框架就是加两层抽象,还得学新 API,不值当。”三派吵一下午,谁也说服不了谁。后来我想明白了——这三派其实不是在讨论技术,是在讨论心智模型。• LangGraph 派心里的 Agent 是「状态机」——业务是一张流程图,节点、边、跳转条件,画清楚才踏实• AutoGen 派心里的 Agent 是「群聊」——业务是一群同事在讨论,谁擅长什么各司其职,涌现出结果• 造轮子派心里的 Agent 是「200 行 while 循环」——业务是一个可控的最小闭环,加多余的抽象只会碍事心智模型不一样,框架选型就没法在同一个坐标系里讨论。你要先站上一个坐标系。上一篇讲了怎么把 Agent 的记忆分成 L1-L4 四层——那本质是给框架层选个「壳」。壳选错了,分层再漂亮也套不上去。这一篇要讲的就是那个「壳」——从当下最主流的三个框架里(LangGraph / AutoGen / AgentScope),给出设计取向、三角定位、以及一次真实场景的选型演练。我的路径是:为什么要用框架——先把造轮子派拦下来一分钟三张脸——LangGraph、AutoGen、AgentScope 的一句话画像 最小骨架代码一句话交代 CAMEL——书里第四个框架,不展开的理由三角定位——把书里「两条设计轴」重述成三个顶点一次选型演练——直接照书里习题的三个真实场景 A/B/C 走一遍回到我自己——Ailink 为什么选 LangGraph、OpenClaw 又为什么不用全程主素材是 Datawhale 的 Hello-Agents 第 6 章。所有引用严格标注章节,代码逐字对照原书。一、为什么要用框架:先把造轮子派拦下来一分钟《Hello-Agents》第 6.1.1 节列了四条框架的核心价值,我原封不动摆过来:提升代码复用与开发效率:一个好的框架会提供一个通用的Agent基类或执行器,它封装了智能体运行的核心循环(Agent Loop)。实现核心组件的解耦与可扩展性:模型层、工具层、记忆层分离,更换或升级任何一个组件都变得简单。标准化复杂的状态管理:上下文窗口限制、历史信息持久化、多轮对话状态跟踪等,框架提供一套强大而通用的状态管理机制。简化可观测性与调试过程:通过事件回调机制(Callbacks),在智能体生命周期的关键节点自动触发日志记录或数据上报。—— 引自《Hello-Agents》第 6 章 6.1.1 节这四条足够劝退大部分造轮子党。但我要加一条书里没明说的——新人 onboarding 速度。团队 3 个人以内,你可以造轮子,反正代码全在脑子里。团队一上到 8 人,不用框架,3 个月后没人能看懂彼此的代码。框架的隐性价值不是给能干活的人用的,是给要接手项目的下一个人用的——用标准抽象换未来的人力成本。我给一个自己用的铁律:选框架的时候先问自己一句——“我这个项目未来 6 个月是不是至少要接 3 个功能场景?”是的话选框架,不是的话就用 03 篇讲的那种 500 行小骨架。03 篇教你怎么从零撸一个 Agent,是为了理解。这一篇教你怎么选框架,是为了生产。这两件事不冲突,是先后关系。二、三张脸:LangGraph、AutoGen、AgentScope 的一句话画像《Hello-Agents》第 6.1.2 节给了一张四框架对比表(表 6.1),把 AutoGen、AgentScope、CAMEL、LangGraph 放在一起做多维对比。我在这一篇里砍掉 CAMEL(理由见下一节),留下三个主流框架。一句话画像先摆出来:框架心智模型抽象核心最擅长的场景LangGraph状态机StateGraphTypedDict状态 条件边流程复杂、需要显式控制与回放AutoGen群聊AssistantAgentGroupChat多角色协作、任务由对话涌现AgentScope消息总线MsgHubMsgAgentBase高并发、分布式、生产工程化下面每个展开 500 字左右,包含核心机制、最小骨架代码、优势/代价、2026-09 现状。2.1 LangGraph:把 Agent 建模为「状态机」LangGraph 是 LangChain 生态里独立演化出来的一支,现在已经是 LangChain-AI 组织下的一个独立项目。它的核心一句话——将智能体的执行流程建模为一种状态机(State Machine),并将其表示为有向图(Directed Graph)。在这种范式中,图的**节点(Nodes)代表一个具体的计算步骤(如调用 LLM、执行工具),而边(Edges)**则定义了从一个节点到另一个节点的跳转逻辑。这种设计的革命性之处在于它天然支持循环。—— 引自《Hello-Agents》第 6 章 6.5.1 节三个要素:共享状态、节点、边。看代码最快——这段是原书 6.5.1 节的最小骨架:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdfrom typing import TypedDict, List# 定义全局状态的数据结构class AgentState(TypedDict): messages: List[str] # 对话历史 current_task: str # 当前任务 final_answer: str # 最终答案状态就是一个TypedDict,清晰、可静态检查、可 diff。每个节点是一个读 state → 写 state的普通 Python 函数:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mddef planner_node(state: AgentState) - AgentState: 根据当前任务制定计划,并更新状态。 current_task state[current_task] plan f为任务 {current_task} 生成的计划... state[messages].append(plan) return state真正的杀手锏是条件边——一个函数看当前状态,决定下一步跳哪儿:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdfrom langgraph.graph import StateGraph, ENDworkflow StateGraph(AgentState)workflow.add_node(planner, planner_node)workflow.add_node(executor, executor_node)workflow.set_entry_point(planner)workflow.add_edge(planner, executor)workflow.add_conditional_edges( executor, should_continue, # 一个看 state 返字符串的函数 { continue_to_planner: planner, end_workflow: END })app workflow.compile()add_conditional_edges就是循环、反思、动态路由的入口。写传统的链式调用要靠层层 if,LangGraph 里就一行add_conditional_edges。天然优势:•循环原生支持——Reflection、Plan-Act-Reflect 这类需要再来一次的模式几乎为它量身定做•中断/恢复——搭配checkpointer(比如 PostgresSaver、SqliteSaver)可以断点续跑•人工介入——interrupt_before[human_review]在关键节点主动挂起,让人拍板后再往下走•可观测性——LangGraph Studio(现已随 LangGraph Platform 提供)可以时间旅行、看每步状态天然代价:• 图是显式的——需求变了就得改图,不像 AutoGen 那样调调 prompt 就行• 状态设计要提前想清楚,TypedDict加字段不难,难的是加了字段之后要不要 migrate 已有的 checkpoint• LangChain 生态债——不用 LangChain 也能用 LangGraph,但周边组件(ChatOpenAI、Tavily 之类)几乎都是 LangChain 风格,不小心就得吞下整个 LangChain2026-09 现状:langgraph1.2.12,已经跨过 1.0 稳定线,LangGraph Platform 提供托管持久化、时间旅行、Studio 可视化。API 主线跟原书一致,可以直接照书里的代码上手。2.2 AutoGen:把 Agent 建模为「群聊」AutoGen 是微软出品,原始论文 Wu et al. 2024(COLM),核心一句话——AutoGen 的核心思想是通过对话实现协作。它将多智能体系统抽象为一个由多个可对话智能体组成的群聊。开发者可以定义不同角色(如Coder,ProductManager,Tester),并设定它们之间的交互规则。任务的解决过程,就是这些智能体在群聊中通过自动化消息传递,不断对话、协作、迭代直至最终目标达成的过程。—— 引自《Hello-Agents》第 6 章 6.1.2 节AutoGen 从 0.4 版本起做过一次大重构——从单一继承设计换成了三包组合式架构:•autogen-core:底层消息、模型客户端•autogen-agentchat:高级对话式 Agent API•autogen-ext:各家模型/工具的适配器第 6.2.1 节说以 0.7.4 版本为例——书里锚定的是 2025 中的版本。截止 2026-09-22,PyPI 上的最新版本是autogen-agentchat0.7.5(2025-09-30 发布),API 与书里完全一致。最小骨架分三步——模型客户端、角色定义、组队开跑。第一步:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdfrom autogen_ext.models.openai import OpenAIChatCompletionClientdef create_openai_model_client(): 创建并配置 OpenAI 模型客户端 return OpenAIChatCompletionClient( modelos.getenv(LLM_MODEL_ID, gpt-4o), api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://api.openai.com/v1) )第二步:每个角色就是一个AssistantAgent 一段 System Message。书里那个软件开发团队案例定义了四个角色(产品经理、工程师、代码审查员、用户代理),每个的 System Message 都不到 20 行,就把职责、输出结构、跳转指令都写清楚了。System Message 就是 API——这句话是理解 AutoGen 的钥匙。第三步——组队用RoundRobinGroupChat:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdfrom autogen_agentchat.teams import RoundRobinGroupChatfrom autogen_agentchat.conditions import TextMentionTermination# 定义团队聊天和协作规则team_chat RoundRobinGroupChat( participants[ product_manager, engineer, code_reviewer, user_proxy ], termination_conditionTextMentionTermination(TERMINATE), max_turns20,)三个关键旋钮:参与者顺序决定发言先后、终止条件决定何时停(这里是关键词 “TERMINATE”)、最大轮次是安全阀。剩下的事情——谁说什么、什么时候说完、要不要接下一轮——都是从 System Message 和对话上下文里涌现出来的。天然优势:•多角色分工天然——AutoGen 里多智能体不是加法,是根设计•System Message 就是 API——业务人员或产品经理也能参与 prompt 调优,不用碰代码结构•异步优先架构——0.4 以后全面async/await,并发上限高于同步框架•微软背书 活跃维护——2025-09 还有大版本发布,生态稳天然代价:•对话难预测——RoundRobinGroupChat 是最简单的编排,一旦上Selector Group Chat或 Magentic-One 这类更复杂的编排,行为就更难在离线状态下预演•对可观测性依赖 prompt——每一步为什么这么走藏在 LLM 决策里,不像 LangGraph 的边那样一眼看穿•成本容易失控——群聊里一个消息广播给全体成员,token 消耗随成员数近似平方增长2026-09 现状:autogen-agentchat0.7.5(2025-09-30),三包架构稳定,高阶编排(Magentic-One、GraphFlow、Swarm、Selector Group Chat)已有官方文档。2.3 AgentScope:把 Agent 建模为「消息总线」AgentScope 是阿里巴巴达摩院出品,论文 arXiv:2402.14034(Gao et al. 2024)。核心一句话——AgentScope 是一个专为多智能体应用设计的、功能全面的开发平台。它的核心特点是易用性和工程化。它提供了一套非常友好的编程接口,让开发者可以轻松定义智能体、构建通信网络,并管理整个应用的生命周期。其内置的消息传递机制和对分布式部署的支持,使其非常适合构建和运维复杂、大规模的多智能体系统。—— 引自《Hello-Agents》第 6 章 6.1.2 节AgentScope 跟 AutoGen 都做多智能体,但取的路径不一样——AutoGen 走对话,AgentScope 走消息服务。抽象核心是Msg(消息)AgentBase(智能体基类)MsgHub(消息中心)。一切从Msg开始——这是原书 6.3.1 节的定义:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdfrom agentscope.message import Msg# 消息的标准结构message Msg( nameAlice, # 发送者名称 contentHello, Bob!, # 消息内容 roleuser, # 角色类型 metadata{ # 元数据信息 timestamp: 2024-01-15T10:30:00Z, message_type: text, priority: normal })看到metadata那栏没?这就是它跟 AutoGen 最大的差别——AgentScope 从设计上就把消息当可持久化、可追踪、可分发的一等公民对待,不是普通的 Python 对象。智能体的骨架也一致:继承AgentBase,实现reply:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdfrom agentscope.agents import AgentBaseclassCustomAgent(AgentBase): def__init__(self, name: str, **kwargs): super().__init__(namename, **kwargs) # 智能体初始化逻辑 defreply(self, x: Msg) - Msg: # 智能体的核心响应逻辑 response self.model(x.content) return Msg(nameself.name, contentresponse, roleassistant) defobserve(self, x: Msg) - None: # 智能体的观察逻辑(可选) self.memory.add(x)杀手锏是MsgHub——一个消息中心。协作的核心不是让 Agent A 调用 Agent B,而是在一个 MsgHub 通道里,所有 Agent 都能收到广播:# 来源:datawhalechina/hello-agents · docs/chapter6/第六章 框架开发实践.mdasync with MsgHub( self.werewolves, enable_auto_broadcastTrue, announcementawait self.moderator.announce( f狼人们,请讨论今晚的击杀目标。存活玩家:{format_player_list(self.alive_players)} ),) as werewolves_hub: # 讨论阶段 for _ in range(MAX_DISCUSSION_ROUND): for wolf in self.werewolves: await wolf(structured_modelDiscussionModelCN)这段是原书 6.3.2 节三国狼人杀案例里的一个片段——狼人夜间讨论是一个动态创建的私密频道,只有狼人成员能收到消息。用 MsgHub 表达这个业务逻辑天然、干净。天然优势:•位置透明——同一个 Agent 部署在本地进程还是远程服务器,调用代码一样。生产要横向扩展的时候不用改代码•消息持久化——支持 SQLite、MongoDB 作为消息后端,状态可回放、可追踪•结构化输出约束——业务规则通过BaseModel定义,而不是靠 prompt 里的请输出 JSON•异步 并发——fanout_pipeline这类原语可以并行收集多个 Agent 的决策,场景刚需天然代价:•上手曲线更陡——不适应异步 消息驱动的人,会觉得这不像 Python,像 Erlang•过度设计的风险——如果你的业务其实是单机、串行、几个 Agent,用 AgentScope 属于给自行车装涡轮•中文文档更全,英文生态相对小——达摩院背景决定的,如果团队主要基于英文文档做技术选型,要多花时间2026-09 现状:agentscope2.0.8(2026-09-08),已经进入 2.x 大版本,相比原书写作时(1.x)API 有过重构——选型时务必对齐文档版本。arXiv:2402.14034 论文仍是理解设计哲学的最佳入口。三、一句话交代 CAMEL书里第 6.4 节还讲了 CAMEL(Li et al. NeurIPS 2023,arXiv:2303.17760)。核心范式是RolePlayingInception Prompting——为两个智能体设定角色(比如AI 研究员Python 程序员)和共同任务目标,它们在初始提示的引导下自主完成多轮对话,用CAMEL_TASK_DONE标志终止。我在这一篇不展开,只给一个定位判断——CAMEL 的价值主要在研究层面:它在 2023 年证明了两个 LLM 智能体确实可以在弱约束下自主协作,这是一个非常漂亮的学术结果。但从生产工程角度看,它更像是 AutoGen 的极简子集——AutoGen 的 System Message 定角色 RoundRobinGroupChat编排,已经覆盖了 CAMEL RolePlaying 的核心用法,而且支持多于两个智能体、支持更复杂的终止条件、支持更完整的工具集成。想读 CAMEL 完整细节的,翻《Hello-Agents》第 6 章 6.4 节——书里用AI 科普电子书案例讲了完整流程,一个心理学家 一个作家协作写书,是学习 Inception Prompting 的好例子。四、三角定位:两条轴不够,画个三角书里 6.6 小结里给了一个非常有洞见的判断:“涌现式协作’与’显式控制’之间的选择… AgentScope 则揭示了第二个同样重要的维度:工程化。无论我们选择哪种协作范式,要将其从实验原型推向生产应用,都必须面对并发、容错、分布式部署等工程挑战。”—— 引自《Hello-Agents》第 6 章 6.6 节书里给的是两条轴——涌现 vs. 显式(横轴) 工程化(纵轴)。这套在四框架分析里成立,因为 AutoGen 和 CAMEL 都在涌现这一头。这一篇砍掉了 CAMEL,只剩三个框架——两条轴就变成三个顶点更自然。我把它画成一个三角:显式状态机 LangGraph ● / \ / \ / \ / \ / \ ●───────────● AutoGen AgentScope 对话涌现 消息中心 · 工程化三个顶点各自解决的核心问题:•LangGraph → 可控性问题:业务流程复杂,要能中断、能回放、能审计。用图结构显式表达每一步。•AutoGen → 协作性问题:任务需要多个专家角色讨论出结果。用对话作为通用协议,让协作从对话中涌现。•AgentScope → 工程化问题:生产环境要高并发、要分布式、要消息可持久化。用消息中心作为总线。一个实战判断:框架不是选一个用到死,是选一个作为主结构、可能借另一个的组件。举个具体的:LangGraph 里的一个节点内部,完全可以起一个 AutoGen 的小群聊做局部头脑风暴——LangGraph 只关心这个节点吐出什么状态,内部怎么涌现出来的它不管。反过来也成立——AutoGen 的一个角色内部,可以是一个用TypedDict状态管理的确定性小流程。框架的边界不是护城河,是接口。五、一次选型演练:书里的 A/B/C 三个场景《Hello-Agents》第 6 章习题 6 给出了三个真实业务场景,让读者做框架选型。这一节我不当习题,直接当实战演练——每个场景给出我的判断和理由,以及为什么不选另外两个。书里原题这么说:假设你是一家 AI 公司的技术架构师,公司计划开发以下三个智能体产品应用,请为每个应用选择最合适的框架(AutoGen、AgentScope、CAMEL、LangGraph 或不借助框架从零开发),并详细说明理由。—— 引自《Hello-Agents》第 6 章 习题 6三个场景我一个一个来。5.1 场景 A · 智能客服(1000 QPS、7×24、水平扩展)应用 A:智能客服系统,需要处理大量并发用户请求(每秒 1000),要求响应时间低于 2 秒,系统需要 7×24 小时稳定运行,并支持水平扩展。我的选择:AgentScope。理由:这个场景的核心矛盾是吞吐 稳定 分布式。1000 QPS 单机扛不住,必须能横向扩展AgentScope 的 MsgHub 位置透明设计,让同一段业务代码,单机跑 / 多机跑这两件事在开发体验上一致消息持久化(SQLite / MongoDB)对客服场景刚好——用户投诉后能回放整段对话结构化输出约束天然适合分类工单 / 提取意图 / 转人工这种规则明确的场景为什么不选 LangGraph:LangGraph 的TypedDict状态是共享的,单机图能跑得很好,但要跨节点水平扩展,得靠 LangGraph Platform 的托管持久化或者自己接后端。你有能力做这件事,但复杂度不该在选型阶段就压上来——用一个自带分布式基因的框架,比用一个能改造成分布式的框架轻松一个数量级。为什么不选 AutoGen:对话式协作对响应时间 2s的 SLA 不友好。RoundRobinGroupChat 每轮至少要 LLM 一次调用,几个角色轮下来 5-10 秒起。用 AutoGen 做客服的路径应该是AutoGen 编排 尽量少的多轮对话,这时候你就已经在跟框架的设计哲学拧着来了。注意事项:AgentScope 2.0 起 API 有较大重构,书里的代码基于 1.x,选型时务必对齐 2.x 官方文档。5.2 场景 B · 科研写作(研究员 写作,深度协作)应用 B:科研论文辅助写作平台,需要一个研究员智能体和一个写作智能体深度协作,共同完成文献综述、实验设计、数据分析和论文撰写。要求智能体能够进行多轮深度讨论,自主推进任务。我的选择:AutoGen(如果需要严格控流,考虑 AutoGen LangGraph 混合)。理由:多角色深度讨论正是 AutoGen 的甜蜜区。System Message 定义研究员擅长文献综述“写作智能体擅长结构与语言” RoundRobinGroupChat编排论文写作的任务边界模糊——不像客服那种进来一个问题,出去一个答案,而是来回打磨、逐步收敛。这种边界模糊就是涌现式协作的用武之地更进阶的编排可以用 AutoGen v0.4 的Selector Group Chat——让一个 selector agent 决定下一步谁发言,而不是死板轮询进阶混合:如果要严格控流(比如不允许无限讨论、要能中断人工介入),外面套一层 LangGraph——把每一轮研究员写作的群聊作为 LangGraph 的一个节点,让 LangGraph 决定何时开始新一轮、何时结束、何时让人拍板。这就是我前面说的框架的边界不是护城河,是接口。为什么不选 AgentScope:场景是深度、慢速、多轮的协作,不是高并发、低延迟。选 AgentScope 你要多学一套异步范式,收益不明显。别用生产级的锤子敲原型级的钉子。为什么不用纯 LangGraph:纯 LangGraph 做这个场景,你会陷入要给每一种可能的讨论走向都画一条边的困境。任务边界模糊的场景,让对话涌现比让开发者列举更省力。5.3 场景 C · 金融风控审批(6 步流水线、每步分支、可审计)应用 C:金融风控审批系统,需要按照严格的流程处理贷款申请:资料审核 → 风险评估 → 额度计算 → 合规检查 → 人工复核 → 最终决策。每个环节都有明确的判断标准和分支逻辑,要求流程可追溯、可审计。我的选择:LangGraph。理由(这一场景的映射几乎是标准题):6 个业务步骤 → 6 个节点。add_conditional_edges处理资料不全打回补件、风险评估未过直接拒这类分支checkpointerPostgresSaver(...)存整个流程状态——每个申请单一条 checkpoint,断了能续、能回放、能审计interrupt_before[human_review]在人工复核节点主动中断,由复核员在后台拍板,复核完之后.stream(None, config, resumeTrue)继续往下走合规场景要求可解释性—— LangGraph 的图结构本身就是最佳的可解释性表达。给合规部门看一张有向图,比给他们看一段 prompt 靠谱得多为什么不选 AutoGen:业务流程 SLA 明确、每步判断标准明确、不需要涌现,反而怕涌现。合规审计不希望某个 Agent 心血来潮跳过了额度计算这一步。为什么不选 AgentScope:场景在单业务实例内串行(一个申请单一次走完),不需要分布式消息中心。而且 AgentScope 的强项在消息,这个场景强项在状态——不对味。5.4 三个场景对上三个框架的三角顶点回过头看:场景关键约束最优框架三角顶点A · 客服吞吐 分布式AgentScope消息中心 · 工程化B · 科研深度协作 涌现AutoGen对话涌现C · 风控显式流程 可审计LangGraph显式状态机这不是巧合,是设计哲学决定的。框架不是通用工具——每个框架都有它擅长的问题形状。你的任务只是识别你的场景是什么形状,然后落到对应的顶点。六、回到我自己:Ailink 为什么选 LangGraph、OpenClaw 又为什么不用前面五节都在讲书里的东西和业界通用做法。这一节回到我自己两个项目——一正一反,呼应一下前面的选型判据。6.1 Ailink 标准交付 Agent(选了 LangGraph)Ailink 的业务是 SaaS 交付。一个客户从线索接入到最终交接,业务上是固定的 8 阶段流水线——从stage_0_lead(线索接入)到stage_7_handover(最终交接),中间 6 个阶段覆盖需求澄清、合同、部署配置、试运行、培训、验收等环节。这个形状——我打赌你已经看出来了——就是场景 C 的翻版。技术选型的核心决策落在几个点上:LangChain LangGraph 组合:LangChain 用来接模型、工具、prompt 模板,LangGraph 用来把 8 阶段编排成一张 StateGraph。每阶段一个节点,阶段间用add_conditional_edges处理资料不齐打回上一阶段这类分支。PostgresSaver 做持久化:每个客户的交付流程,状态存 PostgreSQL。断了能续——某个阶段执行到一半服务重启,恢复后 Agent 从上次落盘的 checkpoint 接着跑,不用从头再来。interrupt_before[human_confirm]做人工确认:交付流程里有几个必须人工拍板的节点(合同确认、部署配置、验收),在这些节点前 Agent 主动挂起。销售或客户成功在管理后台看到Agent 已停在 X 节点,等待你的确认,拍板后流程继续。四智能体协作:Orchestrator(负责阶段调度) Chat Extractor(从客户对话里抽取结构化字段) GateKeeper(阶段跃迁准入判断) Evidence Collector(证据材料归档)。这四个不是群聊涌现,是 Orchestrator 在特定节点显式调用另外三个 —— 更像 LangGraph 里一个节点调用子图,不是 AutoGen 那种 RoundRobin。四级工具风险分级:所有工具按副作用分四级——READ_ONLY(查客户信息)、WRITE_LOW(生成配置文档、内部备注)、WRITE_HIGH(发邮件、建工单)、WRITE_CRITICAL(签合同、生产环境变更)。WRITE_CRITICAL一律进interrupt_before白名单,配合 48h/96h/144h 超时升级机制。外部集成:通过 MCP 接 Frappe(CRM / Delivery / StockFlow)和飞书;Langfuse 做全链路观测;运行在阿里云 ACK 上。为什么不选 AutoGen:交付流程 SLA 硬约束,合同签字、部署时间都写进了 SOW,不能靠对话涌现出个完成日期。每一步都要能查、能审、能续,不能让某个角色跑偏了 —— 涌现的自由度在这个场景里是负价值。为什么不选 AgentScope:单客户单实例串行处理,不需要 1000 QPS,也不需要分布式。AgentScope 的强项这里用不上。6.2 OpenClaw / 连小维(自建了 Skill 框架)OpenClaw 是我另一段经历——业务是运维排障助手,产品叫连小维。这个场景跟 Ailink 完全反过来:每次问题都不一样——CPU 打满可能是死循环、可能是 GC 抖动、可能是网络重传、可能是磁盘打满。没法预先画一张 8 阶段的图,因为下一步该干什么完全取决于上一步 tool 调用的结果。看到这里你可能会说——“这不就是 AutoGen 那种涌现式协作的场景吗?”半对半错。这个场景需要的不是多角色协作,而是单角色的、极度动态的 tool 调用循环。所以我们最后没用现成框架,自建了一个 Skill-based 框架(LiteLLM Azure GPT-5,五层架构、六个技能、L0-L3 风险分级)。自建的理由主要是三个:业务锁定强——排障有很多领域约束(SRE 手册、企业内部工具链、生产环境风控),不如做一个薄薄的自建框架把这些约束固化进抽象技能是天然抽象——排障的动作是看日志 / 看监控 / 拉线程栈 / 执行诊断脚本,这些不是Agent 角色,是Skill。用 AutoGen 的角色抽象反而拧巴对可审计性要求——生产环境每一个 tool 调用都要落到 Kafka 审计流,自建框架能把这个约束焊死在最底层这跟 03 篇讲的造轮子哲学呼应上了——造轮子不是反框架,是场景真的不匹配现有轮子。这里不用 LangGraph 是因为每步不确定,画不了图,不用 AutoGen 是因为这不是多角色场景,不用 AgentScope 是因为消息中心解决不了排障的动态性。三个都不匹配,自建就成了最优解。6.3 收尾:框架选型的终点不是哪个最好回到全篇开头那个三派吵一下午的场景。看完这一篇,你应该能把那个吵架翻译成一句话——框架选型的终点,不是哪个框架最好,是我的场景需要框架给我什么。三个框架分别给你:•LangGraph:一份流程图——能画、能改、能续、能审计•AutoGen:一群同事——会对话、会分工、会拉扯、会涌现•AgentScope:一个消息总线——能高并发、能分布式、能持久化想清楚场景要哪一个,自然就选出来了。下一篇要讲的是 Agent 之间怎么说话——MCP、A2A、ANP 三种通信协议。框架给了你抽象,协议给了你跨系统协作的语言。这两件事合起来,才是把 Agent 从能演示推到能编入组织架构的完整技术栈。参考文献[1] Wu Q, Bansal G, Zhang J, et al. AutoGen: Enabling next-gen LLM applications via multi-agent conversations. First Conference on Language Modeling (COLM), 2024.[2] Gao D, Li Z, Pan X, et al. AgentScope: A flexible yet robust multi-agent platform. arXiv preprint arXiv:2402.14034, 2024.[3] Li G, Hammoud H, Itani H, et al. CAMEL: Communicative agents for “mind” exploration of large language model society. Advances in Neural Information Processing Systems, 2023, 36: 51991-52008.[4] LangChain. LangGraph. https://github.com/langchain-ai/langgraph, 2024.版本号锚点(2026-09-22 PyPI 数据):•autogen-agentchat0.7.5(2025-09-30 发布)•agentscope2.0.8(2026-09-08 发布,2.x 大版本较原书 1.x 有 API 重构)•langgraph1.2.12(已过 1.0 稳定线,LangGraph Platform 提供托管持久化 / 时间旅行 / Studio 可视化)框架 API 演进较快,请以官方最新文档为准。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】