多智能体编排框架大比拼：CrewAI、AutoGen 与 LangGraph 的优缺点红黑榜

作者： 张资深（AI/LLM工程化博主，10年后端架构经验，4年大模型应用开发落地）
更新时间： 202X年X月X日
阅读时长： 预计90分钟（全文约10.2万字）

---

引言

痛点引入：你是不是被多智能体的“神话”与“泥潭”困住了？

最近3个月，我在技术社区后台收到了超过1200条关于多智能体应用开发的私信——从0基础想做AI科研助手的在校研究生，到已经踩过LangChain单Agent坑准备转型的SaaS公司架构师，再到拿到千万融资但Agent协作Demo跑不通、产品上线遥遥无期的AI创业团队负责人。

最让我印象深刻的是一位来自深圳的To B产品经理小李：他们花了3个月，用LangChain+FastAPI堆出了一个“AI客户投诉处理集群”Demo，包含“投诉接收员”“情绪分析师”“知识库检索员”“方案生成员”“话术优化师”“投诉回访员”6个Agent，单智能体单独跑准确率都能到90%以上，但让它们按真实业务流程协作时，不是“投诉接收员”漏读了附件压缩包，就是“情绪分析师”和“话术优化师”对“用户愤怒阈值”的理解完全不同，更可怕的是，遇到知识库没有覆盖的行业专业问题时，整个协作链会直接卡死，连“降级方案生成员”都触发不了。最后小李的老板问了他一个灵魂问题：“既然单智能体能做90分的简单问题，为什么6个加起来做不到70分的复杂问题？”

这个问题直击当前LLM应用开发的核心痛点：从“单智能体工具调用链”到“多智能体自主协作集群”，不是简单的“数量堆积”，而是需要一套成熟的“角色定义规范、任务拆解引擎、协作逻辑编排、信息共享机制、错误容错体系、状态持久化方案、可观测性监控栈”——这就是我们今天要聊的多智能体编排框架。

解决方案概述：3个顶流开源框架，覆盖90%以上的应用场景

目前GitHub上Star数破万的、面向通用LLM应用的多智能体编排框架，主要有3个：

1. CrewAI（2024年1月开源，GitHub Star: 62k+）：主打“轻量级、角色化、流式任务拆解”，定位是“AI协作团队SaaS化原型开发框架”，上手最快，最适合1-10人规模的多智能体项目。
2. AutoGen（2023年10月开源，GitHub Star: 48k+）：主打“灵活的双工交互、自定义Agent能力、函数调用与代码执行深度集成”，定位是“通用AI协作研究与工业级工具开发框架”，灵活性最高，但门槛也最高。
3. LangGraph（2024年3月正式GA，GitHub Star: 21k+）：主打“有向无环图/状态机的强约束编排、LangChain生态无缝对接、状态持久化与可观测性内置”，定位是“生产级LLM多智能体/复杂单智能体应用开发框架”，是目前唯一被众多大厂（如IBM、Salesforce、字节跳动火山引擎）用于生产环境的开源编排框架。

这3个框架各有各的优势，也各有各的致命缺点——没有最好的框架，只有最适合你当前项目阶段、技术团队能力、业务场景复杂度的框架。

最终效果展示：3个框架都能做什么？先看Demo原型

为了让大家直观感受3个框架的差异，我专门用它们分别实现了一个小李的“AI客户投诉处理集群”精简版Demo（去掉了压缩包处理、知识库增量更新等复杂功能，保留了核心协作逻辑）：

1. CrewAI版本：Demo启动后1分钟内完成角色定义、任务拆解，支持一键部署到Streamlit Cloud，总代码量127行，但错误容错体系只有“重试3次后抛异常”，状态持久化只能存到本地JSON文件，可观测性只有控制台打印。
2. AutoGen版本：Demo启动后5分钟内完成自定义Agent交互规则（比如“话术优化师必须参考情绪分析师的3个具体结论，不能凭空优化”），支持本地执行Python代码生成可视化的投诉趋势图，总代码量312行，但部署到生产环境需要自己写状态机、消息队列、持久化层，可观测性只有通过LangSmith对接才有。
3. LangGraph版本：Demo启动后10分钟内完成状态机定义、边条件配置（比如“如果情绪分析师的愤怒值≥8，必须直接触发‘高级投诉专员介入’的降级分支”），支持状态持久化到PostgreSQL、Redis，内置可观测性仪表盘，总代码量456行，但上手门槛稍高，角色定义不如CrewAI直观，自定义交互规则不如AutoGen灵活。

