agent-teams

agent-teams 技能概览

agent-teams 是做什么的

agent-teams 是一个面向 Claude Code 的工作流技能，适用于需要严格 TDD 流水线的多智能体开发项目。只有在你需要的是有协同分工的功能交付，而不只是一次性提示词时，才该使用 agent-teams skill：规格编写、质量门禁、实现、评审、安全扫描，以及 PR/分支编排，都会像一个团队那样协作推进。

适合谁安装

如果你的团队使用 alinaqi/claude-bootstrap，并希望获得可重复的智能体角色分工和强制交接，这个技能会很合适。它最适合那些重视测试先行执行、质量检查阻塞机制，以及减少功能分支中“智能体漂移”的场景。

它的不同之处

它最核心的差异点是不可变的功能流水线：spec、review、失败测试、红灯验证、实现、绿灯验证、代码评审、安全扫描和 PR 创建。agent-teams for Multi-Agent Systems 这套模式本身就带有较强的主张性，流程也相对重，这正是它的设计目的——如果你更看重一致性和可追踪性，而不是灵活性，这会很有帮助。

如何使用 agent-teams 技能

安装并定位技能文件

先通过 Claude Code 的技能管理器走 agent-teams install 流程，然后优先查看 skills/agent-teams/SKILL.md。这个仓库不依赖额外的 rules/、resources/ 或 scripts/ 辅助文件，因此 skills/agent-teams/agents/ 下的智能体定义才是关键的支撑内容。

先读哪些文件

先从 SKILL.md 看起，然后再审阅：

• agents/feature.md
• agents/quality.md
• agents/code-review.md
• agents/security.md
• agents/merger.md
• agents/team-lead.md

这些文件会说明团队预期如何协作、每个角色可以使用哪些工具，以及阻塞检查会发生在哪里。这一点比快速扫一遍更重要，因为 agent-teams usage 依赖的是角色边界，而不只是提示词措辞。

如何更好地提示它

最好的输入是一份包含范围、仓库上下文和约束条件的功能目标。比如，不要只说“加认证”，而应明确给出：

• 目标文件或子系统
• 验收标准
• 测试框架
• 性能/安全约束
• 任何智能体不得修改的内容

一份合格的 agent-teams guide 提示词，应该把“完成”定义清楚。若你没有准确说明行为，质量智能体仍然会卡住流程，但功能智能体可能只会写很窄的测试，或者漏掉边界情况。

什么时候最适合用

适合用于能从并行化规划、测试先行实现、评审和安全检查中受益的功能。对于很小的修补、探索性原型，或者目标极其模糊的任务，它的价值会明显下降，因为完整团队带来的额外开销反而会拖慢你。

agent-teams 技能常见问题

这个技能适合新手吗？

可以，但前提是你愿意阅读智能体文件和测试输出。这个工作流很严格，所以新手能得到结构化支持，但仍然需要给出清晰目标，并理解失败本身就是流程的一部分。

它和普通提示词有什么区别？

普通提示词是让一个模型把所有事情都做完。agent-teams 则把职责拆分给不同智能体，并在每个门禁通过之前阻止流程继续。这样通常能提升多步骤工作的可靠性，但也会增加流程感和操作步骤。

它能在 claude-bootstrap 之外使用吗？

不能把它当成即插即用的保证。这个技能是围绕 claude-bootstrap 的智能体布局、.claude/agents/ frontmatter，以及 SKILL.md 中描述的任务链来设计的。离开这套生态后，你可能需要调整文件路径和编排约定。

什么时候不该使用 agent-teams？

如果只是单文件修改、紧急热修复，或者仓库根本没有有意义的测试套件，就别用它。只要你无法支持 TDD、评审和安全门禁，这套流程就会比普通提示词更重。

如何改进 agent-teams 技能

给团队更好的输入

质量提升最大的一步，往往来自更清晰的验收标准。把预期输入、输出、边界情况，以及功能必须遵循的现有约定都写进去。这样功能智能体写出来的测试才更贴近你的真实意图，而不是靠猜。

减少流水线里的失败点

常见问题包括规格太模糊、缺少测试命令、文件归属不清。只要你知道项目的 test runner、lint 命令和 package manager，就应该提前说明。如果某个功能会碰到共享代码，也要明确指出，避免不同智能体之间发生冲突。

第一次运行后继续迭代

可以先用第一轮暴露缺口，再在第二轮之前细化规格或约束。对 agent-teams 来说，改进通常意味着更清楚的任务边界、更强的负向用例，以及更明确的质量和安全智能体应该在哪些点上阻断流程。

针对你的仓库做调优

如果你的仓库架构比较特殊，或者测试模式不标准，就要在提示词和关联的智能体文件里明确说明。你的输入越贴近仓库真实约束，团队就越不容易滑向泛化的 TDD 行为，agent-teams 的安装和实际表现也会更好。