Agent Team使用教程：用Tmux分屏把多个AI串成自动协作流水线

原始内容整理自飞书文档：Agent Team 使用教程。本文已重构为 Hexo 博客格式，并将字符画流程图改写为 Mermaid。

如果你已经不满足于“只让一个 AI 帮你写几段代码”，而是想让多个 AI 分工协作，分别负责分析、开发、审查，甚至自动修复问题，那 Agent Team 就是一个很值得尝试的模式。

它的核心思路很简单：

一个 Team Lead，配多个专业 Agent，再用 Skill 和消息机制把它们串起来，最后形成一条从需求到交付的自动化工作流。

一、什么是 Agent Team 模式

Agent Team 是一种多 AI 协作模式。它不是单个 Agent 一口气干完所有事情，而是把任务拆成多个角色，让每个 Agent 专注自己更擅长的部分。

在这个模式里，你通常会得到三层能力：

  • 明确分工：每个 Agent 都有自己的职责
  • 自动协作：Agent 之间可以通过消息继续推进流程
  • 闭环执行：从需求到开发到审查再到修复，可以形成链路

核心概念图

这类模式特别适合：

  • 功能开发
  • Bug 修复
  • 跨角色协作
  • 需要多轮验证的任务

二、Tmux 在这里扮演什么角色

1. 为什么要用 Tmux

Tmux 是一个终端复用器。放在 Agent Team 场景里，它最直观的价值是：

给每个 Agent 一个独立的 pane，让你能同时看到多个 Agent 的工作状态。

也就是说，Tmux 不负责 Agent 的逻辑协作，它负责的是“展示与观察”。

2. Tmux 分屏长什么样

Agent Team 教程概览图

3. 典型的三分屏结构

这就是最常见的一种开发协作布局：

  • reviewer 放左边
  • analyst 放中间
  • developer 放右边

这样你在一个终端窗口里，就能同时看到审查、分析和开发三个角色的输出。

三、快速准备环境

1. 安装 Tmux

1
brew install tmux

2. 创建一个基础会话

1
2
tmux new-session -d -s claude-team
tmux attach-session -t claude-team

3. 分割窗口

1
2
3
4
5
6
7
8
# 左右分屏
Ctrl+b, then %

# 上下分屏
Ctrl+b, then "

# 切换 Pane
Ctrl+b, then 方向键

4. 一个三分屏的命令行示例

1
2
3
4
5
6
7
8
9
10
11
# 1. 创建会话
tmux new-session -d -s claude-team

# 2. 先分成左右
tmux split-window -h -t claude-team:0

# 3. 再把右侧继续分割
tmux split-window -h -t claude-team:0.1

# 4. 进入查看
tmux attach-session -t claude-team

5. 如何查看 Pane 编号

1
Ctrl+b, then q

你会看到每个 pane 的编号，例如 %1、%2、%3。

四、没有 Tmux 能不能用

可以。

这点很重要，因为很多人容易误会：

Agent Team 不依赖 Tmux 才能运行，Tmux 只是让你更方便观察多个 Agent 的输出。

也就是说：

  • 有 Tmux：每个 Agent 独立分屏，更适合演示和监控
  • 没 Tmux：Agent 仍然能正常工作，只是输出混在同一个终端里

五、创建一个最常见的开发协作 Team

1. Team 的基本结构

一个最常见的开发协作 Team，通常会包含三个角色：

Agent 角色 Tmux Pane 核心 Skill 职责
analyst 需求分析专家 %2 brainstorming 深度探索需求、识别风险、设计技术方案
developer 代码实现专家 %3 sdd-dev-workflow 创建 OpenSpec、编码实现、补单测
reviewer 代码审查专家 %1 full-review 多维度审查、问题清单、复审验证

2. 创建 Team

1
2
3
4
TeamCreate({
  team_name: "dev-collaboration",
  description: "开发协作团队"
})

3. 创建团队成员

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Agent({
  name: "analyst",
  subagent_type: "general-purpose",
  team_name: "dev-collaboration",
  description: "需求分析与技术方案专家",
  prompt: "你是需求分析专家..."
})

Agent({
  name: "developer",
  subagent_type: "general-purpose",
  team_name: "dev-collaboration",
  description: "代码实现与开发专家",
  prompt: "你是代码实现专家..."
})

Agent({
  name: "reviewer",
  subagent_type: "general-purpose",
  team_name: "dev-collaboration",
  description: "代码审查与质量保证专家",
  prompt: "你是代码审查专家..."
})

4. 一个常见的 Pane 分配结果

创建顺序 Agent 名称 Pane ID 显示位置
第 1 个创建 reviewer %1 左侧
第 2 个创建 analyst %2 中间
第 3 个创建 developer %3 右侧

六、Agent Team 是怎么协作起来的

1. 从需求到交付的主流程

2. 自动修复闭环

这条闭环很关键，因为它让工作流不再停留在“分析 -> 开发 -> 审查”的线性流水线，而是变成了：

  • 能发现问题
  • 能确认问题
  • 能修复问题
  • 能复审问题

也就是说，Agent Team 的价值不只是“并行干活”，而是“能把流程接住”。

七、三个 Agent 的 Prompt 应该怎么设计

1. analyst

核心职责：

  • 需求澄清与探索
  • 技术方案设计
  • 风险识别

建议工作流：

  1. 收到需求后优先调用 brainstorming
  2. 输出结构化分析结果
  3. 把结果传给 developer

2. developer

核心职责：

  • 代码开发
  • 规范驱动开发
  • 代码质量保证

建议工作流：

  1. 接收 analyst 的分析结果
  2. 使用 sdd-dev-workflow 推进开发
  3. 完成后通知 reviewer

