YoussefMadkour/PagerZero
GitHub: YoussefMadkour/PagerZero
PagerZero 是一个基于多 Agent 并行协作的自主故障响应系统,利用大语言模型的 128k 长上下文能力在约 90 秒内完成日志、指标和部署变更的综合根因分析并生成修复建议。
Stars: 0 | Forks: 0
# PagerZero
为 [AMD 开发者黑客松](https://lablab.ai/event/amd-developer-hackathon) 构建 — 赛道 1:AI Agents 与 Agentic Workflows。
## 它的功能
当服务宕机时,值班工程师通常需要花费约 45 分钟手动阅读日志、检查指标并猜测发生了哪些更改。PagerZero 将这项工作缩短至约 90 秒。
在警报触发的瞬间:
1. **日志分析** — 在一次单一的 128k 上下文处理中,从 8,000 多行日志中找到异常集群。无需分块,无需 map-reduce,第 1 行到第 8,000 行之间不会丢失任何信息。
2. **指标关联器** — 识别出 2 小时内时间序列的拐点以及领先与滞后指标。
3. **部署追踪器** — 将近期的部署与事件时间线进行关联,并标记出可疑的代码路径。
4. **根因分析** — 将这三个信号流综合成带置信度分数的排序假设,并提供按来源划分的证据引用。
5. **修复建议** — 生成可执行的 CLI 命令、回滚程序以及起草的事件报告。
Agent 1、2 和 3 **并发**运行。Agent 4 汇总它们的结果。Agent 5 完成收尾工作。
## 为什么需要 MI300X — 计算层面的考量
这绝非一个仅仅贴上 AMD 标签的 API 调用。这里的硬件是真正的核心支撑。
- **128k token 单次处理。** 每个 Agent 在一个 prompt 中就能看到完整的事件经过。8,000 行日志加上结构化指标以及部署差异,大概会占用 60-70k 的输入 token。上下文较小的模型迫使你采用分块和 map-reduce 的方式,这会破坏跨行之间的关联性,而这种关联性正是根因分析生效的关键。
- **五路并发的大上下文推理。** 三个 Agent 并行读取了完整的事件信息。MI300X 的 **192 GB HBM3** 和 **~5.3 TB/s 的内存带宽** 使得这种规模的并行多 Agent 推理在延迟上具有可行性。你不会在迁移 KV cache 时遇到瓶颈。
- **延迟硬性要求为 90 秒。** 真正依赖此系统的值班工程师绝对无法容忍长达 4 分钟的分析。在 CPU 或较小的 GPU 上,你要么进行分块(从而丢失信号),要么将 Agent 串行化(从而超出时间预算)。这两种方案都无法应用于实际的生产环境。
Hugging Face Space 和 AMD Developer Cloud 托管仅仅是为了满足部署需求 — 这是为了符合参赛资格所必需的,而不是系统能运转的核心原因。真正的差异化优势在于底层计算在内存和带宽方面的表现。
## 技术栈
| 层级 | 选择 |
|---|---|
| 模型 | [Qwen2.5-72B-Instruct](https://huggingface.co/Qwen/Qwen2.5-72B-Instruct) — 128k 上下文 |
| 服务 | ROCm 上的 vLLM |
| 计算 | AMD Instinct MI300X |
| 编排 | LangGraph(并行分支 1/2/3 → 4 → 5) — 参见 [ADR 0001](docs/adr/0001-orchestration-framework.md) |
| 后端 | FastAPI + Server-Sent Events |
| 前端 | Next.js 16 + Tailwind 4 |
| 托管 | AMD Developer Cloud (后端) + Hugging Face Space (前端) |
请参阅 [ADR 0002](docs/adr/0002-amd-compute-narrative.md),了解计算设计是如何体现在产品 UI 中的(硬件徽章、按 Agent 统计的 token 数量、并行与串行的耗时对比可视化)。
## 仓库结构
```
backend/ Python 3.12 — FastAPI + LangGraph agent pipeline
frontend/ Next.js 16 dashboard with live agent status SSE
infra/ vLLM launch scripts and AMD deploy helpers
docs/ ADRs and architecture notes
```
## 本地开发
前置条件:Python 3.12,Node 22,[uv](https://github.com/astral-sh/uv)。
```
# Backend (使用 MockLLMClient — 无需 GPU)
cd backend
uv sync
uv run python scripts/generate_scenarios.py
uv run pytest # 16 tests, ~1s
uv run uvicorn pagerzero.api.main:app --reload --port 8000
# Frontend (在另一个终端中)
cd frontend
npm install
npm run dev # http://localhost:3000
```
`MockLLMClient` 会根据场景返回确定性的预设响应,因此整个流水线可以在零 GPU 的环境下几秒钟内运行完毕。真正的 `VLLMClient`(在 MI300X 上运行 Qwen2.5-72B)只需通过一个环境变量即可替换接入:`PAGERZERO_LLM_BACKEND=vllm`。
## 演示场景
| 场景 | 故障原因 | 测试重点 |
|---|---|---|
| `scenario_a_memory_leak` | 会话缓存部署移除了逐出机制;47 分钟后堆内存耗尽 | 跨来源综合(日志 + 指标 + 部署均指向同一个 commit) |
| `scenario_b_pool_exhaust` | 秒杀活动流量耗尽了数据库连接池 | 诚实的“无肇事部署”路径 — 容量事件,而非代码事件 |
| `scenario_c_cascade` | 被禁用的熔断器将上游的减速放大为全面宕机 | 多假设排序,包含一个主要假设和一个次要调查方向 |
## 许可证
MIT — 参见 [LICENSE](./LICENSE)。
标签:128K上下文, AIOps, AI工作流, AMD MI300X, DLL 劫持, IT运维, KV缓存, PyRIT, Qwen, Socks5代理, SRE, 偏差过滤, 关联分析, 告警分析, 多智能体系统, 大上下文推理, 大语言模型, 并行推理, 异常检测, 持续部署, 指标监控, 故障排查, 智能运维, 根因分析, 模块化设计, 深度学习, 硬件加速, 自主智能体, 自动化修复, 逆向工具, 高带宽内存, 黑客松项目