Agent Teams
Agent Teams 功能它允许主 Claude Code 会话充当"团队负责人"或"项目经理"的角色，协调并管理多个独立的 AI 代理，共同完成复杂的任务。
在开始 Agent Teams 工作前，我们要做好前置工作，让 Claude 能更好的执行工作。
前置知识
代理团队与子代理的核心区别？
- 并行工作与直接通信 ：常规的子代理通常独立工作并将结果直接发回给主代理；而代理团队拥有一个共享的任务列表，各个代理可以并行工作并相互直接通信。例如，前端和后端代理可以将代码发送给 QA 代理，QA 代理发现漏洞后能直接将任务打回给开发代理进行迭代修复，形成高效的反馈循环。
- 上下文与权限继承：代理在唤醒时是没有任何历史对话上下文的。但它们会继承主会话的权限（例如绕过权限或允许 bash 命令），并且团队中的所有成员都能直接访问工作区内的文件、MCP 服务器以及技能
前期设置
-
明确需求：你可以在头脑风暴中
brainstrom.md中输出你想要 Agent Teams 的工作方式，无缝接入。用自然语言去组织团队，明确每个 Agent 应该执行的任务，设定明确的整体目标，让每个代理明白它们为何被唤醒以及最终要交付什么， 可以某个代理运用特定模型。 -
提供标准的仓靠文档： 在项目中，可以将官方的 Agent Teams 文档发给 Claude，有助于 Claude 更好的管理代理团队，prompt：
为代理团队创建一个在docs的文件夹中的主参考指南。这将有助于您在未来构建更优秀、更高效的代理团队。这是参考url
-
分配专属文件 ：必须让每个代理负责并编辑自己专属的文件，分出独立空间。如果多个代理同时编辑同一个共享文件，它们可能会互相覆盖对方的工作成果。
-
控制团队规模在 3 到 5 人：由于代理团队是并行运行的，Token 会成倍增加；另外过多的 Agent 会增加工作的复杂度，并不是越多越好的。
-
熟练运用 Plan mode 模式： 在项目规划初期使用，让 Claude 帮你想到你没想到的问题。比如说各个子代理之间的如何联系，是通过file 还是某种方式？
注意事项
- 审批模式：在代理实际执行任务前，先规定它们制定计划或者后期修改计划方向都由主代理（或本人）进行审批确认，这样可以更好地控制项目走向
- 不要将代理团队用于简单的顺序型任务：如果任务是可以按"第一步、第二步、第三步"顺序完成的，且步骤间仅依赖上一步的结果而不需要互相交流，使用普通的子代理即可，不要使用代理团队，否则会大材小用且浪费成本。如果确认要使用 Teams 模式要明确各代理之间是并行执行
- 如果只需要单一的对话上下文历史或只在完全相同的文件上工作，不要使用代理团队 。代理团队的优势在于解决需要各个专业领域代理并行工作、互相反应、分配任务和频繁沟通的复杂高要求项目
完整流程提示
这些都能写到brainstrom.md，然后再执行Workflow部分的执行流程，更加规范化
- 设定全局目标与背景
项目目标： [详细描述项目的最终目的，例如：构建一个带有 React 前端和 REST API 的完整全栈应用。最终结果应该是一个我可以在本地环境中查看并运行的程序，具备用户和发帖功能]。
2. 组建团队与指定模型
请使用 Sonnet 模型 创建一个由 3 名队友组成的团队。
3. 定义角色、依赖关系
- 第一个代理是 后端开发者 ，名字为Loues：主要工作是 设计并编写 REST API 逻辑。专门负责并只能编辑 [后端相关的文件/数据库文件夹] 。当你完成这部分工作后，请主动发消息通知Marcus。
- 第二个代理是 前端开发者， 名字为Marcus：工作是 构建 React 组件并对接 API。请等待 Loues 发送消息后再开始执行 。你专门负责并只能编辑 前端 UI 文件夹 。完成界面和对接后，请将所有的工作成果发送给 Mathew。
- 第三个代理是 QA 测试代理， 名字为Mathew：工作是测试Marcus和Loues提交的代码。你需要仔细检查所有功能，如果发现任何问题，请直接指出并打回给相应的开发者让他们重新修改，直到所有关键问题解决为止。
4. 明确最终交付物
最终交付物必须包含：
一个完整且能够正常运行的应用程序。
一份详细的 QA 测试报告，确认测试通过与失败的情况。
一份开发文档，记录项目中做出的关键决策以及后续如何运行该程序的说明。
QA 测试报告，确认测试通过与失败的情况。
一份开发文档，记录项目中做出的关键决策以及后续如何运行该程序的说明。
这就整合了 Claude docs 层面有完整的项目进度、系统架构、PRD、EDD、测试报告、开发文档、git 提交记录，能让我们开发更加得心应手。
希望对你有所帮助，祝你身体健康。