Multi-Agent System
多智能体系统（Multi-Agent System，MAS）是由多个自主智能体组成的计算系统，各智能体能够感知环境、独立决策并相互通信与协作。该架构广泛应用于人工智能、分布式计算和机器人等领域，通过智能体间的协调与交互，实现单一智能体难以完成的复杂任务。其核心特征包括智能体的自主性、系统的分布式结构以及智能体间的动态交互机制。
核心事实
时间轴 (近 90 天)
在多 Agent 场景下，Agent 数量增加会使 Token 呈组合式增长，同时由于请求呈现高度异步、长短不一的特点，GPU 利用率往往低于批量推理，进一步抬高单位任务的实际算力成本。
从短期看，多 Agent 系统的算力成本会限制其大规模商用，能够率先解决推理效率问题的团队将获得显著的成本优势。
推理经济学（Inference Economics）：目前多数 API 按 Token 定价，但多 Agent 系统会产生大量用户看不到的『内部 Token』（Agent 间通信和自检内容），这部分消耗计入账单，若只按对外可见交互轮次做成本预测就会系统性低估真实开支。
基于单次推理定价的成本预测，在多 Agent 场景下可能严重偏低；产品团队按传统方式估算毛利，可能在规模化后发现实际算力开支远超预期。
多 Agent 系统中通常需要仲裁机制或验证层，这增加额外算力开销，系统越复杂，用于协调和验证的算力占比越高。
多智能体系统（Multi-Agent System）并非 LLM 时代的新概念，在经典 AI 与分布式系统领域已有数十年研究积累
在多Agent协作系统中，每个Agent只能看到前一个Agent交给它的输出却无法直接验证其真实性，错误或幻觉输出可能被下游Agent采纳放大形成错误链
多智能体系统中的协调者角色有基于规则的任务路由、基于 LLM 的动态规划、反思-修订循环等几种主流实现方式
多智能体架构相比单一模型在复杂多步骤工作流中往往更稳定、更可控，但也引入消息传递延迟、协调器决策质量和错误传播等新问题
在多Agent系统中，将智能体限定在特定职责范围内能降低单个智能体的决策复杂度
还有 21 条时间轴事件
全部知识事实 (20)
多智能体协作通常通过编排者-执行者模式实现，一个主控Agent负责任务分解与调度
90%已验证多智能体系统的理论根基可追溯至20世纪80年代的分布式人工智能研究
90%已验证多Agent架构通过任务切分让每个Agent只处理自己职责范围内的上下文，从根本上规避单一实例的注意力稀释问题
90%已验证在多Agent场景中，幻觉问题会被级联放大：一个Agent的错误输出可能成为下一个Agent的输入，导致错误在链路中不断累积
90%已验证多Agent系统（Multi-Agent System, MAS）起源于分布式人工智能领域
90%已验证多智能体协作通过让多个专业化Agent分工配合来完成更复杂的任务
80%已验证多智能体系统（MAS）是分布式人工智能领域的经典研究方向，最早可追溯到上世纪80年代
80%已验证多Agent协作架构（MAS）通过多个专门化智能体各司其职并行运转，能规避单一大模型的上下文窗口限制问题
75%已验证多智能体协作系统有三种主流架构模式：管道式（Pipeline）、层级式（Hierarchical）和对等式（Peer-to-Peer）
75%已验证多智能体系统（MAS）最早可追溯到20世纪80年代的分布式问题求解研究
75%已验证Anthropic、OpenAI等机构的研究表明，多Agent协作在长程任务上的表现显著优于单Agent
70%已验证层级式多智能体系统中存在一个Orchestrator（编排者）智能体负责分解任务并向下游子智能体派发工作
65%已验证业界主流的多Agent协作模式包括层级式（Hierarchical）、对等式（Peer-to-Peer）和流水线式（Sequential）
65%已验证在Agent自动执行多步任务的场景下，一个环节的崩溃可能导致整个工作流失败甚至连锁错误操作
65%已验证在多Agent并行编排中，任务分解粒度过粗导致单个Agent上下文过载，粒度过细则产生大量协调开销
65%已验证Multi-Agent System（多智能体系统）是当前AI领域最前沿的研究方向之一，不同专业Skills的Agent可以像企业职能部门一样分工协作
80%待验证在多智能体架构中，Orchestrator-Worker是一种经典设计范式，将复杂任务分解为编排者和工作者两个层级的角色
90%待验证在多Agent群聊中，成员数量过多会导致上下文混乱，降低协作效率，因为每增加一个成员会更快填满可用Token空间
85%待验证多Agent串联形成完整工作流是当前AI应用从工具走向系统的发展方向
80%待验证多Agent系统的速度瓶颈主要来自Agent间通信开销、任务调度复杂性和API调用并发限制三个方面
80%