Atos обучила 400 инженеров агентному AI через игру с ловушками

Atos и AWS провели трёхдневную AI League для 400 инженеров, чтобы заменить пассивное знакомство с agentic AI практикой под ограничениями. Участники создавали автономную систему, которая должна пройти подземелье, решать задания на клетках, избегать ловушек, собирать монеты и добраться до сокровища за ограниченное время и число жизней. Live leaderboard оценивал не только результат, но и эффективность.

Аудитория была неоднородной: 5% зарегистрированных не знали тему, 25% имели базовое представление, 50% понимали концепцию без практического опыта и лишь 20% уже работали с агентными сервисами. Среди участников были разработчики, product owners и project managers, в том числе люди, впервые использовавшие AWS.

Игровые правила имитировали инженерные компромиссы

Правильный ответ приносил очки, неправильный отнимал жизнь. За достижение финиша начислялся бонус, сохранённые жизни и монеты повышали счёт, а краткие ответы обходили многословные. Дополнительные баллы давали за создание специализированных small language models. Поэтому работающий prompt был только началом: участникам приходилось сокращать tool calls, задержку и расход токенов.

Задания проверяли разные компоненты. Violent Violet требовал настроить content filtering через Amazon Bedrock Guardrails. Memento и Keys & Doors проверяли сохранение контекста через AgentCore memory. Blue Brain и Dark Prophet задействовали Lambda и AgentCore Code Interpreter для исполнения кода и получения данных. Отдельные клетки требовали pathfinding, извлечения структурированных данных и экономного ответа на общий вопрос.

Агент не обязан решать алгоритм языковой моделью

Amazon Bedrock предоставлял модели для reasoning, а AgentCore Runtime размещал контейнеры участников. Через AgentCore Gateway система направляла MCP-вызовы в Lambda-функции для поиска пути, web scraping и вычислений. AgentCore Code Interpreter исполнял код в изолированной среде, а memory хранила сведения о найденных ключах и пройденных испытаниях между взаимодействиями.

Один из полезных уроков — передавать детерминированную задачу детерминированному инструменту. Для маршрута участники реализовывали, например, Breadth-First Search, вместо того чтобы просить LLM угадывать путь. При этом стратегия оставалась агентной: решить, собирать ли все монеты, идти ли к сложному испытанию и стоит ли рисковать жизнью ради высокого счёта.

Guardrails, fine-tuning и наблюдаемость

Guardrails нужно было настроить достаточно строго для блокировки нежелательного контента, но без ложной блокировки легитимных запросов. Избыточный фильтр проваливал соседние задания, слишком мягкий — safety-проверку. В SageMaker Studio участники готовили датасеты и использовали Reinforcement Learning from Verifiable Rewards; serverless fine-tuning обучал модели, которые затем разворачивались на inference endpoints.

Не менее практичным оказался CloudWatch. По наблюдению организаторов, инженеры, изучавшие логи между попытками, улучшали решения быстрее тех, кто менял систему наугад. Это не количественный эксперимент, но вывод совпадает с устройством production-агентов: без трассировки prompt, выбранного инструмента, задержки, стоимости и результата невозможно понять, где именно сломалась цепочка.

Что получилось — и чего кейс не доказывает

По регистрационным данным 400 инженеров получили hands-on опыт с Bedrock, AgentCore, Lambda, Guardrails, Kiro и SageMaker. Лучшие решения сочетали собственные алгоритмы поиска пути, memory-aware агентов, тонкую настройку фильтров и модели, оптимизированные по токенам. Организаторы также отмечают появление внутренних специалистов, готовых применять шаблоны в клиентских проектах.

Однако leaderboard измерял успех в специально созданной игре, а не качество реального enterprise-внедрения. Публикация не приводит pre/post тестов знаний, долю участников, завершивших все задания, или данные о проектах, запущенных после мероприятия. Поэтому корректный вывод ограничен: формат дал массовую практику и показал инженерные trade-offs, но не доказал долгосрочный рост производительности команды.

Почему это важно

Классическое обучение агентам часто заканчивается демонстрацией, где LLM вызывает один инструмент. AI League помещает те же компоненты в среду с ценой ошибки: memory может хранить неверное состояние, лишний вызов ухудшает счёт, guardrail блокирует полезный запрос, а плохой алгоритм тратит время. Благодаря этому абстрактные понятия становятся наблюдаемыми последствиями архитектурного решения.

Практический вывод для компаний — копировать не тему подземелья, а систему измерения. Учебный стенд должен оценивать завершённость задачи, стоимость, latency, устойчивость к ошибкам, качество журналирования и безопасность. Полезно заранее зафиксировать baseline для одинаковой задачи без агента и затем сравнить не только лучший результат, но и распределение показателей всей группы. После игры нужен второй этап на обезличенном рабочем сценарии и повторная оценка через несколько недель. Только тогда соревнование превращается из яркого события в проверяемую инженерную компетенцию.