章节 14 / 29 · 课程总览 · 起始 1:11:35

章节主旨

用一个真实例子演示 Agent Teams:先并行生成若干 analyst agent 各自提方案、内建 debate 达成共识,再据共识分派实现与 review;并借此引出如何用较弱模型压成本、以及 Pipeline 式串行专家交接的取舍。

核心论点

  1. Agent teams 天然自带 debate——因为团队里的 agent 彼此可通信、team lead 又能编排通信,多 agent 共识不必外挂,内建即得。(→ 详解1)
  2. 共识产出要拆成四类看——consensus(收敛建议)、bugs、divergence(分歧)、outliers(离群想法),而非一锅端。(→ 详解2)
  3. 子 agent 用较弱模型往往更划算——sonnet 替 opus 分散执行,同样时间做更多、花更少钱。(→ 详解3)
  4. 专家串行 pipeline 优于单 agent 全包——单 agent 全包会被历史上下文拖出「状态良好区」,且「快速开发」与「深度测试」的激励天然冲突。(→ 详解4)

知识点详解

1. Agent Teams 内建 debate 与共识 1:11:44

是什么。 任务开始时,团队先生成一批 analyst agent,各自带不同 framing 并行跑;UX 底部能看到这些 analyst 线程,可随时 enter 进去看它们在聊什么。它们都先读同一份目标文件(此例是 synaptic-drift.html),再各自给结论。

为什么内建。 把多 agent 共识套到 agent team 上,本质就是 debate 白送:团队里的 agent 本就能互相通信,team lead 还能主动编排这种通信。所以共识不是几个「独立」个体投票,而是可对话协商的——这点比纯独立采样更有意思。

怎么用。 让 team lead 生成 analyst → 各 agent 读料出结论 → 汇总回收并形成共识,随后关闭这批 agent。整个过程你只需在旁按 shift 上下翻看线程。

2. 共识产出的四分结构 1:12:57

是什么。 聚合完各 analyst 的建议后,团队不给你一句话结论,而是拆成四层:

  1. consensus——多数收敛的下一步特征(例:high-res 导出、preset 系统、URL state、可分享链接)。
  2. bugs——过程中被点出的缺陷(例:race condition、mid-render 时下载保存、PNG 高度未校验)。
  3. divergence——明确的分歧比例(例:10 个 agent 里 6 个主张 debounce 重生成 vs. 实时预览)。
  4. outliers——少数离群但可能有价值的点子(移动端响应式、实时动画模式、seed 历史、web worker 卸载等)。

为什么这样拆。 收敛项可直接落地,分歧项标出比例让你自己拍板,离群项则是意外的创意池——四类各有用途,合并看就丢信息了。

3. 子 Agent 的模型分散与 token 权衡 1:14:57

是什么。 实现阶段团队会额外生成 review agent(reviewer bugs、reviewer features)去挑代码质量问题,再把 review 反馈给 team lead。这些外围角色不必都上最强模型。

为什么划算。 当你生成的 subagent 稍弱一些(sonnet 而非 opus),这笔账通常算得过来:同样甚至更短的时间里做得一样多乃至更多,花钱更少。整件事本质是「拿几美元和 token,换一堆 agent 各自出主意并执行」。

分寸。 Nick 明确说存在「最优 token 权衡」,不是无脑全用弱模型;是按角色分散——核心决策留强模型,发散/审查类角色可降配。

4. Pipeline:专家串行交接 1:15:07

是什么。 Pipeline 即在专家 agent 间做顺序交接:任务 A 交给擅长 A 的 agent,产物传给擅长 B 的 agent,再传给 C。前面 agent team 生成 review bug agent 已是这种交接的雏形。

为什么不让一个 agent 全包。 两点:

  1. 上下文污染——单 agent 从头做到尾会积累「它此前做过的一切」的上下文,逐渐滑出「状态良好」的区间,越到后面越乱。
  2. 激励冲突——dev agent 与 test agent 目标相反:开发方被激励用手头一切快速把能跑的东西造出来,测试方被激励尽可能挑出所有毛病;「造新」与「修旧」天然对立。在智能水平持平(都用 opus、不掺杂弱模型)的前提下,把它们拆成各自高度调优的专职 agent,效果明显好于一个 agent 硬扛全部。

怎么用。 建议的分工:A 用 dev agent,B 用 bug fix agent,C 用 test / QA agent,让每段职责各归其位。

术语

  • Agent Teams(agent 团队,一个 team lead 编排一批可互相通信的 agent 协作)
  • Stochastic Multi-Agent Consensus(多 agent 共识,并行多 agent 各自出方案再聚合,套在团队上即内建 debate)
  • Pipeline(流水线,专家 agent 之间顺序交接产物,各司其职)
  • divergence / outliers(分歧项 / 离群项,共识聚合结果里两类非收敛输出)

自检问题

  1. 为什么说 agent teams 的共识「不是独立个体投票」? 答案:因为团队里的 agent 本就能相互通信,team lead 还能编排这种通信,所以共识是可对话协商出来的,而非彼此隔离的独立采样。锚定详解1。 1:12:10
  2. 共识聚合的四层结构分别是什么,各起什么作用? 答案:consensus(可直接落地的收敛建议)、bugs(被点出的缺陷)、divergence(带比例的分歧,供你拍板)、outliers(离群创意池)。锚定详解2。
  3. 为什么宁可用 pipeline 拆专家,也不让单个 agent 全包 A→B→C? 答案:一是单 agent 会被历史上下文污染、滑出「状态良好区」;二是开发与测试激励天然冲突(造新 vs 修旧),拆成专职 agent 在智能持平时效果更好。锚定详解4。 1:16:08