DevOps-Gym: Benchmarking AI Agents in Software DevOps Cycle¶
会议: ICLR 2026
OpenReview: https://openreview.net/forum?id=bP48r4dt7Z
代码: 待确认（论文承诺开源，含评测框架与 baseline 实现）
领域: 代码智能 / AI Agent / 软件工程评测
关键词: DevOps、AI Agent、软件工程 benchmark、工具调用、长程任务
一句话总结¶
DevOps-Gym 是首个覆盖软件 DevOps 全周期（构建配置、运行监控、问题修复、测试生成）的端到端 agent 评测基准，用半自动方式从 30+ 个 Java/Go 真实项目收集 700+ 个任务，并提供带工具调用接口的动态执行环境；评测发现即便是最强的 Claude Code + Claude-4-Sonnet，在监控、构建配置等运维任务上也只有 20%~50% 成功率，端到端流水线任务则是全军覆没的 0%。
研究背景与动机¶
领域现状：随着 LLM 和 agent 的发展，软件开发环节（写代码、改 GitHub issue）已经能被大幅自动化，SWE-bench、HumanEval、SWT-bench 这类基准也把"代码生成 / 问题修复 / 测试生成"评测得相当成熟。
现有痛点：但 DevOps 不只是写代码。一个完整的软件交付周期还包括构建部署、运行监控、运维管理这些"开发之后"的环节，而它们至今仍高度依赖人工。现有基准几乎全部聚焦在孤立的开发任务上，要么只评单点能力，要么把运维任务放在仿真环境或狭窄的基础设施场景（如 IT-bench 的模拟环境、AIOpsLab 的微服务云场景）里，没有一个基准能在真实仓库上评测端到端的 DevOps 能力。
核心矛盾：运维任务和纯代码生成有本质差异——诊断一次内存泄漏，需要反复调用 ps、iostat 这类领域工具去观察进程/IO 状态，解读输出找异常信号，再做多步决策。这要求 agent 具备分析大型项目、理解动态运行时行为、调用领域专用工具、做序贯决策的能力，而这正是现有"读 issue 描述→生成 patch"式静态评测覆盖不到的盲区。同时，绝大多数现有基准也不是为 agentic 系统设计的，缺少带工具调用接口的动态执行环境。
本文目标：构建一个能在真实软件项目上评测 agent 完整 DevOps 周期能力的基准——既要覆盖构建/监控这些未被评测过的运维阶段，又要把任务做成需要工具调用和多步规划的 agentic 形式，还要配套能严格、可扩展打分的执行环境。
核心 idea：把 DevOps 周期蒸馏成四个最小可行阶段（构建配置 → 监控 → 问题修复 → 测试生成），从真实 Java/Go 项目里半自动收集任务，再额外构造把四阶段串起来的端到端流水线任务，统一封装成 terminal-bench 格式的工具调用环境，让 agent 像真实运维工程师一样"在跑着的系统上干活"。
方法详解¶
整体框架¶
DevOps-Gym 本质是一套基准数据集 + 动态评测环境。它把软件 DevOps 周期抽象为四个核心阶段，每个阶段给 agent 一个真实项目和一组对应的命令行工具，要求 agent 通过多步工具调用完成任务：
- 构建配置（Build & Configuration）：工具如
maven、gradle、npm；输入是构建失败的项目或新构建需求，输出是修复 patch 或完整配置文件。 - 监控（Monitoring）：工具如
top、iostat、pprof、ps、free、netstat；输入是一个跑着隐藏性能/资源异常的容器化应用，输出是结构化诊断报告（异常类型 + 量化证据）。 - 问题修复（Issue Resolving）：工具如
sed、grep、awk；输入是带 bug 的项目 + issue 描述，输出是修复 patch。 - 测试生成（Test Generation）：工具如 JUnit、Maven、Go test；输入是 issue 描述，输出是回归测试（断言、覆盖率）。
四阶段之上还有端到端流水线任务：把构建→监控→修复→测试四步顺序串成一条龙，任一步失败整条流水线就算失败。整个基准最终含 704 个任务（54 构建配置 + 34 监控 + 310 问题修复 + 310 测试生成）加 18 个端到端任务，跨 30+ 个真实 Java/Go 仓库，全部转成 terminal-bench 标准格式以便统一的工具调用与打分。
数据收集采用半自动 + 重度专家介入：自动挖掘 CI 日志里的"失败-成功"构建对、用 Multi-SWE-bench/SWT-bench 流程采集修复/测试任务；专家则负责分析上千个真实 GitHub issue 归类异常类型、注入合成故障、复现环境、设计打分。论文强调复现一个监控/构建任务往往要专家花 10+ 小时（重建环境、依赖、配置、触发输入），coding agent 帮不上忙甚至会"抄近道"注入更易触发的别的错误。
关键设计¶
1. 四阶段最小可行 DevOps 流水线：把"开发之后"的运维环节也纳入评测
针对"现有基准只评开发、不评运维"的盲区，作者把 DevOps 蒸馏成构建配置、监控、问题修复、测试生成四个阶段——前两个是几乎没被评测过的新任务，后两个是已有成熟基准的延伸。选这四个的逻辑是它们构成"能跑起来 → 能发现问题 → 能修问题 → 能验证修复"的最小闭环。语言上特意选 Java 和 Go 而非 Python，因为它们代表大型企业级项目、有标准化且非平凡的构建系统和成熟的监控工具链，能逼出真实运维场景的复杂度；同时也顺带暴露了"Python 中心的 agent 跨语言能力差"这一问题。每个阶段都配一组对应的命令行工具，强制 agent 通过工具调用而非静态推理来解题。
2. 监控任务聚焦"渐进式异常"而非崩溃：考验持续观测与时序推理
监控是这套基准最难、也最能区分 agent 能力的阶段。设计上作者刻意只评性能/资源异常，不评崩溃——因为崩溃能直接从 console 或 error log 看出来，没有诊断价值；而内存泄漏、磁盘泄漏、句柄耗尽、CPU 飙升（资源类）以及 IO 瓶颈、低效 SQL 查询（性能类）这六类异常呈现的是缓慢退化模式，早期症状微妙，需要 agent 跨多次请求采集系统行为、对比正常与异常的细微差异才能发现。论文举的例子很具体：一个文件服务器为大文件（≥2 MB）下载引入内存缓存却忘了释放，只在请求大文件时泄漏；agent 必须捕捉跨请求的行为差异才能定位。任务里还混入"系统完全健康"的样本，要求 agent 不能把正常波动误报成异常（考验假阳性控制）。评测用二元准确率：agent 把诊断结论单行写进指定文件，pytest 脚本检查文件是否存在、诊断类型是否与 ground truth 一致。
3. 严格的数据去污染与可复现保障：让评测结果可信
新基准面对的最大威胁是训练数据污染。作者用前缀补全分析（prefix-completion analysis）识别并过滤可能已进入训练语料的仓库，同时删除仓库的 git 元数据防止 agent 从版本历史里直接翻到答案。对每个复现的任务，还由三位资深 DevOps 工程师独立验证异常"确实存在且能被给定工具检测到"（observability validation），异常需在标准监控工具下 5~15 分钟内显现。对构建任务这类既要动态执行验证、又要静态配置分析的场景，则逐任务手工设计多维度打分指标（如框架迁移任务要设计能跨多种配置工具的统一指标）。正是这套去污染让作者能更有底气地把"agent 在 Java/Go 上掉点"归因于真实能力差距，而非记忆泄漏。
4. 端到端流水线任务：考验跨阶段的上下文传递与长程规划
孤立评单点能力测不出 agent 在真实运维里最缺的东西——跨工具维持问题上下文、在阶段间传递诊断信息、验证端到端解的正确性。于是作者构造端到端任务：Stage 1 注入构建配置错误让项目编译不过，agent 先修好建立可运行基线；Stage 2 部署并监控这个含潜伏性能/资源问题的系统，在不被告知问题类型的前提下用工具识别异常；Stage 3 据监控结论做代码级修复；Stage 4 重新构建并写回归测试，且测试必须精准针对 Stage 2 识别出的性能特征。四阶段必须顺序全部通过才算成功，任一步失败即终止——这映射了真实部署里"部分解没有价值"的约束，也是把四个能力真正串成工作流的唯一方式。
一个完整示例¶
以内存泄漏的端到端任务为例走一遍：① agent 拿到一个被注入了"缺依赖/路径错"的文件服务器仓库，先用 maven/gradle 诊断 error log、改配置、重新编译，把项目跑起来（Stage 1 构建）；② 系统跑起来后，agent 用 top/free/ps 持续观测，发现请求大文件时内存只增不减——但它必须在不断涌入的监控 token 流里维持注意力、对比大/小文件请求的差异，才能判定这是"内存泄漏"而非正常波动（Stage 2 监控）；③ 据此定位到那段忘了释放缓存的代码，生成修复 patch（Stage 3 修复）；④ 重新构建并写一个专门触发大文件下载、验证内存不再泄漏的回归测试（Stage 4 测试）。实测中 agent 常卡在 Stage 2——要么 context 被监控流撑爆，要么沉迷分析早期观测而停止实时监控——导致整条流水线 0% 通过。
实验关键数据¶
主实验¶
评测三个最强 agent 框架（OpenHands、mini-SWE-agent、Claude Code）配 5 个 LLM（Claude-4-Sonnet、o4-mini、Gemini-2.5-Pro、DeepSeek-V3.1、Qwen3-Coder-30B），各阶段成功率（%）：
| Agent + 模型 | 构建配置 | 监控 | 问题修复 | 测试生成 |
|---|---|---|---|---|
| Claude Code + Claude-4-Sonnet | 51.85 | 20.56 | 23.87 | 13.87 |
| OpenHands + Claude-4-Sonnet | 42.59 | 14.70 | 23.87 | 11.61 |
| OpenHands + o4-mini | 24.07 | 8.82 | 10.32 | 8.70 |
| OpenHands + Gemini-2.5-Pro | 16.66 | 11.76 | 10.96 | 2.90 |
| OpenHands + Qwen3-Coder-30B | 20.37 | 5.89 | 13.22 | 6.13 |
| OpenHands + DeepSeek-V3.1 | 11.11 | 0.00 | 14.20 | 3.22 |
| mini-SWE-Agent + Claude-4-Sonnet | 29.62 | 2.91 | 5.16 | 0.98 |
| Aider + Claude-4-Sonnet | 5.55 | 0.00 | 9.67 | 2.25 |
最强组合 Claude Code + Claude-4-Sonnet 各阶段成功率仅 13.87%~51.85%，监控和测试生成尤其惨。端到端流水线任务则所有 agent 全是 0%——没有任何一个 agent 能把四阶段全部走通。
跨语言对比与错误分析¶
| 对比维度 | 数据 | 说明 |
|---|---|---|
| 问题修复跨语言掉点 | SWE-bench-Verified 70.4% → DevOps-Gym(Java/Go) 23.87% | 同样 OpenHands+Claude-4-Sonnet，换到 Java/Go 暴跌约 47 个百分点 |
| 构建配置错误类型 | 工具链/环境检测受限 33% / 多步规划失败 23% / 领域知识缺口 37% | 其中 17% 属"本质困难"任务 |
| 框架差异 | Claude Code 远超 mini-SWE-Agent（同为 Claude-4-Sonnet） | agent 架构设计对 SE 任务至关重要 |
关键发现¶
- 监控是最大短板：DeepSeek-V3.1、Aider 等在监控上直接 0%。三大根因——① 监控产生持续演化的状态流，token 还没暴露出问题 context 就被撑爆；② agent 难以持续聚焦实时监控，常分心去分析早期观测而停止观测活系统；③ 基线判别能力差，把正常波动误报成异常。说明当前 agent 缺乏时序推理和持续注意力机制。
- 测试生成比问题修复更难：同一批 issue 上，生成高质量测试的准确率明显低于修复率，因为写测试既要静态理解整个仓库、又要动态推理 bug 如何被触发，而生成 patch 有时靠静态分析（issue 描述里常暗示了修法）就能蒙对。
- 跨语言能力鸿沟真实存在：Java/Go 的编译、依赖管理、构建配置对 Python 中心的 agent 是硬骨头；经严格去污染后这一结论更可信，且从 Claude-3.7→Claude-4 的提升并未跨越这道坎。
- 构建实现类任务（迁移/发布）尤其差：agent 卡在不理解 Maven、goreleaser 这类构建工具的内部机制和真实用法，而不只是解析 error log——这与"改源码 bug"（上下文自包含）有本质区别。
亮点与洞察¶
- 把"开发之后"的运维环节做成可评测基准，是这篇最大的贡献。监控、构建配置这两个阶段几乎没有先例，作者通过专家注入合成异常 + 真实 issue 复现，把"看着系统跑、用工具找异常"这种动态任务标准化成可自动打分的形式。
- 监控任务"只评渐进式异常不评崩溃"的设计取舍很巧：崩溃太好查、没区分度，渐进退化才真正考验时序推理——这个洞察可迁移到任何"诊断类" agent 评测。
- 端到端 0% 这个结果本身就是强信号：它干净利落地证明了当前 agent 在"跨阶段上下文传递 + 长程规划"上的根本缺失，比单点成功率更能说明问题。
- 严格去污染（前缀补全 + 删 git 元数据） 让"跨语言掉点"的归因可信，这套方法论对任何想发布新代码基准的工作都值得借鉴。
- "工具是 OOD"的假设很有启发性：base LLM 很少在 DevOps 工具调用轨迹上训练，所以构建/监控工具用不好——这指向了用专门 agent 工作流数据训练专用模型的方向。
局限与展望¶
- 规模与覆盖有限：监控仅 30~34 个任务、端到端仅 14~18 个，且只覆盖 Java/Go 两种语言和四个 DevOps 阶段；作者承诺继续扩任务、扩语言、扩阶段。
- 评测成本高：复现一个监控/构建任务要专家 10+ 小时，半自动流程难以快速规模化，限制了基准的持续扩张速度。
- 当前只测最强 agent/模型以建立性能上界，尚未系统评测更弱的模型，对"难度梯度"的刻画还不完整。
- 监控用二元准确率评分，只判异常类型对不对，未必能区分"找对类型但证据薄弱"和"诊断扎实"的差别，评测粒度可以更细。
- 可改进方向：作者呼吁社区共建——补更多异常场景与指标、开发更强 agent、训练面向 agent 工作流优化的专用模型。
相关工作与启发¶
- vs SWE-bench / Multi-SWE-bench：SWE-bench 评 Python 仓库的 issue 修复，DevOps-Gym 把问题修复延伸到 Java/Go 并加了更严格的去污染；同一 agent 在 SWE-bench-Verified 上 70.4%、到 DevOps-Gym 只剩 23.87%，更 definitive 地验证了跨语言鸿沟（Multi-SWE-bench 报告过类似趋势但污染控制较弱）。
- vs SWT-bench：SWT-bench 评 Python 的测试生成、用代码覆盖率作软指标；DevOps-Gym 评编译型语言、用"测试必须精准复现 issue 失败且在修复后通过"的严格指标，因此更难。
- vs IT-bench / AIOpsLab：这两者也评监控/运维，但 IT-bench 偏仿真环境、AIOpsLab 局限于微服务云场景且指标偏 agent 效率与成本；DevOps-Gym 在真实仓库上覆盖端到端四阶段，关注任务正确性而非仅效率。
- 核心区别：现有工作几乎都是孤立单点任务、且非为 agentic 系统设计、缺动态工具调用环境；DevOps-Gym 是首个把端到端 DevOps 周期 + 真实仓库 + 工具调用接口 + 严格打分四者合一的基准。
评分¶
- 新颖性: ⭐⭐⭐⭐⭐ 首个端到端 DevOps 全周期 agent 基准，监控/构建配置两个阶段几乎无先例
- 实验充分度: ⭐⭐⭐⭐ 覆盖 3 框架 × 5 模型，错误分析细致，但弱模型与更大规模尚待补充
- 写作质量: ⭐⭐⭐⭐ 动机清晰、任务构造与挑战交代充分，结果（尤其端到端 0%）很有冲击力
- 价值: ⭐⭐⭐⭐⭐ 精准戳中"agent 只会写代码、不会运维"的盲区，为 SE agent 研究指明方向