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