xonika92 часа назад
AI Engineer World's Fair 2026: разбор докладов и куда движется инженерия в сфере ИИ
Уровень сложности: простой.
Время на прочтение: 8 мин.
Охват и читатели: 2,4K.
Искусственный интеллект. Машинное обучение. Программирование. Open source. Управление разработкой. Обзор.
TL;DR: AI Engineer World’s Fair — ежегодная конференция инженеров, которые создают продукты на основе моделей, а не обучают их. В расписании 2026 года было 560 сессий, и почти все сводились к одной мысли: узкое место переместилось с самой модели на окружающую её инфраструктуру — то есть на трейсы, песочницы, эвалы, границы и UI. Ниже — разбор по доступным записям: какие паттерны повторялись из доклада в доклад, как теперь исправляют ошибки агентов после провала и что посмотреть, если время есть только на пять роликов.
AI Engineer World’s Fair 2026 уже прошла, а у меня осталось стойкое ощущение, что я пропустил что‑то важное. Годовой срез прикладной AI‑инженерии в одном месте. В официальном расписании — 560 сессий: пять сотен докладов, воркшопов и кейноутов за несколько дней. Посмотреть всё невозможно, и я решил собрать русскоязычный навигатор, чтобы понять, что там происходило.
Ещё пару лет назад главный вопрос звучал так: «Когда модель станет умнее?» — и от ответа зависело всё. Сейчас модели стали достаточно хороши, чтобы доверить им почти всё, и внезапно оказалось, что ломается уже не интеллект, а среда вокруг него: как дать агенту инструменты, где поставить границы, как записать каждый шаг, как повторить сбой и как понять, что он стал лучше. Про это и была вся конференция — не про модель, а про её инфраструктуру.
Как я это разбирал (и почему это уже часть вывода)
Смотреть 560 сессий подряд бессмысленно, поэтому я собрал агентный пайплайн. Он тянет официальное расписание, метаданные YouTube, субтитры к доступным записям и прогоняет каждую через саммаризацию, складывая всё в один реестр с темами, ссылками и таймкодами.
Из 560 сессий расписания публично на YouTube к моменту сбора нашлось 82 уникальных видео. Ещё три многочасовые трансляции главной сцены я разобрал на 55 тематических сегментов. А более пятисот сессий я вообще не смог получить как отдельные записи — их пока просто нет в открытом доступе. Так что это не полный архив конференции, а навигатор по доступной части.
Возникали сложности. Один доклад про RL‑агента для ETL‑пайплайнов выдавал ошибку HTTP 429 на субтитрах, так что пришлось скачать аудио и обработать его через локальный whisper.cpp, пометив качество расшифровки как запасный вариант. Мелочь, но показательная: даже чтобы просто изучить конференцию про агентов, мне понадобилась своя небольшая инфраструктура с обработкой ошибок и запасными путями.
Всё, что получилось, я выложил отдельно: русскоязычный навигатор в репозитории на GitHub и SPA поверх него на GitHub Pages. Там — русские саммари, тематическая карта, watchlist и ссылки на оригиналы. Это навигатор по доступным материалам, оригиналы он не заменяет. Дальше по тексту я буду ссылаться на конкретные доклады — их все можно открыть и проверить.
Агент — это система исполнения, а не «модель с инструментами»
Самый частый тезис конференции: агент — это не LLM, которой дали пару функций, а система исполнения. Модель предлагает следующий шаг, а платформа вокруг неё проверяет, применяет и записывает. У агента есть состояние, правила, журнал действий, ограничения, механизм восстановления после сбоя и тесты. Модель тут — один из многих компонентов, пусть и центральный.
Инфраструктура вышла на первый план не вместо прогресса моделей, а благодаря ему. Пока модель ошибалась на каждом втором шаге, спорить про журналы и границы было рано. Как только она стала достаточно надёжной, чтобы ей доверили реальные действия, акцент сместился: теперь важно не то, станет ли она ещё умнее, а то, можно ли объяснить, повторить и ограничить то, что она уже делает.
Лучше всего это сформулировано в докладе с говорящим названием What if the harness mattered more than the model?: рычаг качества всё чаще находится не в весах модели, а в инфраструктуре вокруг неё. В том же направлении идёт разговор про детерминированную инфраструктуру для агентов. А на главной сцене отдельным блоком разбирали идею разделения задачи и модели: задачу описывает и контролирует платформа, модель лишь исполняет свою часть. Это был сегмент внутри длинной трансляции, без отдельных глав на YouTube, так чт
Я даю ссылку на таймкод в потоке, а не на точную цитату. Если держать в голове только одну мысль с конференции, то вот эту. Всё остальное — её частные случаи.
Упал в проде? Покажи чек.
Первый частный случай неприятный. Агент что‑то сделал в продакшене, всё сломалось, и вы стоите перед логами, пытаясь понять, что произошло. Сказать «модель сгаллюцинировала» мало. Нужно знать, что агент видел, какие инструменты вызвал, почему выбрал именно это действие и как теперь повторить сбой.
Разработчики выкатывают простую метафору: агенту нужны чеки — как квитанция из магазина, только на каждое действие. Что вызвал, с какими входами, что подтвердилось. В докладе Agents Need Receipts речь идёт как раз о проверяемом следе вместо «я вроде дёрнул нужный инструмент».
Отдельно бьёт по популярному заблуждению доклад Your Agent Failed in Prod. Good Luck Reproducing It. Многие верят, что достаточно выставить temperature=0 — и агент станет воспроизводимым. Не станет. Воспроизводимость даёт не нулевая температура, а record/replay: вы записываете весь прогон целиком, потом стабите узлы с LLM и заново прогоняете инструменты. Инцидент из прода превращается в тест, который защитит вас от такого же падения в будущем.
А доклад The Log Is The Agent договаривает мысль до конца: журнал событий — это не побочный продукт работы агента, а его основа. Архитектура начинается с того, что и как вы записываете, а промпт уже вторичен.
Сто инструментов в промпте — это не суперсила. Есть соблазн думать, что чем больше инструментов у агента, тем он мощнее. Засунул сотню функций в промпт — и пусть выбирает. На практике так вы получаете агента, который путается в собственном арсенале и всё чаще ошибается с выбором.
Доклад с прямым названием The 100-Tool Agent Is a Trap показывает, почему толстый агент проваливается и что делать вместо этого. Рецепт похож на обычный поиск: инструменты складывают в индекс, ищут релевантные под конкретный запрос и подгружают только их. Не весь тулбокс в каждом обращении, а semantic routing и подгрузка по необходимости.
Рядом стоит доклад Skills are the New SDKs, и он мне особенно близок. Навыки становятся тем, чем раньше были SDK: их надо индексировать, версионировать, тестировать и исполнять в контролируемой среде. То есть с навыками агента поступают как с нормальным программным активом, а не как со списком заклинаний в системном промпте.
Оценка живёт в проде, а не на слайде. Дальше конференция бьёт по бенчмаркам — любимой болячке индустрии. Одна красивая цифра в лидерборде давно ничего не гарантирует.
В докладе Production Evals For Agentic AI Systems оценку разбирают как продакшен‑контур. Мерить надо исходы сценариев: дошёл ли агент до цели, насколько удачно вызывал инструменты, как часто эскалировал, где нарушал безопасность, сколько стоил и как восстанавливался после сбоя. Это уже не «76 % на бенчмарке», а набор сигналов, по которым видно, живой продукт или нет.
Обратную сторону той же проблемы показывает доклад с грустным названием User Signal Dies at the Retrieval Boundary. Сигнал качества умирает на границе поиска: пользователь отметил, что ответ был бесполезен, это осело в трейсе, но retrieval на следующем запросе снова достаёт ровно тот же нерелевантный документ, потому что оценка до него не дошла. Если трейсы и оценки остаются красивым дашбордом, из которого поиск ничего не извлекает, одна и та же ошибка повторяется на каждом запуске.
Ответ модели — это ещё не интерфейс. Многие агентные продукты спотыкаются об одно и то же: о прокладку между монитором и креслом.
Доклад Agent Output Is Not UX прямым текстом говорит: сырой вывод модели — это ещё не интерфейс. Пользователю нужен слой поверх: состояние, отмена, понятное отображение того, что агент сделал, и контроль над его действиями. В The UX of AI это разворачивают в конкретику для продуктов с документами и файлами: guided workflows, источники, боковые панели, undo/redo.
Отдельно стоит мой любимый заголовок всей конференции — Browser Agents Don’t Need Better Models. They Need Better Eyes. Браузерным агентам не нужна модель побо
Им нужно нормальное зрение: компактное структурное представление страницы вместо простыни скриншотов, различия между состояниями и обратная связь о том, что действие не удалось. И совсем приземлённый, но важный доклад «Your Agents Need a Save Button»: кнопка сохранения для агента — это не мелочь UI, а контроль над состоянием долгой работы. Ни один из этих докладов не просит модель получше. Все просят харнесс получше. Скорость кода — это ещё и долг. Сильнее всего меня зацепила именно скорость генерации.
Потому что она бьёт по главному хайпу года. История продаётся так: coding‑агенты пишут код быстрее — значит, команда работает быстрее, значит, прогресс. Доклад Your Coding Agent Is Creating Review Debt аккуратно вскрывает подмену. Код действительно генерируется быстрее. Вот только понимать его, ревьюить и сопровождать всё равно приходится людям, и их пропускная способность не выросла. Разница уходит в долг. Не технический долг в старом смысле, а review debt: очередь изменений, которые никто толком не понял, но которые уже в системе.
Мысль звучит скучно, а последствия — нет. Если код пишется быстрее, чем команда успевает его осмысливать и проверять, вы не ускорили разработку, а переложили нагрузку с написания на ревью и сопровождение и сделали вид, что стало лучше.
Что оценка таких агентов сама по себе — непростая задача, показывает SWE‑Marathon: Evaluating Coding Agents at Billion‑Token Scale: гонять coding‑агентов приходится на огромных масштабах, миллиардами токенов, чтобы вообще увидеть, где они ломаются. А на главной сцене отдельно разбирали урок с анализа миллиона AI‑сгенерированных PR. Это тоже был сегмент длинной трансляции без отдельной главы, ссылку даю на таймкод. Сам масштаб в миллион пул‑реквестов уже говорит, что тема из разряда «померещилось» перешла в разряд измеримого.
Куда это всё сходится? Если собрать выводы вместе, вырисовывается один сдвиг. Индустрия движется не к тому, что «агенты сделают всё сами», а к появлению отдельного слоя инфраструктуры, на котором агенты работают безопасно и повторяемо. Харнесс, трейсы, песочницы, разрешения, наблюдаемость, эвалы, UI и понятная эскалация к человеку. Агентные продукты потихоньку начинают проектировать как распределённые системы, а не как чат с приделанными функциями.
Те же повторяющиеся паттерны, если собрать их в табличку:
Паттерн В чём суть Ключевой доклад Агент как система исполнения Модель предлагает шаг, платформа проверяет, применяет и записывает What if the harness mattered more than the model? Receipts и replay Чек на каждое действие; инцидент из прода превращается в тест Your Agent Failed in Prod; Agents Need Receipts Semantic routing Не сто инструментов в промпте, а индекс и подгрузка нужных The 100‑Tool Agent Is a Trap Production evals Мерить исходы сценариев, а не одну цифру бенчмарка Production Evals For Agentic AI Systems Agent UX Слой поверх вывода: состояние, отмена, «зрение» для браузера Agent Output Is Not UX; Browser Agents Don’t Need Better Models Review debt Код генерируется быстрее, чем команда успевает его ревьюить Your Coding Agent Is Creating Review DebtПосле разбора конференции список докладов у меня превратился в список требований к своему проекту: trace/replay по умолчанию, а не когда‑нибудь потом; semantic routing вместо полного тулбокса в каждом запросе; лимиты, сохранение состояния, разрешения и наблюдаемость на каждом шаге; отдельный слой зрения для браузерных и офисных агентов; и подсчёт стоимости и риска по каждому действию, а не только по финальному результату. Ничего магического. Скучная инженерия, которая и отличает работающий продукт от красивого демо.
С чего начать, если времени в обрез? Главную мысль повторю ещё раз, потому что она стоит того. Я строил агентный пайплайн, чтобы разобрать конференцию, которая сама оказалась про harness. В этом весь 2026 год для AI engineering: побеждает не тот, у кого модель заработала больше попугаев, а тот, кто может объяснить, повторить, ограничить и проверить то, что его агент делает.
Я разобрал 82 публично доступные записи из 560 сессий расписания. Больше пятисот сессий в этот разбор не попали просто потому, что их пока нет в открытом доступе. Так что это взгляд по доступной части, а не приговор всей конференции.
Если же смотреть прямо сейчас и только пять роликов, я бы начал с этих: Browser Agents Don’t Need Better Models, Your Agent Failed in Prod, The 100‑Tool Agent Is a Trap, What if the harness mattered more than the model? и Skills are the New SDKs. Остальное, с саммари и таймкодами, лежит в навигаторе.
Пишу об искусственном интеллекте, языковых моделях и инструментах для разработчиков. Тестирую модели и сервисы на реальных задачах, а выводами делюсь в телеграм‑канале.
Ссылки:
Репозиторий на GitHub
Навигатор на GitHub Pages
Теги:
AI Engineer Worlds Fair
AI‑инженерия
агенты
LLM
harness
review
debt
evals
agent UX
AI engineering
Хабы:
Искусственный интеллект
Машинное обучение
Программирование
Open source
Управление разработкой
Нравится +2
Не нравится
Добавить в закладки
4
Поделиться
Комментарии 0
16K+
Охват за 30 дней
40
Карма
Алексей@xonika9
Инди‑хакер
Подписаться
Отправить сообщение
Сайт
Telegram
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Перейти
Перейти в поток AI и ML
Комментарии
Комментировать
Лучшие за сутки
Похожие
Показать лучшие за всё время
Подписаться в Макс
