拆解 AI 协作逻辑：Sub-Agents 与 Agent Teams 核心差异
本文分析 AI 系统中 Sub-Agents 与 Agent Teams 两种协作模式的核心差异，指出多数人堆砌 Agent 的误区，强调应根据任务所需的协作模式进行设计，而非盲目增加智能体数量。
在构建 AI 系统时，面对复杂任务，许多人会习惯性地堆砌多个 Agent，认为数量越多越能解决问题。然而，这种做法往往是错误的。设计的核心不在于 Agent 的数量，而在于任务所需的协作模式：是需要隔离执行的 Sub-Agents，还是需要实时通信的 Agent Teams。
核心内容
目前的 AI 系统构建方式大多存在误区。当任务变得复杂，人们倾向于直接套用多智能体架构，但这其实是在增加不必要的系统开销。
Sub-Agents 更像是函数调用。它是一个被高度隔离的实例，拥有独立的系统提示词、工具集和上下文。它只负责把混乱的探索过程压缩成一个干净的信号返回给父级。这种模式追求的是并行与隔离，Sub-Agents 之间无法直接对话，也不能互相创建新实例。这就像是把任务分发给不同的专业外包，你只关心结果，不关心过程。
Agent Teams 则更像是一个动态运行的操作系统。它们强调协作，通过共享任务层和实时通信来同步状态。一个前端 Agent 发现变动，可以立刻通知后端 Agent。这种模式是持久且具有交互性的。
很多人习惯按角色拆分，比如规划者、开发者、测试者。有观点认为，这种做法会导致严重的上下文丢失。执行者不知道规划者的初衷，测试者也不了解执行者的决策细节。每一次交接都是一次信息熵增。
真正有效的拆分逻辑应该是基于上下文边界的。如果两个任务共享深层的背景信息，就把它们留在同一个 Agent 里。只有当上下文可以被干净地剥离时，才进行拆分。
设计时可以参考这五种模式：提示词链、路由、并行化、编排者-执行者、以及评估者-优化者。
价值与影响
如果任务本身很简单，或者 Agent 之间存在极强的依赖关系，强行引入多智能体反而会因为协调开销过大而导致系统崩溃。与其思考需要多少个 Agent，不如问问：这个任务到底需要什么样的协调？
