mdnowroz13/AI-Incident-Commander---OpenEnv-Hackathon

## 标题："Incident Commander" emoji: "🚨" colorFrom: "blue" colorTo: "indigo" sdk: "docker" pinned: false app_port: 7860 base_path: / # 🚨 AI Incident Commander — OpenEnv Environment ## 本项目解决的问题 事件响应是科技行业最关键、风险最高的挑战之一。当生产服务器宕机时，公司每秒钟都在损失资金。根据行业基准，IT 停机平均每分钟给企业造成 5,600 美元的损失（每小时超过 300,000 美元）。 目前，站点可靠性工程（SRE）完全依赖人工干预。当数据库在凌晨 3:00 崩溃时，工程师必须醒来并在数 GB 的日志中筛选以找到单一的故障点，导致严重的 SRE 职业倦怠和告警疲劳。 平均恢复时间（MTTR）受限于人类的阅读速度。虽然 AI 模型可以瞬间处理 10,000 行的日志文件，但它们一直缺乏逼真的、多步骤的训练环境来学习如何在不危及实际生产服务器的情况下安全地进行故障排查。 这个环境填补了这一空白。它为 Agent 提供逼真的服务器崩溃日志，允许其查询单个服务以进行更深入的诊断，并根据其是否正确识别根本原因并做出适当响应进行评分。这与人类 SRE 遵循的工作流程相同……专为 AI 学习而构建。 ## 为什么选择这个环境 这并非一个标准的一次性 QA 基准测试。它评估的是真正的 Agent 推理能力： 1. **多步骤推理：** Agent 不能仅从初始提示中猜测答案；它们必须主动使用 `investigate` 工具来收集隐藏的诊断线索，然后才能得出结论。 2. **密集奖励 vs 稀疏奖励：** 不同于在回合结束时给出二元的通过/失败，Agent 会因为采取了符合逻辑的故障排查步骤（例如，调查正确的服务）而获得部分奖励。 3. **真实世界后果：** Hard 任务不仅要求发现 Bug；Agent 必须起草在实际 P0 级事件期间所需的实际缓解步骤和面向客户的状态更新。 ## 这一点为何重要 Meta、Google、Amazon……每一家大型科技公司都有处理日常事件的 SRE 团队。训练 AI 自动执行此任务是 AI Agent 领域最有价值的未解决问题之一： - **真实世界的任务：** 事件响应是人类每天都在做的事情 - **多步骤推理：** Agent 必须调查、分析并采取行动——而不仅仅是回答一个问题 - **9 个独特的场景：** 每个难度级别 3 个，每个回合随机选择 - **密集奖励：** 对调查、诊断和响应质量给予部分加分 ## 任务 | 任务 | 难度 | 描述 | 最大步数 | |------|-----------|-------------|-----------| | `easy` | ⭐ Easy | 从日志中识别哪个服务崩溃 | 3 | | `medium` | ⭐⭐ Medium | 找出级联故障的根本原因 | 5 | | `hard` | ⭐⭐⭐ Hard | 完整的事件响应：根本原因 + 受影响服务 + 缓解措施 + 状态更新 | 7 | ### 场景多样性（每个难度 3 个） **Easy**：数据库连接池崩溃、磁盘已满、TLS 证书过期 **Medium**：数据库 OOM 级联、DNS 解析器崩溃、错误配置部署 **Hard**：缓存崩溃、消息队列磁盘已满、JWT 密钥轮换失败 ## 动作空间 Agent 可以采取 3 种类型的动作： ``` { "action_type": "investigate | diagnose | respond", "message": "string — analysis text (for diagnose/respond)", "target_service": "string — service name (for investigate)" } ``` | 动作 | 何时使用 | 作用 | |--------|------|-------------| | `investigate` | 诊断之前的任何时候 | 返回服务的详细诊断信息。调查相关服务可获得少量奖励。 | | `diagnose` | 0 次或多次调查后 | 提交根本原因分析。进行评分和打分。结束 easy/medium 任务。 | | `respond` | 诊断后（仅限 hard） | 提交缓解步骤和客户状态更新。结束任务。 | ## 观察空间 ``` { "echoed_message": "string — incident prompt, investigation results, or grading feedback", "system_status": {"service-name": "healthy | degraded | DOWN"}, "task_name": "string — active task", "step_number": 0, "available_actions": ["investigate", "diagnose"], "services_investigated": ["service-a", "service-b"], "done": false, "reward": 0.05 } ``` ## 评分与奖励设计 奖励是**密集的**且**被限制** 的，以确保持续反馈而不触犯非法边界（0.0 或 1.0）： | 组件 | 最大贡献 | 说明 | |-----------|-----------------|-------| | 调查 | 0.150 | 每个根本原因 +0.05，每个受影响服务 +0.02 | | 诊断 | 0.400 - 0.830 | 根据任务难度变化 | | 响应 | 0.390 | 仅限 Hard 任务 | | **最小回合总分** | **0.005** | 在第 1 步保证（安全下限） | | **最大回合总分** | **0.980** | 保证（安全上限） | ## 评分器设计 每个任务都使用上下文感知的评分器，而不是简单的关键词匹配。 **Easy 评分器**：检查响应是否正确识别了服务*作为原因*。一种否定感知的窗口扫描确保 `"user-service is not the cause"` 不会获得高分。 **Medium 评分器**：两个独立的信号——正确的服务识别（0.44 权重）和正确的技术解释（0.39 权重）。如果响应指出了正确的服务但解释错误，则只能获得部分分数。 **Hard 评分器**：诊断评分器检查根本原因识别和受影响服务覆盖范围。响应评分器独立对缓解步骤（需要 ≥ 3 个相关关键词）和客户沟通质量（需要 ≥ 4 个相关关键词）进行评分。两个部分都必须表现强劲才能获得高分。 所有评分器都使用 `clamp_score()` 来确保输出始终在 `(0.01, 0.99)` 范围内。 ## Baseline Agent 性能 运行 `Qwen/Qwen2.5-72B-Instruct` 作为 baseline agent： | 任务 | 典型得分范围 | 观察行为 | |------|--------------------|--------------------| | easy | 0.840 – 0.890 | 正确识别崩溃的服务；偶尔先进行调查 | | medium | 0.450 – 0.840 | 有时能正确追踪级联故障；在 DNS/配置 场景上表现较弱 | | hard | 0.150 – 0.550 | 诊断部分正确；缓解步骤通常缺乏具体性 | 得分分布证实了难度梯度是真实的——一个更强或调优更好的 Agent 应该在 `hard` 上获得明显更高的分数，从而提供清晰的训练信号。 ## 示例回合（Medium 任务） ``` [RESET] → Agent receives logs: 4 services down in a cascade [STEP 1] → investigate(database) reward=0.000 ← database is a victim, not the cause [STEP 2] → investigate(dns-resolver) reward=0.050 ← correct root cause service [STEP 3] → diagnose("dns-resolver crashed with SIGSEGV due to a buffer overflow in CoreDNS 1.8.3. No failover DNS was configured. All services using .internal hostnames lost name resolution.") reward=0.840 [END] → Episode total: 0.890 ``` ## 设置与使用 ``` # 1. 安装 dependencies pip install -r requirements.txt # 2. 运行 environment server python app.py # Server starts at http://localhost:7860 # 3. 在另一个 terminal 中，运行 baseline inference export HF_TOKEN="hf_..." export MODEL_NAME="Qwen/Qwen2.5-72B-Instruct" python inference.py ``` ## Docker ``` docker build -t incident-commander-env . docker run -p 7860:7860 incident-commander-env ``` ## API 端点 | 端点 | 方法 | 描述 | |----------|--------|-------------| | `/reset` | POST | 开始新回合 (`?task_name=easy\|medium\|hard`) | | `/step` | POST | 提交动作 (JSON body) | | `/state` | GET | 当前环境状态 | | `/health` | GET | 健康检查 | ## 环境变量 | 变量 | 是否必需 | 描述 | |----------|----------|-------------| | `HF_TOKEN` | 是 | HuggingFace API key | | `API_BASE_URL` | 否 | LLM 端点（默认：HF router） | | `MODEL_NAME` | 否 | 使用的模型（默认：Qwen2.5-72B） | | `ENV_URL` | 否 | 环境 URL（默认：localhost:7860） | ## Baseline 得分 | 任务 | 安全范围 | 验证器状态 | |--------|------------|------------------| | easy | 0.005–0.980 | ✅ Passing | | medium | 0.005–0.980 | ✅ Passing | | hard | 0.005–0.980 | ✅ Passing | *注意：该环境在数学上保证保持在 (0, 1) 之间，以满足 OpenEnv Phase 2 约束。* ## 项目结构 ``` incident-commander-env/ ├── app.py # FastAPI server entry point ├── environment.py # OpenEnv Environment implementation ├── models.py # Pydantic Action/Observation/State models ├── tasks.py # 9 scenarios (3 per difficulty) ├── graders.py # Context-aware grading functions ├── inference.py # Baseline inference script ├── openenv.yaml # OpenEnv metadata ├── requirements.txt # Python dependencies ├── Dockerfile # Container build └── README.md # This file ``` ## 设计决策 **为什么选择事件响应？** 这是一项人类在实时压力下且伴随真实经济损失时每天执行的任务。它需要多步骤推理，而不仅仅是单次查找，并且具有可以自动评分的明确正确答案。它不是一个玩具问题。 **为什么使用密集奖励而不是仅限终端奖励？** 稀疏奖励（仅在最后）会给 Agent 关于哪些调查步骤有帮助的零信号。密集奖励让 Agent 能够了解到早期检查根本原因服务具有特定的价值，而不仅仅是整个回合进行得很顺利。 **为什么奖励格式保留 3 位小数？** 使用 `:.2f` 格式，`0.005` 的奖励会打印为 `0.00`。评估器读取的是文本而不是浮点数。三位小数确保部分进度信号始终可见，绝不会因为四舍五入而无声丢失。 **为什么采用否定感知评分？** 朴素的关键词检查会奖励诸如“user-service *不是* 原因”的响应。评分器会扫描服务名称每次提及周围的上下文窗口，如果附近出现否定短语则拒绝它。这使得评分器对恰好提及了正确服务的含糊或错误响应具有鲁棒性。

标签：Agent, AIOps, Apex, Docker, MTTR, OpenEnv, SRE, 事件指挥, 人工智能, 仿真, 偏差过滤, 多步推理, 安全防御评估, 强化学习, 故障响应, 机器学习, 根因分析, 用户模式Hook绕过, 站点可靠性工程, 自动化运维, 训练环境, 请求拦截, 运维, 逆向工具