多Agent系统
多Agent系统（Multi-Agent System）是由多个具备自主决策能力的智能体（Agent）组成的分布式计算架构，各Agent能够感知环境、独立执行子任务，并通过协商、消息传递或共享知识等机制相互协作。该系统适用于单一Agent难以胜任的复杂、动态或大规模任务场景，具有并行处理、模块解耦和容错性强等特点，广泛应用于人工智能、机器人控制、自动化决策等领域。
核心事实
时间轴 (近 90 天)
多Agent系统的失败往往可归因于单个Agent的推理或工具使用不过关，而非协作框架本身，因此建议先用LangGraph等工具把单Agent跑通再引入多Agent编排
多Agent系统的典型冲突包括：两个Agent同时修改同一文件、对同一API配额发起竞争性调用、以及在任务依赖链上产生循环等待。
多Agent系统会引入协调开销、额外推理成本、更多失败模式和潜在分歧，应当在专业化能带来可衡量优势时才使用
将任务拆分给多个subagent会带来子任务结果合并和冲突裁决等新问题，业界对此尚无统一答案
多Agent系统面临的核心挑战包括上下文窗口管理边界、状态一致性保障以及错误传播控制
多Agent系统是企业做降本增效时真正需要的能力，能替代或辅助整条业务链路的自动化
现有的Agent身份验证方案（如基于密码学签名的能力凭证）和沙箱隔离机制提供部分保障，但离生产级别的自组织协作仍有相当距离
为多Agent系统设定对话轮次或token的通信预算，可迫使系统在有限交互内收敛决策，避免无休止讨论
多Agent系统中用文字维持状态的机制会导致通信量随任务复杂度指数级增长，而非线性增长
通过预先定义每个智能体的角色（如规划者、执行者、审查者），可以减少无谓的相互试探并降低通信量
还有 6 条时间轴事件
全部知识事实 (20)
多智能体系统的理论根基可追溯至20世纪80年代的分布式人工智能研究
90%已验证多Agent系统的核心架构通常涉及一个编排Agent（Orchestrator）负责任务拆解与调度，以及多个执行Agent（Worker）负责具体实现
80%已验证多实例并行面临代码冲突、上下文一致性和任务间依赖关系等工程挑战
70%已验证多Agent并行实例数量的增加将使API调用成本线性甚至超线性增长
65%待验证当前多Agent系统面临的核心技术挑战是上下文窗口与长程记忆问题，模型对早期内容的关注度会随对话深度增加而下降（注意力稀释现象）
85%待验证该多Agent系统中每个Agent本质上是一个配置了特定系统提示（System Prompt）和工具集的语言模型实例，通过结构化的消息协议相互通信
85%待验证业界应对长程记忆问题的方案包括外部记忆存储（如向量数据库）、结构化状态机管理和周期性上下文压缩摘要，但目前尚无完美解法
80%待验证协作式Agent在实践中遇到的问题包括信息过载、上下文污染和协作流程设计不当导致的冲突处理机制不完善
70%待验证业界正在探索共享向量数据库、实时代码快照同步以及基于意图的冲突仲裁机制来解决多Agent协作中的上下文一致性问题
70%待验证Agent间通过消息传递、共享内存或事件总线进行通信
60%待验证基于LLM的多智能体系统中，Agent间通信主要有三种方式：共享内存、消息传递、黑板系统
60%待验证多Agent系统中Agent之间的信息传递比人类程序员之间更加完整和结构化
60%待验证多Agent系统中LLM输出的随机性会导致多个Agent串联执行时误差逐层放大，这一现象被称为'误差传播'（Error Propagation）
60%待验证多Agent系统的失败往往可归因于单个Agent的推理或工具使用不过关，而非协作框架本身，因此建议先用LangGraph等工具把单Agent跑通再引入多Agent编排
50%待验证多Agent系统的典型冲突包括：两个Agent同时修改同一文件、对同一API配额发起竞争性调用、以及在任务依赖链上产生循环等待。
50%待验证多Agent系统会引入协调开销、额外推理成本、更多失败模式和潜在分歧，应当在专业化能带来可衡量优势时才使用
50%待验证多Agent系统面临的核心挑战包括上下文窗口管理边界、状态一致性保障以及错误传播控制
50%待验证将任务拆分给多个subagent会带来子任务结果合并和冲突裁决等新问题，业界对此尚无统一答案
50%待验证多Agent系统是企业做降本增效时真正需要的能力，能替代或辅助整条业务链路的自动化
50%待验证现有的Agent身份验证方案（如基于密码学签名的能力凭证）和沙箱隔离机制提供部分保障，但离生产级别的自组织协作仍有相当距离
50%