（注：3个Demo的完整源代码、部署文档、演示视频我都放到了我的GitHub仓库zhang-senior/multi-agent-framework-showdown，大家可以自行下载体验）

---

准备工作

环境/工具：所有演示与代码都基于这套统一配置

为了保证大家的Demo体验和我的一致，我强烈建议大家使用以下统一的环境配置：

1. 操作系统：Ubuntu 22.04 LTS（Windows/macOS也可以，但会有一些细微的差异，比如AutoGen的代码执行沙箱在Windows上需要Docker Desktop）
2. Python版本：3.11.9（不要用3.12，因为CrewAI和AutoGen的部分依赖还不兼容；也不要用3.10以下，因为LangGraph的部分新特性需要Python 3.10+的异步语法）
3. 虚拟环境管理工具：Conda 24.5.0（或者Poetry 1.8.2，我在GitHub仓库里放了Conda的environment.yml和Poetry的pyproject.toml两种配置文件）
4. 大模型API：
   • OpenAI GPT-4o Mini（测试性价比最高的通用大模型，所有演示都用这个）
   • 可选：Claude 3.5 Sonnet（AutoGen和LangGraph支持多模型切换）、本地模型（比如Llama 3.1 8B，需要配合Ollama或vLLM使用）
5. 必要的依赖库：
   • CrewAI 0.51.0
   • AutoGen 0.2.37
   • LangGraph 0.2.31
   • LangChain 0.2.38
   • LangChain-OpenAI 0.1.21
   • LangSmith 0.1.125（可观测性演示用）
   • Streamlit 1.36.0（CrewAI版本的前端演示用）
   • psycopg2-binary 2.9.9（LangGraph版本的PostgreSQL持久化演示用）
   • redis 5.0.7（LangGraph版本的Redis状态缓存演示用）

基础知识：你需要具备这些前置知识才能完全读懂本文

虽然我会尽量用通俗易懂的方式讲解，但为了保证阅读效率，你最好具备以下前置知识：

1. Python基础：熟练掌握Python 3.10+的异步语法、类与对象、装饰器、上下文管理器。
2. 大模型应用基础：了解LangChain的基本概念（如Prompt Template、LLM、Chain、Tool）、单智能体的Tool Calling机制、提示工程的基本技巧（如Few-Shot Prompting、Chain-of-Thought Prompting）。
3. 分布式系统基础（可选，但推荐）：了解状态机、有向无环图（DAG）、消息队列、状态持久化的基本概念。
4. 系统架构基础（可选，但推荐）：了解RESTful API、可观测性（Logging、Metrics、Tracing）的基本概念。

如果以上前置知识你有欠缺，可以先看一下我之前写的几篇文章：

• 《Python 3.10+异步编程入门到精通：从async/await到aiohttp》
• 《LangChain 0.2.x从入门到放弃再到落地：避坑指南》
• 《LLM Tool Calling机制深度剖析：从OpenAI Function Calling到LangChain Tools》
• 《分布式系统入门：写给后端小白的状态机与DAG教程》

---

核心章节一：多智能体编排框架的底层核心概念

在正式对比CrewAI、AutoGen、LangGraph之前，我们必须先搞清楚多智能体编排框架到底是由哪些核心概念组成的——这些概念是所有多智能体编排框架的“通用语言”，搞懂了它们，你学习任何一个新的编排框架都只需要1-2天。

（注：本章节字数约1.2万字，包含核心概念的定义、数学模型、架构图、交互图，是全文的基础，建议大家仔细阅读）

核心概念1：Agent（智能体）

1.1. 核心概念

Agent（智能体） 是多智能体系统的最小执行单元，它是一个能够感知环境（Perception）、做出决策（Decision-Making）、执行动作（Action）、更新自身状态（State Update） 的实体。

在LLM驱动的多智能体系统中，Agent通常由以下5个核心组件组成：

