njdaniel/bloodhound

# bloodhound 🐕 **用于 Kubernetes 的 AI 事件响应 agent pack，使用 Go 编写。** 当警报触发时，bloodhound 会派出一组专门的调查 agent，它们通过 MCP server 查询 metrics、日志、部署和 runbook， 讨论它们的发现，并向 Slack 交付一份有据可查的根因摘要 —— 所有这些都根据可重现的 seeded 故障 benchmark 进行评分。 ## 为什么 On-call 工程师在每次事件中都会将前 20 分钟花在收集上下文上：调出 dashboard，使用 grep 搜索日志，检查部署了什么。 bloodhound 自动化了这一分诊窗口。它**不会**自动修复 — 它只负责报告，且每一项声明都有捕获的查询结果作为支撑。 ## 工作原理 ``` Alertmanager ──▶ Intake ──▶ Planner ──▶ ┌ metrics-hound ─ MCP: Prometheus ├ logs-hound ──── MCP: Loki ├ changes-hound ─ MCP: Kubernetes └ runbook-hound ─ MCP: docs │ Verifier (adversarial: tries to refute the leading hypothesis) │ Reporter ──▶ Slack / terminal / JSON ``` orchestrator 是一个手工编写的状态机，具有明确的预算（token、工具调用、wall clock）、阶段 checkpoint 以及端到端的 OpenTelemetry tracing。这四个 data-source server 是基于官方 [Go SDK](https://github.com/modelcontextprotocol/go-sdk) 构建的独立 MCP server。 ## Benchmark 将在 M4 中推出：在 `kind` cluster 中运行 18 个 seeded 故障场景（糟糕的部署、OOMKill、证书过期、red herring 以及一个实际上一切正常的对照组），由确定性的 grader 根据根因准确性、证据真实性、得出 hypothesis 的时间和成本进行评分。可通过 `make eval` 复现。 ## 路线图 | 里程碑 | 交付物 | |---|---| | M0 ✅ | 骨架：CLI、provider 接口、CI、规范 | | M1 | mcp-prom + metrics-hound：首次真实诊断 | | M2 | 完整 pack：所有四个 MCP server、planner、并行 hound、tracing | | M3 | 对抗性 verifier + Slack reporter | | M4 | Eval harness：18 个场景、grader、此 README 中的记分板 | | M5 | 消融实验（关闭 verifier、mono-agent、模型分层）+ 案例研究 | ## 本仓库的构建方式 bloodhound 采用 spec-first 结合 AI 辅助工作流进行开发：每个功能 都始于 [specs/](specs/) 中的一份设计文档，实施 PR 由 coding agent 根据这些规范驱动并由人工审查，且 CI 包含一个 advisory agent 审查环节。[CLAUDE.md](CLAUDE.md) 编码了内部规则。 该工作流也是本项目展示内容的一部分。 ## 许可证 MIT

标签：EVTX分析, Go, MCP, Ruby工具, 人工智能, 子域名突变, 库, 应急响应, 日志审计, 用户代理, 用户模式Hook绕过, 自动化运维, 自定义请求头