rsionnach/mayday

# Mayday **由 AI 协调的多 Agent 事件响应系统。** [](https://github.com/rsionnach/mayday) [](LICENSE) 事件响应包含大量重复性工作：分类严重程度、识别影响范围、关联变更与症状、起草利益相关者更新、决定是否回滚以及沟通解决方案。大多数工作遵循 AI Agent 可以可靠处理的模式，从而解放人类响应者，让他们专注于真正需要人工判断的任务（新颖的故障模式、关键业务的权衡、跨团队协调）。 Mayday 是一个事件响应系统，其中专门的 AI Agent 在人类监督下协作进行分诊、调查、沟通和修复。每个 Agent 都有明确的领域、定义的决策权及其自身的判断 SLO，用于衡量人类需要修正其工作的频率。Mayday 拥有事件生命周期，并使用 PagerDuty、Slack 和电子邮件等工具作为通知渠道，而不是将它们视为上游事件源。 该项目目前处于架构阶段。设计文档如下，实施尚未开始。 ## 告警流程 ``` Alert Source (Arbiter quality breach / Prometheus alert / any webhook) │ ▼ SitRep Snapshot (correlated context) │ ▼ Mayday Orchestrator (creates incident context) │ ▼ Agent Pipeline (triage → investigate + communicate → remediate) │ ▼ Notification Channels (PagerDuty / Slack / email / status page) ``` Mayday 从任何来源（Arbiter 的质量违规信号、Prometheus 告警规则或任何 webhook）接收告警，向 SitRep 请求相关快照以获取上下文，然后通过其 Agent 流水线协调响应。PagerDuty、Slack、电子邮件和状态页面是 Mayday 用来在需要批准或升级时联系人类的通知渠道。 ## 编排模型 Mayday 使用专门构建的编排器（而非通用 Agent 框架），该编排器根据事件生命周期对 Agent 进行排序。编排器本身不是 Agent。它是一个确定性状态机，负责对 Agent 执行进行排序（传输）。Agent 在其步骤内进行推理（判断）。这遵循 [Zero Framework Cognition](ZFC.md)。 ``` ┌──────────────┐ │ Triage │ severity, blast radius, initial assignment └──────┬───────┘ │ ├───────────────────────┐ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │Investigation │ │Communication │ initial stakeholder notification └──────┬───────┘ └──────┬───────┘ │ │ │ root cause found │ ├───────────────────────┤ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ Remediation │ │Communication │ update with root cause + fix └──────────────┘ └──────────────┘ ``` 分诊首先运行，然后调查和沟通并行运行。当调查产生根本原因时，修复开始，沟通发送包含发现和修复的更新。 ## 事件上下文 所有 Mayday Agent 都读取并写入一个共享的事件上下文对象，该对象在整个事件生命周期中积累发现。这是关于事件已知内容的唯一积累记录： ``` incident_context: id: INC-2026-0142 declared_at: "2026-02-23T14:32:00Z" source: arbiter_quality_breach triage: severity: P1 blast_radius: [checkout-service, payment-gateway] affected_slos: [checkout-availability, payment-latency-p99] assigned_teams: [platform-checkout, platform-payments] investigation: hypotheses: - id: H1 description: "model version update at 14:28 introduced quality regression" confidence: 0.82 evidence: [sitrep-correlation-id-847, arbiter-quality-drop] - id: H2 description: "database connection pool exhaustion" confidence: 0.34 evidence: [log-pattern-conn-timeout] root_cause: H1 communication: updates_sent: - channel: "#platform-incidents" timestamp: "2026-02-23T14:33:12Z" type: initial_notification - channel: status_page timestamp: "2026-02-23T14:35:00Z" type: investigating remediation: proposed_action: rollback_model_version target: rig-webapp risk_assessment: low requires_human_approval: false executed_at: null ``` ## Agent 角色 每个 Agent 都有定义的领域、特定的决策权及其自身的判断 SLO，用于衡量其执行角色的可靠性。 ### 分诊 Agent 根据影响范围和 OpenSRM 清单中的 SLO 影响分类严重程度。确定哪些服务受到影响，哪些团队拥有它们，以及响应的紧急程度。 **可以：** 设置严重程度，通知团队（通过 PagerDuty/Slack 作为通知渠道），分配所有权。 **不可以：** 修复。在未经人类批准的情况下覆盖现有分类。 **判断 SLO：** 严重程度分类的逆转率（目标低于 10%）。 ### 调查 Agent 从 SitRep 快照生成假设，从指标、日志和变更历史中收集证据，并按置信度对根本原因进行排序。根据证据揭示的内容调整调查策略，跟随数据而非固定清单。 **可以：** 形成并对假设进行排序。当置信度超过阈值时声明根本原因。 **不可以：** 执行任何修复。 **判断 SLO：** 与事后审查一致的根本原因比例（成熟期目标 70%）。 ### 沟通 Agent 通过适当的渠道生成适合受众的消息。根据严重程度和利益相关者类型选择沟通渠道，并决定时间（太频繁是噪音，太少会失去信任）。 **可以：** 在预先批准的模板内起草并发送更新。选择渠道和时间。 **不可以：** 与调查结果相抵触。在确认之前沟通解决方案。 **判断 SLO：** 外发通信的人工编辑率（目标低于 15%）。 ### 修复 Agent 根据调查结果、清单定义的安全操作和风险评估选择并执行修复。 **可以：** 向人类建议修复。在未经人工批准的情况下执行预先批准的安全操作（回滚、扩容、禁用功能开关）。 **不可以：** 执行 OpenSRM 清单中未预先批准的新颖修复。对影响范围之外的服务进行更改。 **判断 SLO：** 修复成功率（目标 80%）。 ## 人机协同设计 除非操作在 OpenSRM 清单中被预先批准为安全，否则 Agent 绝不会在未经人工批准的情况下采取破坏性操作。清单定义了哪些操作被视为可自动执行的安全操作（如回滚到已知良好版本或扩容），其他所有操作都需要人工批准。 人类做出严重程度判断，批准新颖的修复，并覆盖 Agent 决策。每个 Agent 决策都会发出 OTel 遥测数据，每个人工覆盖都会反馈到该 Agent 的判断 SLO 中。[Arbiter](https://github.com/rsionnach/arbiter) 的治理层监控这些判断 SLO 并相应地调整 Agent 自主权，使用单向安全棘轮（Arbiter 可以降低 Agent 自主权，但未经人工批准不能增加）。 ## 事后学习 解决后，Mayday 会生成结构化的发现，这些发现会回流到生态系统中，而不是停留在没人再读的文档中： - **清单更新：** 发现映射到具体的 OpenSRM 清单更改（之前过于宽松的更严格 SLO 目标、缺失的新依赖声明、用于修复的新安全操作定义） - **规则细化：** 质量模式为 NthLayer 生成的告警规则提供信息（本应更早触发或根本未触发的告警） - **阈值修订：** Arbiter 的历史数据用于判断是否需要调整判断 SLO 阈值 - **相关性改进：** SitRep 在过去事件上的准确性校准其未来的相关性 这闭合了学习循环，因此系统在每次事件后都会改进，而不仅仅是记录发生了什么。 ## OpenSRM 集成 Mayday 在事件响应期间广泛读取 [OpenSRM](https://github.com/rsionnach/opensrm) 清单： - **严重等级**和 SLO 目标决定应如何紧急地处理降级 - 清单中的**安全操作定义**指定了修复 Agent 可以在未经人工批准的情况下执行哪些修复操作 - **依赖拓扑**告诉调查 Agent 当依赖项受到影响时要检查哪些服务 - **升级路径**和所有权元数据告诉沟通 Agent 要通知哪些团队以及如何联系他们 ## 生态系统集成 Mayday 消耗并为其他生态系统组件生成信号： - **SitRep** 提供相关快照作为每个事件的起始上下文，因此 Mayday 的 Agent 从相关图景开始，而不是原始信号 - **Arbiter** 提供质量分数，用于通知响应中的 AI Agent 是否正在产生可靠的诊断，其治理层根据测量的性能调整 Mayday 的 Agent 自主权 - **NthLayer** 提供拓扑导出和部署门控状态，并消耗 Mayday 的事后发现以细化生成的告警规则 ## OpenSRM 生态系统 Mayday 是 OpenSRM 生态系统中的一个组件。每个组件独立解决一个完整的问题，它们通过共享的 OpenSRM 清单和 OTel 遥测约定组合在一起使用。 ``` ┌─────────────────────────┐ │ OpenSRM Manifest │ │ (the shared contract) │ └────────────┬────────────┘ │ reads │ reads ┌─────────────┬──────┴──────┬─────────────┐ ▼ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Arbiter │ │ NthLayer │ │ SitRep │ │>>MAYDAY< │ │ │ │ │ │ │ │ │ │ quality │ │ generate │ │correlate │ │ incident │ │+govern │ │ monitoring│ │ signals │ │ response │ │+cost │ │ │ │ │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ └──────┬──────┴──────┬──────┘ │ ▼ ▼ ▼ ┌────────────────────────────┐ ┌──────────────┐ │ Streaming / Queue Layer │ │ Consumes │ │ (Kafka / NATS / etc) │ │ all three │ └──────────┬─────────────────┘ └──────┬───────┘ ▼ │ ┌────────────────────────┐ │ │ OTel Collector / │ │ │ Prometheus / etc │ │ └────────────────────────┘ │ │ ┌──────────────────────────────────────┘ │ Learning loop (post-incident): │ Mayday findings → manifest updates │ → NthLayer regenerates → Arbiter │ refines → SitRep improves └──────────────────────────────────────▶ OpenSRM ``` 每个组件都可以独立工作。只需要事件响应协调的人采用 Mayday，而不需要 NthLayer、Arbiter 或 SitRep（尽管 SitRep 的相关快照显著丰富了 Mayday 的上下文）。 | 组件 | 功能 | 链接 | |-----------|-------------|------| | **OpenSRM** | 声明服务可靠性需求的规范 | [opensrm](https://github.com/rsionnach/opensrm) | | **Arbiter** | AI Agent 的质量测量和治理 | [arbiter](https://github.com/rsionnach/arbiter) | | **NthLayer** | 从清单生成监控基础设施 | [nthlayer](https://github.com/rsionnach/nthlayer) | | **SitRep** | 通过信号关联提供态势感知 | [sitrep](https://github.com/rsionnach/sitrep) | | **Mayday** | 多 Agent 事件响应（此仓库） | [mayday](https://github.com/rsionnach/mayday) | ## 架构 Mayday 遵循 [Zero Framework Cognition](ZFC.md)。编排器是纯传输：它接收事件触发器，创建共享上下文，通过流水线对 Agent 执行进行排序，并路由消息。Agent 提供判断：分诊严重程度、形成假设、起草通信和评估修复风险。如果模型不可用，编排器仍会创建事件上下文并将其路由给人类操作员，降级为“无 AI 意见”而不是“无事件响应”。 ## 状态 Mayday 处于架构阶段。此处记录的设计反映了目标架构，实施尚未开始。编排模型和 Agent 角色定义已经详细设计（参见 OpenSRM 仓库中的 [Mayday 架构](https://github.com/rsionnach/opensrm/blob/main/components/mayday/README.md））。 ## 贡献 有关指南，请参阅 [CONTRIBUTING.md](CONTRIBUTING.md)。 ## 许可证 Apache License 2.0。参见 [LICENSE](LICENSE)。

标签：AIOps, DLL 劫持, IT运维, OpenSRM, PageDuty, PyRIT, Python, Slack, Socks5代理, SRE, 偏差过滤, 协作机器人, 告警管理, 多智能体系统, 大语言模型, 工作流自动化, 库, 应急响应, 故障自愈, 无后门, 智能编排, 根因分析, 系统架构, 自动化运维, 自定义请求头, 软件开发