多智能体系统的演化与范式 / Evolution and Paradigms of Multi-Agent Systems

第 1 章：多智能体系统的演化与范式 / Evolution and Paradigms of Multi-Agent Systems

为什么一个在 2023 年才进入主流开发者视野的概念——多智能体系统（Multi-Agent System, MAS）——会在不到两年时间内，从一个学术名词跃升为 AI 工程化最具争议也最具想象力的方向？答案并不在于某个单一算法的横空出世，而在于三条原本独立的技术曲线在同一时刻发生了共振：大语言模型（LLM）推理与规划的通用能力跃迁、函数调用（function calling）与工具协议（tool protocol）的标准化、以及分布式系统思想在 AI 编排（orchestration）层的全面渗透。本章要回答的核心问题是：多智能体系统是如何从学术原型走向工业级工程范式的？它在当代 AI 浪潮中扮演何种角色？ 我们将从分布式人工智能（Distributed Artificial Intelligence, DAI）的经典源头出发，穿过符号主义、行为主义、连接主义的方法论更替，最终落在 2023–2025 年间由 AutoGen、CrewAI、LangGraph、MetaGPT 等框架所代表的工程范式转移上，并辅以供应链、机器人集群、自动化研究、金融交易四个产业语境下的真实价值主张。

1.1 MAS 的学术起源：从 Hewitt 的 Actor 模型到 Jennings 的 GRATE 模型

要理解今天的 LLM 驱动的多智能体框架，必须先回到智能体（agent）这一概念被发明的那个时刻。1973 年，Carl Hewitt 在其关于并行计算的博士论文中提出了 Actor 模型，其核心论断是："计算的本质是消息传递。" 在该模型中，每一个 Actor 都是一个拥有独立状态、能够异步响应消息、并通过消息传递与其他 Actor 交互的自治实体。Actor 模型并未明确提及"智能"，但它奠定了后来几乎所有 MAS 理论的三个基石——自治状态、消息驱动、并发通信——因此被视为 MAS 思想的最远端起点。

进入 1980 年代，随着分布式问题求解（Distributed Problem Solving, DPS）和多智能体系统（MAS）两个分支的分化，DAI 作为独立学科正式成型。1980 年，Reid Smith 在其博士论文中提出了 Contract Net Protocol（合同网协议），将任务分配建模为 Manager–Contractor 之间的"招标—投标—中标"市场机制。这套协议的影响力远超其最初的应用场景（分布式传感与监测），它在今天的 AutoGen、MetaGPT 等框架中依然以"任务分配—角色认领"的形态存在，只是"合同"变成了结构化提示词（structured prompt），"中标"变成了模型驱动的角色选择。

1987 年，Michael Bratman 在哲学层面提出了 Belief–Desire–Intention（BDI） 意图理论，被认为是智能体理性行为的认知基础。1991 年，Anand Rao 和 Michael Georgeff 将 BDI 形式化为可计算架构，定义了基于一阶/二阶模态逻辑的 BDI 解释器。同一时期（1993），Rao 又推出了 AgentSpeak(L) 语言，首次给出了 BDI 智能体的可执行语义。BDI 架构的核心洞见是：一个理性智能体必须同时维护对世界的"信念"、对目标的"愿望"、和承诺执行的"意图"，三者之间的平衡决定了行为的稳定性与适应性。这一思想在今天的多智能体 LLM 系统中以另一种形式复活——当我们为不同 agent 分配 system prompt、memory 与 tools 时，本质上就是在划定它们的"意图空间"。

1990 年代中期，Nick Jennings 等人在英国开发的 GRATE（Generic Rules and Agent Test Environment）模型 是工程化 MAS 的里程碑。Jennings 后来被引用最广的一句话是："*An agent is a computer system, situated in some environment, that is capable of flexible autonomous action in order to meet its design objectives.*" GRATE 不仅提出了 agent 的形式化定义，更引入了联合意图（joint intention） 和共同责任（mutual responsibility） 的概念——多智能体协作不仅仅是各自行为的叠加，还需要共享的目标承诺和失败时的协同响应。这一思想在 30 年后的 CrewAI、LangGraph 的 supervisor pattern 中得到了几乎一比一的呼应：supervisor agent 在任务失败时不仅需要本地重试，还要通知或触发协作 agent 的状态变更。

