Speaker A
Всем привет. Да, сегодня у нас будет поговорим с вами про IC или agent harness. Вообще, в принципе, что это такое и как его собрать и из каких этапов он состоит. А пару слов обо мне, чем вообще я занимаюсь. Так уж вышло, а
Видео объясняет, что такое Agentic Harness, как его собрать и использовать, а также раскрывает концепцию агентов и их инфраструктуры.
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
- Agentic Harness — это инфраструктура и обвязка вокруг модели, обеспечивающая её работу и взаимодействие.
- Агент — это сотрудник с мозгом (моделью) и event log для отслеживания истории действий.
- Надежность и контроль выполнения задач агентом критически важны для стабильной работы.
- Хранение и управление контекстом — ключевые аспекты эффективной работы мультиагентных систем.
- Современные платформы и подходы позволяют создавать гибкие и масштабируемые agent harness'ы.
What the video covers
- Объяснение термина Agentic Harness и его отличия от обычного агента.
- Автор рассказывает о своей работе над платформой для мультиагентных систем.
- Обзор популярных agent harness'ов, таких как Клод, Кодекс и другие.
- Рассмотрение роли модели как 'мозга' агента и harness как инфраструктуры.
- Обсуждение важности event log и рантайма для работы агента.
- Разбор проблем надежности и устойчивости работы агента в различных условиях.
- Примеры использования локальных и серверных запусков агентов.
- Подходы к управлению контекстом и хранению данных для агентов.
- Обсуждение методов контроля и сэнбоксинга для предотвращения ошибок агента.
- Рассмотрение современных трендов и практик в разработке agent harness'ов.
Chapters
- 00:00Введение в Agentic Harness и знакомство с автором
- 03:09Что такое агент и agent harness: определения и примеры
- 05:31Где и как запускается агент: локально и на сервере
- 08:24Надежность работы агента и управление event log
- 11:25Контроль и безопасность: сэнбоксинг и управление доступом
- 13:31Современные подходы к проектированию agent harness
- 17:31Практические советы и рекомендации по использованию агентов
- 19:32Заключение и перспективы развития agent harness
Full Transcript — Download SRT & Markdown
Speaker A
что оказывается я строю платформу для agent harness'ов, да, термин недавно появился, но вот этим, собственно, и занимаемся. Делаем горизонтальную платформу для построения мультиагентных организаций. И так уж вышло тоже второй мой продукт. Он наоборот больше про то, как сделать вертикального агента,
Speaker A
который в своей такой обвязке может помогать строителям делать сметы для стройки. А, отлично. А прежде чем перейдём к харнесам, вообще скажите, какими агентами вы пользуетесь? Вот можете прямо назвать вслух зала.
Speaker A
Клодом. Клодом. Так. Только Клодом, да? А Git там гигачат. Я почему не слышу? Ничего такого нету. Да, [смех] Виталик там, я не знаю, что у Яндекса внутри какие-то тоже, наверное, есть.
Speaker A
Отлично. Скорее всего, вы назвали что-то из этого clкод, курсор, да, Open CD, возможно, кодекс, но есть одна большая неувязочка. И этот список again agent harness'ов, да, я буквально загуглил топ-10 agent harness'ов и посмотрел, да, какие из них есть, вывел сюда.
Speaker A
Получается, ровно в этот же список мы можем добавить точно те же самые гермесы, OpenCl и всё, что сейчас релизится. Отсюда вопрос, что такое же на самом деле Agent Harness? Ну, первым делом, что я сделал, я решил пойти, надо
Speaker A
спросить самого Клода, как он считает, что такое Agent Harness. И в принципе Клод мне так и ответил, да, я его спросил: "Клод, код, ты agent harness?" Он сказал: "Да, я Agent Harness". Но опять же я его спросил, является ли он и
Speaker A
агентом или нет. Он тоже сказал мне, что он является и агентом. В общем, он на всё со мной соглашался. Я от него так и не смог получить ответа утвердительного, что же такое, в чем это отличается Agent Harness от того самого агента. Может
Speaker A
быть, это модель. Давайте посмотрим. Здесь интересная статистика, где, э, где-то приходит GitHub, да, для своего капилота они сделали как раз отличие их Cлайки и гоняли это всё на разных моделях. Ну, например Sonet там по-моему четыре 4,6, да, 4,7 указан. Точно так же
Speaker A
кодекс. Где-то задачи они делали лучше, где-то хуже. Точно также у них есть статистика по количеству затрачиваемых токенов. Кстати, интересно, что токенов они почти везде ели больше. Получается, что это немного не совсем про модель.
Speaker A
Вообще впервые термин harness, да, ну, возможно, он как бы относительно старый, но в рамках и агентов он начал использоваться и появляться вот в феврале 2026 года.
Speaker A
в статье от чата GPT, да, от Open Open AI, где они дали задачу своему кодексу, чтобы он спроектировал с них сразу с нуля какое-то приложение, и они должны были туда вообще не вмешиваться. И, как говорится, здесь понеслось. Через месяц
Speaker A
похожая статья вышла у Клода, да, про харнесы. В апреле уже вообще почти, можно сказать, в каждом блоге начал появляться, да, здесь блог Мартина Фаулера. Кстати, максимально советую.
Speaker A
Очень тоже интересно про агентские харнесы именно для колдинга используется. И в принципе понятно, да, если мы спросим, что такое а вообще агент сейчас уже теперь Google начнёт нам выдавать примерно такое, что агент - это некоторый harness и модель. Мне, в
Speaker A
принципе, очень нравится такой подход, когда мы агента называем каким-то сотрудником. Да, ну давайте представим, что это сотрудник. Он берёт наши задачи и что-то делает и выдаёт нам некоторый результат или артефакт. Отлично. У нас есть сотрудник, мы знаем, что модель -
Speaker A
это его мозг, какой бы он, собственно, ни был, да, китайский, не китайский, американский, российский неважно.
Speaker A
Модель - это его мозг. Но что же такое harness? Отлично. Давайте мы, в принципе, в такой же парадигме и пойдём.
Speaker A
Мы наймём нашего сотрудника, найдём э ту самую заветную карточку зарубежную и возьмём 20 долларов и заключим с ним job offer, возьмём его на работу и пойдём делегировать ему задачи.
Speaker A
Вот у вас наступает ваш первый рабочий день. Вашему сотруднику приходит некоторая задача. Что происходит дальше?
Speaker A
Ну, мы ожидаем от него некоторое решение. В принципе, логично. Мы сотрудника наняли, можем ожидать от него решения. Кстати, а есть те, кто не смог из вот из Клода или из кодекса получить какой-то хороший результат, кто вот прямо неудовлетворён его работой?
Speaker A
Отлично. Вы ему так и напишите. Скажи: "Я тебя уволю, да ты свои 20 долларов отрабатываешь или 100, иначе я тебя уволю.
Speaker A
Скажи мне, что, да, ты должен делать, чтобы я тебя не уволил". А [смех] есть ещё такой хак, можно попросить его, а сказать ему: "У меня остались последние 100 долларов, да, и если ты мне начнёшь приносить денег, я тебя
Speaker A
уволю". Он скажет: "Если у тебя остались последние 100 долларов, то потратиться на подписку не самая хорошая идея".
Speaker A
В общем, да, отлично. Как и любой другой работник, да, обычно мы ему делегируем задачи, он начинает что-то думать, что-то делать, и, в принципе, так по циклу, пока не придёт к нам с результатом и не скажет: "Я сделал камни". Да, в принципе, это выглядит
Speaker A
примерно так. У агента единственное различие от обычного сотрудника, у агента появляется тот самый event, да?
Speaker A
Потому что мы помним, что агент, поскольку у него мозг, ну, принимает токены, отдаёт токены, нам необходимо всё-таки немного помнить историю того, что он делал. И у нашего сотрудника появляется event log, да, сообщение пользователя, месседжи, что он сделал, куда они возвращаются. И нам необходимо
Speaker A
где-то тогда запускать ту самую его думалку. В принципе, неплохо. Где можно запустить думалку? Ну, понятно, на нашем устройстве, в принципе, многие уже так и делают.
Speaker A
Кодекс и наша event log будет появляться у агента в таких вот интересных, да, файликах.
Speaker A
Как правило, все локальные агенты кладут куда-то его примерно в JSONL. Кстати, здесь тоже интересный факт. Если вы кто-то вот пробовал вообще взять всю свою историю, вот сколько вы общения с Клодом и попросить его кастомизовать, а, а вот не опуская руки, теперь
Speaker A
оставьте тех, кто был доволен результатом. Вот. Отлично. Мне, в принципе, да, очень это понравилось, что я попросил тоже точно так же кодекса, э- или Клода, ну, точно не помню, здесь кодекс указан, но, по-моему, я всё-таки Клода просил, а,
Speaker A
чтобы он взял, посмотрел всё, что я делаю, и составил такую некоторую, да, LMK, ну, или просто там некоторую базу знаний вообще всех подходов, всё, что мне нравится и не нравится. И это очень интересный трюк, обязательно попробуйте.
Speaker A
У меня, по-моему, было около 500 Мб, что ли, данных. Это только в Клоде. В кодексе ещё там сколько-то. Конечно, надо, надо всё это ещё потом дорабатывать, но очень такой интересный подход. Отлично. Можем догонять на нашем компьютере все лайки. Многие, как вы,
Speaker A
разработчики, скорее всего, я думаю, очень любите C. Кто-то, может быть, меньше, но тем не менее. Либо в десктопе. И, разумеется, точно так же, раз есть какое-то устройство, мы можем наш агентский цикл гонять где-то на сервере. Но поскольку мы знаем, что
Speaker A
агенты, они могут работать над задачами долго, нам всё-таки хотелось бы, чтобы это всё было надёжно, потому что можем представить такую ситуацию. Наш агент запустился, начал производить те самые event-логи, да, и в какой-то момент подзалип. Ну, с кем не
Speaker A
бывает, отвлёкся на TikTok, да, как и любой сотрудник, он всегда может подзалипнуть и вообще забыть, за что ему платят деньги, за что мы его наняли, и отвлечься на другую задачу. То, в принципе, от такого сотрудника мы ожидаем, что он продолжит свою задачу
Speaker A
без нашего какого-то дополнительного пинка и продолжит её выполнять. Э, отсюда сразу возникает, да, самое главное, что необходимо нашему харнесу - это некоторый рантайм. И как и с любым рантаймом, с ним может пойти что-то не так, да? Что же может пойти не так? Так
Speaker A
уж вышло, что наш сотрудник такой довольно интересный, да, вот он гоняться может почти на любом устройстве, может гоняться у нас, может гоняться где-то в сервере, а мозг у него почему-то вынесен где-то в сторону. Ну вот такой вот неродивый сотрудник. Этот мозг у него
Speaker A
может отпасть, у него могут отпасть иногда руки, которыми он что-то делает.
Speaker A
И отсюда сразу возникает вопрос, что от нашего рантайма такого что-то необходимо, да? Как и в любой такой микросервисной архитектуре, мы ожидаем, что у данного рантайма будет durability, да? То есть, если что-то упало, оно потом продолжить продолжит работать с
Speaker A
этого же места. Также, если где-то какой-то сервис недоступен, что мы к нему сможем постучаться и заново его запустить, получить снова от него результат. Ну и, разумеется, э мы хотим, помимо того, чтобы он был надёжный, мы хотим ещё и выбирать, где эти данные,
Speaker A
да, где та самая его работа будет происходить. И это такая очень прикольная особенность нашего нашего агента. Отлично. Какие мы можем взять рантаймы? Ну, можем пойти и сами попробовать написать этот runtтай руками. Либо взять какой-то готовый фреймворк, landграph, да, тоже неплохой
Speaker A
runтайм. У них есть чекпоинтеры для того самого запоминания, что где был eventlock. Можно взять фреймворк мара, это отверстие, которое написано в тайпскрипте. Но мне, на самом деле, этот фреймворк не очень понравился, потому что он ещё в бета-версии, и очень часто
Speaker A
у нас что-то с ним всё лагало в продакшене, поэтому, э, его не особо советую. Либо можем пойти и взять какой-то готовый оркестратор. Когда мы приступали к разработке своей агентской платформы, мы рассмотрели, на тот момент был почти год назад, несколько разных
Speaker A
оркестраторов. первый, который был, ну, разумеется, в смысле в openource оркестраторов, мне очень понравился Dap их тоже оркестратор для агентов Agency Dapper agents, но, э, не совсем понравились те подходы, которые у них были на тот момент, потому что они всё
Speaker A
ещё продолжали относиться вообще ко всем агентам, как будто бы такой дерминированный сервис, да, микросервисная архитектура и в целом с ней так работать. Дальше мы посмотрели на такой эркестратор Restate. Э, он мне тоже, в принципе, очень импонирует. Мне нравится их подход, и, в принципе, очень
Speaker A
сильная команда стоит за разработкой. Если я правильно помню, Founder Rate - это один из инженеров, который разработал Кавку. И, в принципе, кстати, многие подходы, они там тоже с масштабируемостью там используют. Но с рестйтом есть небольшая проблема в том,
Speaker A
что не самое, как скажем, не самое большое комьюнити, и, в принципе, у них до сих пор не было релизной версии, поэтому мы это маленько тоже решили от себя подальже отодвинуть и взять что-то более надёжное. Вы взяли Temporal, да,
Speaker A
или Temporal. Я постоянно неправильно ставлю ударение этого сервиса, но тем не менее отлично. Open source, Apatch 2.0, лицензия. Можем надёжно гонять наши циклы. Всё классно, но сразу возникает вопрос, нам до бесконечности, да, что ли, эти циклы гонять, потому что отлично
Speaker A
циклы есть, и внты идут, агент что-то производит или тот самый harness, и, э, надо как-то этот цикл останавливать, да?
Speaker A
Ну, как его останавливать? Ну, в первую очередь мы можем остановить, когда задача была выполнена.
Speaker A
Звучит как бы логично, поэтому сразу, когда останавливаться, ну, здесь сейчас уже модно, если какой-то вы пользуетесь клодом, а тот тот самый гол. В принципе, этот гол можно сделать и самому без проблем на любой обвязке вокруг агента.
Speaker A
А можно сделать цикл, да, когда агент будет гонять что-то в цикле, пока в общем, какой-то чекервеifаер, который его проверяет, не решит, что задача выполнена. Либо мы можем сделать более детерминированные критерии останова, да, например, когда какой-то критерий соблюдён. Если предыдущие они больше
Speaker A
рассчитаны именно на семантику, когда агент сам понял, что надо расстановиться, то вторые мы можем на уровне уже как бы инфраструктуры или на уровне вот этой вот обвязки для него останавливать, например. Ну, конечно, это все наши линтеры, тесты, да, чем
Speaker A
больше таких детерминированных а-э верификаторов сделанной задачи мы с вами настроим, тем лучше. Отлично. Получается, runнтай у нас состоит из двух частей. Первое - это некоторая инфраструктура, на которой наш агент должен запускаться надёжно, да, что должен зарабатывать. И некоторая семантика, что агент он может
Speaker A
проверять сам себя, он должен работать, пока не достигнет какой-то цели. В общем, мне вообще нравится этот подход, да, что любой harness по сути - это некоторая инфраструктура и семантика. И в конце как раз тоже маленько будет пару пару слов скажу, почему это особенно
Speaker A
важно. Отлично. Мы теперь знаем, что харness как минимум состоит из рантайма. Но поскольку у нашего агента есть некоторый мозг, он что-то может делать, но мы же не хотим от него получать только текст, надо дать ему руки. Здесь сразу на первое место выходят те самые
Speaker A
тулзы. У любого агента, у любого agent harness есть возможность вызывать тулзы. Ну, это по дефолту везде идёт это.
Speaker A
Давайте мы будем дадим ему читать файл, давайте мы дадим ему возможность писать файл, ну и всё-таки в этом файле маленько что-то поискать, потому что иначе какой смысл от такого агента, который будет всё только читать и писать. Как правило, ещё часто, если
Speaker A
посмотреть клодкод, у него есть ещё websarch. И, в принципе, многие выделяют это отдельно, потому что агенту просто будет проще найти. А есть MCPшки, которые многие настраивают. И самое важное есть баш. Я думаю, в принципе, наверное, можно вообще всё предыдущее
Speaker A
убрать и оставить здесь только баш и сказать агенту: "Вот, ходи в баш и только башем и пользуйся". И сразу возникает такая проблема, когда вы своему сотруднику даёте доступ в баш и даёте полную возможность что-то делать.
Speaker A
Ну я думаю, что любой тимлиц своего стажёра видит примерно вот так, да, когда вы ему доверили задачу. Э поэтому, в общем, сразу возникают определённые проблемы. Может показаться, что таких проблем не было, но нет, конечно.
Speaker A
постоянно возникают, а в одном месте и агент. Мне, в принципе, вообще очень нравится, как сейчас модно стало говорить, что не кто-то накосячил, а у нас и агент пошёл, удалил. Да, у нас и агент взял, стёр. Ну, конечно, это же и
Speaker A
агент накосячил, а не разработчик, который дал ему доступ в продовую базу. Э, да, не суть важно, да, вот много кейсов там и агент снёс стартап очередной на 2,5 млн долларов. А у Реплита и агент снёс, а, прод базу
Speaker A
данных одного из их кастомеров. Причём они об этом сказали только через год. Ну, видимо, когда всё-таки смогли как-то восстановить отношения к своим клиентам.
Speaker A
А или вот, например, кейс, да, где и агент за 9 секунд снёс продовую базу и всем продолжал утверждать, что это делал не я. Ну я говорю, вот в принципе как стажёр. Дали ему в руки гранату, да, он пошёл всё разносить. Поэтому у меня
Speaker A
сразу в голове возникает вот что нашем к нашему агенту мы должны относиться вот примерно как на этой фотке, да, нового инженера, который пустили в протбазу.
Speaker A
Я в принципе даже сам много раз сталкивался. Ну, я такой довольный евангелист по всем этим агентским вещам.
Speaker A
И я не боюсь, да, Bтбой, да, вот давать ему смело кидать какие-нибудь креды, токены, в общем, пусть он там делает, главное задачу сделает. Только надо токен не забыть. И здесь недавно на днях я ему закинул токен, чтобы у меня в
Speaker A
таймвебе проверил возможность подъёма какого-то сервера. А, и ещё сказал ему кодексу, говорю: "Клодкод справился, так что я ожидаю, что тоже справишься". Он долго крутился, в общем, ничего не смог сделать. Поднял мне вместо этого все возможные сервера, которые он смог
Speaker A
поднять в таймвейбе. Хорошо, что я заметил, что он пошёл и поднял, да, и сразу вдруг чек очень сильно увеличился.
Speaker A
Но тем не менее надо чётко понимать, какие задачи выдают своему агенту. Логично, в принципе, когда мне решили доверить задачу, возникает сразу вопрос, ну, не мне, агенту, как обезопасить всех вокруг от меня. Ну, и логично, давайте посадим его в клетку. Ну что ещё им
Speaker A
делать? Других-то выходов нету. И здесь на первую роль выходит тот самый снбоксинг для агентов. Надо понимать, что, во-первых, да, Sandbox - это способ ограничения Blast Rattio и возможности агенту а сделать что-то непоправимое инфраструктуре да вашей либо локальной, либо если вы запускаете вот
Speaker A
так смело на сервере. Но второй момент, что Sandbox - это способ расширения возможностей, ну, и в принципе баш, вашего агента без переписывания каких-то специальных правил. Почему я на этом делаю большой акцент? Когда мы разрабатывали агента для констрактио нашего сервиса, мы довольно чётко
Speaker A
ожидали, что будет фиксированный workflow, фиксированный какой-то UI, пользователи будут заходить, грузить сметы, мы будем видеть результаты. И что происходит дальше? А дальше происходит следующее: а можно выглядеть смету, пожалуйста, без колонки один? А можно добавить ещё пять других колонок? А
Speaker A
давайте мы будем считать в попугаях, а не в метрах. А потом давайте вот вам 10 смет, давайте вы их все сравните и найдёте финальный результат. И интересное становится то, что в принципе пользователи, они уже настолько привыкли к агентам, что они не ожидают от нас
Speaker A
просто каких-то фиксированных агентов. Они ожидают такие полноценные харнесы, чтобы агент в них крутился и выполнял те задачи, которые они им поставляют. Здесь вот, да, интересно, как мы с этим столкнулись, что снбокса мы и не хотели изначально туда прикручивать, но
Speaker A
пришлось. Отлично. Получается, что харness - это некоторый runтайм, это какие-то определённые инструменты, которые есть, да, MCP, там баш, sandbox, в общем, всё то, что вы смогли ему дать.
Speaker A
А, но вот сразу, да, переходим дальше. В принципе, как вот вспомните своё ощущение, когда вы приходите на новую работу, да, или когда вы погружаетесь в новый проект или когда вам необходимо изучить какой-то новый, а, там, навык, да, или умение. Ну, у меня первые там
Speaker A
какая-то мысль всегда примерно вот такая, да? А что делать вообще? А как так? Ну ладно, не буду слуг проносить, да? Как сходить там в туалет там и сразу непонятно вообще, куда двигаться, потом куда смотреть, что вообще от меня хотят.
Speaker A
Потом, в принципе, позитив, подумав маленько, я вспоминаю: "А точно, мне же заплатили за это деньги, надо же что-то сделать, от меня ожидает артефакт, ожидает результат". И в голове сразу возникает та самая должностная инструкция, которая звучит примерно хорошо делай, плохо не делай, да,
Speaker A
репозиторий тут, ты же разработчик, иди работай. И это как раз, в принципе, и называется тот самый контекст. Контекст, который мы тоже хотим дать нашему агенту, чтобы он независимо от каких-то наших дополнительных действий продолжал делать хорошие результаты. В целом, в
Speaker A
принципе, логично, да, чтобы понимать вообще, что происходит, давайте ему тоже такую инструкцию и дадим, да, код не ломай, пиши хорошо, в общем, делай хорошо, и хорошо будет. Отлично. Для этого придумали, да, уж так появилось, зашло файлик Agents MD. Наверное, многие
Speaker A
про него слышали. В любом проекте он настроен. Мне вообще нравится подход Мартина Фаулера. Он часто ссылается, что AgentsMD, да, - это table of content. Я думаю, в принципе, если посмотреть како-нибудь LMвики Карпатова, то любой вот этот вход входной индекс, да, как
Speaker A
раз agent MD - это есть, по сути, индекс нашего проекта, и является такой на начало того, начало знания о нашем проекте, начало своей задачи.
Speaker A
Отлично. Мы знаем в целом, что происходит в проекте. Ну, мы, наверное, хотим помнить, что вообще в этом проекте мы делали в рамках задачи. Поэтому здесь возникает короткая память или тот самый eventтлок, про который мы с вами говорили. И мы хотим помнить, что мы
Speaker A
вообще когда-то делали, да, долго вот этот Longterm memory либо сохранить, либо а вспомнить, да, все эти раги, базы и тому подобное. Сразу возникает та вопрос, где вообще этот контекст нам с вами хранить? Ну, мы можем попытаться сделать фиксированную структуру данных
Speaker A
для нашего какого-то агента его знаний и попытаться её продумать изначально и сунуть куда-то в базу данных. К сожалению, опять же, наш продовый опыт показал, что пользователи ожидают теперь от агента больше, нежели просто какую-то фиксированные знания и workкflow.
Speaker A
Поэтому логично, что нам необходимо продумать правильно организацию файлов в пространстве, да, в файловой системе, чтобы наш агент мог в ней, а, ориентируясь, выполнять поставленную ему задачу. Ну вот здесь на примере, да, как это могло, как это выглядит у Гермеса. В
Speaker A
принципе, тот же самый подход, да, Agent, мы посмотрели, что GMES Agent Harness, у него точно также есть какие-то файлики Soul MD, да, с его идентичностью. У него есть скилы, есть вот event он там где-то хранит в state DB, но это event log старых сессий. Ну и
Speaker A
какую-то память он сохраняет в Memory MD. То же самое плюс-минус в Open Claw. В общем, любые харнесы. Теперь это вот такой формат описания аа каких-то файлов, да. Единственное, что мы здесь ещё забыли, что нам помимо всех знаний в
Speaker A
контекст мы ещё кладём описание всех инструментов. Это очень важно. А потому что понятное дело, что в контекст, в общем модели наш наш агент, да, наш сотрудник должен вообще понимать, помимо того, что есть в организации и знания организации, должен
Speaker A
понимать, что он может делать. И в этом плане мне очень нравятся последние подходы, которые возникают. очень, э, ну, я не знаю, в России, наверное, не шибко слышал, но вот на западном рынке уже начинают к этому переходить.
Speaker A
Например, вот EV от Версля, да, они это тоже такой очень удобный э фреймворк. То есть, по сути, о чём они говорят? О том, что агент, агент - это становится фиксированной структурой файлов, что бы он ни делал. А вот как раз agent
Speaker A
hardness - это там, где это всё будет запускаться и всё работать. Ну, как бы Версль, да, берёт на себя инфраструктурно.
Speaker A
А здесь, да, кстати, видно, что есть там моделька описана у них в AGНTS, инструкции есть у каждого агента, тулзы, в общем, всё описано именно статическими файлами, подгенты, всё, что, в общем, всё, что можно. Но возникает сразу вопрос: а разве мы можем вообще всё
Speaker A
запомнить? Да, и э контекст у модельки он не резиновый, да? И вот так уж выходит, что наш вот этот вот сотрудник, он какой-то очень хитрый. Чем больше данных ему даёшь, чем больше водных даёшь, тем дороже он нам обходится с
Speaker A
вами каждый месяц. А в целом, я, конечно, не знаю, рынок труда такой устраивает или нет. Мне кажется, надо вести какие-то ограничения на таких сотрудников. Да, чем больше данных получает, тем э больше мы должны мы платить. Возникает сразу вопрос, как нам
Speaker A
вообще все эти знания обработать? В принципе, в разных харнесах все по-разному пытаются обработать э те или иные форматы данных. Ну, понятное дело, самый первый - это некоторая суммаризация. А что такое суммаризация?
Speaker A
Понятно, многие с этим сталкивались. Как только мы сильно много общаемся с нашим агентом или evвент перерос, он начинает всё это дело сокращать, пытаясь освободить какую-то память и увеличивая то самое контекстное окно, через которое мы ему пишем сообщение. Ну, выглядит всё
Speaker A
это примерно так, да? Мы это можем опять же настроить. Например, в плоткоде можно сказать: "Сумаризуем на 80%, можно вообще не ставить лимиты", но тогда он, скорее всего, упадёт по финалу. А, отлично. суммаризуем. Что ещё можно?
Speaker A
Можно добавить offload. То есть в чём идея? В том, чтобы наш agent harness, да, наш агент, он должен, э, когда получает сильно много данных, например, вызов от какого-то тула, он вместо того, чтобы весь его поместить в контекст и
Speaker A
запомнить, например, мы ему чётко в нашем, э, вот в клод-коде, насколько я помню, по-моему, 10.000 токенов. Если у вас из тула приходит больше 10.000 токенов, он автоматически создаёт небольшой файлик. Что это позволяет? Ну, по сути, это как в том в Прата Крибском
Speaker A
море. Да, у меня есть ключ, нет, лучше. У меня есть рисунок ключа. Примерно так агента мы и делаем. У не у него висит рефа на результат тула, и если надо, он потом в неё сходит. Разумеется, чтобы сходить в это всё дело и посмотреть, во
Speaker A
всех hardnessв есть progressive disclosure. Кстати, clд, как только добавили у себя вот этот прогресиive disclosure, у них контекст, экономия контекста там стала до 80%. Ну, мы сейчас с вами ещё про другие методы тоже поговорим. Что это означает? Это
Speaker A
означает, что мы в контекст не грузим сразу всё, что можно. Мы, э, скилы, тулы, в общем, любые сторонние данные, мы их оставляем вне нашего основа контекста. Но при необходимости наш агент должен уметь найти эту информацию и получить её. По сути, мы всё время с
Speaker A
вами держим компактный индекс. Ну вот здесь я скину как раз те самые скрины, как это выглядит в скилах и в MCP, да?
Speaker A
То есть, если вы зайдёте и вам станет интересно, вы увидите, что MCP тулы теперь у Клода, они у него хранятся просто по ссылке. Кстати, странно, что здесь токены не подписаны. Мне казалось, там было раньше подписано, что там по
Speaker A
10-20 токенов. Ну, в общем, всё, что есть, он хранит как бы по ссылке и под агентов, и скилы, и не грузит всё это в рантайме. Ну, кстати, скилы, да, это тот самый теперь on demand загружаемый Мп, поэтому, я думаю, многие уже ими
Speaker A
пользовались. В общем, точно точно такой же хороший пример progressive disclogра, который загружается при необходимости.
Speaker A
Так, раз. Во. И мы с вами что ещё можем делать? Мы с вами можем оптимизировать ответ от тулов. То есть делать это опять же на уровне таком дискретном. Не пытаться анализировать, что именно он ответил, а пытаться как-то заоптимизировать, вырезать лишнее, а, и
Speaker A
и оставить только нужное. Ну, например, я вот здесь вставил, да, такой пример вызова РТК. Кто не пользовался РТК, знает такое Rastel Kit. О, много рук. Я вот не помню, там ещё какое-то одно выходило более популярное такое, что-то или как-то так называется, которой
Speaker A
больше, чем РТК, может токенов экономить. Ну вот здесь пример моего клодкода, у которого РТК стоит уже примерно, ну, за последние 8 недель. Я не помню, когда я его поставил, но это результат за последние 8 недель. То есть он мне сэкономил. Вместо 100 млн токенов
Speaker A
он оставил только 19 млн токенов. Причём из них вот там всё ушло, всякие грепы, да, в Amazon что-то копировал, линты и всё это понятно. А, отлично. Но я, в принципе, кстати, вот как поставил РТК, мне кажется, мне стало подписки намного
Speaker A
больше хватать. А, и последний - это прошлый будет такой более детерминированный подход, да, и мы много говорили, что есть как бы схематический больше, но мы можем попытаться именно оптимизировать ответы от модели. Для этого есть тоже разные скилы. Некоторые говорят: "Просто пишите
Speaker A
ему be brief". Вот это вот всё. Последнее время сейчас за стал популярный. Это тот самый cavem skill.
Speaker A
Не знаю, пользовался кто-то или нет. Я поначалу поставил его. Он мне, в принципе, как бы был о'кей, но через какое-то время я удивился. Думаю, как-то Клод странно пишет, как какой-то реально как реагент, там ходить сюда, сюда не ходить. Думаю, нет, думаю, ладно, верну
Speaker A
ему чуть более человеческое. В чём идея? В том, что в этом скиле прописано, чтобы должен оставлять только важное вот без вся всего вот этого, что он любит выдавать. Ну, он как там в примере, да, баг в midleвери проверь, там меньше
Speaker A
равно, больше равно, но тоже многие говорят, что очень много а экономят. Но если честно, надо прямо привыкать к такому клоду после всего этого дела получается, что контекст у нас - это некоторая инфраструктура, да, где мы её мы её должны хранить, мы можем знать,
Speaker A
как мы её должны обрабатывать, мы можем какие-то хаки придумывать для обработки. И контекст - это некоторая семантика, опять же, да? То есть мы можем оптимизировать, мы можем, э, ну, вернее, просить модель по-другому ответить, мы можем подтягивать или просить её
Speaker A
подтянуть другие данные. В принципе, тот же самый паттерн повторяется. Отлично. Получается, у нашего сотрудника есть рантай, инструменты, контекст, и вроде всё хорошо, но не хватает, да, вот что есть в любой компании, вот в любой корпорации, что есть корпоративная
Speaker A
политика, да, всё вот это вот на должна цель, он должен идти к великому. Поэтому мы давайте ему сделаем ещё и политики сверху. Э, ну политики, не в рамках именно что политики, а полисис как некоторые ограничения. Ну какое самое
Speaker A
популярное? Не очень-то хотели, чтобы наш агент, да, наш сотрудник выжирал все бюджеты и к нам не не возвращался с результатом. Поэтому давайте явно ему объявим лимит на какие-то итерации, добавим бюджетирование. Я думаю, скоро сюда добавится точно также аэ прямой
Speaker A
доступ к деньгам, да. Я думаю, что у каждого агента или у каждой там будет свой некоторые волет. А, кстати, из последнего вот я видел, что они уже такое тоже начинают добавлять. Ну, в общем, кто слышал все эти протоколы
Speaker A
X402, ACP, да, там MPPIN Pment протокол, в общем, всё вот это вот, я думаю, тоже скоро добавится к бюджетированию. То есть мы нашему сотруднику будем не только ставить лимиты на итерации и токены, будем мы ещё говорить: "Больше пяти баксов не трать". Следующее,
Speaker A
разумеется, все мы очень любим, когда мы поставили нашему стажёру задачу, он её долго делает и или ещё лучше делает её быстро, но возвращается к нам уже с финальным результатом. Мы не хотим, чтобы он нас постоянно дёргал, но тем не
Speaker A
менее, если он где-то, ну, задуплил, да, [смех] так говоря, мы хотим, чтобы он всё-таки к нам вернулся, а, и, э, попросил от нас какое-то подтверждение.
Speaker A
И опять же здесь тоже такая классная стата, что, э, вот этот Human in the loop, да, он нужен не для того, чтобы там вообще давайте харно сделаем, человека полностью уберём, он будет сам там крутиться. Нет, разумеется, мы хотим, чтобы в каких-то решениях
Speaker A
определённых агент всё равно к нам возвращался, да, чтобы он, если понял, что ой, извини, я что-то посмотрел, я поднял 40 серверов, я ожидаю, что он ко мне вернётся и скажет: "Слушай, не посмотри, не удалил ли я чего лишнего
Speaker A
или там я, возможно, снёс продовую базу данных и что ты будешь делать со мной?" Вот уволю. А и разумеется, некоторые гартрейлы. Гарртрейлы тоже делятся, по сути, на таком два фактора. Один более детерминированный, да, второй более сематический. Ну, первое - это,
Speaker A
разумеется, давайте настроим, про которые мы уже говорили, тестеры, линтеры, всевозможные тайп-чеки, в общем какой-то может структурный анализ, да, всё, что дёшево, мы в своих харнесах пытаемся настроить вообще по максимуму. Чем больше мы настроим, ну, тем больше будет, тем проще нам будет
Speaker A
валидировать задачу. И, разумеется, гартрейлы такие уже более дорогие, да, когда агенту необходимо пройти ревью другого агента, когда мы применяем тот самый LMS Judge, который должен подтвердить того, что наш там плреквест готов или не готов. Но эта вся вещь уже
Speaker A
как раз про семантику, она подороже. Получается, что харнес базово состоит из четырёх слоёв. Это некоторый runнтай нашего агента, где он трудится и работает. Это доступ к его инструментам.
Speaker A
Это правильно организованный контекст. И это некоторые политики. Если мы перерисуем её по той же схеме, про которую я говорил поначалу, да, что есть инфра, есть семантика, получается, что любая агентская обвязка, она по сути является инфраструктурной частью, да, где наши есть рантаймы, опять же
Speaker A
инструменты, которые где-то гоняются, и есть семантической частью. Сразу возникает вопрос: а что нам с этим делать? Вот мы знаем, что есть отдельная инфра и есть семантика, да, нам как разработчикам, куда мы вообще с этим идём и что будет дальше. И мне здесь
Speaker A
очень нравится, по-моему, это слайд от Бена Эванса, а, с его одного из недавних докладов, если я правильно называю фамилию. Здесь, э, количество строительства квадратуры, э, дата-центров по сравнению со строительством офисов в Америке. То есть мы явно видим, что где будут как раз
Speaker A
обитать те самые наши харнесы и наши сотрудники будущего, да. Поэтому мы понимаем, что - это не просто какая-то обвязка рукогента, а это корректно сформированная пространство, да, вот самое нетоксичное пространство в в компании, да, в команде, чтобы он мог
Speaker A
выполнять поставленные ему задачи. Поэтому, что нам необходимо? Нам уже сейчас необходимо проектировать задачи для наших агентов таким образом. Ну и в принципе всё его окружение, а чтобы он мог их без нашего вмешательства прямого решать, потому что, ну, никто не любит
Speaker A
микроменедже своих сотрудников, а особенно стажёров вот этих вот безбашенных. А-э, и всё, что, скорее всего, к чему мы придём, да, и все всё, что мы будем делать, я думаю, что будет выглядеть примерно вот так на рубеже ближайших пару лет. Раньше всё все
Speaker A
говорили, что оно компилируется, да, а сейчас, наверное, все будут бегать, заниматься своими вещами и говорить, что, ну, оно там агентится. А на этом у меня всё. Большое спасибо.
Speaker A
[аплодисменты] Спасибо. Спасибо большое, Артём. Так, настало время вопросов. Есть ли? Спасибо большое за доклад. Всё-таки вопрос: пытаться делать свои харнесы или всё-таки глубоко копнуть в имеющиеся вот эту тему? Подраскрой, пожалуйста.
Speaker A
Да, да, да, я раскрою. Я всё-таки стою на том, что поэтому я разделил, что вот есть инфра и семантика, да, если с точки зрения делать свои харнесы именно как вот инфраструктурную часть, делать свои тулы, свои лупы, идти настраивать
Speaker A
конекшн там ко всяким разным инструментам, то я бы сказал, что здесь надо пользоваться тем, что уже есть на рынке. Ну и благо openсорсных вещей, их очень много, да, поэтому мы даже там по сути делаем свой контролп для харнестов.
Speaker A
И я лично могу назвать очень много openсорсных конкурентов. И вот там буквально датабкс, да, там неделю назад выкатил тоже свою платформу по управлению харнесами. Поэтому я бы сказал, что мы не должны идти в написание именно инфровой части, нам
Speaker A
необходимо её поддерживать, но мы должны учиться именно правильно проектировать вот это пространство, чтобы агент потом с в нём смог разобраться и семантически решить нашу задачу.
Speaker A
Спасибо. Есть ещё? О давай давайте. А, спасибо. Очень действительно полезные вещи. А как ты бы предложил агенту дать ещё возможность ээ а или это делается просто через MCP, ну, иметь доступ к ээ к дополнительной информации? Это просто там он сам идёт, грубо говоря, к твоим
Speaker A
каким-то базам знаний, к какому-то конфренс или чему-то. Или он, допустим, как-то через какой-то рак там достаёт какую-то информацию, которая бы ему помогла в работе.
Speaker A
Да. Ну, спасибо за вопрос. Да, в идеале, понятное дело, что мы ему описываем способ решения задачи. То есть, если мы ему явно не описали: "Сходи в такой-то рак, да, или там, ну, если у него нет вообще информации, что ему надо куда-то
Speaker A
сходить, и мы ему не описали явно: "Сначала проведи какой-то реч, собери больше информации, найди практики, как это принято в индустрии", то, конечно, он этого не станет делать и пойдёт всё делать просто в лоб. То есть, чем больше мы сможем ему описать то именно, знаете,
Speaker A
вот как по бизнес-процессу, да, вот как по workкфлоу, что мне нравится подход, когда мы начинаем приступать задачи, кажется многим, что давайте мы просто агенту напишем, он сделает, да, как сделать хорошего агента, давайте напишем, он там сам напишет нам хорошего
Speaker A
агента, которого делает. Нет, мы идём сначала пытаемся разобраться в бизнес-процессе и как бы специалист решал эту задачу и потом организуем пространство, чтобы наш агент также решал. Если мы знаем, что специалист сначала посмотрел бы какие есть базы данных, какие есть знания, ну, значит,
Speaker A
надо это чётко зафиксировать. Либо там в скеле, да, на способ решения, а, ну, либо там вообще, возможно, сразу в Agence MD. Ну, то есть мы не ожидаем от того, чтобы он прошёл все флоow, о котором мы у себя как бы в голове знаем,
Speaker A
а ему не объяснили. Спасибо. А вот там я видел, да, молодой человек там был, да, он был вторым.
Speaker A
Да, спасибо большое за доклад. А у меня такой вопрос. Когда мы говорим про снбоксы для агентов, а кажется, что нужно делать какие-то гардрейлы для того, чтобы он там не сливал корпоративной политики, секреты или что-то ещё. Вот какие подходы тут можно
Speaker A
предложить в целом, чтобы обеспечить эти гардлейлы и лмкам не отправлять лишнего? Да. Ну я могу рассказать, каким подходом мы используем. Просто он уже маленько у меня не влезал в доклад, поэтому я эту часть намеренно убрал. Мне вообще нравится подход такой, что гартрейлы все
Speaker A
говорят, что там secкcюity, secюurриity. Я считаю, что в первую очередь нам именно важен governance, то есть управление. И поэтому, по-моему, как раз, если здесь есть коллеги с Гигачата, да, там со Сбера, вчера или позавчера Сбер выкатил свою платформу, там EVness
Speaker A
или EVL называется, по вот именно управлению харнесами. А, и и здесь точно так же по тому, по доступам, да, то есть мы не хотим пытаться заблокировать те действия, которые там агент пошёл плохие делать по Гартрейлу. Мы хотим их сразу
Speaker A
заранее предотвратить путём того, что мы просто на уровне вот этих вот гавон, да, управления доспами, мы ему это не разрешим. Ну, мы, например, у себя рассмотрели несколько подходов. Вот есть там рбаки, аки, всё вот это вот. Но эти системы не подходят.
Speaker A
Мы используем подход, relation based access control. И, грубо говоря, у нас каждый или что агент, какой доступ, к каким данным может получить, он, э, вот на уровне вот этих вот связей контролируется. То есть там граф связи появляется. Это, если интересно, можете
Speaker A
поподробнее почитать. Сейчас два проекта есть. в этой сфере основных open sourceных. Это от Ori Network, вот у них есть кето - это Open FGA, по-моему, называется Open Frain, что-то там такое.
Speaker A
Вот там очень интересно как раз написано, как в общем ответ краткий, да, лучше настроить не пытаться не предотвратить через секюрити, а лучше давайте будем делать и управлять к чему агент имеет доступ.
Speaker A
Спасибо. Так вот там был молодой человек в светлой футболке был, да? Спасибо за доклад. Вопрос такой: ну, Харнес он, получается, это что-то универсальное, да, но при этом очевидно, что есть мощный опус какой-нибудь и есть какой-то локальный сервачок на 2 Мб. Вот
Speaker A
в зависимости от мощности модели должен отличаться, нужно ли это закладывать туда? Да, ну здесь, смотри, получается жеха вот опус, да, модель она сама нам по сути не важна, потому что модель она работает. Вот говорю, что агент наш сотрудник, у него мозг лежит где-то там,
Speaker A
мы же обвязку можем гонять вообще в принципе хоть хоть там на девайсах. И поэтому а я бы не сказал, что нам прямо нужно как-то чётко вот больше выделять, а кроме случаев, когда ты знаешь, что у тебя агент может там запускать какие-то
Speaker A
высоконагружные сервисы, да? То есть, например, мы там наше вот приложение гоняем, и, разумеется, мы не поднимаем его на два CPU, один там RAM, но мы стараемся ему этот снbox всё кидать побольше, потому что мы хотим как бы end
Speaker A
to его проверять, не микроменджерить, но чтобы он запустил, прошёл по функциональным требованиям, посмотрел прокликал прямо сразу в браузере.
Speaker A
Конечно, тогда под такой флоу, но уже нужен побольше харнес. А если, ну, в остальном, то есть от модели же получается не зависит здесь всё. То есть это уже в инфру часть идёт, он остаётся.
Speaker A
Угу. Спасибо. Вот там сосед. Да, сосед. Спасибо за доклад. Очень интересна тема с инбоксинга. А мне кажется, она может быть не совсем актуальна, когда ты работаешь как такой промптнжениринг, да, ты сказал что-то сделать, агент сделал. Там, ну, не такой
Speaker A
большой разброс, что может агент натворить, да. Э, другая история, когда у тебя уже есть там какой-то харнес, который ты собрал, он работает условно с Ralf Lлуop, да, и он уже может бесконечно работать. У него могут быть ограничения там, ну,
Speaker A
закончи, ну, например, он делает какой-то resarch, да, и мы ему выставили ограничение: "Умри, перестань работать, когда наступит там 10 млн токенов суммарно, да, в цикле ты потратишь или там какой-нибудь тайм-аут".
Speaker A
Какие есть варианты с сэнбоксинга для решения таких задач? Потому что, очевидно, агент может пойти в различные стороны, учитывая большое количество итераций.
Speaker A
Очевидно, что может быть докер, но есть зафиксированные случаи, когда агент умел и выходить за границы с энбоксинга, используя там уязвимости докера и так далее. Что ты посоветуешь?
Speaker A
А какой снбоксинг использовать или есть вариант? Во, здесь интересно, потому что мы по сути свой имплементировали, но это ладно, да, есть всегда желание написать что-то своё, особенно с вап-кодингом, но я бы, наверное, в это не лез. По сути,
Speaker A
все снбоксинги, они сейчас устроятся на плюс-минус готовых. Вот есть A2B, да, он там строится на факрекере от амазоновской технологии. Есть от гугла на базе Gвизера, как раз есть всякие baseбоксинги, которые стараются, чтобы ты это сегодня делал. Последнее, я
Speaker A
помню, я, к сожалению, не помню точно, как называлась репа и от кого сделана. Вот я знаю, хорошее было от Алибаба, а выходил у них свой Sandbox. И вторые ребята, я вот, к сожалению, забыл название, но они очень быстро поднимают
Speaker A
инбоксы. То есть мне, в принципе, снбоксы нравятся те, которые, знаешь, в режиме serverless работают. При необходимости он поднялся, задачу сделал и потом как бы прекратил, например. А что-то на F, я не помню. В общем, они за, по-моему, 50 мскунд для тебя
Speaker A
поднимаются. Ну, а теперь получается для агента это важно, поскольку он может в баш пойти, и нам всё-таки для ответа важно, чтобы он быстро его поднял, а не по минуте ждал под в кубернетисе. Ну ладно, не минут по 10 секунд, по 30. Вот
Speaker A
поэтому какие-то вот такие подход, да, Дейтона. В общем, всё, всё на openсорсе, да. Желательно, желательно Open Source, желательно APCH, ну или МИ. Надеюсь, ответил.
Speaker A
Спасибо за вопрос. Так, вы там, молодой человек в в конце, да, в ближе. С краю.
Speaker A
С краю. Да, да, да. Скажите, пожалуйста, как вы определяете границы ответственности каждого конкретного агента? То есть, как вы определяете, нужен один агент тут или несколько, да, для разных классов задач?
Speaker A
Как структурируете базы знаний для них? Ну, то есть, а, какая-то общая база знаний, да, для всех агентов и какой-то там права доступа для них выдаются на те или иные части или То есть для каждого какая-то копия, да, база знаний, куда ему только нужно?
Speaker A
Угу. Да. Ну, здесь могу сказать сразу ответить, что поскольку мы позиционируем всю эту систему политиков и доступов как некоторое дерево, поэтому зависимости от того, какой как бы там на базе relation, да, она сделано, какая связь есть, какой сущности. Например, у нас есть связь,
Speaker A
как Таска, да, и можно дать агенту, например, доступ в какой-то определённый инструмент, но ровно на 1 час, или дать ему доступ на вызов этого инструмента с определённым параметром. Ну, то есть там довольно такой гранулярный набор. И как мы это структурируем? Ну, у разных
Speaker A
агентов, понятное дело, есть свои разные инструменты. Это всё, в принципе, мне кажется, уже во многих системах настраивается. Но мы ещё стараемся здесь зависимости от того, какая Idденти его вызывала, да, то есть как раз, если вызывал пользователь, то у него могут
Speaker A
быть одни доступы ещё на делегирование агентом. Если ему задачу дал другой агент через A2A, например, протокол, то у него может быть доступов меньше, потому что уже такая задача могла прилетать из какого-то неверифицируемого источника. Ну, то есть, в принципе, это
Speaker A
настраиваемое вот как раз на базе вот этого вот подхода с relation based accessминами. Спасибо. Вопрос у девушки на седьмом ряду.
Speaker A
Спасибо большое за доклад. Хотела поинтересоваться, я правильно понимаю, что если мы грамотно и жёстко написали харнес, то мы можем спокойно вытащить, например, старую джипетишку оттуда и ставить новую. И программа будет работать как бы без изменений, без старую GPюшку. Не, опять же, да, говорю,
Speaker A
что Харнес это он гово GPU вообще не имеет никакого отношения. Вот даже там мне очень нравилось, когда вот первое время убежал клодкод, да, всё-таки убежал и агент Clotдкод, и многие там вайп-кодеры пошли такие: "Сейчас я у себя запущу этот OpenCL код или что-то
Speaker A
такое называлось". А потом удивлялись: "А почему это не работает?" Ну потому что мозг, он как раз нашего агента, он и гоняется на GPU, а GPU находится где-то вынесено. Поэтому вот говорю эти харнесты, их по сути можно от них не
Speaker A
зависит только одно, что агент доделает задачу, ну и какие данные он получит. Всё остальное уже как бы там вызов самой ЛНК, он лежит за нашей гранью, если мы говорим про харнесы. Поэтому как бы факт смены GPU он никак здесь не влияет. Мы
Speaker A
можем даже в наш харнес пойти другую модель поменять и посмотреть, лучше она станет работать или нет.
Speaker A
Спасибо. Вот у молодого человека вопрос. Здравствуйте, Михаил. А спасибо за доклад. А мне кажется, вот предыдущий вопрос, не уверен, что был GPU. Там GPT бы тоже подошло.
Speaker A
А GPT можем? Да. Думаеш, собственно вопрос на предыдущем докладе, там одном из предыдущих говорили о том, что вот Сбер делал экосистему там вокруг моделей старых, да, а слабых моделей сильно шагнули и теперь им вот эта обвязка вся мешает. И вопрос,
Speaker A
собственно, как делать Харнес таким образом, чтобы он не мешал модели там в будущем через полгода, через год или каким образом адаптироваться под это? То есть какие-то маркеры, какие-то, не знаю, какие-то критерии. Да, интересный вопрос. Мне просто кажется, вот здесь подход к карнесам, он ещё
Speaker A
приводит к маленько другому пути в том плане, что мы сейчас пытаемся подоптимизировать всё это дело под большую модель, но как только мы переходим под оптимизации харнеста и оптимизации пространства под решение сдачи, мы сразу переходим уже ближе к вопросу слэмок, то есть маленьких
Speaker A
языковых моделей, чтобы они разбирались в отдельно взятом харнесе и задаче лучше, чем их а большие конкуренты.
Speaker A
Поэтому я думаю, что здесь скорее все будут переходить. Ну, Харнес он, в общем, интересный вопрос на того, что он мешает, не мешает, потому что можно в кулаарах объяснить. Я знаю такие харнесы, которые 50% своей работы отдают только на поддержание самого себя, а
Speaker A
задачу не выполняют. Такие тоже есть. Поэтому мы стараемся правильно именно, чтобы Харнес он был больше про семантику, да, её поддерживал, а инфраструктурный уровень мы стараемся не выдерживать наружу, ну как бы не поднимать наружу, чтобы не было такого, что агент там должен всё время спамить
Speaker A
задачи, делать сам себе проекты, подпроекты. В общем, на поддержание жизнеспособностихарства он не должен тратить много усилий. Надеюсь, ответил.
Speaker A
Спасибо. И вот последний вопрос у молодого человека. Да. Добрый день. Вопрос такой короткий. А какие метрики могли бы посоветовать, чтобы определить, что Харнес хороший или плохой вот в качестве ключевых?
Speaker A
А это хороший вопрос. Какие метрики посоветуешь? Ну бу-бу-бум. Ну я бы сказал так, в рамках агентов нас основное интересует, что нас интересует Taskition Rate. Да, если мы как ме инженеры, мы всегда заинтересованы в том, чтобы задача решалась end to end.
Speaker A
Мы не хотим заглядывать внутрь того, как задача работает. Мы ожидаем, мы дали все спеки и вводные условия, результат получили. Конечно, мы можем смотреть на количество потраченных токенов, если у нас стоит такая задача, но я бы в первую очередь смотрел на Taskition rate,
Speaker A
потому что чем меньше размывается наше людское внимание, да, тем больше, скорее всего, задач мы можем делать в параллели. Поэтому я, когда смотрел бы в Харнесе, я бы именно ожидал, что он должен делать задачу в первую очередь делать задачу, а второе за меньшее
Speaker A
количество шагов. Это, кстати, интересно, потому что недавно было сравнение вот этих, да, Джалма, по-моему, и, а, иклода, да, что там JLM 5,2, ей надо 80 шагов на выполнение той же самой задачи, когда клоду надо 60. Ну вот вот такие, в общем, я бы посмотрел
Speaker A
на Taskusion Rate. Ну и в принципе, мне кажется, это продовые метрики в большинстве таких систем.
Speaker A
Спасибо.
Topics:Agentic Harnessагентымультиагентные системыискусственный интеллектрантаймevent logКлодКодексинфраструктура агентовсистемы управления задачами
