# Bug Hunt Swarm

> 针对 Bug、回归、崩溃、偶发行为或无法解释的失败进行并行只读多智能体根因调查。在用户要求调查 Bug、查找根因、追溯回归、理解为何崩溃、或想要附带...的排名诊断时使用。触发词：bug调查、根因分析、回归追踪、崩溃诊断、只读调查、多智能体诊断、并行调查、bug hunt、root cause、regression trace。

- Skill: `kscz0000/bug-hunt-swarm` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kscz0000/bug-hunt-swarm`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/bug-hunt-swarm/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: kscz0000 (https://skillmd.com/u/kscz0000)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kscz0000/bug-hunt-swarm

---


# 缺陷猎杀群组
## 适用场景

当你需要对 Bug、回归、崩溃、偶发行为或无法解释的失败进行并行只读多智能体根因调查时，请使用本技能。在用户要求调查 Bug、查找根因、追溯回归、理解为何崩溃，或想要附带...的排名诊断时使用。


并行启动四个只读子智能体调查 Bug，再由主智能体对可能的原因进行排序，并推荐最快可证明或修复该问题的路径。本技能以诊断优先：在本工作流中不要编辑文件或实施修复。

## 第一步：构建缺陷信息包

首先收集最小且有用的调查信息包：

1. 现象
2. 预期行为
3. 实际行为
4. 复现步骤（若已知）
5. 影响范围
6. 相关证据，例如日志、堆栈跟踪、失败测试、截图、最近的 diff 或环境细节

优先采用以下来源顺序：

1. 用户的直接描述
2. 用户提供的明确文件、堆栈跟踪、日志、测试或截图
3. 当 Bug 表现为回归时，查看当前 git 变更或最近仓库历史
4. 围绕失败点的最小相关代码路径或子系统

如果 Bug 报告描述不充分，则推断出最小的问题陈述，并说明尚不清楚之处。

在启动子智能体之前，先阅读与受影响区域最相关的项目指令和文档，例如：

- `AGENTS.md`
- 仓库工作流文档
- 受影响子系统的架构、状态、路由、模式或运行时文档

## 第二步：界定调查范围

为该调查群组撰写一份简短的调查简报：

1. 看起来损坏的是什么
2. 尚未被证实的是什么
3. 系统中最可能涉及的部分
4. 已存在的证据
5. 什么样的证据可算作确认

在有用处使用只读证据收集手段：

- `rg`、`git diff`、`git log`、`git show`
- 阅读日志、崩溃跟踪和配置
- 已有的测试运行或最小且安全的复现命令

在本技能中不要编辑文件、注入新的检测代码或实施修复。

## 第三步：并行启动四个只读调查员

当问题足够大或足够模糊，以至于并行调查能带来帮助时，启动四个子智能体。对于微小且明显的问题，直接在本地调查也是可接受的。

对每个子智能体：

- 提供相同的缺陷信息包和调查简报
- 声明该子智能体为只读
- 不允许该子智能体编辑文件、运行 `apply_patch`、暂存变更、提交，或执行任何其他会改变状态的操作
- 只要求简洁的调查输出
- 要求其提供：假设、支持证据、缺失证据、最小证明步骤以及置信度
- 告知子智能体避免泛泛的代码质量反馈、吹毛求疵或缺乏证据的猜测
- 告知子智能体只将发现反馈给主智能体

使用以下四个调查角色。

### 子智能体一：复现与范围调查

厘清确切的失败形态及其边界。

需检查：

1. 最窄且最可靠的触发条件
2. 让 Bug 出现或消失的条件
3. 失败边界处的预期与实际行为对比
4. 影响是局部的、跨模块的、确定性的，还是偶发的

该子智能体为只读。不得编辑文件、应用补丁或做任何其他工作区变更。

推荐的子智能体角色：`reviewer`

### 子智能体二：代码路径与故障接缝调查

追踪最可能的执行路径，并定位行为发生偏离的接缝。

需检查：

1. 状态转换、生命周期边界或顺序问题
2. 调用方与被调用方之间不匹配的假设
3. 数据流或控制流的中断
4. 最可能对此次失败负责的最小代码区域

该子智能体为只读。不得编辑文件、应用补丁或做任何其他工作区变更。

推荐的子智能体角色：用于广泛追踪时使用 `explorer`，当更需要进行深入的本地推理时使用 `reviewer`

### 子智能体三：近期变更与回归调查

在附近的历史或变更后的契约中查找可能的回归源。

需检查：

1. 与该现象在时间上相关的最近 diff
2. 配置、标志、依赖、模式或迁移的漂移
3. 多个入口本应同步更新却只完成部分更新的情况
4. 与 Bug 报告时间吻合的行为变更

该子智能体为只读。不得编辑文件、应用补丁或做任何其他工作区变更。

推荐的子智能体角色：`reviewer`

### 子智能体四：证明计划与可观测性调查

确定确认或否定主要假设的最快方式。

需检查：

1. 应当失败的最小现有测试或复现
2. 最有用的当前日志、跟踪、指标或断言
3. 一个能快速提高置信度的最小非破坏性命令
4. 缺失哪些证据，以及如何在不造成大范围干扰的情况下收集它们

该子智能体为只读。不得编辑文件、应用补丁或做任何其他工作区变更。

推荐的子智能体角色：`reviewer`

仅报告能实质提升找到真正原因概率的假设。返回两个有证据支撑的理论，远胜于返回六个含糊的猜测。

## 第四步：综合得出排序后的假设

综合工作由主智能体负责。将子智能体的输出视为原始调查输入，而非最终输出。

合并并对假设进行排序：

- 合并重复项
- 剔除薄弱的猜测
- 偏好证据胜过简洁
- 将可能的根本原因与单纯的诱因区分开
- 仅在仍有合理性时保留备选理论

将保留下来的假设规范化为以下结构：

1. 假设
2. 支持证据
3. 缺失或冲突的证据
4. 最小证明步骤
5. 置信度：高、中或低

如果证据过于薄弱而无法真正排序，请直接说明，并改为提出主要的悬而未决的问题。

## 第五步：输出一条清晰的诊断路径

按以下顺序呈现结果：

1. 最可能的根本原因
2. 合理的备选原因（若有）
3. 最快的证明步骤
4. 推荐的修复路径
5. 悬而未决的问题或阻碍

当修复尚不明朗时，推荐下一步的证明步骤，而不是假装诊断已经完成。

在合适时，可将动作归类为：

- `prove now`（立即证明）
- `fix next`（下一步修复）
- `follow up later`（稍后跟进）

在本技能中不要实施修复。输出是一份带优先级路径的只读诊断。

## 局限

- 仅当任务明确匹配其上游来源和本地项目上下文时，才使用本技能。
- 在应用变更之前，请验证命令、生成的代码、依赖、凭证以及外部服务的行为。
- 不要把示例当作针对特定环境的测试、安全审查或用户对破坏性或高成本操作的批准之替代品。