DaniAkash/codex-crisis-room

# 危机指挥官代理 **🚨 检测事件。🧠 运行根因分析。🛠️ 协调修复。✅ 仅在生产环境稳定后关闭。** Crisis Commander Agent 被设计成像一位运营同事一样响应软件事件：它检测重复故障，自动启动根因分析（RCA），关联监控和仓库证据，更新事件报告，通知利益相关者，调用 Codex 启动修复路径，等待人工合并确认，并监控生产环境直到事件真正稳定。 `codex-crisis-room` 是一个展示该代理实际运作的黑客松环境。当前构建在模拟生产环境中运行指挥官，但命令循环本身是真实的，并设计用于接入真实的仓库、监控系统和事件工作流。

## ✨ 这是什么 Codex Crisis Room 是一个用于演示代理式事件响应的模拟环境。 该项目围绕一个核心思想：**一个 AI 事件指挥官应该能够执行运营工作，而不仅仅是回答问题**。 在实时演示中，指挥官： - 在 Slack 中检测重复的计费失败 - 在不等待人工提示的情况下启动自动化根因分析 - 关联模拟的 Sentry 和 GitHub 信号中的事件证据 - 识别可疑的 Pull Request 和相关文件 - 随着调查进展更新事件报告 - 通知利益相关者 - 调用 Codex 准备修复路径 - 暂停等待人工确认后再合并 - 监控发布流程，并在健康检查通过后关闭事件 ``` flowchart LR A[🚨 Alert burst in Slack] --> B[🧠 Crisis Commander detects repeated incident] B --> C[📡 Correlate monitoring evidence] C --> D[🗂️ Inspect repo changes and suspect PRs] D --> E[🧵 Update incident report and page stakeholders] E --> F[🛠️ Invoke Codex to start the fix] F --> G[👩‍💻 Human review gate] G --> H[🚀 Rollout and monitor] H --> I[✅ Stabilize and close incident] ``` ## 🤖 危机指挥官代理 危机指挥官代理是项目的核心。 它被设计用来处理一个真实的待命事件负责人通常需要在多个系统和人员之间协调的工作流： ### 检测 - 从传入的告警流量中识别重复的故障模式 - 将嘈杂的信号分组为一个事件 - 自动启动分类处理 ### 调查 - 查询监控证据中的重复特征 - 检查与受影响系统相关的最近仓库变更 - 使用可疑的 PR 和相关文件缩小可能的回归路径 - 随着学习深入维护结构化的事件状态 ### 协调 - 在新证据到达时更新事件报告 - 在事件线程中通知利益相关者 - 在适当时候将工作交接给人工审核者 - 明确跟踪事件归属 ### 解决 - 调用 Codex 启动修复路径 - 在模拟环境中打开候选修复的 Pull Request - 在合并前等待人工确认 - 审核确认后恢复发布流程 ### 发布后监控 - 检查发布后的恢复信号 - 区分残余故障与真正的持续影响 - 仅在监控窗口干净后关闭事件 这个黑客松版本演示了一个种子计费失败事件上的指挥官，但设计目标是支持真实的仓库和事件工作流。 ## 💾 持久化事件状态 指挥官不会作为一次性的聊天响应运行。它在持久化的事件状态上运行，该状态可以存活于演示流程中，并可被渲染为 Slack 更新、报告和监控进展。 ``` flowchart LR A[Slack trigger] --> B[Crisis Commander run] B --> C[XState incident actor] C --> D[Typed JSON persistence] C --> E[Incident report state] C --> F[Milestones] F --> G[Slack story shaping] G --> H[Slack thread updates] E --> I[Rendered incident report] D --> C ``` ## 🌐 为何需要 Crisis Room 演示环境是模拟的，因为真实的突发事件不适合作为黑客松的依赖项。 真实的部分包括： - 指挥官循环 - 工具编排 - 事件状态转换 - 由 Slack 触发的事件流程 - 里程碑生成 - 人工审核门控 - 监控和稳定化逻辑 - 报告渲染 模拟的部分包括： - Sentry 证据负载 - GitHub 调查负载 - 修复 Pull Request 的副作用 - 生产健康检查 - 最终事件报告目的地 这种权衡在保持真实产品核心不变的前提下，使演示具有确定性。模拟层可以被替换为实时集成，而不会改变整体代理架构。 ## 🎬 演示流程 当前的演示是一个以 Slack 为首的事件叙事。 1. 计费监控器向 `#incidents` 发送 3 次连续的续费失败。 2. 危机机器人检测到重复并启动自动化根因分析。 3. 指挥官关联一个重复的 Sentry 特征与最近的计费变更。 4. 它发布可能的回归路径、可疑的 PR 和相关文件。 5. 更新事件报告并通知利益相关者。 6. 调用 Codex 启动修复并打开候选修复的 Pull Request。 7. 暂停等待真实的人工审核者确认修复。 8. 确认后，恢复流程，发布修复，监控恢复，并关闭事件。 结果是一个由真实代理状态支撑的、可信的“事件室”线程，而不是预先写好的剧本回放。 ## 🧪 让这不仅仅是一个脚本化演示的原因 Codex Crisis Room 不仅仅是打印预先写好的 Slack 消息。 实现包含： - 真实的工具循环指挥官 - 类型化的事件状态和转换 - 持久化的事件记录 - 基于场景的调查工具 - 从实际执行中派生的里程碑 - Slack 传输和线程处理 - 合并前真实的人工审核门控 - 随时间推移改变事件结果的监控进展 这意味着 Slack 故事是实际事件进展逻辑的表现层。 ## 🏗️ 架构 ### 1. 事件指挥官代理 指挥官是决策核心。它通过工具调用而非硬编码脚本步骤来运行事件工作流。 职责： - 决定下一步采取的操作 - 收集证据 - 更新事件报告 - 协调人工参与 - 推动事件朝向解决 - 仅在事件稳定或需要人工输入时停止 ### 2. 工具循环 代理使用 Vercel AI SDK 的工具循环和 OpenAI 模型实现。模型基于当前事件上下文进行推理，并从一组有限的事件工具中进行选择。 当前工具类包括： - 重复事件检测 - 分类启动 - 类 Sentry 信号检查 - 类 GitHub 变更检查 - 事件报告更新 - 利益相关者通知 - 候选修复 Pull Request 创建 - 负责人分配 - 合并进展 - 生产健康检查 ### 3. 事件状态层 事件生命周期被显式建模，而不是从聊天输出中推断。 该层使用： - `XState` 作为事件状态机 - 用于调查、协调、合并、监控和关闭的类型化转换 - 类型化的 JSON 持久化，以便事件在服务器重启后仍可恢复 ``` stateDiagram-v2 [*] --> new new --> triage_started triage_started --> investigating investigating --> stakeholders_notified stakeholders_notified --> fix_pr_opened fix_pr_opened --> owner_assigned owner_assigned --> fix_merged fix_merged --> monitoring monitoring --> monitoring monitoring --> stabilized stabilized --> [*] ``` ### 4. 场景引擎 场景引擎驱动模拟的生产环境。 它提供有状态的、不断演化的响应，使代理看到一个随着事件进展而变化的世界： - 修复前故障激增 - 可疑证据指向真实的回归路径 - 部署后监控保持嘈杂 - 事件仅在通过干净检查后才稳定 ### 5. Slack 传输 Slack 是主要的演示界面。 Slack 层处理： - Socket Mode 事件摄入 - 从重复事件消息中检测触发器 - 将线程映射到事件 ID - 以故事形式的机器人回复 - 合并前的人工审核者确认 - 事件关闭更新 ### 6. 报告层 报告层将结构化的事件状态转换为可读的事件摘要和最终的渲染报告输出。 ## ⚙️ 技术栈 - **Bun**：运行时、包管理器和测试运行器 - **Hono**：轻量级服务器和路由层 - **TypeScript**：类型化应用层 - **Vercel AI SDK**：指挥官的工具循环编排 - **OpenAI 模型**：推理和工具选择 - **Slack Socket Mode + Web API**：实时 Slack 演示传输 - **XState**：可靠的事件生命周期状态机 - **Zod**：类型化运行时验证 - **JSON 持久化**：用于演示的重启安全事件存储 ## 📋 当前能力 - 真实的 Slack 触发事件启动 - 从消息爆发中自动检测重复事件 - 具有状态输出的模拟 Sentry 和 GitHub 调查工具 - 结构化的时事线事件状态和报告 - 显式涉及 Codex 的候选修复生成步骤 - 合并前的人工审核门控 - 发布后监控和稳定化流程 - 用于演示回放和调试的渲染化转录/报告界面 ## 🚀 运行项目 ### 先决条件 - Bun - OpenAI API 密钥 - 配置了 Socket Mode 的 Slack 应用 ### 安装 ``` bun install ``` ### 启动 ``` bun run start ``` ### 环境变量 项目期望存在一个包含以下值的 `.env` 文件： - OpenAI 访问密钥 - Slack 机器人/应用令牌 - Slack 事件频道 ID - 可选的演示特定值，如审核者提及、利益相关者提及、仓库链接和报告链接 请参阅 `.env.example` 获取完整的变量列表 ## 🗂️ 仓库结构 ``` src/ agent/ Incident Commander Agent, tools, traces, milestones incidents/ State machine, persistence, scenario engine, services slack/ Socket Mode transport, rendering, trigger detection demo/ Transcript and Slack story shaping reporting/ Incident report state and rendering routes/ Health, debug, incident, and agent endpoints ``` ## 🎯 当前范围 该仓库当前专注于一个种子计费续费事件场景。 这是有意为之。黑客松构建的目标是证明事件指挥官代理能够极其出色地处理一个可信事件的完整生命周期。 ## 🔭 未来方向 下一步不是“让演示更花哨”。而是使用真实的表面替代模拟表面： - 真实的 Sentry 集成 - 真实的 GitHub 调查和 Pull Request 链接 - 真实的事件报告目的地 - 多种事件类别 - 更丰富的生产与发布信号 - 更广泛的仓库感知事件推理 ## 为何这很重要 软件事件是代理系统可以提供杠杆的最清晰场景之一： - 工作是多步骤的 - 上下文分散在多个系统之间 - 时间至关重要 - 人类仍需保持控制 Crisis Commander Room 展示了当 Codex 成为一位运营同事而非聊天机器人时的样子。

标签：agentic incident response, AI incident-response agent, AI 代理, AI 协作, Codex, codex-crisis-room, GitHub 集成, incident simulation, RCA 根因分析, Sentry 集成, SEO 关键词, Slack 集成, SRE, Stakeholder 通知, 事件仿真, 事件报告, 人类确认, 代码修复, 偏差过滤, 健康检查, 危机管理, 合并确认, 告警关联, 操作自动化, 模拟生产环境, 监控告警, 站点可靠性工程, 自动化响应, 自动化攻击, 自动化运维, 证据关联