整个 1990 年代到 2010 年代，MAS 学术研究的重心在于协商机制（negotiation）、协调算法（coordination）和通信语言（ACL，如 FIPA ACL）。然而这一阶段的 MAS 始终没能跨过工业化的门槛，原因有三：(1) 智能体之间的通信成本远高于单体系统；(2) 缺乏能够跨域泛化的"通用推理引擎"；(3) 工程化工具链极度匮乏。彼时一个 MAS 原型往往需要数月的协议设计与数月的协议实现，性价比远不如单体专家系统。

转折发生在 2022–2023 年。当 GPT-4、Claude 等大模型具备了通用规划、自然语言协议理解、零样本工具调用 三项能力后，原本需要用形式化语言（KIF、ACL）显式编码的协调协议，现在可以用自然语言 prompt 来表达。原本需要为每个 agent 单独训练的推理模型，现在可以共享同一个基座模型通过角色 prompt 差异化。这一变化使得 MAS 从"高研究成本、低复用率"的学术原型，转变为"低边际成本、高复用率"的工程范式。这就是为什么我们说 MAS 不是一个新概念，而是一个等待被重新工程化的旧概念。

```mermaid flowchart LR A[1973 Actor Model<br/>Hewitt] --> B[1980 Contract Net<br/>Smith] B --> C[1987 BDI Theory<br/>Bratman] C --> D[1991 BDI Arch<br/>Rao & Georgeff] D --> E[1993 AgentSpeak L<br/>Rao] E --> F[1995 GRATE<br/>Jennings] F --> G[1997 FIPA ACL<br/>Standardization] G --> H[2000s MAS Research Plateau<br/>High Cost Low Reuse] H --> I[2022 LLM Capability Leap] I --> J[2023 AutoGen / LangChain Agents] J --> K[2024 CrewAI / LangGraph / MetaGPT] K --> L[2025 Swarm / Anthropic MCP Era] ```

> 图 1-1：智能体范式演化时间线。从 Hewitt 的 Actor 模型到 2025 年的 MCP 时代，每一阶段都为下一次的工程化爆发埋下了种子。

1.2 智能体的形式化定义与四要素

在工程实践中，关于"什么是 agent"的争论从未停止。本节我们梳理两条最重要的定义线：Russell & Norvig 的 AI 教科书视角 与 Wooldridge 的 MAS 学术视角，并据此推导 LLM 时代的智能体判据。

Russell 与 Norvig 在《Artificial Intelligence: A Modern Approach》中给出的 agent 定义是高度功能化的：*An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators.*（智能体是任何可以通过传感器感知环境、并通过执行器作用于环境的事物。）这一定义的优点是完全去本体化——它不要求 agent 必须有"心智"，只要存在感知–动作循环即可。在这个意义上，一个 PID 控制器、一个 if-else 决策树、甚至一个简单的脚本，都可以是 agent。这一定义在工程上极易落地，因此在 LLM 框架的文档中被广泛采用（如 LangChain、LlamaIndex）。

然而 Wooldridge 在其 1995 年的奠基性论文中提出了更严格的版本。他区分了弱定义（weak notion） 与强定义（strong notion）：弱定义要求 agent 具备自主性（autonomy）、社会性（social ability）、反应性（reactivity）、前瞻性（pro-activeness）；强定义在此之上还要求 agent 具有心智状态（mental attitudes），包括信念、愿望、意图等认知成分。这一定义的影响力在于，它把"agent"从功能主义的黑盒提升为可分析、可建模、可验证的对象。一个工程系统如果只满足弱定义，我们通常称之为"自动化代理"；如果同时满足强定义，则可以称之为"真正的智能体"。

