AI Agent Teams 配置与实战指南

向夏威夷梦断明暄

195人浏览 · 2026-07-14 21:52:06

向夏威夷梦断明暄 · 2026-07-14 21:52:06 发布

为什么需要 Agent Teams？
你有没有过这种经历：

本来要加个登录功能，写着写着顺便"优化"了数据库连接池
优化完发现原来的认证逻辑被改坏了
改回来，又改坏了另一个模块
最后回头一看——登录功能还没做完
这就是目标漂移和质量失控。

Agent Teams 的思路很简单：把一个 AI 拆成多个角色，每个角色有明确的职责边界。

Planner 产品经理 → Builder 开发 → Reviewer QA
Planner（产品经理）：分析需求，锁定目标，生成实施 spec。目标写入持久文件，后续所有阶段都读这个文件
Builder（开发）：严格按 spec 写代码。不越界，不自行优化
Reviewer（QA）：对照 spec 审查。检测目标偏移、功能偏移、回归风险
核心保障：目标持久化。 Planner 把目标写入文件，不依赖对话记忆。Builder 和 Reviewer 每次都从文件读取目标，不从上下文推断。用户中途说"顺便优化 XXX"，Planner 读文件判断偏离，拒绝并记入 backlog。

二、Claude Code：从零搭建 Agent Teams
2.1 安装 Claude Code
先确保装好 Claude Code CLI：

macOS / Linux

npm install -g @anthropic-ai/claude-code

或者直接从官网下载

https://docs.anthropic.com/en/docs/claude-code/overview

验证安装：

claude --version
2.2 开启 Agent Teams
Agent Teams 是实验性功能，默认关闭。需要在配置中开启：

编辑 ~/.claude/settings.json（全局）或项目级 .claude/settings.json：

{
“env”: {
“CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS”: “1”
}
}
💡 提示：设置这个环境变量后，重启 Claude Code 即可生效。不需要写任何代码或配置文件。

2.3 定义 Agent 角色（可选但推荐）
在 ~/.claude/agents/ 目录下创建 markdown 文件，每个文件定义一个 agent 角色：

~/.claude/agents/
├── planner.md ← 产品经理：分析需求，锁定目标
├── builder.md ← 开发：按 spec 写代码
└── reviewer.md ← QA：审查，检测偏移
文件格式：YAML frontmatter + Markdown body：

name: planner
description: 项目目标守护者。分析需求，持久化目标，确保不被偏移。
tools: Read, Grep, Glob, Bash

你是"目标守护者"。核心职责：

分析用户需求，判断是否在项目目标范围内
将最终目标写入持久文件，不依赖对话记忆
生成可执行的实施 spec
遇到歧义必须 ask，不要自己假设
不能写代码——只出计划和 spec
builder.md 和 reviewer.md 同理。

2.4 使用 Agent Teams
在 Claude Code 中直接用自然语言：

让 Claude 自动分配任务

我要做一个用户管理系统。Spawn 三个 teammate：

planner 负责分析需求和锁定目标
builder 负责写代码
reviewer 负责审查

或者更简洁

用 planner→builder→reviewer 流程做一个登录功能
Claude 会自动 spawn teammate，分配任务，协调工作。Teammate 之间可以通过共享 task list 通信。

💡 关键区别

Subagents（子代理）只能向主 agent 报告结果，不能互相通信。Agent Teams（团队）中 teammate 可以直接互相发消息、共享任务列表。对于需要协作讨论的复杂任务，用 Teams；对于只需要结果的简单任务，用 Subagents。

三、其他工具：opencode / MiMoCode 配置
如果你用的是 opencode 或 MiMoCode（opencode 的增强版），agent team 的实现方式不同——通过 skill 系统来实现相同的效果。

3.1 Skill 系统 vs Agent Teams
维度 Claude Code Agent Teams opencode / MiMoCode Skills
编排方式 Lead agent 自动协调 teammate 主 agent 按 skill 顺序执行
通信 Teammate 之间直接通信单向：每个阶段输出传递给下一阶段
配置 ~/.claude/agents/.md .mimocode/skills//SKILL.md
持久化共享 task list 文件系统（GOAL.md / SPEC.md）
3.2 配置步骤
第一步：创建 skill 目录