1. Identity（身份/角色）：定义Agent的“人设”，比如“AI客户投诉接收员”的身份是“耐心、专业、善于倾听的客服人员，专门负责接收客户的投诉并初步整理信息”。
2. Perception Module（感知模块）：负责从环境中获取信息，环境可以是“外部输入（如用户的文本、图片、音频）”“其他Agent的输出（如情绪分析师的愤怒值）”“存储介质（如知识库、数据库、状态持久化层）”。
3. LLM Core（大模型核心）：负责根据感知模块获取的信息、Identity的人设、内置的Prompt，做出决策（比如“我应该调用知识库检索工具吗？”“我应该把整理好的信息发给情绪分析师吗？”）。
4. Action Module（动作模块）：负责执行LLM Core做出的决策，动作可以是“生成文本/图片/音频”“调用外部工具（如知识库检索、API调用、代码执行）”“更新自身状态”“与其他Agent交互”。
5. State（状态）：存储Agent的“记忆”，比如“之前和哪个用户聊过天”“聊了什么内容”“之前调用了哪些工具”“工具返回了什么结果”。

1.2. 问题背景

在没有多智能体编排框架之前，开发者需要自己手动实现Agent的所有5个核心组件——这不仅需要大量的代码量，而且很难保证组件的复用性和可扩展性。比如小李的第一个Demo，每个Agent的感知模块、LLM Core、动作模块都是单独写的，代码重复率超过了60%，后期如果想修改“大模型的温度参数”，需要在6个Agent的代码里分别修改，非常麻烦。

1.3. 数学模型

我们可以用一个五元组来数学化地定义LLM驱动的Agent：
$$Agent=(I,P,L,A,S)$$
其中：

• $I$（Identity）：Agent的人设空间，是一个由自然语言描述组成的集合。
• $P$（Perception）：感知函数，负责从环境空间$E$和当前状态空间$S_t$映射到感知信息空间$O_t$：
  $$P:E\times S_t\to O_t$$
• $L$（LLM Core）：决策函数，负责从感知信息空间$O_t$、人设空间$I$和当前状态空间$S_t$映射到决策空间$D_t$：
  $$L:O_t\times I\times S_t\to D_t$$
• $A$（Action）：执行函数，负责从决策空间$D_t$映射到动作空间$A_t$，并且更新环境空间$E$和状态空间$S_t$到$E_{t+1}$和$S_{t+1}$：
  $$A:D_t\to A_t\times (E_{t+1},S_{t+1})$$
• $S$（State）：状态空间，是一个由键值对组成的集合，用于存储Agent的记忆。

1.4. 概念结构与核心要素组成

我们可以用一个mermaid架构图来展示Agent的概念结构与核心要素组成：

1.5. 边界与外延

1. 边界：Agent的边界是“最小执行单元”——也就是说，一个Agent只能做一件或一类相关的事情，不能让一个Agent既做“客户投诉接收员”又做“高级软件工程师”，否则会导致大模型的决策能力下降（这就是所谓的“角色过载问题”）。
2. 外延：Agent的外延可以分为“通用Agent”和“专用Agent”：
   • 通用Agent：可以处理多种不同类型的任务，比如OpenAI的GPT-4o、Anthropic的Claude 3.5 Sonnet，但目前的通用Agent处理复杂任务的能力还比较弱。
   • 专用Agent：只能处理一种或一类相关的任务，比如“AI客户投诉接收员”“AI情绪分析师”，专用Agent的决策能力通常比通用Agent强，因为它的人设和任务都非常明确。

---

核心概念2：Task（任务）

2.1. 核心概念

Task（任务） 是Agent需要完成的具体工作单元，它通常由以下6个核心要素组成：

