Claude AI 代理团队完全指南：让多个 AI 协同工作
在开始使用代理团队之前，建议先做一个准备工作：让 Claude 学习代理团队的官方文档。你可以提供文档链接，让它生成一份本地参考指南，这样在后续构建过程中查询会更快速。
如何编写提示词
代理团队的成本较高，速度也相对较慢，但如果使用得当，输出质量会显著提升。好消息是，你可以用接近自然语言的方式来调用它们。
基本的提示词模式是：指定使用哪个模型（Sonnet 或 Opus）组建多少个代理，然后为每个代理定义角色、职责和协作方式。
提示词的关键要素包括：首先设定一个明确的目标，因为代理启动时只能看到你输入的提示，没有其他上下文。例如：”目标是构建一个可运行的全栈应用，配备 REST API 和 React 前端。最终结果应该是一个可以在本地主机上查看的运行应用，包含用户和帖子功能，以及一份 QA 测试报告。”
然后定义团队结构：”组建一个三人团队，使用 Sonnet 模型。第一个是后端开发者，第二个是前端开发者，第三个是质量保证人员。”在描述中要明确协作流程：”后端开发者完成后，给前端开发者发消息。前端开发者等待后端的消息，完成后把所有内容发给质量保证人员。”最后说明最终交付物：运行中的应用、测试报告和关键决策文档。
该做与不该做的事项
务必做到：
- 让每个代理拥有特定的文件：避免代理共享文件，防止互相覆盖工作成果
- 定义明确的输出：不要使用模糊的交付物描述
- 明确指定通信对象：清楚说明每个代理应该与谁沟通以及沟通的目的
- 控制团队规模在 3-5 个：大规模代理群（10 个以上）成本会成倍增加
- 提供完整的背景信息：代理启动时没有历史上下文，需要在提示词中提供所有必要信息
代理团队的工作原理
以一个实际案例来说明：创建一个研究团队，目标是整理工作区，包含研究员、战略家和评论家三个角色。
系统会创建团队和待办事项清单，然后并行启动三个代理。每个代理收到的是主代理发送的角色定义：”你是研究团队的研究员，你的工作内容是……”同时包含协作指令：”完成后，用消息工具把你的分析结果发给战略家和评论家。”
在执行过程中，系统会实时更新进度。当研究员完成任务后，主代理会确认：”你把结构化清单发给战略家和评论家了吗？请确保两位队友都收到了。”研究员确认后，其他代理就能基于这些信息继续工作。
所有任务完成后，主代理会收集成果并关闭各个代理：”保存你的工作，准备关闭。”最终输出一份详尽的文档，比如发现了 11 个文件缺口的分析报告。
如果使用终端环境（特别是配合 Tmux），你可以在多个窗格中同时看到不同代理的工作状态和思考过程。例如前端开发者（蓝色）、后端开发者（绿色）和质量保证代理（黄色）各自在独立窗格中工作，你可以实时查看他们的进度，甚至与他们沟通或提供额外信息。
核心运作规则
代理团队有三个关键运作规则：
1. 各自拥有领地
每个代理应该有自己的文件，只编辑自己负责的内容，避免冲突。
2. 直接私信沟通
代理之间可以直接交流，不需要通过主代理作为中间人。
3. 并行工作
代理可以同时工作，不一定要按顺序交接。
代理启动时会继承主会话的权限设置（例如 bash 命令权限），并且可以访问你的文件、MCP 服务器和技能工具。
一个重要的功能是计划审批模式：让所有代理先制定计划，经主代理批准后再执行，这能有效防止工作方向偏离。
常见陷阱与解决方案
问题 1：不断请求许可
解决方案：预先批准某些工具或指令，避免代理频繁暂停等待授权。
问题 2：交付成果被覆盖
解决方案：明确指定文件所有者，确保每个代理只操作自己的文件。
问题 3：代理闲置
解决方案：在提示词和计划中为每个代理分配明确的工作或依赖关系。
问题 4：成本过高
解决方案：减少代理数量，优先使用成本较低的模型。
问题 5：错误终止导致工作丢失
解决方案：会话结束时，主代理会发送”关闭请求”，让各代理先保存临时文件，确认准备就绪后再干净地关闭，避免未清理的残局。
何时使用代理团队？
代理团队适用于以下场景：
- 任务复杂度高，需要多个专业领域的协作
- 需要并行处理多个模块或功能
- 代理之间需要频繁沟通和任务分配
- 对输出质量要求极高
不适合使用代理团队的场景：
- 简单的顺序流程任务
- 单文件或小规模修改
- 预算有限，需要控制 Token 成本
对于这些简单场景，使用普通的子代理或在同一会话中完成即可。
实战提示词示例
下面是两个完整的提示词示例，展示如何构建代理团队。
示例 1：简单的三人开发团队
"目标：构建一个待办事项应用，包含 Node.js 后端和 React 前端。
用 Sonnet 组建一个三人团队：
- 后端开发者 - 负责创建 Express API，包含用户认证和待办事项的 CRUD 操作。完成后发消息给前端开发者，提供 API 文档。文件：backend/ 目录下的所有文件。
- 前端开发者 - 等待后端开发者的消息。收到 API 文档后，构建 React 界面，实现登录、注册和待办事项管理功能。完成后通知 QA 测试员。文件：frontend/ 目录下的所有文件。
- QA 测试员 - 等待前端开发者完成通知。进行端到端测试，编写测试报告，列出所有发现的问题和改进建议。文件：qa-report.md
最终交付物：可运行的全栈应用 + 完整的测试报告。"
示例 2：内容创作团队
"目标：为技术博客创作一篇关于 AI 代理的深度文章。
用 Opus 组建一个四人团队：
- 研究员 - 收集关于 AI 代理的最新资料、论文和案例研究。整理成结构化文档发给撰稿人和编辑。文件：research-notes.md
- 撰稿人 - 基于研究员提供的资料，撰写 3000 字的技术文章，包含代码示例和实践建议。完成初稿后发给编辑和技术审核员。文件：article-draft.md
- 编辑 - 审查文章的语言、结构和可读性，提出修改建议。文件：editing-feedback.md
- 技术审核员 - 验证文章中的技术细节、代码示例的准确性。文件：technical-review.md
最终交付物：经过多轮审核的高质量技术文章 + 审核意见汇总。"
Claude 代理团队的运行过程详解
当你提交一个代理团队提示词后，Claude 会经历以下几个阶段：
阶段 1：解析与规划（5-10 秒）
主代理首先会解析你的提示词，识别出：
- 团队目标和最终交付物
- 需要创建多少个代理
- 每个代理的角色和职责
- 代理之间的依赖关系和通信流程
- 文件分配和权限设置
这个阶段你会看到类似这样的输出：
正在创建代理团队...
✓ 已识别 3 个代理角色
✓ 已建立任务依赖关系
✓ 已分配文件权限
阶段 2：代理初始化（10-15 秒）
主代理会并行启动所有子代理。每个代理会收到：
- 它的角色定义和具体任务
- 可以访问的文件列表
- 需要与哪些代理通信
- 继承的权限设置（bash、文件操作等）
你会看到：
正在初始化代理...
→ 后端开发者 (agent-1) 已启动
→ 前端开发者 (agent-2) 已启动
→ QA 测试员 (agent-3) 已启动
阶段 3：并行执行（时间不定）
这是最核心的阶段。代理们开始工作：
- 独立代理会立即开始执行任务
- 有依赖关系的代理会等待前置任务完成
- 代理之间通过消息系统通信
- 主代理会定期向你汇报进度
如果你在 Tmux 终端中运行，你会看到多个窗格同时显示不同代理的工作状态：
[蓝色窗格 - 后端开发者]
正在创建 Express 服务器...
✓ 已创建 server.js
✓ 已配置数据库连接
正在实现用户认证...
[绿色窗格 - 前端开发者]
等待后端 API 文档...
[待机中]
[黄色窗格 - QA 测试员]
等待前端完成...
[待机中]
阶段 4：代理间通信（实时）
当一个代理完成任务后，它会主动发消息给下一个代理：
[后端开发者 → 前端开发者]
"API 已完成。文档在 api-docs.md。
主要端点：
- POST /api/auth/login
- POST /api/auth/register
- GET /api/todos
- POST /api/todos
- PUT /api/todos/:id
- DELETE /api/todos/:id"
[前端开发者]
收到消息，开始构建界面...
阶段 5：质量检查与汇总（最后 1-2 分钟）
所有代理完成任务后，主代理会：
- 收集所有输出文件
- 验证交付物是否完整
- 生成最终报告
- 向每个代理发送关闭请求
正在收集成果...
✓ 后端代码已保存
✓ 前端代码已保存
✓ 测试报告已生成
正在关闭代理...
→ 后端开发者已安全关闭
→ 前端开发者已安全关闭
→ QA 测试员已安全关闭
任务完成！
典型输出结果展示
让我们看看一个完整的代理团队任务的输出是什么样的。
场景：使用三人团队构建一个简单的博客系统
最终输出文件结构：
project/
├── backend/
│ ├── server.js
│ ├── routes/
│ │ ├── auth.js
│ │ └── posts.js
│ ├── models/
│ │ ├── User.js
│ │ └── Post.js
│ └── package.json
├── frontend/
│ ├── src/
│ │ ├── App.jsx
│ │ ├── components/
│ │ │ ├── Login.jsx
│ │ │ ├── PostList.jsx
│ │ │ └── CreatePost.jsx
│ │ └── api/
│ │ └── client.js
│ └── package.json
├── qa-report.md
└── project-summary.md
主代理的最终报告（project-summary.md） ：
# 博客系统开发完成报告
## 项目概述
成功构建了一个全栈博客系统，包含用户认证和文章管理功能。
## 团队协作情况
- 后端开发者：完成时间 8 分钟，创建了 6 个文件
- 前端开发者：完成时间 12 分钟，创建了 8 个文件
- QA 测试员：完成时间 5 分钟，发现 3 个问题
## 关键决策
1. 使用 JWT 进行用户认证
2. 采用 MongoDB 作为数据库
3. 前端使用 React + Vite
4. 实现了基本的错误处理和输入验证
## 已知问题（来自 QA 报告）
1. 登录失败时错误提示不够明确
2. 文章列表缺少分页功能
3. 建议添加文章搜索功能
## 如何运行
1. 后端：cd backend && npm install && npm start
2. 前端：cd frontend && npm install && npm run dev
3. 访问 http://localhost:5173
## Token 使用统计
- 总消耗：约 45,000 tokens
- 后端开发者：15,000 tokens
- 前端开发者：22,000 tokens
- QA 测试员：8,000 tokens
QA 测试报告（qa-report.md）节选：
# QA 测试报告
## 测试环境
- Node.js v18.17.0
- Chrome 120.0
## 功能测试结果
### ✅ 通过的测试
1. 用户注册功能 - 正常工作
2. 用户登录功能 - 正常工作
3. 创建文章功能 - 正常工作
4. 查看文章列表 - 正常工作
5. 编辑文章功能 - 正常工作
6. 删除文章功能 - 正常工作
### ⚠️ 发现的问题
1. **错误提示不明确**（优先级：中）
- 位置：Login.jsx:45
- 问题：登录失败时只显示"登录失败"，没有说明具体原因
- 建议：区分"用户名不存在"和"密码错误"
2. **缺少分页**（优先级：高）
- 位置：PostList.jsx
- 问题：如果文章很多，页面会很长
- 建议：实现分页或无限滚动
3. **性能问题**（优先级：低）
- 问题：每次编辑文章都会重新加载整个列表
- 建议：使用局部更新
## 安全性检查
✅ 密码已加密存储
✅ JWT token 有过期时间
✅ API 端点有认证保护
⚠️ 建议添加请求频率限制
## 总体评价
项目基本功能完整，代码质量良好。建议优先解决分页问题。
性能与成本分析
根据实际使用经验，这里是不同规模任务的性能数据：
小型任务（3 个代理，简单应用）
- 执行时间：15-25 分钟
- Token 消耗：30,000-50,000
- 成本（Sonnet）：约 $0.15-0.25
- 成本（Opus）：约 $0.75-1.25
中型任务（4-5 个代理，复杂应用）
- 执行时间：30-50 分钟
- Token 消耗：80,000-150,000
- 成本（Sonnet）：约 $0.40-0.75
- 成本（Opus）：约 $2.00-3.75
大型任务（5+ 个代理，企业级项目）
- 执行时间：1-2 小时
- Token 消耗：200,000-500,000
- 成本（Sonnet）：约 $1.00-2.50
- 成本（Opus）：约 $5.00-12.50
优化建议：
- 对于简单任务使用 Sonnet，复杂任务才用 Opus
- 控制代理数量在 3-5 个
- 明确定义每个代理的职责，避免重复工作
- 使用计划审批模式，防止代理跑偏浪费 token
高级技巧：混合使用不同模型
你可以为不同代理指定不同的模型：
"用 Opus 创建主代理，但子代理使用 Sonnet：
- 架构师（Opus）- 负责整体设计和关键决策
- 前端开发者（Sonnet）- 实现界面
- 后端开发者（Sonnet）- 实现 API
- 测试员（Sonnet）- 执行测试"
这样可以在保证质量的同时降低成本。关键的架构决策用 Opus，具体实现用 Sonnet。
总结
代理团队是 Claude 最强大的功能之一，但也是最昂贵的。关键是要：
- 写清晰的提示词，明确目标和交付物
- 合理分配代理角色和文件权限
- 建立清晰的通信流程
- 使用计划模式防止跑偏
- 根据任务复杂度选择合适的模型
掌握这些技巧后，你就能用代理团队处理真正复杂的项目，让多个专业化的 AI 协同工作，完成单个代理难以胜任的任务。
