Pritsudo/Incident-Review-Env
GitHub: Pritsudo/Incident-Review-Env
该项目是一个确定性的强化学习风格环境，旨在通过结构化交互和奖励机制评估大模型在生产运维事故中的响应能力。
Stars: 0 | Forks: 0
## 标题: Incident Review Env
emoji: 👀
colorFrom: blue
colorTo: indigo
sdk: docker
pinned: false
license: gpl-3.0
short_description: RL-style incident response environment
base_path: /web
# incident-review-env
## 项目概述
`incident-review-env` 是一个确定性的、RL（强化学习）风格的故障响应环境，用于评估 LLM 智能体在生产运维事故中的表现。智能体不仅通过自由形式的聊天进行回答，而是通过类型化的动作与结构化环境交互，并在每一步后获得奖励。
该环境模拟了真实的 on-call 工作流：
- 对嘈杂警报和有意义的警报进行分类
- 检查日志
- 识别根本原因
- 选择安全的补救措施
- 撰写事后分析报告
这使得该项目适合以可复现的方式对智能体行为进行基准测试。
## 动机
真实的故障响应是一项高影响力的工程任务，但仅凭非结构化的提示很难进行评估。该项目提供了：
- 确定性场景
- 类型化的 API 契约
- 明确定义的任务
- 确定性评分器
- 范围在 `0.0` 到 `1.0` 之间的归一化分数
这使得不同模型或智能体策略之间能够进行公平比较。
## 最终项目结构
```
incident-review-env/
|-- .env
|-- .dockerignore
|-- .gitignore
|-- Dockerfile
|-- README.md
|-- client.py
|-- inference.py
|-- models.py
|-- openenv.yaml
|-- requirements.txt
|-- test_smoke.py
`-- server/
|-- __init__.py
|-- app.py
|-- environment.py
|-- tasks.py
|-- graders/
| |-- utils.py
| |-- __init__.py
| |-- triage_grader.py
| |-- rca_grader.py
| `-- postmortem_grader.py
`-- scenarios/
|-- __init__.py
|-- base.py
|-- db_overload.py
|-- memory_leak.py
|-- bad_deploy.py
`-- high_latency.py
```
## 核心组件
### `server/app.py`
FastAPI 入口点。它暴露了以下接口：
- `GET /health`
- `POST /reset`
- `POST /step`
- `GET /state`
### `server/environment.py`
这是主要的环境引擎。它负责：
- 选择场景
- 重置状态
- 执行动作
- 更新奖励
- 判断任务何时完成
### `server/tasks.py`
定义可用任务：
- `alert_triage`
- `root_cause`
- `full_resolution`
### `server/scenarios/`
包含确定性故障数据集：
- `db_overload`
- `memory_leak`
- `bad_deploy`
- `high_latency`
每个场景包括：
- 警报
- 日志
- 指标
- 根本原因
- 别名
- 补救命令
- 预期的行动项
### `server/graders/`
包含确定性评分函数：
- triage grader
- RCA grader
- postmortem grader
### `models.py`
定义用于以下内容的类型化 Pydantic 模型：
- 动作
- 观察
- 奖励
- 步骤/重置响应
- 完整环境状态
### `inference.py`
这是评估使用的基线推理脚本。它负责：
- 调用 `/reset`
- 读取观察结果
- 选择动作
- 调用 `/step`
- 以 `[START]`、`[STEP]` 和 `[END]` 格式打印结构化日志
## 任务
### 1. `alert_triage`
目标：
- 将警报分类为 `symptom`（症状）、`cause`（原因）或 `noise`（噪音）
难度：
- 简单
完成条件：
- 当所有警报都被分类时完成
### 2. `root_cause`
目标：
- 分类足够的证据
- 提交有效的根本原因假设
难度：
- 中等
完成条件：
- 当分诊和 RCA 质量达到任务阈值时完成
### 3. `full_resolution`
目标：
- 分类警报
- 识别根本原因
- 应用补救措施
- 提交事后分析报告
难度：
- 困难
完成条件：
- 当补救措施成功且事后分析报告提交后完成
## 观察空间
每个 API 步骤返回一个包含以下内容的 `Observation` 对象：
- `task`
- `step_count`
- `max_steps`
- `scenario_id`
- `scenario_title`
- `alerts`
- `visible_logs`
- `metrics`
- `active_hypothesis`
- `remediation_history`
- `postmortem_submitted`
- `partial_scores`
- `hints`
- `degraded`
该观察结果是智能体进行推理的实际输入。
## 动作空间
环境支持五种动作。
### `classify_alert`
Payload：
```
{"id": "A04", "label": "cause"}
```
### `query_logs`
Payload：
```
{"keyword": "backfill"}
```
### `set_hypothesis`
Payload：
```
{"cause": "unbounded analytics backfill saturating the primary postgres database"}
```
### `issue_remediation`
Payload：
```
{"command": "pause analytics backfill"}
```
### `write_postmortem`
Payload：
```
{
"timeline": ["...", "...", "..."],
"impact": "...",
"rca": "...",
"action_items": ["...", "..."]
}
```
## 奖励逻辑
奖励是确定性的，并限制在 `0.0` 到 `1.0` 之间。
公式：
```
total =
0.30 * triage_score +
0.30 * rca_score +
0.30 * postmortem_score +
0.10 * efficiency_score
```
奖励组成部分：
- `triage_score`：警报分类质量
- `rca_score`：假设质量
- `postmortem_score`：编写的事故总结质量
- `efficiency_score`：步骤越少得分越高
- `penalty`：因不安全行为而应用
## OpenEnv 元数据
根目录下的 [openenv.yaml](d:/RL/incident-review-env/openenv.yaml) 包含：
- 环境名称和版本
- 应用入口点
- HTTP 运行时类型
- 包含难度的任务元数据
当前任务元数据：
- `alert_triage`
- `root_cause`
- `full_resolution`
## 系统的实际输入
系统的输入不是单一的纯英文提示。真正的输入是由 `/reset` 或 `/step` 返回的结构化观察结果。
观察示例：
```
{
"task": "full_resolution",
"step_count": 0,
"max_steps": 25,
"scenario_id": "db_overload",
"scenario_title": "Primary Database Saturation",
"alerts": [
{
"id": "A01",
"source": "prometheus",
"service": "orders-api",
"severity": "critical",
"message": "Checkout p95 latency exceeded 2.8s",
"timestamp": "2026-04-06T10:00:00Z"
},
{
"id": "A04",
"source": "prometheus",
"service": "orders-db",
"severity": "warning",
"message": "Long running query count above 40",
"timestamp": "2026-04-06T10:00:30Z"
}
],
"visible_logs": [
"2026-04-06T10:00:11Z orders-db postgres[4421]: LOG duration=18450ms statement=SELECT * FROM order_events ...",
"2026-04-06T10:00:28Z analytics-worker backfill[71]: started tenant-wide revenue backfill without LIMIT clause"
],
"metrics": {
"cpu": 97.0,
"latency": 2860.0,
"memory": 78.0
},
"active_hypothesis": null,
"remediation_history": [],
"postmortem_submitted": false,
"partial_scores": {
"triage": 0.0,
"rca": 0.0,
"postmortem": 0.0,
"efficiency": 1.0
},
"hints": [
"Complete triage, identify root cause, remediate safely, and submit a postmortem."
],
"degraded": false
}
```
## 系统的实际输出
系统输出是一系列动作和分数。
动作示例：
```
{"action_type": "classify_alert", "payload": {"id": "A04", "label": "cause"}}
```
```
{"action_type": "set_hypothesis", "payload": {"cause": "unbounded analytics backfill saturating the primary postgres database"}}
```
```
{"action_type": "issue_remediation", "payload": {"command": "pause analytics backfill"}}
```
最终终端输出格式：
```
[START] task=full_resolution env=incident-review-env model=Qwen/Qwen2.5-72B-Instruct backend=https://router.huggingface.co/v1 seed=44
[STEP] step=1 action={"action_type": "classify_alert", "payload": {"id": "D06", "label": "cause"}} reward=0.1210 done=False error=None
...
[END] success=True steps=9 score=0.7781 rewards=[...]
```
此格式很重要，因为评估流水线需要严格的 `[START]`、`[STEP]` 和 `[END]` 行。
## 基线行为
基线推理脚本按顺序运行所有 3 个任务：
- `alert_triage`
- `root_cause`
- `full_resolution`
典型的确定性分数范围：
- `alert_triage`：大约 `0.20` 到 `0.26`
- `root_cause`：大约 `0.50` 到 `0.55`
- `full_resolution`：大约 `0.73` 到 `0.78`
## 设置与运行
从仓库根目录：
```
python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt
```
启动服务器：
```
uvicorn server.app:app --host 0.0.0.0 --port 7860
```
运行推理：
```
python inference.py
```
运行测试：
```
python -m unittest test_smoke -v
```
## 必需的环境变量
项目支持：
- `API_BASE_URL`
- `MODEL_NAME`
- `HF_TOKEN`
- `ENV_BASE_URL`
- `RUN_SEED`
- `MAX_STEPS`
- `SUCCESS_THRESHOLD`
## 验证状态
该项目结构专为 OpenEnv 风格的评估而设计，包括：
- 类型化模型
- 根目录 `inference.py`
- 根目录 `openenv.yaml`
- 根目录 `Dockerfile`
- 3 个任务
- 评分器
- 确定性评分
- 结构化日志
这使得该项目已准备好进行最终验证和提交。
标签：Agent, API交互, AV绕过, DLL 劫持, Docker, FastAPI, LLM, Python, RL, SRE, Unmanaged PE, 事后分析, 事故响应, 偏差过滤, 告警分类, 大语言模型, 安全防御评估, 强化学习, 技术债务, 故障排查, 无后门, 根因分析, 环境模拟, 生产环境, 确定性环境, 自动化运维, 评估, 请求拦截, 运维, 逆向工具