Speaker A
Миллион строк кода, полсотни пулл-реквестов и ноль строк, которые написал человек. Это не фантазия, это внутренний продукт OpenAI. Его выпустили за 5 месяцев. И ключевое слово во всей этой истории не модель. Ключевое слово — это harness.
Видео раскрывает концепцию harness engineering для улучшения работы агентов OpenAI через кодовую обвязку, а не только модели.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- Качество работы агента определяется не моделью, а кодовой обвязкой — harness.
- Harness engineering предотвращает ошибки агента структурно, через код, а не через промты.
- Четыре ключевые функции harness: constrain, inform, verify, correct.
- Автоматизация обратной связи и ограничений критична для стабильной работы агентов в продакшене.
- Развитие harness важнее, чем просто улучшение моделей, для создания надежных AI-систем.
What the video covers
- Видео рассказывает о внутреннем продукте OpenAI, созданном за 5 месяцев, где ключевым элементом является harness, а не модель.
- Harness — это инженерная обвязка вокруг модели, которая превращает её мощность в полезное действие, обеспечивая надежность и качество.
- Принцип harness engineering формулируется как предотвращение ошибок агента через код, а не промты или инструкции.
- OpenAI выделяет четыре функции harness: ограничение (constrain), информирование (inform), проверка (verify) и исправление (correct).
- На примере агента для когортного анализа показаны реальные проблемы и решения, связанные с зацикливанием и расходом ресурсов.
- Промты рассматриваются как должностные инструкции, которые версионируются и тестируются для повышения эффективности агента.
- Видео подчеркивает важность автоматической обратной связи для агента через линтеры, тесты и пайплайны, а не ручной контроль.
- Рассматриваются дополнительные слои harness и их роль в обеспечении стабильности и качества работы агентов в продакшене.
- Обсуждается, что качество агента определяется не только моделью, но и комплексной инженерной обвязкой вокруг неё.
- Видео призывает к смещению ценности разработчиков в сторону развития инженерии harness для создания надежных и эффективных агентов.
Chapters
- 00:00Введение и концепция harness
- 02:16Принцип harness engineering и его история
- 04:50Проблемы зацикливания агента и решения constrain
- 07:18Роль промтов как должностных инструкций (inform)
- 09:49Проверка и исправление ошибок агента (verify и correct)
- 12:21Слои harness и их значение для продакшена
- 22:43Значение автоматизации и наблюдаемости
- 35:08Заключение: развитие harness важнее моделей
Full Transcript — Download SRT & Markdown
Speaker A
Общепринятый взгляд такой: чтобы агент работал лучше, нужна модель помощнее, контекст побольше, желательно миллионы параметров, чтобы туда влезло всё, что у нас есть. И, конечно, провайдер за это получит как можно больше денег. Я вижу по-другому. Качество агента определяет не модель, а код вокруг неё. Почему же
Speaker A
мне верить? У меня агенты крутятся в продакшене и причём довольно-таки давно. Это и когортный анализ для программы лояльности, и я ментор для обучения, и C-система, [музыка], где агенты ревьювают код за людей, и агент для помощи и сырье
Speaker A
команде и ещё многие другие, их не один десяток. Так что это не один агент и не один [музыка] проект. И каждый слой обвязки вокруг этих агентов появился из экспериментов и наблюдений, а иногда из инцидентов. Сегодня покажу эти свои
Speaker A
только как каждому пришли. Заодно станет понятно, почему у одних получается миллион строк, а у других миллион долларов пеп. Разберём, что такое harness, пройдём все его функции и на живом агенте поймём, почему ваш эксепириенс — это главное оружие в этой игре.
Speaker A
Кто смотрел серию про систем дизайн для агентов, которая у нас была на канале не так давно, слово harness уже там слышал.
Speaker A
В третьей части мы там разбирали продакшн, и оно там мелькнуло одним небольшим блоком. Сегодня же полный разбор. А кто не смотрел, ничего страшного, можете посмотреть потом.
Speaker A
Ссылка будет в описании. Ну что, поехали. Harness дословно — это упряжь, но мне ближе другая картинка. LM — это двигатель от машины. Есть мощнее, есть слабее, но двигатель сам по себе, он без колёс, без трансмиссии, без руля и без прочего. И
Speaker A
он не очень пригоден для использования. Вы не поедете до двигателя на работу. Harness — это всё остальное от машины.
Speaker A
То есть всё, что превращает мощность в движение туда, куда вам надо. Слово, кстати, не новое. Harness тестирование — это обвязка вокруг тестируемой фичи. И этому термину уже не один десяток лет.
Speaker A
Практику применяли и раньше. Антропик писал про обвязку длинных агентов ещё осенью двадцать пятого, но ими дал Митчел Хашимота, основатель HashiCorp, он же создатель Terraform. В феврале двадцать шестого он опубликовал пост про свой путь работы с агентом и стал называть
Speaker A
это harness engineering. И это сформулировало принцип. Каждый раз, когда ты видишь, что агент ошибается, ты инженеришь решение так, чтобы эта ошибка стала структурно невозможной. Не промтом и не инструкцией, а кодом. И это логично, потому что агенты намного эффективнее, когда выдают правильный
Speaker A
результат с первого раза. И самый надёжный способ этого добиться — это дать агенту [музыка] быстрые и качественные инструменты, которые автоматически говорят ему, где он ошибся. Обратите внимание на слово автоматически. Не вы руками смотрите, не вы пишите комментарии в чат своему
Speaker A
агенту, а система сама даёт ему обратную связь. И это может быть линтер, тест, лисяй пайплайн. И инженеры-разработчики делают это уже десятилетиями. Так что, если вы посмотрели твит Роберта Мартина о том, как он работает с агентами и какая у него обвязка вокруг, то не надо
Speaker A
говорить, что это просто Роберт Мартин стал у нас вайп-кодером, потому что его обвязка вокруг моделей невероятно сложная, и она как раз-таки сделана для того, чтобы говорить агенту, что он сделал плохо. OpenAI пошли дальше и дали формальное определение. Райан Лапо
Speaker A
описал harness как систему из четырёх функций: constrain, то есть ограничить, что агент может делать,
Speaker A
сказать ему, что он должен делать, verify — проверить, что он сделал это правильно, и correct — поправить, когда пошло что-то не так. Это определение, ой, оно рабочее, но не единственное. Уже есть академические обзоры, которые раскладывают harness на семь слоёв. И их
Speaker A
мы тоже с вами рассмотрим, но ближе к концу. Также посмотрим, чего четвёрки от OpenAI не хватает. Но проще всего как раз-таки начать с этих четырёх принципов, которые обозначил OpenAI.
Speaker A
Дальше пройдём по всем четырём на наших агентах. И за каждым словом стоит конкретный инженерный слой и конкретная цена за его отсутствие.
Speaker A
В самом начале я упоминал про агента для когортного анализа. Это у нас работает в продакшене. Здесь у нас программа лояльности, и там у нас огромное количество событий. Маркетолог пишет человеческим языком: "Покажи тех, кто 3 месяца ходил в магазин и раз в неделю
Speaker A
покупал чипсы", и после этого получает когорту без SQL, без тикета в датакоманду. У него сразу же всё получается готово. Звучит это как счастье. А теперь про этого агента. Он дошёл до продакшена ещё до того, как термин harness появился. Ну и давайте на
Speaker A
нём попробуем что-нибудь поразбирать. И начнём с фазы constrain. Когда мы строили когорты на модели GPT-4O. Вы скажете, что это за устаревшая модель? Но это было так давно, и тогда это была практически топовая модель. И в какой-то момент у
Speaker A
нас агент зацикливается. Он дёргает один и тот же тул с теми же аргументами, получает тот же ответ, не понимает, что уже был здесь, и дёргает снова. И этот цикл повторялся 100 раз подряд. То есть он дёргал его одно и то же, одно и то же
Speaker A
и не понимал, что что-то идёт не так. Счёт за эту его уверенность в том, что ему надо дёрнуть этот тул 100 раз, конечно, пришёл к нам. И OpenAI нам ничего не сказал. Извините, пацаны, что ваша наша модель тут дёргает тулы по 100
Speaker A
раз. Ну, так вышло. Как раз-таки после этого у нас появился жёсткий лимит итераций на цикл. Появился детектор повторяющихся вызовов. То есть агент дважды вызвал один и тот же тул с теми же аргументами, и это у нас был флаг. Плюс к этому мы добавили бюджеты, и если он
Speaker A
их превышал, то есть потратил какие-то лимиты, то всё, он останавливался и звал человека. Говорит: "Слушай, я что-то сделал, не знаю, что тут дальше делать. У меня кончились мои лимиты".
Speaker A
Также туда добавили серию с бэкапами, circuit breaker на внешний API, graceful degradation и всё, что вы ставите на обычный сервис, чтобы он не умер от одного тайм-аута. Только здесь он защищает нас не от падения, а от бесконечной уверенной активности.
Speaker A
Constrain. Отдельная история — этот доступ мы дали команде этого агента с широкими правами. И, конечно, все пошли тестировать, писать запросы, искать интересные когорты и сочетания. И при этом один из пользователей за 3 часа накрутил 28 долларов. Просто потому, что
Speaker A
токен-бюджеты не были настроены. И каждый следующий вопрос тянул в контекст всю историю, и ограничение "не гоняй лишние токены в промте", если бы мы его туда добавили, оно бы, конечно, тут тоже абсолютно никак не помогло с этой замечательной моделью. И после этого у
Speaker A
нас появился у каждого сабагента минимальный промт, минимальный набор тулов и жёсткий токен-баджет один.
Speaker A
Помните кейс Pocket OS из третьей части? [музыка] Агент с рутовым токеном снёс продакшн-базу, а ограничения из промта процитировал уже после своей замечательной исповеди. Constrain — это когда физически нельзя, а не код строго запрещён. Итак, следующий слой — это
Speaker A
inform. Наш промт для когортного агента прожил 57 версий до того, как он стал эффективно работать в продакшене. И это не потому, что мы горфоманы перечитывали его и что-то исправляли. Это потому, что промт — это должностная инструкция.
Speaker A
Приходишь на работу, получаешь инструкцию, работаешь не по ней. Всё, до свидания. Почему ты нарушил свои должностные инструкции с промтами? Ровно то же самое. И каждая новая версия — это какой-то зафиксированный инсайт в процессе тестирования или использования.
Speaker A
Агент понял задачу не так. Мы уточняли формулировку, замеряли, стало ли лучше, и после этого обновляли версию. Промт лежит в репозитории, версионируется, и каждой версии есть измерение. И это уже не выглядит как когда вы пишите в чат: "Ну там сделай, пожалуйста, мой промт
Speaker A
ещё покрасивее, прочитай". Я тут увидел замечательный ролик, как надо оформлять промты. Нет, это инженерный артефакт, который измеряли, тестировали и обновляли. Но не думайте, не каждая версия делала лучше. В одном из наших агентов было оче...
Speaker A
их помещать в контекстное окно получилось не очень эффективно. Мы решили, что надо разделять и давать ему определённый набор тулов для того, чтобы максимально эффективно вызывать тот тул, который нужен для конкретного запроса.
Speaker A
Поэтому основная цель была от модели - это выбрать правильный тул на запросе. И для того, чтобы подобрать то, сколько тулов, как они должны выглядеть, что сделать для того, чтобы мы эффективно решили задачу. Мы подошли довольно-таки системно. Мы меняли модели, количество
Speaker A
тулов, описания и замеряли всё это после каждого прогона. Количество [музыка] тестов там было невероятно большое. И мы выяснили, что больше инструкций не значит лучший результат, потому что новые правила могут конфликтовать со старыми. И модель вам, конечно, не объяснит, какое она выбрала и почему.
Speaker A
Поэтому относиться надо к промту не как документу, который мы что-то добавляем, он у нас растёт. Нет, это система уравнения, где каждое новое условие может сломать предыдущие. Verify, это прямо офигенный слой, потому что он может вам спасти не только деньги, но и
Speaker A
вашу репутацию. И здесь есть развилка, которой легко проскочить. Проверки бывают двух типов, и стоят они очень по-разному. И начнём с того типа, который появился у нас первым. В нескольких пайплайнов мы использовали модели OPUS. Обновили с одной версии на
Speaker A
более новую, модную, которую, как говорилось, всё работает отлично, как всегда, супер круто. Если бы мы это тестировали просто глазами, сделали бы несколько запросов, ну, вроде стало лучше или лучше, было бы тяжело понять.
Speaker A
Но у нас был автоматический замер качества на эталонных запросах, и этих запросов было очень много. И когда мы его проходили, выяснилось, что новая модель нам отдаёт иероглифы. Мы решили, что нас это не устраивает с точки зрения качества, и решили остаться на
Speaker A
предыдущей версии модели, [музыка] и она у нас не поехала в продакшн. Поэтому каждый раз, когда выходит свежая модель, будь то Kimi 3 или COД 5 или JLM новый, мы сразу прогоняем её на наших проектах.
Speaker A
Свои тесты, свои данные и свои метрики. И цифры говорят очень хорошо: подходит нам эта новая модель, улучшает она качество или нет. Потому что смотреть на публичные бенчмарки, ну да, вроде лучше.
Speaker A
Но на нашем конкретном домене вполне вероятно, что всё будет работать немножко по-другому. Так вот, verify - это когда у вас есть ответ на вопрос: агент стал лучше или хуже. И ответ не должен зависеть ни от чего: настроения или маркетинга нового провайдера. Ну да,
Speaker A
за такую проверку надо платить. И часто прогнать модель занимает несколько часов. Получить весь этот набор и понять, лучше, хуже, взвесить решение. И тогда будет понятно, почему мы приняли это решение, обновляем, не обновляем, перешли на более дорогую модель или
Speaker A
остались на более дешёвой. А есть ещё проверки другого типа. Они срабатывают мгновенно и абсолютно не могут ошибиться в том, что проверяют. Это инварианты, зашитые в наш код. Возьмём как пример нашего когортного агента и посмотрим, что верно про его ответ всегда, чтобы
Speaker A
там маркетолог не спросил. Когорта не может быть больше базы, дата не может выходить за период, который запросили.
Speaker A
идентификатор сегмента, либо есть в справочнике, либо ответ невалиден. [музыка] И таких инвариантов у нашего домина, у нашей модели всего довольно-таки много. И их можно проверять моментально. И они нам ничего не стоят, потому что они зашиты в наш код. Здесь уже неважно, какую мы
Speaker A
используем модель, потому что эти правила не будут меняться никогда. Так вот, проверять надо не только ответ, потому что модель формирует, что она формирует и запрос. И в этом случае получается, что гораздо важнее проверять аргументы вызова. Причём ещё до того,
Speaker A
как сам вызов ещё не случился. То есть мы ограничиваем агента от действий, которые он ещё не сделал. Так вот, плохой ответ вы просто выбросите, а вот удалённую базу уже не вернёте. Так вот, этот валидатор стоит перед тулом, а не
Speaker A
после него. А есть поломка, которую вообще не видно на конференции. И я инженер. Инженер из Open AI назвал это stateхо, то есть дыра в состоянии.
Speaker A
Пользователь попросил агента что-то запомнить. Агент ответил, что запомнил. Интерфейс без ошибок. И на следующем ходу агент этого факта не знает. То есть запрос у нас не прошёл, и мы никуда не сохранили эту запись. Чем же это хуже обычного краш? Когда мы просто с вами
Speaker A
крашимся, мы замечаем [музыка] эти ошибки. А вот такой тихий успех - это ложь, потому что на следующем ходу наша модель будет звучать очень уверенно, но эта уверенность будет поверх неполной или сломанной истории. Поэтому, если у нас с вами не просто какой-то чатагент,
Speaker A
а он у нас что-то делает, создаёт какие-то записи или какие-то действия, то, возможно, если агент ответил пользователю, то запись о действии или результаты этого действия должны у нас с вами где-то уже существовать. И в этом случае не может быть ответа без этой
Speaker A
записи. И здесь у нас с вами получается чистый инвариант. Замкнуто, без исключений. И это всё на уровне кода.
Speaker A
Звучит это всё классно. Здесь мы сделаем инвариант. Здесь у нас будет judge модель. Всё это будет между собой вариться, и мы получим идеальную систему. Но на самом деле есть очень сложный вопрос: а где же эта граница?
Speaker A
Что можно унести в наш детерминированный код, а что нельзя? Хочется перенести в код как можно больше, но надо разобраться, всё ли может удержать наш код или нет. Здесь хорошо бы сделать какие-то правила для того, чтобы определять, можно ли из этого что-то
Speaker A
сделать в НВриант в коде или нельзя. И тут можно задать несколько вопросов. Первый: замкнуто ли это на самом ответе?
Speaker A
Как пример, сумма возвратов не может быть больше суммы заказа. И вариантов тут других нет. Мы можем это, конечно, положить в код. А далее это когорта, который просил маркетолог. Здесь уже нельзя. Тут нужен смысл вопроса, а его в ответе у нас нет. Второй ответ
Speaker A
одинаковый сегодня и через год. Если ваша проверка сама зовёт модель, чтобы решить, то это не инвариант. Это ещё один слой, который сам работает на вероятность, а значит, и его самого надо проверять. Модель в роли судьи - это абсолютно нормальная практика, но при
Speaker A
этом в детерминированном слое её быть не должно. И третий, бывают ли исключения? Есть ли хоть один законный случай, когда можно нарушить? Значит, перед вами не инвариант. Это у нас будет ивристика. И в коде ей опять же не место. А если вы,
Speaker A
не дай бог, её положите в ваш Харнес, то он будет блокировать правильные ответы, и это будет хуже пропущенной ошибки.
Speaker A
Пропущенную вы хотя бы увидете и обсудите, а заблокированную никто не увидит. Что из этого складывается?
Speaker A
Проверка выстраивается в три уровня. [музыка] Внизу у нас инварианты в коде. Работают они мгновенно и надёжно, но ловят только то, что замкнуто на самом ответе. Это как инварианты в наших DDдишных подходах к нашим моделям, когда модель может сама проверить своё
Speaker A
состояние. Чуть выше - это замеры на эталонных запросах. Эти замеры, они сильно дороже. Они запускаются не постоянно по каким-то событиям, либо смена модели, либо мы хотим что-то проверить, потому что это довольно-таки дорого, но оно ловит у нас, если что-то, какие-то проблемы со
Speaker A
смыслом. И в код в это мы не можем записать такие проверки. Это как то, что я вам рассказывал про иероглифы после смены модели. Нвариантом такое поймать очень тяжело, потому что предсказать такой нвариант очень тяжело, что нам надо соблюдать, чтобы не попал иероглиф.
Speaker A
Кто же знал, что вообще такое правило надо куда-то добавлять? Так вот, что же у нас будет здесь на самом верху? Кто у нас будет проверять? То, что не смогли словить наши инварианты, то, что не смогли словить наши замеры, ну и,
Speaker A
конечно, то, что не уследило модель на уровень своих промтов. И это у нас будет с вами человек.
Speaker A
Соответственно, человек может разрулить всё остальное. Все те проблемы, которые у нас могут возникнуть, мы можем с вами решить на уровне человека. Есть правило, по которому эта конструкция у нас с вами живёт. Каждый инцидент, каждый инсайт - это попытка спустить проверку на уровень
Speaker A
ниже. Если человек увидел глазами, что что-то работает не так, мы можем добавить это в наши с [музыка] вами замеры. Если же замеры что-то ловят регулярно и выяснилось, что нарушение - это всегда ошибка и нету никаких исключений, значит, нам надо перенести
Speaker A
это уже на уровень инварианта в наш код. Помните формулировку хэшимота изначала? сделать ошибку структурно невозможной и понимать, как построить всю вот эту систему с замерами, инвариантами, с наблюдениями, это та работа, которую надо делать для того, чтобы наши с вами
Speaker A
агенты отвечали хорошо, правильно и были безопасны. Так вот, давайте ещё раз напомним список из этих четырёх слов, которые предложил Open AI.
Speaker A
И получается, что эти четыре слова - это как те шишки, которые были надбиты людьми, которые делают агентов, которые испытывают эту боль и добавляют слой, ещё один слой, ещё один слой для того, чтобы получить агентов, которые всё-таки делают то, что надо. И как мы помним, я
Speaker A
уже неоднократно упоминал про Гарнер, который предсказывает, что больше 40% агентских проектов будут закрыты к двадцать седьмому году из-за неконтролируемых расходов, непонятной бизнес-ценности и недостаточного контроля риска. То есть, смотря на эти четыре слова, мы можем понять, что у нас
Speaker A
с вами будут расходы без ценность у нас будет без verify, риски у нас будут без констraйн, а бизнес будет не очень хорошо описана на уровне информ. И это ровно те дыры, которые мы с вами только что обсуждали. Всё это стоит денег и
Speaker A
времени. Грубо говоря, харнес пропорционален цене ошибки, а не громкости хайпа. То есть, если вы собираете какой-то прототип за выходные для себя или какой-то внутренний инструмент на нескольких человек, то, наверное, вы можете сильно не соблюдать всё это и где-то сделать попущение.
Speaker A
Возможно, нам вам не нужен никакой Kill switch, follловер, эталонные замеры и тому подобное, потому что вы поиграетесь и потом всё это выкинете. Слой имеет смысл строить тогда, когда вы посчитали, во что обходится его отсутствие. И, наверное, у меня большинство из этих
Speaker A
слоёв появилось именно так. Сначала пришёл какой-то счёт, а потом появился код. О'кей. Всё, что я вам показал - это защита от ошибок. А Харнес ещё даёт агенту работать без вас.
Speaker A
Короткое отступление. Оно объяснит, почему вокруг циклов вообще столько шума. В шестьдесят шестом, и да, в 1966 году двое итальянцев Бёма и Якапини опубликовали статью Communication of the ACM. Она закрывала старый спор о языках программирования. И спор был примерно
Speaker A
такой: "Мой язык лучше твоего". Нет, это мой лучше твоего. И показали они следующее: "Если в языке есть последовательность, есть условия и есть цикл, то на нём вычислимо всё, что вообще вычислимо, и больше ничего не требуется". Это аналогия недоказательств. Теорема про языки
Speaker A
программирования, а не про агент. А агент с Тулами был вычислительно полон и до всякой моды на циклы. Так что пока мы с вами промли модель по одному запросу, у нас была последовательность и было условие. А вот циклы появились недавно.
Speaker A
[музыка] И когда мы собирали свои циклы с лимитами и метриками, я думал, это у нас проект такой довольно-таки специфический. А потом посмотрел, что люди делают, у которых агенты пишут миллионы строк, и увидел ту же самую конструкцию, только доведённую до
Speaker A
предела. В феврале двадцать пятого Карпаты придумал терминкодинг. не пишешь код руками, а описываешь, что хочешь, и модель генерирует. Этот термин стал вирусным. За ним стоит очень много хайпа и недопонимания. Если хотите, как-нибудь разберём, что является вайп-кодингом, а что не является
Speaker A
вайп-кодингом. Но через год на Сиквой и АСН Карпаты [музыка] сам переформулировал, что на вайб-кодинге любой может собрать прототип. А вот уже для рабочей системы нужен агентик инженеринг. Инженер проектирует систему, которая держит планку качества профессионального софта. А в марте
Speaker A
двадцать шестого он показал, что имеет в виду проект Auto Resсarch. Вы наверняка о нём слышали. Маленький репозиторий, одна GPU и 630 строк тренировочного кода. Карпаты даёт агенту задачу ускорить обучение маленькой GPT и уходит. Агент остаётся один, редактирует в trinpй, [музыка] запускает тренировку
Speaker A
ровно на 5 минут, смотрит метрику. Улучшилась оставляет ухудшилось откатывает. И заново всё это прогоняется в цикле. Через двое суток Карпаты возвращаются к логу. Около 700 экспериментов, порядка 20 улучшений.
Speaker A
Время обучения до уровня GPT2 упало с 2 часов до часа 48. То есть это 11% прироста. То есть пока человек спал, ел, делал что-то, его агенты работали и улучшались. Он не промл агента 700 раз, он один раз спроектировал цикл.
Speaker A
Фиксированный бюджет времени, автоматическая метрика и автоматическое решение. Всё остальное цикл сделал сам. Борис Черни, создатель Клодкод в Антропик, в июне двадцать шестого сказал фразу, которая разлетелась по всем лентам. По-русски это значит вот что. Я больше не промчу Клода. У меня крутятся
Speaker A
циклы, которые промтят его за меня. Моя работа - это писать циклы. А это значит, что создатель одного из самых продвинутых агентских инструментов в мире, ну, по крайней [музыка] мере, наверное, самого популярного, который зарабатывает больше всего денег, больше не пишет промты. Так вот, задумайтесь,
Speaker A
чем это отличается от научитесь правильно формулировать запрос, потому что наверняка у вас лента в Ютюба забита. Я нашёл замечательный скилл, суперкрутой промт, который исправит кд.
Speaker A
А теперь всё станет вообще намного дешевле и круче. С этими замечательными настройками мои агенты пишут самый лучший код на свете. Так вот, когда вы это делаете, вы крутитесь внутри циклов.
Speaker A
Нам же сейчас говорят, что лучше не крутиться внутри циклов, а проектировать эти самые циклы. И по факту это была моя работа последние месяцы. Не поговорить с моделью, а построить систему, в которой модель работает, проверяется и поправляется без меня. Так вот,
Speaker A
индустрия прошла путь. Напиши хороший промт к новой парадигме. Спроектируй хороший цикл. Промт - это один выстрел, а цикл итерирует до результат. И Харн сделает эти итерации безопасными и дешёвыми. И у этого движения есть общепринятая разбивка на три фазы.
Speaker A
Первоя - это промт инжиниринг. И здесь у нас с вами узкое место в формулировке контекст engниринг.
Speaker A
Здесь же узкое место переезжает информацию в нашем контекстм окне и харнес. Здесь у нас узкое горошко переезжает в среду выполнения. Но интересно, тут не сама вот эта лесенка, а движение и логика этого движения. Каждая фаза не отменяет предыдущую, а она полностью её
Speaker A
в себя вбирает. Промт у нас с вами никуда не делся. Он просто стал версионируемым артефактом внутри нашего Харнеса. Контекст у нас тоже с вами никуда не делся. Он у нас стал слоем, который собирается нашим кодом. И то, что когда-то кричали: "Во, промт
Speaker A
engниринг, целая новая профессия". Всё, эта профессия у нас с вами закончилась. И не потому, что она у нас с вами куда-то делась, а она стала у нас с вами подсистемой для нашего харнесса. Но если харнес - это у нас с вами циклы, лимиты,
Speaker A
верификация ретрай circuitбреakры персионируемые артефакты и многое другое, вам это ничего не напоминает? Антропик ещё в двадцать четвёртом году, когда ещё даже мы не мыслили о таком количестве агентов, сформулировал: самые успешные реализации агентов не использовали сложные фреймворки или специализированные библиотеки. Они
Speaker A
строились на простых компонуемых паттернах. И как мы знаем, да, каждую неделю выходят какие-то новые агенты, новые фреймворки, которые нам обещают достичь нашей цели всего за несколько минут. И да, они не врут, мы с вами получим замечательное демо. [музыка] Но
Speaker A
как только мы пытаемся на этом демо реализовать то, что нам действительно надо, мы хотим сделать какие-то уникальные вещи для нас, получается, что оно не очень хорошо работает. А если мы ещё и настоящий трафик включили на этот демо-режим, то мы с вами получим, скорее
Speaker A
всего, большой-большой провал, потому что продакшн сволой, понимание того, как всё это работает, этот фреймворк или какой-то новый небольшой агент оставил полностью вам. То есть лимиты, изоляция, метрики, откаты, это всё лежит полностью на вас. Ещё в двадцать четвёртом году
Speaker A
Декс Хорти из Human Wayare собрал методологию 12 Factor Agents. Он поговорил с фаундерами, которые делали агентов и доводили это до продакшна. И ключевой вывод был такой: хорошие агенты - это в основном просто софт. То есть это хорошо написанный код, в который LM
Speaker A
вызовы встроены точечно. И три фактора оттуда прямо про Харнес. Когда он писал эти 12 факторов, ещё никакого харнеса не было, но они прямо очень хорошо попадают. И это владей промтами, владей контекстным окном и потоком управления.
Speaker A
Так что, когда вы отдаёте эти три пункта на уровень вашего фреймворка или какого-то нового неизвестного суперкрутого агента, которого вы взяли с гита, знаете, что, возможно, вы потеряли контроль ровно там, где он важнее всего.
Speaker A
Скептики уже написали, что инжениринг - это переименованный платформенный инженеринг. Middleware sre control plan modлcom. И да, они, скорее всего, правы практически целиком. И именно поэтому Кэнд инженер - это и есть тот человек, который сейчас важнее всего для того,
Speaker A
чтобы мы могли построить с вами настоящего хорошего продакшн-агента. И под одним из прошлых видео был довольно-таки интересный комментарий.
Speaker A
Вот он. Бэкэндер, который умеет масштабировать бизнес, должен сейчас сменить направление и масштабировать агентов, чтобы через 2-3 года хайп прошёл, потом вернуться обратно, но уже потеряв опыт. И да, это резонный страх, но давайте разберём. Харнес у нас с вами
Speaker A
состоит из ретраль лимитов изоляции, версионирования, CI, наблюдаемости. И если агентский хайп завтра куда-то у нас с вами сдуется, в чём я очень сильно сомневаюсь, то какой из этих навыков обесценится?
Speaker A
Никакой. Скорее всего, вы, наоборот, даже прокачаетесь в вашей профессии, потому что это ровно тот же самый стек, но у него появился новый потребитель, и это агент. И настоящая крутая инженерия, которую, к сожалению, далеко не все умеют, сейчас очень востребована для
Speaker A
агентов. И, как мне кажется, сейчас развитие в инженерии важнее, чем когда-либо раньше. Так вот, куда же смещается эта ценность наша как разработчика? И давайте посмотрим, что говорят у нас некоторые лидеры. Лопапола описывает, что делает команда, пока агенты писали миллион строк кода. Работа
Speaker A
инженера сместилась с написания кода на проектирование среды и формулирование намерения и на построение обратных связей. И это описание работы очень похоже на описание того, что раньше делали синьор бэкмт инженеры, лиды и тому подобное. Код теперь пишет агент.
Speaker A
Раньше писали джуниор медвы. А вот за то, что вокруг этого кода, за ту среду, в которой агент не может навредить, за спецификацию, по которой он понимает задачу, за обратные связи, которые ловят его ошибки раньше, чем их увидят клиенты, за это уже как раз-таки
Speaker A
ответственны синьоры нового поколения. И ещё одна небольшая работа, которая вышла в июле двадцать шестого. Исследователи задали неочевидный вопрос: а что Харнес меняет, кроме результата? При этом задачу, среду и базовую модель зафиксировали намерт. меняли только обвязку и смотрели не на финальный
Speaker A
успех, а на то, что агент сообщает о себе по дороге движения к этой цели.
Speaker A
Насколько он продвинулся, насколько рискует, сможет ли откатиться и во что обойдётся починка и что вообще он будет делать дальше. Заблокировали агенту часть действий, жали ему попытки починки, проверяли выборочно, обрезали влоги ради экономии. Задача решена.
Speaker A
Галочка стоит, все довольны. А вот картина [музыка] мира, из которой агент принимает каждое следующее решение. уже совершенно другая. Так вот, наш с вами Харнес, он не просто ловит ошибки, он формирует ход рассуждения нашего агента.
Speaker A
Поставили какие-то лимиты, и агент начал считать задачу более рискованной, чем она есть. Обрезали лок ради экономии токенов, и агент перестал видеть, что он уже что-то до этого попробовал. Вы думали, что вы уменьшили его расходы, но вы поменяли его поведение. Так вот,
Speaker A
какой же был вывод у авторов этого эксперимента? Дизайн Харнес - это экспериментальная переменная, а не деталь реализации. Так вот, Антропик сама подтвердила это на своём продукте.
Speaker A
6 недель пользователи жаловались, что Квод тупет. Когда разобрались, выяснилось, что это было три независимых баганс инженерии. Понизили Reason Effort, сломали очистку свинки истории, так что она срабатывала каждый ход и добавили лимит многословности в системный промт. Модель при этом не
Speaker A
трогали вообще. Иследствие отсюда абсолютно практическое. Если вы меряете две модели на своём агенте, а обвязка при этом разная, вы меряете не модели, вы меряете обвязки. Именно поэтому одна и та же модель показывает разные числа в разных инструментах. Именно поэтому
Speaker A
спор, эта модель тупее или та модель тупее, сейчас у меня работает лучше, сейчас работает хуже- это почти всегда не про модели. И влияние обвязки его уже померили. Исследователи из Фунданского и Пекинского университетов дали Харнес автоматически эволюционировать. 10раций и на каждый система смотрит на провалы
Speaker A
агента и правит собственные правила и инструменты, которыми она это делает. Бенчмарк называется Terminal Bench 2.
Speaker A
Начали они с 70%, а доехали до 77. При этом ручной Харness от кодек C застрял практически на 72%. То есть Харнес обгоняет Харнес. И даже уже появилась работа с громким названием. Хватит сравнивать агентов, не раскрывая Харнес.
Speaker A
Они взяли одни и те же модели, прогнали под разными обвязками, и дисперсия от Харнеса оказалась почти в восемь раз больше, чем от выбора модели. И в шести случаях из девяти рейтинг модели при смене обвязки менялся. И это уже не
Speaker A
единичный эксперимент, а целое направление. За последние месяцы вышли работы про Харнес, который сам себя переписывает пологом собственных провалов. И порядок величины там был примерно такой же. И про обвязку, накопленное состояние которой потом переносит на другую базовую модель. То
Speaker A
есть Харнес потихоньку становится отдельным активом, который живёт дольше, чем модель, которая находится под ним.
Speaker A
Но при этом можно услышать, что модели скоро станут такими умными, они в себя впитают всё это, и все наши с вами обвязки никому будут не нужны, так же как промт инженеринг. Ну, мы, конечно, поживём и увидим. Но при этом, если мы
Speaker A
посмотрим на те эксперименты, о которых мы сейчас говорили, то там модель не трогали вообще. Меняли только обвязку, [музыка] и бенчи менялись на семь пунктов. А дальше может быть простая логика. Чем сильнее прокачання модель, тем больше ей доверяют, тем дороже
Speaker A
обходится её ошибка и тем важнее рамки, которых ошибка не превращается в катастрофу. На последний яй инженер World Fair инженер из Open AI вышел с докладом, который назывался Your agents didn't fail, your harness did. И лучше этого не сказать никак.
Speaker A
В самом начале я ещё говорил, что мы потом рассмотрим семь слоёв. Так вот, возвращаемся. Вышел обзор, который сводит больше сотни работы и два десятка живых систем в одну таксономию. И они разделили это всё на семь слоёв. Первые четыре - это структурное ядро обвязки.
Speaker A
Последние три - это контрольный контур поверх неё. Давайте по ним пройдёмся, чтобы понять, как эта структура ложится на нашу харнес-нженерию.
Speaker A
И первое - это ядро, [музыка] где вообще исполняется код нашего агента. В какой он запущен песочницей? Как всё это устроено? Мы это с вами затронули в констрей. Второй - это тулинг.
Speaker A
Здесь будут лежать протоколы тулов и валидация схем. И это невероятно важный слой, в котором нам с вами надо научиться работать с нашими тулами, потому что не все модели умеют хорошо вызывать наши тулы. И работа с тулами, как я вам сказал в начале, у нас идёт
Speaker A
через эксперименты. Мы смотрим, как модели умеют работать с нашими тулами, с нашими описаниями, умеет ли их вызывать с правильным описанием получать информацию о них. Также работа с тулами - это работа с ошибками. Когда ваш тул что-то возвращает, он должен возвращать
Speaker A
всю информацию так, что будет понятно для наших агентов. И когда мы с вами говорили про свой verify от Open AI, формально он живёт именно здесь. И в первой части серии про systemм дизайн для яагентов мы с вами разбирали, что же
Speaker A
такое тулинг и из чего он состоит. Следующий слой - это у нас с вами контекст.
Speaker A
И здесь у нас с вами будет то, что видит наша модель на коротком горизонте, на горизонте сессии и на постоянном. Это будет наш с вами informм. Во второй части серии Проя агентов мы разбирали четыре типа памяти: бюджет контекстного
Speaker A
окна и как не раздуть его до потолка. Это всё именно здесь. Следующий - это life cycle.
Speaker A
Здесь у нас с вами будет оркестрация и поток управления, стоит машины, применение политик, один агент в цикле или несколько агентов. То есть, грубо говоря, от нашей с вами задачи до пулреквеста, если мы с вами будем использовать кодинг агентов для описания
Speaker A
этого слоя. Это у нас с вами первый контур, но есть ещё второй контур, в котором есть три слоя, без которых всё это будет работать не очень хорошо. И здесь у нас с вами будетбиility.
Speaker A
Слой observability позволяет нам с вами реагировать на любые поломки, недочёты, неправильный тулинг, что-то пошло не так. В момент времени, когда это произошло, мы можем получать алёрты, мы будем наблюдать за системой, и мы сможем расследовать инциденты при помощи этого
Speaker A
слоя. Если его не будет, мы с вами будем лететь вслепую и не видеть, куда же мы с вами движемся, что происходит и как возможно что-то исправить. А может быть, оптимизировать. Для этого для всего также нужно построить очень хорошо свой
Speaker A
обзервабиility. И помните stateх из блока провер verify? Блок там был чист, а вот действия, к сожалению, не сохранились. И здесь бы нам могло помочь Обзервобили для того, чтобы понять, что пошло не так. Так вот, без наблюдаемости, которая отслеживает
Speaker A
цепочку от пользователя, мы узнаем о дефектах только когда этот пользователь нам напишет нашу поддержку. А может быть, он не напишет, и наш агент будет всё время работать криво. И в третьей части наших видео про системдизаign агентов мы разбирали этот свой подробно.
Speaker A
Там мы говорили про метрики по каждому Тлу, детекция плохих циклов, история и что делать с ризанными токенами.
Speaker A
Поэтому, если вы ещё не смотрели эту серию, я советую начать именно с этого блока, потому [музыка] что без обзервабилити всё остальное вообще не важно. Я считаю, что это один из самых важнейших слоёв, когда мы строим с вами агентские системы. Иначе, как я уже
Speaker A
сказал, всё вот это будет работать вслепую. Итак, следующий - это verification. Здесь у нас с вами будет оценка и обратная связь, все те три уровня проверок, которые мы разбирали недавно, когда говорили про инварианты, замеры и человека, который может также помочь нам
Speaker A
с вами всё верифицировать. Также в этом исследовании здесь прописано про модель в роли судьи и финальный - это governance.
Speaker A
То есть здесь у нас с вами будет безопасность и политики поверх всего остального. Соответственно, всё, что связано с пром инжекнами и то, что мы разбирали с вами defense and уже остал говорить, то, что мы с вами разбирали, ну, действительно, мы с вами всё это
Speaker A
разбирали в цикле видео про агентов, где вышло четыре видео. Можете посмотреть их, ссылка в описании, и тогда вам станет всё это хорошо понятно. И очень часто слой выпускают из вида, потому что большинство фреймворков и множество агентов, которых вы можете найти на
Speaker A
гитхабе, не содержит либо содержит недостаточную объём инструментов для того, чтобы защитить нашу с вами систему от возможной атаки. Так вот, как вы видите, вот это вот всё не про модели.
Speaker A
Мы здесь с вами не сказали: "Берём самую лучшую модель, и оно всё работает". Нет, это как раз-таки всё наша обвязка.
Speaker A
Поэтому Харнес он у нас выступает как актив. И модели они у нас с вами дешевеют, превращаются в товар, появляется куча классных китайских недорогих моделей, но при этом ваша обвязка, которую вы знаете, настроили и сделали хорошо, она так дешеветь, как
Speaker A
модели, не будет. Она будет только дорожать, потому что именно в неё вложен весь ваш опыт, все ваши эксперименты и знания. Поэтому вы можете легко заменить одну модель на другую, и всё также продолжит работать хорошо. При этом, если у вас очень слабый харнес, то смена
Speaker A
модели может повлиять критически на то, как работает ваш агент. Поэтому, когда вы меняете модель, не забывайте запускать все тесты, о которых я говорил. И возможно, если модель стала действительно очень какой-то классной, нам надо переоценить, что-то изменить, а может быть, что-то добавить для того,
Speaker A
чтобы наша система работала ещё лучше. Вспомните то, с чего я начал. миллион строк, 1.00 плуреквестов и ноль ручного кода. И возможно в начале это звучало как магия модели, которая это может себе позволить сделать. Но теперь вы точно знаете, что это не вопрос модели, а
Speaker A
вопрос того, как мы можем выстроить нашу с вами обвязку вокруг этой самой модели. То есть среда, ограничения, верификация, обратные связи - это всё невероятно важно. И получается, что двигатель у всех один и его продают по API, вы платите за токены. А вот уже то, какую
Speaker A
можно машину собрать на этом двигателе, зависит целиком полностью от вас. И получается, что харнес инжениринг - это не новая профессия, на которую надо идти куда-то переучиваться. Это вся та инженерия, только под другим взглядом, к который мы с вами привыкли, который мы с
Speaker A
вами выполняем уже последние много десятилетий. И если раньше мы строили вот эту вот всю инфраструктуру для кода, который пишет человек, то сейчас, если мы говорим про кодинг агентов, мы строим эту инфраструктуру для агента, который пишет нам с вами код. И получается, что
Speaker A
вот эту вот обвязку мы делаем для этого исполнителя, который ошибается часто, непредсказуемо и очень уверенно нам может затирать что-то, что он знает, как надо делать. И поэтому наша с вами задача сделать так, чтобы эта уверенность была не только на уровне
Speaker A
модели, но и на уровне нашего кода, на уровне нашей обвязки, что позволит нам дать качественный результат в наших агентах. И, конечно, всё это встречается не на одном каком-то конкретном агенте.
Speaker A
Это всё встречается на каждом новом агенте всё одинаково. И все те агенты, о которых я говорил, у них у всех есть одни и те же свои. Да, немножко что-то по-разному настроено, разные тесты написаны, под них выбирается разный тулинг, разные модели. Агенты имеют
Speaker A
различные настройки, но при этом набор инструментов у нас будет примерно одинаковый для всех. И если вы делаете агентов, давайте проверим прямо сейчас, насколько хорошая у вас обвязка. Лимиты итерации вашего агента, они у нас в коде или в промте? Есть ли у вас
Speaker A
автоматический замер качества, если вы меняете модель, с которой работает ваша обвязка? Или вы проверяете это вручную, написав какие-то сообщения в чат. А как вы версионируете ваши промты? Можете ли вы откатиться к предыдущей, провести а-тестирование и сверить, что стало
Speaker A
лучше, что стало хуже? И последнее, может ли ваш агент выполнить какое-либо необратимое действие, пока вы спите? И сколько ответов вас устроило, столько слоёв Харнес у вас и есть. Поэтому, если вы хотите построить или уже строите своего агента, то начинайте не с выбора
Speaker A
самой лучшей модели, а начинайте с правильной харнес- инженерии. Ну а на этом всё. Удачи. Пока. Пишите агентов, которые будут невероятно крутыми, не развалят ваш продакшн и будут работать прямо как чис. M.
Topics:harnessагенты OpenAIмашинное обучениеинженерия агентовпромтыкодовая обвязкаconstrainverifycorrectинструменты AI