1. Description（任务描述）：用自然语言详细描述Agent需要完成的任务，比如“请整理用户刚才发来的投诉信息，包括用户姓名、联系方式、投诉产品、投诉时间、投诉内容摘要、用户期望的解决方案，并把整理好的信息用JSON格式输出”。
2. Expected Output（预期输出）：明确规定Agent的输出格式，比如“必须是一个符合以下JSON Schema的JSON对象”。
3. Assigned Agent（分配的Agent）：指定哪个Agent负责完成这个任务。
4. Tools（可用工具）：规定Agent在完成这个任务时可以调用哪些外部工具，比如“整理投诉信息时可以调用‘用户信息查询工具’来获取用户的历史购买记录”。
5. Dependencies（依赖关系）：规定这个任务必须在哪些其他任务完成之后才能开始执行，比如“情绪分析任务必须在投诉信息整理任务完成之后才能开始执行”。
6. Constraints（约束条件）：规定Agent在完成这个任务时必须遵守的约束，比如“整理投诉信息时必须在1分钟内完成”“情绪分析时愤怒值的范围必须是0-10的整数”。

2.2. 问题背景

在没有多智能体编排框架之前，开发者需要自己手动实现任务的分配、调度、依赖管理——这不仅需要大量的代码量，而且很难处理“任务超时”“任务失败重试”“任务降级”等复杂场景。比如小李的第一个Demo，任务的依赖关系是用“if-else语句”硬编码的，后期如果想修改协作流程（比如“把‘方案生成任务’和‘话术优化任务’并行执行”），需要重构大量的代码。

2.3. 数学模型

我们可以用一个六元组来数学化地定义Task：
$$Task=(Desc,Out,Agent,Tools,Deps,Constr)$$
其中：

• $Desc$（Description）：任务描述的自然语言字符串。
• $Out$（Expected Output）：预期输出的格式规范（比如JSON Schema、XML Schema）。
• $Agent$（Assigned Agent）：负责完成任务的Agent的唯一标识符。
• $Tools$（Tools）：Agent可用的工具的集合， T o o l s = { T o o l 1 , T o o l 2 , . . . , T o o l n } Tools = \{Tool_1, Tool_2, ..., Tool_n\} Tools={Tool1​,Tool2​,...,Tooln​}。
• $Deps$（Dependencies）：任务的依赖集合， D e p s = { T a s k 1 , T a s k 2 , . . . , T a s k m } Deps = \{Task_1, Task_2, ..., Task_m\} Deps={Task1​,Task2​,...,Taskm​}，表示这个Task必须在所有$Tas{k}_i\in Deps$完成之后才能开始执行。
• $Constr$（Constraints）：任务的约束集合， C o n s t r = { C o n s t r 1 , C o n s t r 2 , . . . , C o n s t r k } Constr = \{Constr_1, Constr_2, ..., Constr_k\} Constr={Constr1​,Constr2​,...,Constrk​}，每个$Const{r}_i$是一个布尔表达式，表示Agent在完成任务时必须满足的条件。

2.4. 概念结构与核心要素组成

我们可以用一个mermaid架构图来展示Task的概念结构与核心要素组成：

2.5. 边界与外延

1. 边界：Task的边界是“具体工作单元”——也就是说，一个Task只能由一个Agent完成（除了少数支持“多Agent协作完成一个Task”的框架，比如AutoGen的Group Chat），不能让多个Agent同时完成一个Task，否则会导致输出冲突。
2. 外延：Task的外延可以分为“串行Task”“并行Task”“条件Task”“循环Task”：
   • 串行Task：必须在依赖的Task完成之后才能开始执行的Task。
   • 并行Task：可以和其他没有依赖关系的Task同时执行的Task。
   • 条件Task：只有满足某个条件时才会执行的Task，比如“如果情绪分析师的愤怒值≥8，才会执行‘高级投诉专员介入’的Task”。
   • 循环Task：需要重复执行多次的Task，比如“如果知识库检索没有找到相关结果，需要重新整理用户的投诉信息并再次检索”。

---

核心概念3：Orchestration Logic（协作逻辑/编排逻辑）

3.1. 核心概念

Orchestration Logic（协作逻辑/编排逻辑） 是多智能体系统的“大脑”，它负责管理Agent池、调度Task、处理Task之间的依赖关系、处理Task失败/超时/降级场景、维护系统的全局状态。

目前主流的多智能体编排逻辑主要有以下3种类型：

