CloudOpsBench: najlepsi agenci AI rozwiązują około 60 proc. zadań w chmurze AWS, a większość porażek to błędy rozumowania
CloudOpsBench to otwarty benchmark, który testuje agentów AI na codziennych zadaniach inżynierów DevOps. Wersja 1.0 zawiera 45 zadań na AWS, od naprawy awarii i migracji po zabezpieczanie dostępu i likwidację całych projektów. Autorzy, zespół kierowany przez Anga Chena z Uniwersytetu w Michigan, twierdzą, że głównym problemem agentów nie jest wiedza o chmurze, tylko rozumowanie.
Ranking: 60,6 proc. na szczycie
Według publicznego leaderboardu najlepszy wynik uzyskał Claude Fable 5.1 (tryb max) uruchomiony w Claude Code: wskaźnik zaliczonych prób wyniósł 60,6 proc. Drugie miejsce zajął GPT-6 Astra (max) w Codex z wynikiem 58,9 proc., trzecie Gemini 4 Argon (high) w Gemini CLI z 57,5 proc. Czwarty jest Grok 4.7 (high) w Cursor CLI z 56,5 proc. Stawkę zamykają modele otwarte lub tańsze: DeepSeek V4.1 Flash z 21,8 proc. i Kimi K3.1 Pro z 19,1 proc.
Ranking pokazuje też, jak bardzo liczy się narzędzie, w którym model pracuje. GPT-6 Astra na poziomie „high” osiąga 54,2 proc. w Codex, ale 42,8 proc. w frameworku Terminus-2. Grok 4.7 (high) ma 56,5 proc. w Cursor CLI i 48,3 proc. w Grok Build. Różnice kosztów są duże: wynik Claude’a Fable 5.1 kosztował według tabeli 404,3 dol., a niewiele słabszy Gemini 4 Argon 100,5 dol.
Jak to mierzą
Zgodnie z opisem metodologii każdy wpis w rankingu to 45 zadań uruchamianych czterokrotnie, czyli 180 prób. Agent dostaje powłokę bez uprawnień roota oraz dostęp do AWS CLI, boto3 i Terraform, a na zadanie ma 40 minut. Wskaźnik rozwiązań liczony jest jako zaliczone próby podzielone przez sumę zaliczonych, niezaliczonych i zakończonych przekroczeniem czasu. Błędy ewaluacyjne są z rachunku wyłączane.
Zadania można uruchomić w prawdziwym AWS albo w emulatorze Vera Emulator, a wyniki w obu trybach mają być identyczne. Chen mówił o tym w rozmowie z The Register: „przebieg działania oraz wyniki agenta w prawdziwej chmurze i w naszym emulatorze są dokładnie takie same”. Dodał, że zaletą benchmarku jest brak konieczności korzystania z rzeczywistego wdrożenia w chmurze, co obniża koszt i ryzyko testów.
Gdzie agenci się mylą
W analizie porażek autorzy ustalili, że około 80 proc. niepowodzeń to błędy rozumowania: agent źle ocenia zakres zadania, nie sprawdza wszystkich istotnych usług albo kończy pracę zbyt wcześnie. Pozostałe około 20 proc. to niewłaściwe działania, a część z nich ma nieodwracalne skutki dla infrastruktury. Żaden z testowanych modeli nie wykonuje wszystkich zadań.
Dla zespołów myślących o oddaniu agentom dostępu do produkcyjnej chmury ważny jest rodzaj błędu. Agent, który nie znajdzie wszystkich zasobów do posprzątania albo uzna zadanie za skończone w połowie, zostawia po sobie niedokończoną robotę. Rzadszy, ale groźniejszy scenariusz to działanie, którego nie da się cofnąć.
Otwarty projekt, kolejne chmury w planach
Kod projektu jest dostępny na GitHubie na licencji Apache 2.0. Autorzy planują rozszerzenia na GCP, Azure i OCI. CloudOpsBench nie jest jedyną próbą ustandaryzowania takich testów. Microsoft opisał wcześniej framework AIOpsLab, a społeczność Kubernetes publikuje roadmapę devops-bench, z naciskiem na testy na żywych klastrach.
Warto zauważyć, że liczby w różnych opisach CloudOpsBench nie zawsze są podawane w ten sam sposób. Tabela na stronie głównej podaje 58,9 proc. dla GPT-6 Astra w trybie max, a w niektórych streszczeniach pojawia się niższa wartość około 53 proc.