将这一框架映射到 2025 年的 LLM Agent 上会非常有趣：

• **自主性（Autonomy）**：LLM Agent 通常运行在 LangGraph、CrewAI 这类编排框架之上，其推理路径由模型自主决定，而非由硬编码控制流支配。这满足自主性。
• **社会性（Social Ability）**：MAS 中的 agent 通过消息总线（message bus）、共享内存（shared memory）、或黑板系统（blackboard）进行通信。LLM 时代的对应物是 inter-agent message passing、shared state store（如 Redis）、以及结构化任务清单（如 TodoList tool）。这满足社会性。
• **反应性（Reactivity）**：经典 MAS agent 必须在环境变化时在有限时间内做出反应。LLM Agent 的反应性主要体现在：(1) 工具调用返回错误时的重试机制；(2) 用户输入抵达时的即时响应；(3) 协作 agent 反馈抵达时的动态调整。这是当前最弱的环节，因为 LLM 推理延迟（通常 0.5–10s）远高于经典 agent 的毫秒级响应。
• **前瞻性（Pro-activeness）**：agent 不仅要响应事件，还要主动追求目标。LLM Agent 的前瞻性通常通过 ReAct、Plan-and-Execute、Reflexion 等规划范式实现。

这意味着：当代主流 LLM Agent 已经基本满足 Wooldridge 的弱定义，并在大多数场景下逼近强定义——只是其"心智状态"不再是显式的 BDI 数据库，而是隐式地编码在 prompt context 与 memory buffer 中。这种隐式化带来了灵活性，也带来了可控性的根本挑战，这一点我们将在第 3 章详细展开。

需要特别强调的是，工程界与学术界对 agent 的定义存在显著张力。工程师更倾向 Russell & Norvig 的去本体化定义，因为它便于实现与测试；学者更倾向 Wooldridge 的强定义，因为它便于形式化分析与可验证性。本书采用一种工程导向的扩展定义：智能体是一个能够感知环境状态、维持内部记忆、自主选择动作（含工具调用与其他 agent 通信）、并对结果进行反思的运行时实体。这一定义不要求意识、不要求自由意志，但要求可观测的认知循环——这也是本书所有后续讨论的隐含前提。

1.3 单体 LLM 与多智能体编排的本质区别

工程读者最容易问的问题是：既然有了 GPT-4、Claude 这种通用大模型，为什么还需要多智能体？单体 LLM 难道不能直接完成所有任务吗？ 这个问题的答案隐藏在四个被大多数 prompt engineer 忽视的系统性边界中。

第一，上下文边界（Context Boundary）。 当前主流模型的上下文窗口在 128K–1M tokens 之间，但有效上下文（effective context）远小于标称窗口——Lost-in-the-Middle 现象表明，模型对窗口中段的注意力显著弱于两端。即使使用 1M 窗口，单个对话中也难以容纳：(a) 多个独立任务的完整 prompt；(b) 所有工具的完整 schema 描述；(c) 跨任务的状态信息；(d) 历史对话的完整摘要。MAS 通过上下文分区（context partitioning） 解决了这个问题：每个 agent 拥有自己的 system prompt、自己的 memory、自己的 tool subset，主对话（master conversation）只携带必要的路由信息与摘要。LangGraph 的 state graph、CrewAI 的 crew context，本质上都是上下文分区的工程化实现。

第二，工具调用边界（Tool Invocation Boundary）。 单体 LLM 在调用工具时面临三个具体问题：(1) 工具数量超过 20–30 个时，模型选择准确率显著下降；(2) 不同任务需要不同的工具组合（如代码任务需要 REPL、文档任务需要搜索、研究任务需要浏览器），将所有工具一次性暴露给一个 agent 会造成选择困惑；(3) 工具调用的失败处理（重试、降级、替代）需要专门的状态机。MAS 通过工具路由（tool routing） 解决了这些问题：每个 agent 仅暴露与其角色匹配的工具子集，工具调用在各自的执行沙箱中进行，失败处理由各自的 retry policy 决定。这与微服务架构中 API gateway 的思路如出一辙。

