多Agent系统
多Agent系统（Multi-Agent System）是由多个具备自主决策能力的智能体（Agent）组成的分布式计算架构，各Agent能够感知环境、独立执行子任务，并通过协商、消息传递或共享知识等机制相互协作。该系统适用于单一Agent难以胜任的复杂、动态或大规模任务场景，具有并行处理、模块解耦和容错性强等特点，广泛应用于人工智能、机器人控制、自动化决策等领域。
核心事实
时间轴 (近 90 天)
由于每个Agent都可能带来自主决策的不确定性，多Agent系统的整体行为难以像单Agent那样通过简单提示词约束来保证，需要引入编排框架、角色定义、轮次限制和结果校验等额外工程手段。
系统中大多数Agent并不需要最强的模型，真正需要强模型的Agent通常很容易识别，比如对语气、判断力或复杂推理有要求的环节。
按Agent分配模型可以同时解决为简单查询支付前沿模型高成本和判断力任务得到弱回答两个问题。
单纯增加 Agent 数量并不能线性提升产出，反而可能因为协调成本上升而降低整体效率。
没有沙箱隔离的多Agent协同框架在生产环境是不可接受的。
全量传递上下文历史适合两跳以内、对准确性要求极高的短链场景。
加州伯克利分析过1600多条真实执行轨迹，发现接近四成的失败并非单个Agent能力不足，而是Agent之间信息没对齐。
多Agent的难点不是把单个Agent造出来，而是设计上下文怎么在它们之间流动。
多Agent系统中三个常见反模式：无脑转发完整历史、拿散文当交接没有schema、把线性流程硬拆成多Agent。
写摘要时的视角应该是“下一个Agent需要什么”，而不是“我刚才做了什么”。
还有 28 条时间轴事件
全部知识事实 (20)
多智能体协作通常通过编排者-执行者模式实现，一个主控Agent负责任务分解与调度
90%已验证多智能体系统的理论根基可追溯至20世纪80年代的分布式人工智能研究
90%已验证多Agent系统的核心架构通常涉及一个编排Agent（Orchestrator）负责任务拆解与调度，以及多个执行Agent（Worker）负责具体实现
80%已验证多实例并行面临代码冲突、上下文一致性和任务间依赖关系等工程挑战
70%已验证多Agent并行实例数量的增加将使API调用成本线性甚至超线性增长
65%待验证当前多Agent系统面临的核心技术挑战是上下文窗口与长程记忆问题，模型对早期内容的关注度会随对话深度增加而下降（注意力稀释现象）
85%待验证该多Agent系统中每个Agent本质上是一个配置了特定系统提示（System Prompt）和工具集的语言模型实例，通过结构化的消息协议相互通信
85%待验证业界应对长程记忆问题的方案包括外部记忆存储（如向量数据库）、结构化状态机管理和周期性上下文压缩摘要，但目前尚无完美解法
80%待验证业界正在探索共享向量数据库、实时代码快照同步以及基于意图的冲突仲裁机制来解决多Agent协作中的上下文一致性问题
70%待验证Agent间通过消息传递、共享内存或事件总线进行通信
60%待验证多Agent系统的Agent间通信机制包括三类：黑板系统、消息传递和共享内存模型
60%待验证基于LLM的多智能体系统中，Agent间通信主要有三种方式：共享内存、消息传递、黑板系统
60%待验证协作式Agent在实践中遇到的问题包括信息过载、上下文污染和协作流程设计不当导致的冲突处理机制不完善
60%待验证多Agent系统中Agent之间的信息传递比人类程序员之间更加完整和结构化
60%待验证多Agent系统中LLM输出的随机性会导致多个Agent串联执行时误差逐层放大，这一现象被称为'误差传播'（Error Propagation）
60%待验证由于每个Agent都可能带来自主决策的不确定性，多Agent系统的整体行为难以像单Agent那样通过简单提示词约束来保证，需要引入编排框架、角色定义、轮次限制和结果校验等额外工程手段。
50%待验证按Agent分配模型可以同时解决为简单查询支付前沿模型高成本和判断力任务得到弱回答两个问题。
50%待验证系统中大多数Agent并不需要最强的模型，真正需要强模型的Agent通常很容易识别，比如对语气、判断力或复杂推理有要求的环节。
50%待验证单纯增加 Agent 数量并不能线性提升产出，反而可能因为协调成本上升而降低整体效率。
50%待验证没有沙箱隔离的多Agent协同框架在生产环境是不可接受的。
50%