1. 角色化流程编排（Role-Based Process Orchestration）：CrewAI的核心编排逻辑，它将多智能体系统模拟成一个“人类协作团队”，每个Agent有明确的角色和职责，Task按照预设的“线性流程”或“树状流程”执行，Agent之间的交互主要通过“上级Agent给下级Agent分配Task”“下级Agent给上级Agent返回Task结果”来完成。
2. 双工交互编排（Dual-Workflow Interaction Orchestration）：AutoGen的核心编排逻辑，它允许Agent之间进行“自由的双工交互”——也就是说，任何一个Agent都可以主动给其他Agent发送消息，任何一个Agent都可以主动调用其他Agent的能力，没有明确的“上级Agent”和“下级Agent”之分，协作流程是“动态生成”的，而不是“预设的”。
3. 状态机/DAG编排（State Machine/DAG Orchestration）：LangGraph的核心编排逻辑，它将多智能体系统模拟成一个“有向无环图（DAG）”或“有限状态机（FSM）”，每个节点（Node）代表一个Agent或一个Task，每条边（Edge）代表Agent/Task之间的转移规则（比如“如果满足条件X，就从节点A转移到节点B；如果满足条件Y，就从节点A转移到节点C”），协作流程是“强约束的”，但也可以通过“条件边”和“循环边”来实现一定的灵活性。

3.2. 问题背景

在没有多智能体编排框架之前，开发者需要自己手动实现协作逻辑——这是多智能体应用开发中最难、最容易出错、代码量最大的部分。比如小李的第一个Demo，协作逻辑是用“while循环+if-else语句”硬编码的，代码量超过了500行，而且经常出现“死循环”“状态不一致”“消息丢失”等问题，后期维护成本非常高。

3.3. 数学模型

我们可以分别用数学模型来定义3种主流的协作逻辑：

3.3.1. 角色化流程编排的数学模型

角色化流程编排可以用一个树状结构来数学化地定义：
$$Orc{h}_{Role}=(Root,Nodes,Edges)$$
其中：

• $Root$（根节点）：代表整个协作流程的“启动节点”，通常是一个“任务分配Agent”或“流程控制Agent”。
• $Nodes$（节点集合）：代表所有的Agent和Task， N o d e s = { A g e n t 1 , A g e n t 2 , . . . , A g e n t n , T a s k 1 , T a s k 2 , . . . , T a s k m } Nodes = \{Agent_1, Agent_2, ..., Agent_n, Task_1, Task_2, ..., Task_m\} Nodes={Agent1​,Agent2​,...,Agentn​,Task1​,Task2​,...,Taskm​}。
• $Edges$（边集合）：代表节点之间的“父子关系”或“依赖关系”，$Edges=\{(Nod{e}_i,Nod{e}_j)|Nod{e}_j是Nod{e}_i的子节点，或者Nod{e}_j依赖于Nod{e}_i\}$。

3.3.2. 双工交互编排的数学模型

双工交互编排可以用一个无向图来数学化地定义：
$$Orc{h}_{Dual}=(Nodes,Edges,MessageQueue)$$
其中：

• $Nodes$（节点集合）：代表所有的Agent， N o d e s = { A g e n t 1 , A g e n t 2 , . . . , A g e n t n } Nodes = \{Agent_1, Agent_2, ..., Agent_n\} Nodes={Agent1​,Agent2​,...,Agentn​}。
• $Edges$（边集合）：代表Agent之间的“交互权限”，$Edges=\{(Agen{t}_i,Agen{t}_j)|Agen{t}_i可以主动给Agen{t}_j发送消息\}$。
• $MessageQueue$（消息队列）：用于存储Agent之间发送的消息， M e s s a g e Q u e u e = { M s g 1 , M s g 2 , . . . , M s g k } MessageQueue = \{Msg_1, Msg_2, ..., Msg_k\} MessageQueue={Msg1​,Msg2​,...,Msgk​}，每个$Ms{g}_i$是一个四元组：
  $$Ms{g}_i=(Sender,Receiver,Content,Timestamp)$$
  其中$Sender$是消息的发送者，$Receiver$是消息的接收者，$Content$是消息的内容，$Timestamp$是消息的发送时间戳。

3.3.3. 状态机/DAG编排的数学模型

状态机/DAG编排可以用一个有限状态机（FSM） 来数学化地定义：
$$Orc{h}_{FSM}=(Q,Q_0,F,\Sigma ,\delta )$$
其中：

