大多数 AI 系统从一开始就建错了。
大多数人在任务变得复杂时，第一反应就是上多 Agent 系统。这通常是一个错误的直觉。
真正的问题不是"我应该用多个 Agent 吗"，而是"这个任务实际上需要什么样的协作？"
Sub-Agents：带隔离的并行
Sub-agent 是在自己独立上下文里运行的专门实例，本质是委托。你分配专注的工作，它返回干净的结果。
每个 sub-agent 得到：
- 定义其角色的 system prompt -有限的工具集
- 完全隔离的上下文
- 一个范围清晰的任务
完成后它只返回最终输出，不返回推理过程或中间步骤。这很重要，因为 sub-agent 是关于压缩，不只是速度。它们把混乱的探索变成干净的信号。
有严格约束：
- Sub-agents 之间不能互相通信
- Sub-agents 不能生成新的 agents
- 所有东西通过父 Agent 流动
这保持系统可预测和干净。
Agent Teams：协作式通信
Agent teams 为协作构建。不是孤立的工作者，而是有保持上下文、实时通信和实时适应的 agents。包括：一个分配和综合的主 Agent、执行任务的团队成员、追踪进度和依赖的共享任务层。
这实现了真正的协作。前端 Agent 可以通知后端变化，其他东西立即更新。
核心区别
Sub-agents 是执行导向的：隔离、无状态、单次、父 Agent 控制。
Agent teams 是协作导向的：持久、交互、上下文共享、点对点。
用 sub-agents 当任务独立时。用 teams 当任务互相依赖时。
大多数人错在哪
大多数系统按角色划分：规划者、开发者、测试者。这会在每次交接时产生上下文丢失——实现者不知道规划者知道什么，测试者不知道实现者决定什么，质量在每个边界下降。
更好的方法是基于上下文的分解：问——这个任务实际上需要什么信息？如果两个任务共享深层上下文，就把它们放在同一个 Agent 里。只有当上下文可以被干净分离时才拆分。
真正重要的 5 个模式
- Prompt chaining — 顺序步骤
- Routing — 把任务发送到正确的 Agent
- Parallelization — 并行运行独立工作
- Orchestrator–worker — 一个 Agent 委托
- Evaluator–optimizer — 生成并精炼
什么时候不用多 Agent 系统
单一 Agent 就够用的情况：用多 Agent 系统当——你需要上下文隔离，你有并行任务，你需要专业化。
避免用多 Agent 当——Agents 之间高度依赖，协作开销太高，任务很简单。
最终原则：围绕上下文边界设计，而不是角色。从简单开始，只在需要时才增加复杂度。