随着多智能体架构从实验走向生产，开发者面临一个关键问题：何时应该投入精力构建多智能体系统？错误的判断可能导致数月开发付诸东流，而优化单个智能体的提示词就能达到同等效果。本文深入探讨了多智能体的价值与代价，并提出了一个以“上下文耦合度”为核心的决策框架，帮助开发者避免低效的复杂化，精准选择适用场景。
智能速览
多智能体系统并非总是优于单智能体，盲目增加复杂性可能得不偿失。
多智能体架构的主要代价是Token成本剧增和跨智能体的信息损耗，即“通信税”。
判断是否拆分的核心标准是子任务间的上下文耦合度，而非任务类型。
低耦合任务如并行搜索、信息消化、黑盒验证，适合拆分为独立的Sub-agent。
高耦合任务如核心编码开发，应保持在单一上下文中以避免决策链断裂。
业界成熟的实践多采用Orchestrator-Worker模式，Sub-agent更像是可调用的工具。
精华内容
多智能体架构虽带来并行探索等优势，但其引入的成本与信息损耗不容忽视。如何判断投入产出比，避免不必要的复杂性，成为开发者必须思考的问题。
单智能体的瓶颈
当任务复杂度超出单一上下文窗口的承载能力时，单智能体架构会暴露其局限性。一个常见信号是上下文退化：随着对话增长，早期的失败尝试和调试信息会污染后续推理，导致决策质量下降甚至重复错误。
另一个信号是工具集膨胀。当单个智能体可调用的工具超过15至20个时，其选择工具的准确率会显著下降，尤其是在工具定义模糊的情况下。此外，研究类任务中，单个智能体串行搜索的覆盖面有限，难以满足对广度的要求，这些都是单一上下文空间不足的明确迹象。
多智能体的代价
将系统拆分为多个智能体并非没有代价。最直观的是Token成本的跃升。根据Anthropic的实践数据，启用单个Agent比普通聊天多用约4倍Token，而多智能体系统则多用约15倍，这是一笔巨大的开销。
更深层次的代价是信息在传递过程中的损耗，即“通信税”。主智能体向子智能体分发任务时，原始意图的微妙之处可能被简化；子智能体返回结果时，探索过程中的上下文线索又被高度压缩。这种信息损耗有时会抵消掉投入更多Token带来的性能提升。更隐蔽的代价是隐式决策链的断裂，拆分后的智能体无法共享各自行为背后的决策逻辑，容易导致最终的输出结果间产生冲突。
决策的核心原则
既然多智能体有利有弊，那么拆分决策应遵循什么原则？按问题类型（如研究类用多智能体，编码类用单智能体）一刀切的方式过于粗糙。一个编码项目内部，也可能同时包含适合拆分和不适合拆分的子任务。
更有效的判断标准是上下文耦合度：两个子任务需要共享多少上下文才能各自正确完成。决策的边界应该沿着上下文的边界来画，而非沿着功能的边界。如果在上下文耦合度最高的地方（如规划、编码、测试等顺序依赖的环节）强行拆分，信息传递的损耗会最大，效果最差。
场景下的应用
Deep Research是多智能体架构的“理想型”场景，因为不同的研究路径之间天然独立，上下文耦合度极低。搜索“半导体供给侧”和“需求侧趋势”是两条互不干扰的路径，各自只需将最终提炼出的数百Token关键发现返回给主智能体即可，大量的原始搜索数据对其他路径而言是纯粹的噪声。
相比之下，Coding Agent的场景则更复杂。核心编码任务（如架构设计、代码实现）上下文耦合度高，一个文件的改动可能引发连锁反应，不适合拆分。但其中的子任务，如代码搜索、文档消化、测试验证等，耦合度低，则非常适合拆分给专门的Sub-agent处理。
实践判断流程
综合以上分析，可以形成一个简洁的判断流程。首先，应穷尽单智能体的优化空间，包括优化提示词、进行上下文压缩、精简工具集等。许多看似需要多智能体的问题，其实是单智能体的上下文管理没做好。
如果仍有瓶颈，再识别需要扩展的信号，如上下文窗口极限、工具集过大、信息覆盖不足等。最后，根据上下文耦合度进行拆分：低耦合子任务拆分为Sub-agent，高耦合子任务保留在主智能体内。如果无法确定，则默认不拆，因为拆错的代价通常大于不拆。
决定采用多智能体架构的关键，不在于追求技术的时髦，而在于对任务上下文耦合度的深刻洞察。以“上下文耦合度”为尺，审慎地增加系统复杂性，才是构建高效智能体系统的正解。随着AI技术的飞速发展，未来是否会出现延迟、权限等新的决策维度？这仍需我们持续探索与思考。