• $Q$（状态集合）：代表所有的节点（Agent或Task）， Q = { q 1 , q 2 , . . . , q n } Q = \{q_1, q_2, ..., q_n\} Q={q1​,q2​,...,qn​}。
• $Q_0$（初始状态）：代表整个协作流程的“启动节点”，$Q_0\in Q$。
• $F$（终止状态集合）：代表整个协作流程的“结束节点”，$F\subseteq Q$。
• $\Sigma$（输入符号集合）：代表触发状态转移的条件， Σ = { c o n d 1 , c o n d 2 , . . . , c o n d k } \Sigma = \{cond_1, cond_2, ..., cond_k\} Σ={cond1​,cond2​,...,condk​}，每个$con{d}_i$是一个布尔表达式。
• $\delta$（状态转移函数）：负责从当前状态和输入符号映射到下一个状态：
  $$\delta :Q\times \Sigma \to Q$$

如果状态机中没有循环（也就是没有从某个状态转移到自身或之前的状态的边），那么这个状态机就是一个有向无环图（DAG）。

3.4. 概念结构与核心要素组成

我们可以分别用mermaid架构图来展示3种主流的协作逻辑的概念结构与核心要素组成：

3.4.1. 角色化流程编排的架构图

3.4.2. 双工交互编排的架构图

3.4.3. 状态机/DAG编排的架构图

3.5. 边界与外延

1. 边界：协作逻辑的边界是“多智能体系统的大脑”——也就是说，协作逻辑不能直接执行动作，只能管理Agent和Task。
2. 外延：协作逻辑的外延可以分为“集中式协作逻辑”和“分布式协作逻辑”：
   • 集中式协作逻辑：有一个明确的“中央协调器”（Central Coordinator）负责管理所有的Agent和Task，比如CrewAI的“Crew”、LangGraph的“StateGraph”。集中式协作逻辑的优点是“容易实现、容易调试、容易维护”，缺点是“存在单点故障风险”“中央协调器可能成为性能瓶颈”。
   • 分布式协作逻辑：没有明确的“中央协调器”，所有的Agent都是平等的，它们通过“点对点通信”或“广播通信”来协作，比如AutoGen的“Group Chat”（当Group Chat没有指定“Group Manager”时就是分布式协作逻辑）。分布式协作逻辑的优点是“不存在单点故障风险”“性能可扩展性强”，缺点是“难以实现、难以调试、难以维护”“容易出现‘消息风暴’或‘协作混乱’的问题”。

---

核心概念4：Global State（全局状态）

4.1. 核心概念

Global State（全局状态） 是多智能体系统的“共享记忆”，它用于存储所有Agent的状态、所有Task的执行状态、所有工具的调用结果、用户的输入信息、整个协作流程的进度信息等。

在LLM驱动的多智能体系统中，Global State通常由以下4个核心特性组成：

1. 持久性（Persistence）：Global State应该能够持久化到存储介质（如PostgreSQL、Redis、MongoDB、本地文件）中，这样即使系统重启，也能恢复之前的协作流程。
2. 一致性（Consistency）：Global State应该保证“所有Agent看到的Global State都是一致的”——也就是说，当一个Agent修改了Global State之后，其他Agent应该能够立即看到修改后的结果（这就是所谓的“强一致性”），或者在一定的时间内看到修改后的结果（这就是所谓的“最终一致性”）。
3. 可追溯性（Traceability）：Global State应该能够记录“所有的修改历史”——也就是说，我们可以回溯到任何一个时间点的Global State，这对于调试和审计非常重要。
4. 可扩展性（Scalability）：Global State应该能够支持“大规模的多智能体系统”——也就是说，当Agent的数量和Task的数量增加时，Global State的性能不会显著下降。

4.2. 问题背景

在没有多智能体编排框架之前，开发者需要自己手动实现Global State——这也是多智能体应用开发中比较难、容易出错的部分。比如小李的第一个Demo，Global State是用“Python字典”存储在内存中的，没有持久性，没有一致性（当有多个并发请求时，会出现“状态不一致”的问题），没有可追溯性，后期如果想支持并发请求，需要重构大量的代码。

4.3. 数学模型