第三，状态管理（State Management）。 单体 LLM 应用的状态通常由开发者通过 conversation buffer、vector store、summary chain 手动维护。这在复杂任务（如多步骤研究、长流程审批、跨系统协调）中会导致：(a) 状态分散在多个数据结构中，难以保证一致性；(b) 状态更新缺乏原子性，容易出现部分失败；(c) 状态可观测性差，调试成本极高。MAS 通过分布式状态（distributed state）+ 主状态协调器（master coordinator） 来管理：在 LangGraph 中表现为 redux-like 的 state graph，每一步都是不可变的状态转换；在 CrewAI 中表现为 hierarchical process 的共享 context store；在 MetaGPT 中表现为 publish-subscribe 的共享消息池。

第四，故障隔离（Failure Isolation）。 在单体 LLM 系统中，任意一个 tool call 失败、任意一次解析错误、任意一次模型超时，都可能导致整个对话状态污染、后续推理偏移甚至无限循环。MAS 通过任务分解（task decomposition）+ 局部重试（local retry） 实现了细粒度的故障隔离：一个 agent 的失败可以仅触发该 agent 的重试或回退，而不污染其他 agent 的状态。这与微服务中的 circuit breaker、bulkhead 模式高度相似。

为了定量说明上述差异，我们可以做一个简化的成本–延迟估算。假设一个研究任务由 5 个子任务组成，每个子任务平均需要 3 次 LLM 调用和 2 次工具调用：

| 架构 | LLM 调用总数 | 端到端延迟（串行） | 端到端延迟（并行） | 上下文占用峰值 | |---|---|---|---|---| | 单体 LLM（顺序执行） | 15 | $5 \cdot T_{llm} + 10 \cdot T_{tool}$ | 不支持 | ~120K tokens | | 多智能体（5 agent 协作） | 15+（含通信开销约 2–4 次） | 不适用 | $T_{llm} + 2 \cdot T_{tool}$（近似） | ~25K tokens / agent |

其中 $T_{llm}$ 表示单次 LLM 推理延迟（约 1–5 秒），$T_{tool}$ 表示单次工具调用延迟（约 0.5–3 秒）。可并行化的子任务越多，MAS 在延迟上的优势越明显。在金融高频决策、多机器人协调等场景下，这一差距足以决定系统的可用性。

需要强调的是，MAS 并非在所有维度上都优于单体 LLM。它的代价包括：(a) 通信开销——agent 之间传递消息需要额外的 LLM 调用，可能造成 10%–30% 的额外 token 成本；(b) 状态同步开销——分布式状态的最终一致性（eventual consistency）可能导致短期不一致；(c) 调试复杂度——从单体系统的单一 trace 变为多 agent 的分布式 trace，可观测性要求显著提升；(d) 协议设计成本——如何定义角色、消息格式、协作模式需要前期投入。因此，MAS 是一种有适用边界的工程选择，而非普适的最优解。

一个朴素的判断准则是：如果任务可以被清晰地分解为多个相对独立的子任务，且子任务之间的状态共享需求较弱，那么 MAS 通常优于单体 LLM；反之，如果任务高度耦合、需要大量共享上下文、且子任务边界模糊，那么单体 LLM + 强 prompt 工程往往更优。 第 6 章我们会给出一个更形式化的决策框架。

1.4 MAS 的工程价值与代价：四个维度的取舍

从单体架构到多智能体架构的迁移，本质上是软件工程中"分治原则"（Divide and Conquer）在 AI 时代的重新应用。本节我们从四个工程维度展开分析。

模块化（Modularity）。 MAS 架构将一个复杂 AI 系统拆分为多个职责单一的 agent，每个 agent 对应一个明确的角色（如 Researcher、Coder、Reviewer、Project Manager）。这种拆分带来的好处是：(a) 单一职责使得每