在项目根目录下

mkdir -p .mimocode/skills/planner
mkdir -p .mimocode/skills/builder
mkdir -p .mimocode/skills/reviewer
mkdir -p .mimocode/skills/develop
mkdir -p .mimocode/dev
第二步：创建四个 SKILL.md 文件

.mimocode/
├── dev/
│ ├── GOAL.md ← planner 持久化目标（不可变）
│ ├── SPEC.md ← planner 生成实施 spec
│ └── BACKLOG.md ← 被拒绝的优化请求
└── skills/
├── planner/SKILL.md
├── builder/SKILL.md
├── reviewer/SKILL.md
└── develop/SKILL.md
第三步：在配置中注册 skill 路径

编辑全局配置 ~/.config/mimocode/config.json：

{
“$schema”: “https://mimo.xiaomi.com/mimocode/config.json”,
“skills”: {
“paths”: [“.mimocode/skills”]
}
}
重启后生效。

3.3 Planner Skill 示例

name: planner
description: 项目目标守护者。分析需求，持久化目标到文件，确保目标不被偏移。

Planner - 目标守护者

执行流程

分析用户需求，判断是否在项目目标范围内
持久化目标：将最终目标写入 .mimocode/dev/GOAL.md
生成 spec：将实施步骤写入 .mimocode/dev/SPEC.md
如果用户中途提出优化请求，检查是否偏离 GOAL.md，偏离则拒绝

强制规则

GOAL.md 一旦写入不可被 builder/reviewer 修改
你不能写代码——只出计划和 spec
遇到歧义必须 ask 用户澄清
3.4 Builder 和 Reviewer
Builder 的核心规则：每次开始前读取 GOAL.md 和 SPEC.md，严格按 spec 写代码，遇到边界情况停下来问。

Reviewer 的核心规则：每次审查前读取 GOAL.md 和 SPEC.md，对照检查 spec 合规、目标偏移、功能偏移、回归风险，给出 APPROVE 或 REJECT。

⚠️ 关键设计原则

Builder 和 Reviewer 每次都从文件读取目标，不从对话上下文推断。这是防止目标漂移的核心机制。对话记忆会随着 turn 增加而衰减，但文件不会。

四、实战：安卓劫持项目完整落地
以 D:\Desktop\安卓劫持项目为例，展示完整的 develop workflow 流程。

4.1 项目背景
这是一个 Android 安全研究项目，包含一个伪装成系统工具的双层 App。核心架构：

前端伪装：SystemToolActivity 显示系统信息和"一键优化"按钮
隐藏触发：点击 Android 版本文本 7 次 → 显示"高级功能"区域
霸屏机制：三层防逃逸（Activity 拦截 + Service 浮层 + AccessibilityService 回拉）
4.2 Planner 阶段：锁定目标
用户输入：“给 App 加一个屏幕录制功能”

Planner 分析后写入持久文件：

GOAL.md（不可变）

项目最终目标

构建一个伪装成系统工具的 Android 安全研究 App，包含：

前端伪装层（系统信息展示 + 一键优化）
隐藏功能触发（连续点击触发高级功能）
霸屏劫持机制（三层防逃逸）
开机自启 + 状态管理

SPEC.md（本次实施）

实施步骤

在 SystemToolActivity 添加 MediaRecorder 权限声明
创建 ScreenRecordService 前台服务
在高级功能区域添加"屏幕录制"开关
开关启动/停止录制，录制文件保存到 app 私有目录
添加录制时长显示

验收标准

录制开关在高级功能区域内
录制时状态栏有通知
录制文件可正常播放
用户中途说：“顺便把数据库连接池也优化一下”

Planner 读取 GOAL.md，判断：数据库优化不在当前目标范围内 → 拒绝，记入 BACKLOG.md。

4.3 Builder 阶段：按 Spec 实现
Builder 读取 GOAL.md 和 SPEC.md，严格按步骤实现：

Builder 输出

实现了什么

按 SPEC.md 步骤 1-5 完成

改动了哪些文件

AndroidManifest.xml: 添加 RECORD_AUDIO 权限
app/src/…/ScreenRecordService.java: 新建前台服务
app/src/…/SystemToolActivity.java: 添加录制开关逻辑