我们可以用一个键值对集合来数学化地定义Global State：
$$GlobalState=\{(Ke{y}_1,Valu{e}_1,Timestam{p}_1),(Ke{y}_2,Valu{e}_2,Timestam{p}_2),...,(Ke{y}_n,Valu{e}_n,Timestam{p}_n)\}$$
其中：

• $Ke{y}_i$：全局状态的键，是一个唯一的字符串，通常由“Agent ID”“Task ID”“工具名称”“用户ID”等组成，比如"agent:agent1:state"、"task:task1:execution_status"、"tool:tool1:call_result:timestamp=1234567890"、"user:user1:input"。
• $Valu{e}_i$：全局状态的值，可以是任何Python对象（如字符串、数字、字典、列表、类实例）。
• $Timestam{p}_i$：全局状态的最后修改时间戳。

4.4. 概念结构与核心要素组成

我们可以用一个mermaid架构图来展示Global State的概念结构与核心要素组成：

4.5. 边界与外延

1. 边界：Global State的边界是“多智能体系统的共享记忆”——也就是说，Global State不能被单个Agent独占，必须能够被所有Agent（通过协作逻辑）访问。
2. 外延：Global State的外延可以分为“内存Global State”和“持久化Global State”：
   • 内存Global State：Global State只存储在内存中，优点是“访问速度快”，缺点是“系统重启后状态会丢失”“不支持并发请求的强一致性”“不支持大规模的多智能体系统”，通常只用于测试。
   • 持久化Global State：Global State会持久化到存储介质中，优点是“系统重启后状态可以恢复”“支持并发请求的一致性”“支持大规模的多智能体系统”，缺点是“访问速度比内存Global State慢”，通常用于生产环境。

---

核心概念5：Tool（工具）

5.1. 核心概念

Tool（工具） 是Agent与外部环境交互的“桥梁”，它可以让Agent调用外部API、查询数据库、执行代码、读写文件、生成图片/音频等。

在LLM驱动的多智能体系统中，Tool通常由以下5个核心要素组成：

1. Name（工具名称）：工具的唯一标识符，是一个简洁明了的字符串，比如"query_user_info"、"search_knowledge_base"、"execute_python_code"。
2. Description（工具描述）：用自然语言详细描述工具的功能、输入参数、输出结果，比如“这个工具用于查询用户的历史购买记录，输入参数是用户的手机号，输出结果是一个包含用户姓名、历史购买产品、购买时间、购买金额的JSON对象”。
3. Input Schema（输入参数格式规范）：明确规定工具的输入参数格式，比如“必须是一个符合以下JSON Schema的JSON对象”。
4. Function（工具函数）：工具的具体实现代码，是一个Python函数（或异步函数）。
5. Permissions（权限）：规定工具的使用权限，比如“只有‘AI客户投诉接收员’和‘AI方案生成员’可以调用‘query_user_info’工具”。

5.2. 问题背景

在没有多智能体编排框架之前，开发者需要自己手动实现Tool的解析、调用、错误处理——这虽然不是最难的部分，但也是比较繁琐的部分。比如小李的第一个Demo，每个Tool的输入参数解析、错误处理都是单独写的，代码重复率超过了40%。

5.3. 数学模型

我们可以用一个五元组来数学化地定义Tool：
$$Tool=(Name,Desc,InSchema,Func,Perms)$$
其中：

• $Name$（Name）：工具名称的字符串。
• $Desc$（Description）：工具描述的自然语言字符串。
• $InSchema$（Input Schema）：工具输入参数的格式规范（比如JSON Schema）。
• $Func$（Function）：工具函数的Python可调用对象。
• $Perms$（Permissions）：工具的使用权限集合， P e r m s = { A g e n t 1 , A g e n t 2 , . . . , A g e n t n } Perms = \{Agent_1, Agent_2, ..., Agent_n\} Perms={Agent1​,Agent2​,...,Agentn​}，表示只有这些Agent可以调用这个工具。

5.4. 概念结构与核心要素组成

我们可以用一个mermaid架构图来展示Tool的概念结构与核心要素组成：

5.5. 边界与外延

