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智能体, 多区域容灾, 故障自愈, 混沌工程, 运维自动化, 逆向工具