Kanhaiya76618/band-sentinel
GitHub: Kanhaiya76618/band-sentinel
基于 Band 的多 Agent 自主 on-call 系统,通过对抗式协作实现生产故障的自动诊断、混沌验证、审批执行与复盘报告生成。
Stars: 0 | Forks: 0
# Aegis — 永不休眠的自主 on-call 工程师
一个基于 **Band** 构建的多 Agent 事件响应“作战室”。当生产环境出现故障时,五个
专家级 Agent 会汇聚在同一个 Band 房间中,找到根本原因,在混沌重放中**证明**修复方案,
获取一次人工审批,执行 failover,并自动撰写复盘报告 — 从而将 MTTR 从约 42 分钟缩短至约 1.5 分钟。
为 **Band of Agents Hackathon** (lablab.ai) 构建。融合了“能让你被录用的 23 个项目”中的四个:
日志/指标**异常检测** (#13)、**混沌测试** (#14)、**多区域 failover** (#15) 和
**云成本**量化 (#16) — 此外还结合了 text-to-SQL 遥测 (#08) 以及工具使用 + 记忆 (#06)。
## 立即运行(无需密钥,结果确定)
```
pip install pydantic
python -m backend.run # from the aegis/ directory
```
你将看到 Band 房间的记录:
```
@observer detects a SEV1, correlates it to deploy v2.3.1, opens the room
@diagnostician root cause: memory leak from the deploy (text-to-SQL evidence)
@remediator fix #1: "scale 6 -> 12 pods"
@validator chaos replay -> REJECTED (leak is unbounded, still breaches SLO)
@remediator fix #2: "rollback v2.3.1 + failover to us-west-2"
@validator chaos replay -> PASSED (p99 308ms, 0% errors, within SLO)
@commander irreversible -> asks @human -> approved -> executes -> RESOLVED
@commander auto-postmortem: MTTR 89s, ~$38k downtime averted
```
## 为什么这种架构能胜出
- **“先拒绝后修复”的机制是最大的亮点。** `@validator` 利用自身生成的证据(混沌重放)
*推翻*了 `@remediator` 的首个修复方案,
从而迫使其进行修改。在事件处理过程中,一个 Agent 挑战另一个 Agent 的主张
是 Slack webhook 在物理层面上根本无法做到的事情 — 这证明了 Band 才是真正的
协调层,而不仅仅是一个通知渠道。
- **跨角色的对抗,而非线性流水线。** 大多数团队采用的都是
planner→executor 模式。带有否决权的质疑型 validator 则更为罕见,且难以伪造。
- **拒绝机制是计算出来的,而非预设脚本。** `scale_pods` 失败是因为混沌
模型显示,无论 pod 数量多少,泄漏都会达到饱和;`rollback_and_failover`
通过是因为模型表明它不会发生泄漏。改变场景,结论也会随之改变。
- **以单个数字体现的业务价值:** 规避了约 3.8 万美元的停机损失,MTTR 从 42 分钟降至 1.5 分钟。
## 架构
```
┌────────────────────── BAND ROOM ──────────────────────┐
telemetry │ @observer ─signal→ @diagnostician ─hypothesis→ │
──────────►│ @remediator ⇄ @validator (reject / pass loop) │
│ │ pass │
│ @commander ─approval→ @human │
│ │ execute → RESOLVED → postmortem │
└─────────────────────────────────────────────────────────┘
every arrow is a RoomMessage on the AgentBus → LocalBus now, BandBus at kickoff
```
Provider 划分(体现“跨框架协作”加分项 + 同时冲击两项合作伙伴大奖):
| agent | framework | provider |
|----------------|--------------|--------------|
| @observer | LangGraph | AI/ML API |
| @diagnostician | CrewAI | Featherless |
| @remediator | LangGraph | AI/ML API |
| @validator | CrewAI | Featherless |
| @commander | orchestrator | AI/ML API |
## 文件
```
backend/
contracts.py typed message schema (the room's shared language)
bus.py AgentBus + LocalBus (now) + BandBus stub (kickoff swap)
llm.py OfflineLLM (zero keys) + AI/ML API + Featherless clients
mockservice.py fault-injectable service + the chaos-replay simulator
detector.py z-score anomaly detection over a rolling baseline (#13)
agents/roster.py the five agents
orchestrator.py drives the reject-then-fix cascade through the bus
run.py colored transcript + verdict
```
## 在启动时上线(3 处替换)
1. **Featherless / AI/ML API** — 将 `.env.example` 复制为 `.env`,粘贴密钥,
根据 provider 配置指南确认每个 `BASE_URL`/`MODEL`,设置
`LLM_MODE=aiml`。OfflineLLM 的占位文案将被真实的模型输出所取代;
逻辑保持不变。
2. **Band** — 根据 Band Agent API 文档填充 `BandBus` 中的三个 `TODO`(post / subscribe / history),
并设置 `BUS=band` 和 `BAND_*` 环境变量。
3. 运行 `LLM_MODE=aiml BUS=band python -m backend.run`。同样的代码,现在已在 Band 中实时运行。
## 3 分钟演示脚本
1. (0:00) “现在是凌晨 3 点。us-east 的 checkout-api 刚刚开始出现故障。” 运行程序。
2. (0:30) 指出**拒绝时刻**:“看 — 第一个修复方案被另一个
同级 Agent 的混沌重放击落了。这场争论完全发生在 *Band 内部*。”
3. (1:30) 修改后的修复方案通过,commander 等待人工拦截后,执行操作。
4. (2:15) 最终结论:MTTR 从 42 分钟降至 1.5 分钟,规避了 3.8 万美元损失,自动提交了复盘报告。
5. (2:45) “五个 Agent,两个框架,两个模型 provider,一个 Band 房间。”
标签:AI智能体, 多区域容灾, 故障自愈, 混沌工程, 运维自动化, 逆向工具