Ankitpatil944/-incident-response-commander
GitHub: Ankitpatil944/-incident-response-commander
这是一个用于评估 AI 代理在生产中断期间指挥能力的基准环境，模拟真实告警与拓扑证据以测试事故分类、团队分配及决策沟通能力。
Stars: 0 | Forks: 0
title: Incident Response Commander
sdk: docker
app_port: 7860
base_path: /web
tags:
- openenv
- incident-response
- sre
- production
- real-world
# 事件响应 Commander
`incident_env` 是一个用于**生产中断期间事故指挥**的真实 OpenEnv 基准测试。与解决玩具问题不同，Agent 必须表现得像一个值班的 Incident Commander：对严重性进行分类，分配正确的响应团队，决定是否升级，并在不确定的情况下发布结构化状态更新。
该环境旨在实现**确定性评估**和**轨迹形状奖励**，同时感觉就像一个实际的操作工作流。每个回合都会展示来自隐藏事故场景的告警、日志、服务拓扑和时间线证据。Agent 通过标准的 OpenEnv 循环进行交互：`reset()` → `step()` → `state()`。
## 为什么这个基准测试很重要
现代 Agent 越来越被要求在高风险的生产环境中运行。事故指挥需要：
- 将根本原因与下游症状区分开来
- 选择正确的组织所有者，而不仅仅是命名一个损坏的服务
- 决定是否有必要进行广泛的升级
- 清晰地沟通，避免幻觉或夸大客户影响
该基准测试评估 Agent 是否可以按顺序完成这四项工作，并进行确定性评分，并对低质量决策给予明确惩罚。
```
flowchart LR
A[Reset Task] --> B[Alerts + Logs + Timeline]
B --> C[Agent Decision]
C --> D[Classify Severity]
C --> E[Assign Team]
C --> F[Set Escalation]
C --> G[Publish Status]
D --> H[Reward + Penalties]
E --> H
F --> H
G --> H
H --> I[Next State or Episode End]
```
## Agent 必须做什么
每个回合都需要四个具体的输出：
1. `SEV-1` 到 `SEV-4` 严重性分类
2. 负责团队分配：
`backend`, `infra`, `database`, `network`, `security`, `sre`
3. 升级决策：
`true` 或 `false`
4. 结构化沟通：
`summary`, `customer_impact`, `next_action`, `owner`
该环境目前包含 **28 个确定性场景**：
- `8` 个简单
- `8` 个中等
- `12` 个困难
困难场景包含冲突信号、嘈杂的基础设施症状、误导性告警和模糊的所有权，以减少简单的模式匹配。
## 任务设计
公开了三个基准测试任务并由基线使用：
| Task ID | Difficulty | What It Tests |
|---|---|---|
| `easy_triage` | Easy | 具有明显所有权和严重性的明显故障 |
| `medium_coordination` | Medium | 需要更好的团队/升级推理的混合信号 |
| `hard_conflict` | Hard | 最响亮的告警并非根本原因的冲突证据 |
任务选择在 [incident_env/tasks/catalog.py](./incident_env/tasks/catalog.py) 中实现，场景数据在 [incident_env/tasks/scenarios.py](./incident_env/tasks/scenarios.py) 中。
```
xychart-beta
title "Benchmark Shape"
x-axis ["easy_triage", "medium_coordination", "hard_conflict"]
y-axis "Relative reasoning burden" 0 --> 10
bar [3, 6, 9]
```
## 动作、观察和状态空间
### 动作：`IncidentAction`
Agent 使用类型化的 Pydantic 模型执行操作：
- `action_type`
- 用于 `classify_severity` 的 `severity`
- 用于 `assign_team` 的 `team`
- 用于 `set_escalation` 的 `escalate`
- 用于 `publish_status` 的 `status_update`
- 可选的 `rationale`
### 观察：`IncidentObservation`
Agent 接收：
- 事故元数据：`incident_id`、`title`、`task_name`、`difficulty`
- 证据：`alerts`、`logs`、`service_map`、`timeline`
- 四个所需决策维度的进度标志
- 目前提交的选择
- `allowed_actions`
- `last_action_error`
- `reward_breakdown`
- `steps_remaining`
### 状态：`IncidentState`
环境跟踪：
- 回合身份和计数器
- 提交的严重性/团队/升级/状态
- 每个维度的奖励组件
- 累积惩罚
- 最终有界分数
## 奖励设计
环境在整个轨迹中返回形状奖励，而最终回合分数则严格保持在评估器要求的范围内。
正向组件：
- `+0.30` 正确的严重性
- `+0.30` 正确的团队
- `+0.20` 正确的升级
- `+0.20` 准确的沟通
沟通学分分为：
- 服务/事故摘要质量
- 客户影响正确性
- 缓解方向
- 所有者正确性
惩罚行为：
- 错误的严重性/团队/升级决策会降低分数
- 重复的决策会降低分数
- 低质量或矛盾的状态更新会降低分数
- 当上游分流错误时，沟通会被削弱
所有公开的任务分数都严格限制在 `(0, 1)` 范围内，以满足评估要求。
## 基线推理
所需的根级 [inference.py](./inference.py) 使用 OpenAI 客户端并发出严格的评估器日志：
- `[START]`
- `[STEP]`
- `[END]`
它按顺序运行所有三个任务，目前产生：
| Task | Local Baseline Score |
|---|---|
| `easy_triage` | `0.99` |
| `medium_coordination` | `0.99` |
| `hard_conflict` | `0.99` |
该基线是确定性的，并由证据驱动。它不再直接基于精确的场景标题。
## 本地设置
```
python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install --upgrade pip
pip install -e .[dev]
Copy-Item .env.example .env
```
至少设置：
```
HF_TOKEN=your_token_here
API_BASE_URL=https://router.huggingface.co/v1
MODEL_NAME=Qwen/Qwen2.5-72B-Instruct
```
## 本地运行
直接 Python 使用：
```
from incident_env import IncidentAction, IncidentEnv, SeverityLevel
env = IncidentEnv()
obs = env.reset("easy_triage")
obs, reward, done, info = env.step(
IncidentAction(action_type="classify_severity", severity=SeverityLevel.SEV1)
)
```
启动环境服务：
```
python -m server.app
```
或者：
```
server
```
然后打开：
```
http://127.0.0.1:7860/web
```
## 验证
```
python -m pytest -q
.\.venv\Scripts\openenv validate
python inference.py
docker build -t incident-env .
docker run --rm -p 7860:7860 incident-env
```
## Docker 和 Hugging Face Spaces
根目录下的 [Dockerfile](./Dockerfile) 兼容 HF Space，并设置：
- Python 3.11 slim
- `ENABLE_WEB_INTERFACE=true`
- `uvicorn server.app:app --host 0.0.0.0 --port 7860`
使用以下命令部署：
```
.\.venv\Scripts\openenv push --repo-id /incident-response-commander
```
部署后，设置 Space 配置：
- Secret: `HF_TOKEN`
- Variable: `API_BASE_URL=https://router.huggingface.co/v1`
- Variable: `MODEL_NAME=Qwen/Qwen2.5-72B-Instruct`
然后验证：
- `/reset`
- `/schema`
- `/web`
## 仓库布局
```
incident_env/
|-- client.py
|-- env.py
|-- graders.py
|-- models.py
|-- task_graders.py
|-- server/
| |-- app.py
| |-- incident_environment.py
| |-- requirements.txt
| `-- web_ui.py
`-- tasks/
|-- catalog.py
`-- scenarios.py
```
## 是什么让此提交强有力
- 真实的操作工作流，而不是玩具基准测试
- 确定性和程序化评分
- 带有惩罚的轨迹形状奖励
- 明确的简单/中等/困难进阶
- Docker + Hugging Face Space 部署
- 用于事故演练的自定义 `/web` 界面
- 在 `openenv.yaml` 中公开任务/评分器
## 范围
这故意设计为 **incident command benchmark**，而不是一个完整的工单系统、chatops 或实时工具使用模拟器。该环境针对黑客松约束下的可靠评估进行了优化：确定性评分、有界运行时间和简单部署，同时仍然模拟组织关心的真实决策循环。
标签：AI基准测试, Docker, NIDS, OpenEnv, SRE, 事件指挥, 偏差过滤, 决策支持, 升级决策, 告警管理, 团队调度, 大模型评测, 安全防御评估, 容器化, 故障响应, 故障定级, 服务拓扑, 根本原因分析, 状态更新, 生产环境, 确定性评估, 自动化运维, 请求拦截, 轨迹奖励, 逆向工具