测试结果

录制启动/停止: 通过
状态栏通知: 通过
文件保存: 通过

未覆盖的边界

SPEC.md 未说明录制分辨率/帧率，使用默认值
4.4 Reviewer 阶段：检测偏移
Reviewer 读取 GOAL.md 和 SPEC.md，逐项审查：

Reviewer 输出

审查结论: APPROVE

Spec 合规

步骤1: 权限声明已添加
步骤2: ScreenRecordService 已创建
步骤3: 高级功能区域已添加开关
步骤4: 启动/停止逻辑已实现
步骤5: 录制时长显示已实现

目标偏移

未引入与项目目标无关的功能 ✓

功能偏移

未引入 SPEC.md 未要求的功能 ✓

回归风险

未修改已有功能 ✓

测试覆盖

关键路径已测试 ✓
4.5 文件结构
D:\Desktop\安卓劫持
├── .mimocode/
│ ├── dev/
│ │ ├── GOAL.md ← 项目最终目标（不可变）
│ │ ├── SPEC.md ← 本次实施 spec
│ │ └── BACKLOG.md ← 被拒绝的优化请求
│ └── skills/
│ ├── planner/SKILL.md
│ ├── builder/SKILL.md
│ ├── reviewer/SKILL.md
│ └── develop/SKILL.md
├── app/src/
│ └── main/java/com/example/utilitybox/
│ ├── SystemToolActivity.java
│ ├── ScreenRecordService.java
│ ├── BackgroundService.java
│ ├── HijackState.java
│ └── SystemAccessibilityService.java
├── build.gradle.kts
└── settings.gradle.kts
五、真实对话：从零拉起团队
以下是 Claude Code Agent Teams 的真实操作记录，展示从开启功能到团队就绪的完整过程。

5.1 启动 Claude Code
PS C:\Users\GOD> claude

╭─── Claude Code v2.1.139 ─────────────────────────────────────────────────╮
│ Welcome back! │
│ deepseek-v4-pro · API Usage Billing │
│ C:\Users\GOD │
╰──────────────────────────────────────────────────────────────────────────╯
5.2 用自然语言拉起团队
不需要写任何配置文件，直接说：

❯ Spawn 三个 teammate：

planner 负责分析需求、锁定目标、生成 spec
builder 负责按 spec 写代码
reviewer 负责审查有没有目标偏移和回归问题
你看一下现在的 “D:\Desktop\安卓劫持” 这个项目
Claude 自动读取项目结构，理解上下文。

5.3 持久化到 Memory
teammate 默认只在当前会话有效。通过 memory 持久化，下次新会话可以恢复：

❯ 这三个 teammate 只对这个项目生效，可以写到 memory

● 记忆已写入。现在创建团队并拉起三个 teammate。

3 background agents launched (↓ to manage)
├ @planner
├ @builder
└ @reviewer
💡 关键操作：把团队配置写入 memory 后，下次在新会话中说"拉起安卓劫持团队"，Claude 会读取记忆、重建这三个 teammate。不需要每次都重新描述角色。

5.4 团队就绪
● 全部完成。总结一下：

记忆已持久化（跨会话保留）：

project_android_hijack.md — 项目概要、技术栈、协作模式
reference_android_hijack_team.md — 三角色定义和拉起方式

团队已创建：android-hijack，三名 teammate 正在后台加载项目上下文：

┌──────────┬──────────┬─────────────────────────────┐
│ 角色 │ 名称 │ 职责 │
├──────────┼──────────┼─────────────────────────────┤
│ Planner │ planner │ 读需求 → 定位源码 → 出 spec │
├──────────┼──────────┼─────────────────────────────┤
│ Builder │ builder │ 读 spec → 改代码 │
├──────────┼──────────┼─────────────────────────────┤
│ Reviewer │ reviewer │ 对比 spec vs diff → 查回归 │
└──────────┴──────────┴─────────────────────────────┘

新会话下说"拉起安卓劫持团队"我就会读取记忆、重建这三个 teammate。
5.5 分配任务
❯ 目前已经开发到了 v3.03 现状与计划.md，可以看一下。还有几点要交代：