Зачем агенту обвязка — конспект доклада Jediah Katz

01 / Главное

Часть обвязки можно удалить. Остальная становится важнее.

Модель усваивает приёмы

По тезису Каца, сильные модели уже сами исследуют кодовую базу, вносят правки, проверяют результат и продолжают длинную задачу. Специальные инструкции для этих навыков постепенно теряют ценность.

Обвязка расширяет круг задач

Она помогает агентам освоить новые рабочие сценарии и обеспечивает то, что нельзя перенести в веса модели: устойчивое исполнение, ограничение полномочий и экономное использование ресурсов.

02 / Устройство · 02:02 ↗

Два слоя с разными обязанностями

Agent harness, или агентная обвязка, связывает модель с приложениями пользователя, компьютерами и внешними сервисами. Кац называет её «глазами и руками» модели.

Runtime определяет, где исполняется цикл агента и как хранится состояние, чтобы работу можно было возобновить. Это привычные задачи разработки надёжных систем.

Слой контекста и оркестрации выбирает модель, момент вызова и входные данные. Здесь находятся промпты, инструменты, память, сжатие контекста и правила, корректирующие поведение агента.

Именно второй слой часто имеют в виду в спорах о «смерти обвязки». Выводы о нём нельзя автоматически переносить на всю систему.

03 / Обучение · 05:00 ↗

Обвязка создаёт данные для своего упрощения

Сначала инженеры компенсируют слабости модели. В Cursor, по рассказу Каца, для применения правок использовали отдельную небольшую модель, а для исследования репозитория и проверки работы добавляли инструкции. С улучшением моделей эти механизмы начали удалять.

Кац приводит два исследования: сравнение семи моделей в разных обвязках на SWE-Bench-Lite и работу Apple и EPFL об MLE-Bench. В его пересказе сложная обвязка не дала существенного выигрыша в доле решённых задач, особенно для более сильных моделей. Позже он уточняет: стоимость выполнения при этом различалась.

Слева — сравнение результатов моделей в Pi, Codex и Claude Code; справа — работа Apple и EPFL об обвязках для ML-задач. 05:02 ↗

Цикл данных, или data flywheel

Обвязка делает трудную задачу выполнимой. Больше пользователей пробуют её решать, лаборатории получают больше данных, а модели учатся выполнять такую работу самостоятельно. После этого часть вспомогательной логики становится ненужной.

Дальше инженеры открывают следующий класс задач. Там снова нужны инструменты и правила, пока модель не освоит и эти навыки.

Здесь передан аргумент докладчика и содержание его слайда; это не независимая проверка упомянутых исследований.

06:16 · объяснение цикла ↗

04 / Новые задачи · 07:34 ↗

От разового чата к постоянному координатору

В описании Каца GrokBot строится вокруг долгоживущих ботов-координаторов. Они общаются с пользователем, ведут работу и распределяют задания между рабочими агентами.

Для такой системы команда снова добавляет инструкции и ограничения. Агенту нужно создавать презентации, бронировать поездки, сообщать о ходе работы без лишних уведомлений, выбирать между действием и уточняющим вопросом, а также запоминать предпочтения пользователя.

Похожее расширение происходит внутри разработки: написание кода становится частью более длинного процесса. Кац описывает внутренний сценарий, где сообщение об ошибке запускает её разбор, облачный агент готовит исправление и видео «до/после», а после слияния и начала развёртывания другой агент следит за проблемами в production.

Координация полного цикла

Такую систему он называет «фабрикой ПО» и подчёркивает, что эта идея ещё не решена полностью. Её обвязка координирует уже целых агентов, а не только отдельные вызовы языковой модели.

10:52 · фабрика ПО ↗

05 / Постоянные обязанности · 12:07 ↗

Надёжность, полномочия и стоимость

Непрерывное исполнение

Задачи растягиваются с минут до часов и дней. Кац считает облачную среду необходимой для автономного коллеги: ноутбук пользователя может уснуть и прервать работу.

12:16 ↗

Доверие и безопасность

Умение решить задачу не определяет допустимые действия. Обвязка ограничивает доступ конкретного агента и пользователя, защищает от опасных операций и непредвиденных расходов.

12:43 ↗

Цена и скорость

Команда GrokBot оптимизировала попадания в кэш, расход токенов и сочетание моделей. По словам Каца, это снизило стоимость и ускорило работу без потери качества; численных результатов он не приводит.

13:21 ↗

Прогноз докладчика

90 %

агентной работы, по прогнозу Каца, через шесть месяцев будет выполняться вне ноутбука. Это прогноз из доклада, а не измеренная доля.

17:15 ↗

06 / Проектирование · 14:21 ↗

Закладывайте возможность удалить функцию

Кац ожидает, что продуктовые сценарии некоторое время будут развиваться быстрее моделей. Обвязка станет сложнее, прежде чем её удастся упростить. Поэтому новые механизмы должно быть легко добавлять и убирать.

Команда меньше раскрывает внутреннее устройство пользователю: по закону Хайрама на любое доступное поведение кто-нибудь начнёт полагаться. Это ускоряет изменения, но уменьшает прозрачность; докладчик признаёт этот компромисс.

Единый механизм подписок

Сообщение в Slack, падение CI у нужного pull request и наступление заданного времени могут разбудить агента через один инструмент подписки на события. Такой базовый интерфейс позволяет добавлять сценарии без отдельных механизмов для каждого из них.

15:45 · подписки ↗

Временные исправления с учётом срабатываний

Shim в докладе означает временное правило, которое исправляет нежелательное поведение модели. Например, агенту напоминают ответить, если пользователь слишком долго ждёт. Команда хранит такие правила централизованно и журналирует каждое срабатывание.

Дашборд Firings by shim: составные столбцы показывают срабатывания разных временных правил во времени. 16:12 ↗

Бот наблюдает за дашбордом. Когда правило перестаёт срабатывать, он предлагает pull request на его удаление. Сам график на слайде показывает систему наблюдения, а не доказательство, что все правила уже стали ненужными.

Что перенести в свою работу

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

Практические выводы из подходов, описанных в докладе.

07 / Навигация по видео