企业官网建设流程全解析

引子:选框架其实是选心智模型

项目里刚决定要做一个 Agent,团队立刻分成三派。

一派要LangGraph:“要能画图、要能中断、要能回放,状态不显示我睡不着觉。”

一派要AutoGen:“用对话把角色分工搞清楚,微软背书稳,大不了跑偏了加个终止关键词。”

一派干脆不用框架:“200 行就能撸完,加个框架就是加两层抽象,还得学新 API,不值当。”

三派吵一下午,谁也说服不了谁。

后来我想明白了——这三派其实不是在讨论技术,是在讨论心智模型。

• • LangGraph 派心里的 Agent 是「状态机」——业务是一张流程图,节点、边、跳转条件,画清楚才踏实
• • AutoGen 派心里的 Agent 是「群聊」——业务是一群同事在讨论,谁擅长什么各司其职,涌现出结果
• • 造轮子派心里的 Agent 是「200 行 while 循环」——业务是一个可控的最小闭环,加多余的抽象只会碍事

心智模型不一样,框架选型就没法在同一个坐标系里讨论。你要先站上一个坐标系。

上一篇讲了怎么把 Agent 的记忆分成 L1-L4 四层——那本质是给框架层选个「壳」。壳选错了,分层再漂亮也套不上去。这一篇要讲的就是那个「壳」——从当下最主流的三个框架里(LangGraph / AutoGen / AgentScope),给出设计取向、三角定位、以及一次真实场景的选型演练。

我的路径是:

1. 1. 为什么要用框架——先把造轮子派拦下来一分钟
2. 2. 三张脸——LangGraph、AutoGen、AgentScope 的一句话画像 + 最小骨架代码
3. 3. 一句话交代 CAMEL——书里第四个框架,不展开的理由
4. 4. 三角定位——把书里「两条设计轴」重述成三个顶点
5. 5. 一次选型演练——直接照书里习题的三个真实场景 A/B/C 走一遍
6. 6. 回到我自己——Ailink 为什么选 LangGraph、OpenClaw 又为什么不用

全程主素材是 Datawhale 的 Hello-Agents 第 6 章。所有引用严格标注章节,代码逐字对照原书。

一、为什么要用框架:先把造轮子派拦下来一分钟

《Hello-Agents》第 6.1.1 节列了四条框架的核心价值,我原封不动摆过来:

1. 1. 提升代码复用与开发效率:一个好的框架会提供一个通用的Agent基类或执行器,它封装了智能体运行的核心循环(Agent Loop)。
2. 2. 实现核心组件的解耦与可扩展性:模型层、工具层、记忆层分离,更换或升级任何一个组件都变得简单。
3. 3. 标准化复杂的状态管理:上下文窗口限制、历史信息持久化、多轮对话状态跟踪等,框架提供一套强大而通用的状态管理机制。
4. 4. 简化可观测性与调试过程:通过事件回调机制(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(理由见下一节),留下三个主流框架。

一句话画像先摆出来:

下面每个展开 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 风格,不小心就得吞下整个 LangChain

2026-09 现状:langgraph==1.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-agentchat==0.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( model=os.getenv("LLM_MODEL_ID", "gpt-4o"), api_key=os.getenv("LLM_API_KEY"), base_url=os.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_condition=TextMentionTermination("TERMINATE"), max_turns=20,)

三个关键旋钮:参与者顺序决定发言先后、终止条件决定何时停(这里是关键词 “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-agentchat==0.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( name="Alice", # 发送者名称 content="Hello, Bob!", # 消息内容 role="user", # 角色类型 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__(name=name, **kwargs) # 智能体初始化逻辑 defreply(self, x: Msg) -> Msg: # 智能体的核心响应逻辑 response = self.model(x.content) return Msg(name=self.name, content=response, role="assistant") 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_broadcast=True, announcement=await 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_model=DiscussionModelCN)

这段是原书 6.3.2 节"三国狼人杀"案例里的一个片段——狼人夜间讨论是一个动态创建的私密频道,只有狼人成员能收到消息。用 MsgHub 表达这个业务逻辑天然、干净。

天然优势:

• •位置透明——同一个 Agent 部署在本地进程还是远程服务器,调用代码一样。生产要横向扩展的时候不用改代码
• •消息持久化——支持 SQLite、MongoDB 作为消息后端,状态可回放、可追踪
• •结构化输出约束——业务规则通过BaseModel定义,而不是靠 prompt 里的请输出 JSON
• •异步 + 并发——fanout_pipeline这类原语可以并行收集多个 Agent 的决策,场景刚需

天然代价:

• •上手曲线更陡——不适应异步 + 消息驱动的人,会觉得"这不像 Python,像 Erlang"
• •过度设计的风险——如果你的业务其实是单机、串行、几个 Agent,用 AgentScope 属于给自行车装涡轮
• •中文文档更全,英文生态相对小——达摩院背景决定的,如果团队主要基于英文文档做技术选型,要多花时间

2026-09 现状:agentscope==2.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)。核心范式是RolePlaying+Inception 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。

理由:

1. 1. 这个场景的核心矛盾是吞吐 + 稳定 + 分布式。1000+ QPS 单机扛不住,必须能横向扩展
2. 2. AgentScope 的 MsgHub + 位置透明设计,让"同一段业务代码,单机跑 / 多机跑"这两件事在开发体验上一致
3. 3. 消息持久化(SQLite / MongoDB)对客服场景刚好——用户投诉后能回放整段对话
4. 4. 结构化输出约束天然适合"分类工单 / 提取意图 / 转人工"这种规则明确的场景

为什么不选 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 混合)。

理由:

1. 1. 多角色深度讨论正是 AutoGen 的甜蜜区。System Message 定义"研究员擅长文献综述"+“写作智能体擅长结构与语言” +RoundRobinGroupChat编排
2. 2. 论文写作的任务边界模糊——不像客服那种"进来一个问题,出去一个答案",而是"来回打磨、逐步收敛"。这种"边界模糊"就是"涌现式协作"的用武之地
3. 3. 更进阶的编排可以用 AutoGen v0.4+ 的Selector Group Chat——让一个 selector agent 决定下一步谁发言,而不是死板轮询

进阶混合:如果要严格控流(比如不允许无限讨论、要能中断人工介入),外面套一层 LangGraph——把每一轮"研究员+写作"的群聊作为 LangGraph 的一个节点,让 LangGraph 决定何时开始新一轮、何时结束、何时让人拍板。这就是我前面说的"框架的边界不是护城河,是接口"。

为什么不选 AgentScope:场景是深度、慢速、多轮的协作,不是高并发、低延迟。选 AgentScope 你要多学一套异步范式,收益不明显。别用生产级的锤子敲原型级的钉子。

为什么不用纯 LangGraph:纯 LangGraph 做这个场景,你会陷入"要给每一种可能的讨论走向都画一条边"的困境。任务边界模糊的场景,让对话涌现比让开发者列举更省力。

5.3 场景 C · 金融风控审批(6 步流水线、每步分支、可审计)

应用 C:金融风控审批系统,需要按照严格的流程处理贷款申请:资料审核 → 风险评估 → 额度计算 → 合规检查 → 人工复核 → 最终决策。每个环节都有明确的判断标准和分支逻辑,要求流程可追溯、可审计。

我的选择:LangGraph。

理由(这一场景的映射几乎是"标准题"):

1. 1. 6 个业务步骤 → 6 个节点。add_conditional_edges处理"资料不全打回补件"、"风险评估未过直接拒"这类分支
2. 2. checkpointer=PostgresSaver(...)存整个流程状态——每个申请单一条 checkpoint,断了能续、能回放、能审计
3. 3. interrupt_before=["human_review"]在人工复核节点主动中断,由复核员在后台拍板,复核完之后.stream(None, config, resume=True)继续往下走
4. 4. 合规场景要求可解释性—— LangGraph 的图结构本身就是最佳的可解释性表达。给合规部门看一张有向图,比给他们看一段 prompt 靠谱得多

为什么不选 AutoGen:业务流程 SLA 明确、每步判断标准明确、不需要涌现,反而怕涌现。合规审计不希望"某个 Agent 心血来潮跳过了额度计算这一步"。

为什么不选 AgentScope:场景在单业务实例内串行(一个申请单一次走完),不需要分布式消息中心。而且 AgentScope 的强项在"消息",这个场景强项在"状态"——不对味。

5.4 三个场景对上三个框架的三角顶点

回过头看:

这不是巧合,是设计哲学决定的。框架不是通用工具——每个框架都有它擅长的问题形状。你的任务只是识别"你的场景是什么形状",然后落到对应的顶点。

六、回到我自己: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 风险分级)。

自建的理由主要是三个:

1. 1. 业务锁定强——排障有很多领域约束(SRE 手册、企业内部工具链、生产环境风控),不如做一个薄薄的自建框架把这些约束固化进抽象
2. 2. 技能是天然抽象——排障的动作是"看日志 / 看监控 / 拉线程栈 / 执行诊断脚本",这些不是"Agent 角色",是"Skill"。用 AutoGen 的角色抽象反而拧巴
3. 3. 对可审计性要求——生产环境每一个 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-agentchat==0.7.5(2025-09-30 发布)
• •agentscope==2.0.8(2026-09-08 发布,2.x 大版本较原书 1.x 有 API 重构)
• •langgraph==1.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%免费】