📒 学霸笔记:Agent Teams——打造你的第一支“虚拟研发团队”
Top Student Notes: Agent Teams — Build Your First “Virtual R&D Team”
课程 / Course: AI 原生开发工作流实战 / AI-Native Development Workflow in Practice
章节 / Section: 前沿技术速递 / Frontier Tech Express
主题 / Topic: Agent Teams(智能体团队)
作者 / Author: Tony Bai
1. 章节定位 / Why This Matters
中文
这一讲讨论的是 2026 年 AI 原生开发的重要新趋势:Agent Orchestration(智能体编排)。
如果说 2025 年的关键词是 Coding Agent,让我们第一次真正感受到“自然语言编程”;那么 2026 年的关键词就是 Agent Teams——不再只是和一个 AI 协作,而是像管理一个“虚拟研发团队”一样,组织多个 Agent 并行工作。
English
This lecture focuses on an important 2026 trend in AI-native development: Agent Orchestration.
If Coding Agents defined 2025 by making “natural-language programming” real, then 2026 is about Agent Teams — not just collaborating with one AI, but managing multiple agents like a virtual engineering team.
2. 核心问题 / Core Problem
中文
在之前的工作流里,我们通常和单个 Agent协作。即使使用了 Sub-agent,本质上仍然是:
- 一次只执行一个角色
- 任务大多是串行推进
- 单个上下文窗口容易成为瓶颈
- 复杂任务中,注意力与记忆容易溢出
当任务变成:
- 前后端并行开发
- 测试与开发同步推进
- 多模块、多语言、多职责协作
单个 Agent 就容易“顾此失彼”。
English
In earlier workflows, we usually collaborated with a single agent. Even with sub-agents, the model was still:
- one role at a time
- mostly serial execution
- limited by one context window
- vulnerable to attention and memory bottlenecks
When tasks become:
- frontend and backend development in parallel
- testing alongside implementation
- multi-module, multi-language, multi-role collaboration
a single agent starts to lose effectiveness.
3. 范式跃迁 / Paradigm Shift
从“单兵作战”到“集群协作”
From Solo Agent to Cluster Collaboration
旧范式 / Old Paradigm
Human ↔ One Agent
└─ sequential work
└─ one context window
└─ one attention focus
新范式 / New Paradigm
Human → Team Lead Agent
├─ Backend Dev Agent
├─ Frontend Dev Agent
├─ QA Agent
└─ (More specialized agents...)
中文
Agent Teams 的本质,是把单个智能体的工作模式,升级为一个多智能体协作系统。
你不再只是“和 AI 一起写代码”,而是在“管理 AI 团队”。
English
The essence of Agent Teams is upgrading from a single-agent workflow into a multi-agent collaborative system.
You are no longer just “coding with AI”; you are managing an AI team.
4. Agent Teams vs Sub-agents / 与 Sub-agents 的本质区别
| 对比项 | Sub-agents | Agent Teams |
|---|---|---|
| 执行方式 | 串行 / Serial | 并行 / Parallel |
| 实例数 | 一个 Claude 会话内切换人格 | 多个独立 Claude Code 实例 |
| 上下文 | 子角色不继承主上下文,但仍受单会话流程限制 | 每个队员拥有独立上下文 |
| 协作方式 | 主 Agent 主导,子角色辅助 | 队员间可通过 mailbox 和 shared task list 协作 |
| 适用任务 | 小范围、角色切换型任务 | 复杂、可拆解、模块隔离度高的任务 |
一句话总结 / One-line Summary
- Sub-agents = 智能分身 / smart personas
- Agent Teams = 虚拟团队 / virtual team
5. Agent Teams 架构 / Architecture
┌────────────────────┐
│ Human Commander │
│ 人类指挥官 │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Team Lead (队长) │
│ - 任务拆解 │
│ - 分工调度 │
│ - 进度协调 │
│ - 结果汇总 │
└──────┬────┬────────┘
│ │
┌─────────────┘ └─────────────┐
▼ ▼
┌────────────────┐ ┌────────────────┐
│ Backend Dev │ │ Frontend Dev │
│ 后端开发队员 │ │ 前端开发队员 │
└────────────────┘ └────────────────┘
└─────────────┬─────────────┘
▼
┌────────────────┐
│ QA Engineer │
│ 测试工程师 │
└────────────────┘
Team Lead(队长)职责 / Responsibilities
- 拆解任务 / Break down tasks
- 分配工作 / Assign tasks
- 协调进度 / Coordinate progress
- 合成结果 / Synthesize results
- 保持全局视野 / Maintain global vision
Teammates(队员)职责 / Responsibilities
- 聚焦自己的任务域 / Focus on their own domain
- 使用独立上下文窗口 / Use independent context windows
- 与其他队员直接通信 / Communicate directly with other teammates
- 在共享任务列表中协作 / Collaborate via shared task list
6. 三大核心优势 / Three Core Advantages
6.1 完全并行 / Full Parallelism
中文
前端、后端、测试可以同时开工,彼此互不阻塞。
English
Frontend, backend, and testing can all start at the same time without blocking each other.
6.2 独立上下文 / Isolated Context
中文
每个 Agent 只关心自己的任务,不会被其他任务细节污染。
English
Each agent only focuses on its own task and is not polluted by irrelevant details from other tasks.
6.3 自主协同 / Autonomous Coordination
中文
队员之间可通过消息和共享任务列表协作,不需要人类频繁充当“传声筒”。
English
Teammates can collaborate through messages and a shared task list, reducing the need for the human to act as a go-between.
7. 业界前沿案例 / Frontier Industry Example
16 个 Claude 重写 C 编译器
16 Claudes Rebuilding a C Compiler
案例信息 / Case Snapshot
Anthropic 研究团队做了一个极具代表性的实验:
- 启动 16 个 Claude Code Agent
- 用 Rust 从零开始写一个 C 编译器
- 基于 Git 仓库同步协作
- 分工覆盖:
- 词法分析 / Lexical analysis
- 语法分析 / Parsing
- IR 生成 / IR generation
- 寄存器分配 / Register allocation
- 汇编生成 / Assembly generation
- 性能优化 / Performance optimization
- 架构审查 / Architecture critique
测试策略 / Testing Strategy
- 使用 GCC 作为 Oracle(预言机)
- 对比 Claude 编译器输出与 GCC 输出
- 以此验证正确性
结果 / Result
- 消耗约 20 亿输入 Token
- 产出约 10 万行代码
- 可编译:
- SQLite
- Redis
- PostgreSQL
- Linux 6.9 内核(x86 / ARM / RISC-V)
启示 / Takeaway
当多个 Agent 拥有独立上下文并能协同工作时,它们可处理的工程复杂度会指数级上升。
When multiple agents have isolated contexts and can coordinate, the complexity they can handle grows exponentially.
8. 实战演练 / Practical Demo
任务:10 分钟开发一个 Todo List 全栈应用
Task: Build a Full-Stack Todo App in 10 Minutes
需求 / Requirements
- 后端 / Backend: Go + Gin + SQLite,提供 RESTful API(CRUD)
- 前端 / Frontend: React + Vite + TailwindCSS,单页应用
- 测试 / Testing: 为后端 API 编写集成测试
9. 环境准备 / Environment Setup
启用实验特性 / Enable Experimental Feature
# 在 ~/.claude/settings.json 中设置 / In ~/.claude/settings.json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
# 或通过环境变量 / Or via environment variable
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
版本要求 / Version Requirement
- Claude Code 2.1.32+
- 可通过
/status查看版本 / Check version with/status
推荐环境 / Recommended Environment
- iTerm2 (macOS)
- tmux
因为支持 Split Panes(分屏模式),可同时观察多个 Agent 的工作状态。
Because Split Panes let you observe multiple agents simultaneously.
teammateMode
- 默认是
auto - 系统会自动决定使用:
- 分屏显示模式 / Split-pane mode
- 进程内显示模式 / In-process mode
10. 指挥官 Prompt / Commander Prompt
我要开发一个最简单的 Todo List 应用,包含:
后端:使用 Go + Gin + SQLite,提供 RESTful API(增删改查)。
前端:使用 React + Vite + TailwindCSS,实现单页应用。
测试:为后端 API 编写集成测试。
请创建一个 Agent Team 来并行完成这个任务:
Backend Dev:负责后端代码和数据库设计。
Frontend Dev:负责前端页面和 API 调用。
QA Engineer:负责编写测试脚本。
你是 Team Lead。请先规划 API 接口定义,然后指挥前后端并行开发,最后由 QA 进行验证。
Prompt 设计亮点 / Why This Prompt Works
- 明确目标 / Clear goal
- 明确技术栈 / Clear tech stack
- 明确角色分工 / Clear role assignments
- 明确执行顺序 / Clear workflow sequence
- 指定 Team Lead 身份 / Explicit Team Lead identity
11. 观察协作流程 / Collaboration Flow
工作流分解 / Workflow Breakdown
Step 1: Team Lead 分析需求并初始化团队
Step 2: Team Lead 定义 API 接口
Step 3: Backend Dev 与 Frontend Dev 并行开发
Step 4: QA Engineer 等待依赖完成后开始验证
Step 5: Team Lead 定期收集进展
Step 6: 所有队员确认关闭任务
Step 7: Team Lead 汇总结果并清理团队
中文理解
这里最关键的一点是:QA 并不是一开始就能动手。
如果它依赖后端 API 或前端页面,它会进入等待状态,直到其他队员产出足够的工作结果。
English Understanding
A key observation is that QA cannot always start immediately.
If it depends on backend APIs or frontend pages, it will wait until enough work has been completed by other teammates.
12. 人类如何介入 / How Humans Intervene
查看队员状态 / Inspect Teammates
- 使用
Ctrl + t打开 teammate 列表
权限模型 / Permission Model
- teammate 初始权限 = Team Lead 权限
- 如果 Lead 使用:
--dangerously-skip-permissions - 那么所有队友也会继承该权限
风险与收益 / Trade-off
收益 / Benefit:
- 团队工作更流畅
- 减少人工频繁确认
风险 / Risk:
- 安全边界更宽松
- 需要更高的环境信任度
13. 验收与收尾 / Acceptance and Cleanup
收尾过程 / Closure Process
当所有任务完成后:
- Frontend Dev 确认关闭
- QA Engineer 确认测试完成
- Backend Dev 确认关闭
- Team Lead 清理团队
- 向人类汇报结果
如果本地还保留团队痕迹,可显式输入:
Clean up the team
14. 本地存储位置 / Local Storage Locations
团队配置 / Team Config
~/.claude/teams/{team-name}/config.json
任务配置 / Task Data
~/.claude/tasks/{team-name}/
中文
这说明 Agent Teams 并不是“纯概念功能”,而是真正在本地维护了团队配置与任务状态。
English
This shows Agent Teams are not just conceptual — they maintain actual local configuration and task state.
15. 最佳实践 / Best Practices
15.1 任务粒度要合适 / Choose the Right Task Granularity
适合单 Agent 的情况 / Better for a Single Agent
- 线性任务 / Linear tasks
- 强依赖顺序 / Strong sequential dependencies
- 改 A 后再改 B / Edit A, then B
适合 Agent Teams 的情况 / Better for Agent Teams
- 并行度高 / High parallelism
- 模块隔离度高 / Strong modular separation
- 前后端联调 / Frontend-backend coordination
- 多语言翻译 / Multi-language translation
- 微服务拆分 / Microservice decomposition
原则 / Principle: 不要为了用而用。
Don’t use Agent Teams just for the sake of using them.
15.2 关注 Token 成本 / Watch Token Costs
中文
每个 Teammate 都是独立 Claude 实例,意味着:
- 独立上下文
- 独立推理
- 独立 Token 消耗
所以 5 人团队,成本可能接近单 Agent 的 5 倍。
English
Each teammate is an independent Claude instance with:
- its own context
- its own reasoning
- its own token consumption
So a 5-agent team may cost roughly 5x that of a single-agent workflow.
Delegate Mode(委派模式)
- 让 Team Lead 只负责指挥和传递消息
- 不自己写代码,避免“抢活”
- 减少上下文浪费
切换方式:
- 创建团队后按 Shift + Tab
15.3 角色定义要清晰 / Define Roles Clearly
中文
角色越具体,效果通常越好。
例如:
- “最苛刻的安全审计员”
- “追求极致性能的 C++ 专家”
- “专门盯错误日志的运维工程师”
English
The more specific the role, the better the collaboration usually becomes.
Examples:
- “the strictest security auditor”
- “a performance-obsessed C++ expert”
- “an ops engineer focused on error logs”
15.4 显示模式建议 / Display Mode Recommendation
中文
如果环境允许,优先使用 Split Panes 模式,因为你可以:
- 同时观察多个 Agent
- 实时监控协作状态
- 获得真正的“上帝视角”
English
If your environment supports it, prefer Split Panes mode because you can:
- observe multiple agents at once
- monitor collaboration in real time
- gain a true “god view” of the team
16. 本讲核心结论 / Key Conclusions
结论 1 / Conclusion 1
Agent Teams 标志着软件工程从“人机结对编程”走向“人机组织管理”。
Agent Teams mark the shift from human-AI pair programming to human-AI organizational management.
结论 2 / Conclusion 2
并行执行 + 自主协同 是 Agent Teams 相比 Sub-agents 的决定性优势。
Parallel execution + autonomous coordination are the defining advantages over sub-agents.
结论 3 / Conclusion 3
Agent Teams 特别适合:
- 结构复杂任务 / structurally complex tasks
- 单 Agent 难以覆盖的工程问题 / engineering problems too large for one agent
- 高并行、强分工场景 / highly parallel, strongly partitioned work
结论 4 / Conclusion 4
未来高级工程师的重要能力之一,可能不再只是“自己写多少代码”,而是:
你是否能指挥一支由 AI 组成的虚拟研发团队,在半小时内解决过去一周的工程问题。
Whether you can direct a virtual AI engineering team to solve in 30 minutes what used to take a week.
17. 高频考点 / Exam-Style Key Points
Q1. Agent Teams 与 Sub-agents 最大区别是什么?
答 / Answer:
Sub-agents 是同一会话下的角色切换,主要是串行执行;
Agent Teams 是多个独立实例并行协作,拥有独立上下文与直接协作能力。
Q2. Agent Teams 的核心架构是什么?
答 / Answer:
Team Lead + Teammates
Lead 负责规划、调度、协调、汇总;
Teammates 负责各自任务,并通过 mailbox 和 shared task list 协作。
Q3. 为什么 Agent Teams 适合复杂任务?
答 / Answer:
因为它能通过:
- 任务拆解
- 并行推进
- 上下文隔离
- 自主协同
来突破单 Agent 的上下文与注意力瓶颈。
Q4. 使用 Agent Teams 的主要代价是什么?
答 / Answer:
- Token 成本显著增加
- 组织复杂度提高
- 权限管理更敏感
18. 思维导图 / Mind Map
Agent Teams
│
├─ 背景
│ ├─ 2025: Coding Agent
│ └─ 2026: Agent Orchestration
│
├─ 核心问题
│ └─ 单 Agent 的上下文和注意力瓶颈
│
├─ 架构
│ ├─ Team Lead
│ └─ Teammates
│
├─ 优势
│ ├─ 并行执行
│ ├─ 独立上下文
│ └─ 自主协同
│
├─ 对比 Sub-agents
│ ├─ Sub-agents = 串行角色切换
│ └─ Agent Teams = 多实例并行协作
│
├─ 实战
│ └─ Todo 全栈应用
│ ├─ Backend Dev
│ ├─ Frontend Dev
│ └─ QA Engineer
│
├─ 最佳实践
│ ├─ 合适的任务粒度
│ ├─ 关注 Token 成本
│ ├─ 清晰角色定义
│ └─ 推荐 Split Panes
│
└─ 趋势
└─ 从“写代码的人”变成“管理 AI 团队的人”
19. 学霸级总结 / Top-Student Summary
中文
这篇文章的核心,是让我们从“使用一个 AI 工具”升级到“管理一组 AI 成员”。
Agent Teams = 多个独立 Agent 的并行协作系统,通过 Team Lead 统一调度、Teammates 独立执行,突破了单 Agent 的上下文限制。它特别适合复杂、可拆分、高并行的工程任务,如前后端联调、测试协作、多模块开发。
但它也不是银弹:需要关注 任务粒度、Token 成本、角色定义与权限控制。
未来的软件工程师,不只是写代码的人,更是 AI 虚拟研发团队的组织者、指挥者和验收者。
English
The core of this lecture is a mindset upgrade: from using one AI tool to managing a team of AI workers.
Agent Teams = a parallel collaboration system of multiple independent agents, coordinated by a Team Lead and executed by specialized teammates. This breaks the context limitation of a single agent and is especially useful for complex, decomposable, highly parallel engineering tasks.
However, it is not a silver bullet: you must manage task granularity, token cost, role clarity, and permissions.
The future software engineer is not just someone who writes code, but someone who organizes, directs, and validates an AI virtual R&D team.
20. 一句话记忆 / One-Sentence Memory Hook
Agent Teams 不是“更强的单个 AI”,而是“可被你指挥的 AI 组织”。
Agent Teams are not just a stronger single AI, but an AI organization you can direct.
如果你愿意,我下一步可以继续为你整理这一讲的:
- 课后复习版精简笔记 / concise revision notes
- 面试问答版 / interview Q&A version
- 可直接保存的
.md原文件版本 / clean markdown source - 与前面 Agent Skills 一讲的对比总结 / comparison with Agent Skills