rsionnach/nthlayer-respond

# nthlayer-respond **由 AI 协调的多智能体事件响应。** [](https://github.com/rsionnach/nthlayer-respond) [](LICENSE) 事件响应涉及大量重复性工作：分类严重程度、识别爆炸半径、关联变更与症状、起草利益相关者更新、决定是否回滚以及沟通解决方案。大多数工作遵循 AI 智能体可以可靠处理的模式，从而将人类响应者解放出来处理真正需要他们的判断决策（新颖的故障模式、业务关键权衡、跨团队协调）。 nthlayer-respond 是一个事件响应系统，其中专业 AI 智能体在人类监督下协作进行分诊、调查、沟通和修复。每个智能体都有明确的领域、定义的决策权限以及自己的判断 SLO，用于衡量人类需要纠正其工作的频率。nthlayer-respond 拥有事件生命周期，并使用 PagerDuty、Slack 和电子邮件等工具作为通知渠道，而不是将它们视为上游事件来源。 该项目目前处于架构设计阶段。设计文档如下，实现工作尚未开始。 ## 告警流 ``` Alert Source (nthlayer-measure quality breach / Prometheus alert / any webhook) │ ▼ nthlayer-correlate Snapshot (correlated context) │ ▼ nthlayer-respond Orchestrator (creates incident context) │ ▼ Agent Pipeline (triage → investigate + communicate → remediate) │ ▼ Notification Channels (PagerDuty / Slack / email / status page) ``` nthlayer-respond 从任何来源（nthlayer-measure 的质量违规信号、Prometheus 告警规则或任何 webhook）接收告警，从 nthlayer-correlate 请求相关快照以获取上下文，然后通过其智能体流水线协调响应。PagerDuty、Slack、电子邮件和状态页面是 nthlayer-respond 用来在需要批准或升级时联系人类的通知渠道。 ## 编排模型 nthlayer-respond 使用专门构建的编排器（而非通用智能体框架），根据事件生命周期对智能体进行排序。编排器本身不是智能体。它是一个确定性状态机，负责对智能体执行进行排序（传输）。智能体在其步骤内进行推理（判断）。这遵循 [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 └──────────────┘ └──────────────┘ ``` 分诊首先运行，然后调查和沟通并行运行。当调查产生根本原因时，修复开始，沟通发送包含发现和修复的更新。 ## 事件上下文 所有 nthlayer-respond 智能体都读取并写入一个共享的事件上下文对象，该对象在整个事件生命周期中累积发现。这是关于事件已知内容的单一累积记录： ``` 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 ``` ## 智能体角色 每个智能体都有定义的领域、特定的决策权限以及自己的判断 SLO，用于衡量其执行角色的可靠性。 ### 分诊智能体 (Triage Agent) 根据爆炸半径和 OpenSRM 清单中的 SLO 影响对严重程度进行分类。确定哪些服务受到影响、哪些团队拥有它们以及响应的紧迫程度。 **可以：** 设置严重程度、通知团队（通过 PagerDuty/Slack 作为通知渠道）、分配所有权。 **不可：** 修复。在未经人工批准的情况下覆盖现有分类。 **判断 SLO：** 严重程度分类的推翻率（目标低于 10%）。 ### 调查智能体 (Investigation Agent) 从 nthlayer-correlate 快照生成假设，从指标、日志和变更历史中收集证据，并按置信度对根本原因进行排名。根据证据揭示的内容调整调查策略，遵循数据而非固定清单。 **可以：** 形成假设并排序。当置信度超过阈值时宣布根本原因。 **不可：** 执行任何修复。 **判断 SLO：** 与事后审查一致的根本原因占比（成熟期目标 70%）。 ### 沟通智能体 (Communication Agent) 通过适当的渠道制作适合受众的消息。根据严重程度和利益相关者类型选择沟通渠道，并决定时机（太频繁是噪音，太不频繁会失去信任）。 **可以：** 在预先批准的模板内起草和发送更新。选择渠道和时机。 **不可：** 与调查结果相矛盾。在确认之前沟通解决方案。 **判断 SLO：** 外发通信的人工编辑率（目标低于 15%）。 ### 修复智能体 (Remediation Agent) 根据调查结果、清单定义的安全操作和风险评估来选择并执行修复。 **可以：** 向人类建议修复。在未经人工批准的情况下执行预先批准的安全操作（回滚、扩容、禁用功能开关）。 **不可：** 执行 OpenSRM 清单中未预先批准的新颖修复。对爆炸半径之外的服务进行更改。 **判断 SLO：** 修复成功率（目标 80%）。 ## 人机协同设计 除非操作在 OpenSRM 清单中被预先批准为安全，否则智能体绝不会在未经人工批准的情况下采取破坏性操作。清单定义了哪些操作被视为可以自动执行（如回滚到已知良好版本或扩容），其他所有操作都需要人工批准。 人类做出严重程度判断、批准新颖的修复方案并覆盖智能体决策。每个智能体决策都会发出 OTel 遥测数据，每次人工覆盖都会反馈到该智能体的判断 SLO 中。[nthlayer-measure's](https://github.com/rsionnach/nthlayer-measure) 治理层监控这些判断 SLO 并相应调整智能体自主权，使用单向安全棘轮（nthlayer-measure 可以降低智能体自主权，但未经人工批准不能增加）。 ## 事后学习 解决后，nthlayer-respond 产生结构化的发现，这些发现回流到生态系统中，而不是停留在没人再读的文档中： - **清单更新：** 发现映射到特定的 OpenSRM 清单更改（之前过于宽松的更严格 SLO 目标、缺失的新依赖声明、用于修复的新安全操作定义） - **规则优化：** 质量模式为 NthLayer 生成的告警规则提供信息（本应更早触发或根本未触发的告警） - **阈值修订：** nthlayer-measure 的历史数据告知判断 SLO 阈值是否需要调整 - **关联改进：** nthlayer-correlate 在过去事件上的准确性校准其未来的关联 这关闭了学习循环，因此系统在每次事件后都会改进，而不仅仅是记录发生了什么。 ## OpenSRM 集成 nthlayer-respond 在事件响应期间广泛读取 [OpenSRM](https://github.com/rsionnach/opensrm) 清单： - **严重程度层级**和 SLO 目标决定应如何紧急处理降级 - 清单中的**安全操作定义**指定修复智能体可以在未经人工批准的情况下执行哪些修复操作 - **依赖拓扑**告诉调查智能体当依赖项受到影响时应该检查哪些服务 - **升级路径**和所有权元数据告诉沟通智能体应该通知哪些团队以及如何联系他们 ## 生态系统集成 nthlayer-respond 消费并产生其他生态系统组件的信号： - **nthlayer-correlate** 提供相关快照作为每个事件的起始上下文，因此 nthlayer-respond 的智能体从相关图景而非原始信号开始 - **nthlayer-measure** 提供质量分数，告知响应中的 AI 智能体是否产生可靠的诊断，其治理层根据测量的性能调整 nthlayer-respond 的智能体自主权 - **NthLayer** 提供拓扑导出和部署门状态，并消费 nthlayer-respond 的事后发现以优化生成的告警规则 ## OpenSRM 生态系统 nthlayer-respond 是 OpenSRM 生态系统中的一个组件。每个组件独立解决一个完整的问题，当通过共享 OpenSRM 清单和 OTel 遥测约定一起使用时，它们可以组合。 ``` ┌─────────────────────────┐ │ OpenSRM Manifest │ │ (the shared contract) │ └────────────┬────────────┘ │ reads │ reads ┌─────────────┬──────┴──────┬─────────────┐ ▼ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ MEASURE │ │ NthLayer │ │CORRELATE │ │>RESPOND< │ │ │ │ │ │ │ │ │ │ quality │ │ generate │ │correlate │ │ incident │ │+govern │ │ monitoring│ │ signals │ │ response │ │+cost │ │ │ │ │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ └─────────────┴──────┬──────┴─────────────┘ ▼ ┌──────────────────────────┐ │ Verdict Store │ │ (shared data substrate) │ │ create · resolve · link │ │ accuracy · gaming-check │ └────────────┬─────────────┘ │ OTel side-effects ▼ ┌──────────────────────────┐ │ OTel Collector / │ │ Prometheus / Grafana │ └──────────────────────────┘ Learning loop (post-incident): nthlayer-respond findings → manifest updates → NthLayer regenerates → nthlayer-measure refines → nthlayer-correlate improves → OpenSRM ``` **nthlayer-respond 如何融入：** - nthlayer-respond 消费 **nthlayer-correlate 的关联裁决**（带有置信度分数和血统）作为每个事件的起始上下文，因此智能体从相关图景而非原始信号开始 - 每个 nthlayer-respond 智能体发出自己的**裁决**（分诊、调查、沟通、修复），通过血统链接到通知它们的 nthlayer-correlate 裁决——任何一点的人工覆盖都会校准上游的每个组件 - **nthlayer-measure** 监控 nthlayer-respond 的智能体判断 SLO，并通过单向安全棘轮调整自主权 - **NthLayer** 提供拓扑导出和部署门状态，并消费事后发现作为规则优化 每个组件都可以独立工作。只需要事件响应协调的人可以采用 nthlayer-respond，而不需要 NthLayer、nthlayer-measure 或 nthlayer-correlate（尽管 nthlayer-correlate 的关联裁决显著丰富了 nthlayer-respond 的上下文）。 | 组件 | 功能 | 链接 | |-----------|-------------|------| | **OpenSRM** | 声明服务可靠性要求的规范 | [OpenSRM](https://github.com/rsionnach/opensrm) | | **nthlayer-learn** | 记录 AI 判断并衡量正确性的数据原语 | [nthlayer-learn](https://github.com/rsionnach/nthlayer-learn) | | **nthlayer-measure** | AI 智能体的质量测量和治理 | [nthlayer-measure](https://github.com/rsionnach/nthlayer-measure) | | **NthLayer** | 从清单生成监控基础设施 | [nthlayer](https://github.com/rsionnach/nthlayer) | | **nthlayer-correlate** | 通过信号关联提供态势感知 | [nthlayer-correlate](https://github.com/rsionnach/nthlayer-correlate) | | **nthlayer-respond** | 多智能体事件响应（本仓库） | [nthlayer-respond](https://github.com/rsionnach/nthlayer-respond) | ## 架构 nthlayer-respond 遵循 [Zero Framework Cognition](ZFC.md)。编排器是纯传输：它接收事件触发器，创建共享上下文，通过流水线对智能体执行进行排序，并路由消息。智能体提供判断：分诊严重程度、形成假设、起草通信和评估修复风险。如果模型不可用，编排器仍会创建事件上下文并将其路由给人工操作员，降级为“无 AI 意见”而非“无事件响应”。 ## 状态 nthlayer-respond 处于架构设计阶段。此处记录的设计反映了目标架构，实现工作尚未开始。编排模型和智能体角色定义已详细设计（参见 OpenSRM 仓库中的 [nthlayer-respond architecture](https://github.com/rsionnach/opensrm/blob/main/components/mayday/README.md))。 ## 贡献 有关指南，请参阅 [CONTRIBUTING.md](CONTRIBUTING.md)。 ## 许可证 Apache License 2.0。参见 [LICENSE](LICENSE)。

标签：AIOps, Apex, DevSecOps, FTP漏洞扫描, OpenSRM, PagerDuty, PyRIT, Slack集成, SRE, 上游代理, 人工智能, 偏差过滤, 告警关联, 多智能体系统, 安全编排, 故障修复, 故障排查, 机器学习, 架构设计, 用户代理, 用户模式Hook绕过, 网络调试, 自动化, 自动化运维, 自定义请求头