Don't Build Multi-Agents：为什么多代理系统并非最佳选择 2025-10-31 0 浏览 0 点赞 长文 Don't Build Multi-Agents 文章地址：https://cognition.ai/blog/dont-build-multi-agents 核心观点 "用于 LLM 智能体的框架令人失望。我想基于我们自己的试错经验，提供一些构建智能体的原则，并解释为什么一些诱人的想法在实践中实际上相当糟糕。" 上下文工程的重要性 这篇文章探讨了"上下文工程"（Context Engineering）在构建 AI 代理中的重要性，特别是在处理长时间运行和复杂任务时的可靠性。 核心原则 1. 分享上下文，而非单一消息 代理之间的上下文共享是确保任务一致性的关键。 问题分析： - 如果每个子代理都只知道自己的任务 - 而不了解其他子代理的进展 - 那么最终的结果可能会出现风格不一致或误解 解决方案： - 建立全局上下文共享机制 - 确保所有代理都能访问相关信息 - 维护任务的整体一致性 2. 行为隐含决策 每个行为都代表着一个隐含的决策，因此应该谨慎对待。 关键要点： - 避免使用不符合这一原则的代理架构 - 对于复杂任务，必须管理好上下文窗口 - 防止信息溢出导致的问题 实践建议： - 仔细设计每个代理的行为 - 明确每个决策的影响范围 - 控制上下文窗口的大小 3. 多代理系统的挑战 尽管多代理系统看似能提高效率，但实际应用中存在诸多问题。 主要挑战： - 缺乏有效的跨代理上下文传递 - 系统通常会非常脆弱 - 多个代理协作并未能显著提高性能 - 不能有效地共享和同步信息 为什么多代理系统失败？ 信息孤岛 - 每个代理只知道自己的任务 - 缺乏全局视角 - 难以协调整体目标 上下文丢失 - 跨代理通信时信息损失 - 上下文窗口管理困难 - 历史信息难以追溯 协调成本 - 代理间通信开销大 - 同步机制复杂 - 容易出现竞态条件 上下文工程的未来 "上下文工程"是 AI 代理构建中的核心任务，未来可能会成为构建代理的标准原则。 当前状态： - 尽管有一些理论和方法 - 这一领域仍在不断发展 - 需要灵活性和谦逊 发展方向： - 更好的上下文管理机制 - 统一的上下文共享标准 - 高效的信息传递协议 实践建议 构建单一代理 - 优先考虑单一、强大的代理 - 而非多个弱小的代理 - 通过上下文工程提升能力 管理上下文窗口 - 仔细设计上下文结构 - 优先保留关键信息 - 定期清理无用信息 保持简单 - 避免过度设计 - 从简单方案开始 - 根据实际需求迭代 适用场景 适合单代理 - 需要长期上下文的任务 - 复杂的推理任务 - 需要全局视角的问题 可能需要多代理 - 完全独立的并行任务 - 明确分工的专业任务 - 有清晰边界的子问题 总结 多代理系统虽然在理论上很吸引人，但在实践中往往因为上下文管理问题而表现不佳。构建 AI 代理时，应该优先考虑上下文工程，通过更好的上下文管理来提升单一代理的能力，而不是盲目地构建多代理系统。 文章地址：https://cognition.ai/blog/dont-build-multi-agents 原文链接 Don't Build Multi-Agents 完整文章 #AI Agent #Cognition AI #LLM #上下文工程 #多智能体 #最佳实践 #架构 #系统设计