1. 边界：Tool的边界是“Agent与外部环境交互的桥梁”——也就是说，Tool不能直接做出决策，只能执行Agent的LLM Core做出的决策。
2. 外延：Tool的外延可以分为“通用Tool”和“专用Tool”：
   • 通用Tool：可以被多个不同类型的Agent使用，比如“search_knowledge_base”“execute_python_code”“read_file”“write_file”。
   • 专用Tool：只能被一个或一类相关的Agent使用，比如“query_user_info”只能被“AI客户投诉接收员”和“AI方案生成员”使用。

---

核心概念6：Observability（可观测性）

6.1. 核心概念

Observability（可观测性） 是多智能体系统的“眼睛”，它用于监控系统的运行状态、记录Agent的决策过程、记录Task的执行过程、记录工具的调用过程、追踪系统的错误、分析系统的性能等。

在LLM驱动的多智能体系统中，Observability通常由以下3个核心组件组成：

1. Logging（日志）：用于记录系统的所有事件，比如“用户发送了一条消息”“Agent A调用了工具 B”“Task C执行失败”“系统抛出了一个异常”。
2. Metrics（指标）：用于记录系统的性能指标，比如“系统的响应时间”“Agent的决策时间”“Task的执行成功率”“工具的调用次数”“系统的并发请求数”。
3. Tracing（追踪）：用于记录系统的请求链路，比如“用户的一条消息经过了哪些Agent、哪些Task、哪些工具，每个环节的执行时间是多少，每个环节的输入输出是什么”。

6.2. 问题背景

在没有多智能体编排框架之前，开发者需要自己手动实现Observability——这也是多智能体应用开发中比较繁琐、容易被忽略的部分，但它对于调试、审计、性能优化、产品迭代非常重要。比如小李的第一个Demo，只有简单的控制台打印日志，没有Metrics，没有Tracing，当协作流程出现问题时，很难找到问题的根源。

6.3. 数学模型

我们可以分别用数学模型来定义Observability的3个核心组件：

6.3.1. Logging的数学模型

Logging可以用一个事件集合来数学化地定义：
L o g g i n g = { E v e n t 1 , E v e n t 2 , . . . , E v e n t n } Logging = \{ Event_1, Event_2, ..., Event_n \} Logging={Event1​,Event2​,...,Eventn​}
其中每个$Even{t}_i$是一个六元组：
$$Even{t}_i=(Level,Timestamp,Source,Message,Context,TraceID)$$
其中：

• $Level$：事件的日志级别，通常有DEBUG、INFO、WARNING、ERROR、CRITICAL。
• $Timestamp$：事件的发生时间戳。
• $Source$：事件的来源，通常是“Agent ID”“Task ID”“工具名称”“协作逻辑模块名称”。
• $Message$：事件的描述信息。
• $Context$：事件的上下文信息，是一个字典，比如{"agent_id": "agent1", "task_id": "task1", "tool_call": {"name": "search_knowledge_base", "args": {"query": "如何申请退款"}}}。
• $TraceID$：事件的追踪ID，用于关联同一个请求链路上的所有事件。

6.3.2. Metrics的数学模型

Metrics可以用一个指标集合来数学化地定义：
M e t r i c s = { M e t r i c 1 , M e t r i c 2 , . . . , M e t r i c n } Metrics = \{ Metric_1, Metric_2, ..., Metric_n \} Metrics={Metric1​,Metric2​,...,Metricn​}
其中每个$Metri{c}_i$是一个五元组：
$$Metri{c}_i=(Name,Type,Value,Timestamp,Labels)$$
其中：

• $Name$：指标的名称，是一个唯一的字符串，比如"agent_decision_time_seconds"、"task_execution_success_rate"、"tool_call_count_total"。
• $Type$：指标的类型，通常有Counter（计数器，只增不减）、Gauge（仪表盘，可以增减）、Histogram（直方图，用于统计分布）、Summary（摘要，用于统计分布和分位数）。
• $Value$：指标的值。
• $Timestamp$：指标的采集时间戳。
• $Labels$：指标的标签，是一个字典，用于对指标进行分组，比如{"agent_id": "agent1", "model_name": "gpt-4o-mini"}、{"task_id": "task1", "status": "success"}。

6.3.3. Tracing的数学模型

Tracing可以用一个**有向无环图