NaveenCK-10/AIRS-env

## 标题：AIRS Env emoji: 🤖 colorFrom: blue colorTo: purple sdk: docker app_port: 7860 pinned: false # 🚨 AIRS — Autonomous Incident Response Simulator [](https://naveenck10-airs-env.hf.space/docs) [](https://naveenck10-airs-env.hf.space) []() []() ## ⚡ AIRS 的功能 - 🔍 **诊断故障** — Agent 接收生产告警，解析嘈杂的日志，识别根本原因 - 🛠️ **采取纠正措施** — 重启服务，扩展基础设施，解决级联问题 - 📊 **对决策进行评分** — 多因子奖励评估，衡量诊断准确性、操作正确性、推理质量和效率 - 🔄 **模拟真实状态** — 操作会改变实时系统状态；错误的修复会让情况更糟 - 🎯 **难度可扩展** — 从明显的单一故障到模糊的级联停机 ## 🚀 为什么这很重要 生产事件响应是软件工程中**最困难的现实世界推理问题**之一。今天的 SRE 团队手动处理它。明天，AI Agent 将需要处理它。 | 问题 | 为什么现有基准会失败 | AIRS 如何解决它 | |---|---|---| | 事件是**有状态的** | 静态基准使用单一输入 → 输出 | AIRS 的操作会跨步骤改变系统状态 | | 诊断需要**因果推理** | 仅靠模式匹配是不够的 | 中等/困难任务具有模糊、冲突的信号 | | 错误的操作有**后果** | 对错误答案没有惩罚 | AIRS 会对不正确的操作和后期故障进行惩罚 | | 推理必须是**可解释的** | 只有最终答案重要 | AIRS 对 Agent 的解释质量进行评分 | 大多数 AI 基准测试 Agent **知道什么**。AIRS 测试它**如何思考**。 **如果您正在为 DevOps、SRE 自动化或事件响应构建 AI Agent — 这是您需要的评估环境。** ## 🧠 AIRS 的独特之处 | 特性 | AIRS | 典型基准 | |---|---|---| | **有状态模拟** | ✅ 操作改变系统状态 | ❌ 静态输入/输出 | | **多步骤回合** | ✅ 每个事件最多 5 步 | ❌ 单次预测 | | **部分得分** | ✅ 分别奖励诊断、操作和推理 | ❌ 二元正确/错误 | | **惩罚机制** | ✅ 错误操作和后期故障会受到惩罚 | ❌ 错误没有后果 | | **难度阶梯** | ✅ 简单 → 中等 → 困难，模糊度递增 | ❌ 难度扁平 | | **确定性评分器** | ✅ 可重现的分数，外部评估器 | ❌ 主观评估 | | **可解释的决策** | ✅ 推理字段按质量评分 | ❌ 不需要推理 | ## 🧩 任务设计 — 三种推理模式 每个难度级别测试一个根本不同的认知挑战： ### 🟢 简单 — 直接信号映射 (4 个事件) 具有清晰日志证据的单点故障。测试 Agent 是否能读取信号并果断采取行动。预期：**1 步**。 **示例：** `"DB connection timeout"` + 数据库状态 `"down"` → 重启数据库。 ### 🟡 中等 — 冲突信号 (4 个事件) 具有混合状态信号的模糊日志条目。测试 Agent 是否能区分**根本原因和症状**。预期：**2 步**。 **示例：** `"Cache miss rate high"` + `"DB query latency elevated"` — 这是数据库问题还是缓存问题？Agent 必须通过依赖链进行推理。 ### 🔴 困难 — 级联故障分析 (2 个事件) 所有服务同时降级。日志显示每个组件都有故障。测试 Agent 是否能执行**因果推理**以识别触发级联的起源故障。预期：**3 步**。 **示例：** API 宕机 + 数据库缓慢 + 缓存过载 — Agent 必须识别出缓存过载是根本原因，而不仅仅是最响亮的告警。 ## 🧠 推理评估 AIRS 不仅检查答案 — 它评估 **Agent 如何思考**。 ### 多因子评分 (6 个组成部分) | 因子 | 权重 | 衡量内容 | |---|---|---| | 正确的诊断 | **0.35** | Agent 是否识别了根本原因？ | | 正确的操作 | **0.40** | 它是否采取了正确的补救步骤？ | | 推理质量 | **0.15** | 解释是否实质（>5 个单词）？ | | 效率奖励 | **0.05** | 在 ≤2 步内解决？ | | 错误操作惩罚 | **−0.30** | 惩罚 `do_nothing`、`ignore`、`random_action` | | 后期故障惩罚 | **−0.10** | 3 步之后的错误操作 | ## 🧪 示例交互 **1. 启动一个事件：** ``` curl -X POST https://naveenck10-airs-env.hf.space/reset ``` ``` { "incident_id": "INC100", "alert": "High latency detected", "logs": ["DB connection timeout", "Retry failed"], "system_status": { "api": "degraded", "database": "down", "cache": "healthy" } } ``` **2. Agent 推理并行动：** ``` curl -X POST https://naveenck10-airs-env.hf.space/step \ -H "Content-Type: application/json" \ -d '{ "diagnosis": "database_failure", "action": "restart_database", "reason": "DB connection timeout in logs + database is down → root cause is database failure" }' ``` **3. 环境响应：** ``` { "reward": 0.95, "done": true, "info": { "effects": ["Database recovered"], "resolved": true } } ``` ✅ **系统在 1 步内恢复。分数：0.95/1.00。** ## 🏗️ 架构 ``` Agent ─── POST /step ──▶ ┌─────────────────┐ │ FastAPI Layer │ ◀── POST /reset, GET /state └────────┬────────┘ │ ┌────────▼────────┐ │ AIRSEnv │ Stateful episode manager └────────┬────────┘ │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ SystemSimulator Reward Engine Grader (state machine) (6 factors) (deterministic) ``` | 组件 | 文件 | 角色 | |---|---|---| | API Layer | `api/main.py` | FastAPI 端点（reset, step, state, tasks, grader, baseline） | | Environment | `core/environment.py` | 有状态的回合生命周期 + 奖励计算 | | Simulator | `core/simulator.py` | 系统状态机 — 操作改变服务健康状态 | | Grader | `evaluation/grader.py` | 确定性外部评分（镜像环境逻辑） | | Incidents | `data/incidents_v1.json` | 跨 3 个难度级别的 10 个精选场景 | | Inference | `inference.py` | LiteLLM 代理客户端 + 启发式回退 | ## 📊 基线性能 | 难度 | 基线分数 | 提升空间 | 缺失内容 | |---|---|---|---| | 🟢 简单 | **0.95** | 5% | 接近最优 — 信号清晰 | | 🟡 中等 | **0.15** | **85%** | 启发式算法无法解决模糊信号 | | 🔴 困难 | **0.15** | **85%** | 级联故障需要因果推理 | | **平均** | **0.42** | **58%** | **智能 Agent 巨大的提升空间** | ## 🌍 使用案例 | 领域 | 应用 | |---|---| | **AI SRE Agents** | 训练和评估基于 LLM 的 Agent 以进行自主事件响应 | | **DevOps Automation** | 在生产部署之前对自动修复管道进行基准测试 | | **Incident Response Training** | 为待命工程团队模拟现实的中断场景 | | **LLM Evaluation** | 测试序列推理和因果分析能力 | | **RL Research** | 具有稀疏、多因子奖励信号的多步骤决策环境 | ## ⚙️ 快速开始 ### 本地 ``` pip install -r requirements.txt uvicorn api.main:app --reload # → http://127.0.0.1:8000/docs ``` ### Docker ``` docker build -t airs-env . docker run -p 7860:7860 airs-env # → http://127.0.0.1:7860/docs ``` ## 🔌 API 参考 | 端点 | 方法 | 目的 | |---|---|---| | `/reset` | GET / POST | 开始一个新的事件回合 | | `/step` | POST | 提交诊断 + 操作 + 推理 | | `/state` | GET | 当前环境状态 | | `/tasks` | GET | 列出可用的难度级别 | | `/grader` | POST | 确定性外部评分 | | `/baseline` | GET | 基线启发式性能 | 📖 **[交互式 API 文档 →](https://naveenck10-airs-env.hf.space/docs)** ## 🧩 OpenEnv 配置 ``` name: airs-env version: 1.0.0 entrypoint: command: uvicorn api.main:app --host 0.0.0.0 --port 7860 endpoints: reset: { method: POST, path: /reset } step: { method: POST, path: /step } state: { method: GET, path: /state } tasks: { method: GET, path: /tasks } grader: { method: POST, path: /grader } baseline: { method: GET, path: /baseline } ``` ## 📁 项目结构 ``` airs-env/ ├── api/main.py # FastAPI endpoints ├── core/ │ ├── environment.py # Stateful AIRSEnv (reset / step / reward) │ └── simulator.py # System state machine ├── evaluation/grader.py # Deterministic external grader ├── baseline/run.py # Heuristic baseline runner ├── data/incidents_v1.json # 10 incident scenarios (3 difficulty levels) ├── inference.py # LiteLLM proxy inference + heuristic fallback ├── models.py # Pydantic schemas ├── tasks.py # Task definitions (easy / medium / hard) ├── openenv.yaml # OpenEnv specification ├── Dockerfile # Production container ├── requirements.txt # Dependencies └── pyproject.toml # Package configuration ``` ## 🏆 总结 AIRS 是一个**生产级 OpenEnv 环境**，它向 AI Agent 提出与真实 SRE 团队面临的相同问题：嘈杂的日志、级联故障和时间关键型决策。 它不是一个玩具基准 — 它是对现实条件下**序列推理、因果诊断和可解释操作**的结构化评估。 **Phase 1 ✅ · Phase 2 ✅ · Live on HF Spaces ✅ · Deterministic Scoring ✅**

标签：API部署, Docker, IT运维, OpenEnv, Socks5代理, SRE, 人工智能, 偏差过滤, 可解释性, 因果推理, 基础设施管理, 多步推理, 安全防御评估, 故障诊断, 根因分析, 模拟仿真, 用户模式Hook绕过, 系统状态管理, 系统运维, 级联故障, 网络安全, 自主智能体, 自动化应急响应, 训练环境, 评估基准, 请求拦截, 逆向工具, 隐私保护