Бенчмарк для ИИ-бэкендеров: как ABC-Bench проверяет настройку Docker и деплой, и почему Claude 4.5 здесь лучший

Код написан. Контейнер не запускается. Знакомо?

ИИ-агенты 2026 года генерируют код, который заставляет плакать от умиления. Чистый, идиоматичный, с учётом всех последних фич языка. А потом этот код пытается зажить в Docker-контейнере и умирает на третьей секунде из-за неправильного WORKDIR.

Это не баг. Это системная проблема. Модели научились писать, но не научились разворачивать. ABC-Bench, опубликованный в январе 2026, вскрыл этот нарыв публично. И да, результаты до сих пор (на 08.03.2026) шокируют.

SWE-bench устарел. Встречайте ABC-Bench

Старые бенчмарки вроде BigCodeArena проверяли код в вакууме. ABC-Bench — это полный цикл. От пустой директории до работающего API, который отвечает на HTTP-запросы.

Задача для агента выглядит так: "Создай сервис на FastAPI для управления задачами с PostgreSQL". Звучит просто. Но под капотом:

• Нужно выбрать правильный базовый образ (Python:3.12-slim, а не alpine, если не хочешь проблем с компиляцией).
• Написать Dockerfile, который копирует код, устанавливает зависимости из requirements.txt с учётом версий.
• Создать docker-compose.yml, который поднимает сервис и базу, линкует их, настраивает volumes для персистентности.
• Прописать healthcheck для контейнера с приложением.
• Убедиться, что сервис запускается и на GET /health отдаёт 200 OK.

Это не теортест. Это работа бэкенд-разработчика. И именно здесь ИИ-агенты, претендующие на эту роль, спотыкаются.

Разбор полётов: как модели гробят деплой

Авторы ABC-Bench не просто фиксируют успех/провал. Они записывают каждое действие агента и классифицируют ошибки. После анализа тысяч запусков вырисовывается чёткая картина глупостей.

Самое смешное (и грустное): многие агенты пишут идеальный код приложения, но потом в Dockerfile делают COPY . /app а рабочую директорию указывают как WORKDIR /src. Или экспозируют порт 8000 в Dockerfile, а в коде приложение слушает 8080. Мелочь? В продакшене из-за этого останавливаются развертывания.

Лидер безоговорочный: Claude Sonnet 4.5

На фоне этого провального карнавала выделяется одна модель. Claude Sonnet 4.5 (актуальная версия на март 2026) набрала 68% успешных выполнений задач в ABC-Bench. Разрыв со вторым местом — больше 20 пунктов. Почему?

Он не идеален. Пропускает healthcheck, иногда ошибается с версиями Python для конкретных библиотек. Но он единственный, кто стабильно делает три ключевые вещи:

1. Использует многоэтапную сборку (multi-stage build) для оптимизации размера образа.
2. Явно задаёт переменные окружения для подключения к БД в docker-compose.yml.
3. Пишет скрипт запуска с gunicorn/uvicorn для продакшена, а не для разработки.

Это уровень senior-разработчика, а не стажёра. Подробнее об этом разрыве мы писали в разборе первых результатов ABC-Bench.

Хватит читать, давайте тестировать: запуск ABC-Bench

Хотите проверить своего любимого агента? ABC-Bench — open source. Вот как его крутить.

1 Подготовка стенда

Вам нужен Linux-сервер или мощная машина с Docker и Python 3.12+. Виртуалка подойдёт. Клонируем репозиторий и ставим зависимости.

git clone https://github.com/abc-bench/abc-bench.git
cd abc-bench
pip install -r requirements.txt

Важно: убедитесь, что Docker daemon запущен и у пользователя есть права на его использование без sudo. Иначе агент не сможет запускать контейнеры.

2 Выбор и настройка агента

ABC-Bench работает с агентами через единый API. В папке agents/ есть примеры для Claude, GPT, Gemini. Возьмём для теста Claude 4.5 через Anthropic API.

Создаём файл конфигурации config/claude_sonnet.yaml:

agent_type: "claude"
model: "claude-3-5-sonnet-20241022"
api_key: ${ANTHROPIC_API_KEY}
temperature: 0.1
max_tokens: 4000

3 Запуск задачи

Задачи лежат в tasks/. Выбираем, например, task_03_fastapi_postgres.json. Запускаем бенчмарк.

python run_benchmark.py \
  --agent-config config/claude_sonnet.yaml \
  --task tasks/task_03_fastapi_postgres.json \
  --output-dir results/claude_run_1

Скрипт создаст изолированную временную директорию, передаст агенту описание задачи и будет записывать все его действия: каждый созданный файл, каждую выполненную команду. Процесс занимает от 10 до 45 минут в зависимости от модели.

4 Чтение отчёта

После завершения в output-dir появится детальный лог и финальный вердикт. Самое интересное — файл summary.json.

{
  "task_name": "fastapi_postgres",
  "success": true,
  "total_time_seconds": 842,
  "failure_reason": null,
  "files_created": ["Dockerfile", "docker-compose.yml", "requirements.txt", "app/main.py"],
  "checks_passed": ["container_built", "services_up", "api_health_ok"]
}

Если success: false — смотрите failure_reason и логи в agent_steps.log. Там будет пошаговая история того, как агент шёл к провалу.

Ошибки, которые вы увидите первыми

Проверив пару моделей, вы начнёте узнавать паттерны. Вот на что смотреть сразу.

• Таймаут установки зависимостей. Агент указывает в requirements.txt библиотеку без версии, она тянет за собой граф зависимости, и pip install длится 20 минут, пока бенчмарк не отрубит задачу. Лечение: всегда фиксировать версии.
• Проблемы с volumes в docker-compose. Классика: - ./:/app:ro сломается, если запускать не из той директории. Нужно использовать абсолютные пути или переменные.
• Забытый .dockerignore. Агент создаёт идеальный Dockerfile, но в образ попадает 2 ГБ мусора. Бенчмарк это не штрафует, но в реальности — критично.
• Неправильный порядок команд в Dockerfile. COPY до RUN pip install? Кеш слоёв не работает. Установка пакетов системы после pip? Лишние слои. Claude 4.5 здесь выигрывает, потому что чаще делает это правильно.

Для глубокого разбора ошибок рекомендую нашу статью «Почему ломаются AI-агенты в продакшене», где мы разбираем похожие кейсы на другом бенчмарке.

Вопросы, которые вы хотели задать

ABC-Bench честный? Не заточен ли под Claude?

Нет. Задачи формулируются нейтрально. Критерии успеха чисто технические: контейнер собрался, сервисы поднялись, health-эндпоинт ответил. Авторы бенчмарка открыто выложили все задачи и код валидации. Claude 4.5 лучше просто потому, что лучше понимает контекст и меньше допускает детских ошибок.

Можно ли использовать ABC-Bench для тестирования локальных моделей?

Да, но готовьтесь к боли. Вам нужно написать агента, который будет работать с API вашей локальной модели (например, через Ollama). Проблема в том, что большинство локальных моделей на март 2026 (Qwen3.5, Llama 3.3, DeepSeek Coder) имеют контекст 4K-32K токенов, а задачи ABC-Bench с логами могут его превышать. Агент будет терять часть инструкций и гарантированно провалится. Подробнее о сравнении локальных и облачных моделей — в нашем расследовании.

Что дальше? Будет ли ABC-Bench 2.0?

По слухам, команда работает над задачами с Kubernetes (написание Helm-чартов, настройка ingress, HPA). Это следующий уровень адской боли для ИИ-агентов. Если сегодня они падают на docker-compose, то что будет с k8s manifests? Ждём к концу 2026 года.

А пока совет простой: если ваш ИИ-агент генерирует Docker-конфигурацию, не запускайте её сразу в продакшен. Прогоните через ABC-Bench или хотя бы через ручную проверку по чек-листу. Сэкономите часы на дебаге и гигабайты на диске от раздутых образов.

И да, закладывайте на деплой с участием ИИ в два раза больше времени. Пока что.

Подписаться на канал