3. reviewer

核心职责：

  • 全面代码审查
  • 质量把关
  • 生成测试建议

建议工作流：

  1. 接收 developer 的完成通知
  2. 使用 full-review 做系统审查
  3. 有问题时回推给 analyst 和 developer
  4. 通过后广播完成

4. 角色分工的一个原则

错误示范是职责重叠：

  • analyst 既分析需求又直接写代码
  • developer 又开发又审查
  • reviewer 又审查又做需求澄清

正确做法是让每个 Agent 的边界尽量清楚：

  • analyst 专注想清楚
  • developer 专注做出来
  • reviewer 专注看仔细

八、Agent 之间是怎么通信的

核心工具是 SendMessage。

1. 发给指定 Agent

1
2
3
4
5
6
SendMessage({
  type: "message",
  recipient: "analyst",
  content: "请分析这个需求",
  summary: "分配分析任务"
})

2. 广播给全员

1
2
3
4
5
SendMessage({
  type: "broadcast",
  content: "任务完成！",
  summary: "完成通知"
})

3. 为什么这个消息机制重要

因为它决定了 Team 不是一堆孤立的 Agent，而是一个会继续向前滚动的系统。

没有消息机制时，流程通常是：

  • Agent 各做各的
  • 每一步都等人工串联

有了消息机制之后，流程就能变成：

  • analyst 做完主动通知 developer
  • developer 做完主动通知 reviewer
  • reviewer 发现问题再主动回推

九、Tmux 和 Team 的对应关系

1. 一个常见映射

2. 推荐的三分屏布局

1
2
3
4
5
┌──────────────┬──────────────┬──────────────┐
│     %1       │     %2       │     %3       │
│   reviewer   │   analyst    │  developer   │
│     🟦       │     🟩       │     🟨       │
└──────────────┴──────────────┴──────────────┘

3. 配置文件会长什么样

创建 Team 后，系统通常会生成类似这样的配置文件：

1
~/.claude/teams/dev-collaboration/config.json

里面会包含：

  • Team 名称和描述
  • Team Lead 信息
  • 每个 Agent 的配置
  • Tmux Pane ID
  • 工作目录

十、几个很实用的最佳实践

1. 明确角色分工

不要让多个 Agent 的职责重叠太多，否则表面上是“多智能体”，实际上只是多份噪音。

2. 设计可回环的工作流

最差的模式是每一步都等人工确认。更好的模式是：

analyst -> developer -> reviewer -> 修复闭环

3. 给 Agent 配专业 Skill

不要只写一句“你来做这个”，而是尽量让角色和 Skill 对齐。

例如：

  • analyst -> brainstorming
  • developer -> sdd-dev-workflow
  • reviewer -> full-review

4. 关键节点要主动同步状态

例如：

  • OpenSpec 提案已生成
  • 开发已完成
  • 审查已开始
  • 问题已修复

这样整个 Team 才能稳定协同，而不是陷入“每个人都在忙，但没人知道现在进展到哪”的状态。

十一、传统方式和 Agent Team 的区别

维度 传统方式 Agent Team
参与方式 1 个 AI + 多次人工干预 1 个 Team Lead + 多个专业 AI
需求分析 快速理解，容易遗漏 深度分析，覆盖更完整
代码实现 直接编码，规范不稳定 按 Skill 和流程推进
代码审查 可能跳过或很轻 多维度系统审查
问题修复 人工发现、人工跟进 自动发现、自动闭环
文档产出 零散 结构化沉淀
人工干预 每一段都要盯 主要在启动和协调时介入

一句话总结差别

传统方式更像：

“让一个 AI 干活，再由人不断兜底。”

Agent Team 更像：

“先把角色、技能和协作关系搭好，再让系统自己把任务往前推。”

十二、常见问题

Q1：Agent 会一直运行吗？

不会。完成任务后，Agent 会进入 idle 状态，不会持续占着资源。

Q2：如何查看 Agent 状态？

Agent 会自动发送 idle 通知。常见状态包括：

  • available
  • busy
  • offline

Q3：如何终止 Agent 或整个 Team？

可以发 shutdown 请求，也可以直接删除整个 Team。

1
TeamDelete()

Q4：Tmux 关闭了，Agent 还在吗？

通常还在。Tmux 窗口只是展示层，关闭它不等于 Team 停止。

Q5：一定要用 Tmux 吗？

不是。Tmux 只是为了让多个 Agent 的输出更容易观察。

十三、可以怎么继续进阶

1. 动态扩 Team

简单任务可以只用：

  • analyst + developer

复杂任务可以扩成：

  • analyst + architect + developer + tester + reviewer

2. 跨 Team 协作

前端 Team 和后端 Team 并行，再由集成 Team 做收口，也是完全可行的。

3. Skill 链式调用

一个 Agent 不一定只能有一个 Skill。比如 developer 可以按顺序接：

  • sdd-dev-workflow
  • unit-test-generator
  • code-quality-optimizer

十四、最后总结

Agent Team 模式最核心的价值，不在“多开几个 AI 窗口”，而在于它把这些东西同时建立起来了：

  1. 专业分工
  2. 自动协作
  3. Skill 约束
  4. 闭环修复
  5. 文档沉淀

它真正适合的场景，是那些已经不是“改一行代码”能解决的问题，而是需要分析、实现、验证和回推的一整条链路。

如果你想开始尝试，最简单的一步就是：

先搭一个三角色 Team：analyst + developer + reviewer

然后让它从一个真实需求开始跑起来。

文档版本：v1.0
适用版本：Claude Code latest
整理时间：2026-06-05