Transcription
Итак, поехали. Кто я такой? Э- очень давно в индустрии из Белоруссии. Я, да, последние лет, сколько там уже восемь я технический директор, архитектор, э, фаo фаундер, делал архитектуру для разных больших проектов. А вклю архитектором Cordend мира. Вот с тех пор мне понравилась эта борда. А вот в мои интересы входит развитие инженера прежде всего, потому что я последние 2 с по года занимаюсь оббщением архитекторов fullтайм. А всего обучаю архитекторов я с девятнадцатого года, кажется, много уже обучал. Провожу курсы в рамках бренда Hardens of Skills для опытных инженеров. Мы много делаем интересного, связанного с, а-а, экспертизой любого рода в IT, от, ну, сейчас и я, и агентов, и прочего до классического старого доброго systemдизаign, аэ, и организационных возможностей изменений. Основное отличие того, что мы делаем - это не пересказ книг, статей или чего бы то ни было, а это опыт, опыт и сообщества, и мы, собственно, и участников различных курсов, которые мы структурируем и преподносим. Вот.
О'кей, поехали. А что такое агент? А я, ладно, я начну немножко с другого. В этой лекции я хочу показать, каков каким будет искусственный интеллект в будущем. Потому что в фантастике, а, ну, вообще во многих фильмах и так далее, у есть такая идея, что есть некий суперразум, а, который обрёл субъектность какую-то и начал что-то делать, тот же Терминатор и так далее. Вот. И я хочу донести такую мысль, которая противоречит этому мифу, о том, что суперразум будущего - это не единый такой мегамозг. Это огромный, сложный взаимодействующий рой множество маленьких специализированных программ, которые общаются друг с другом. И вот как именно они общаются с друг другом и как именно эти программы, использую использующие искусственный интеллект устроены, я сегодня и попробую вам рассказать.
Вот одна программа этого роя - это, собственно, и есть агент. А чем он отличается от обычного, не знаю, интерфейса, чата, чат GPT, гени или чего угодно? А потому что чат GPT может сделать рекламный текст, может написать код, но вообще-то этого мало. А потому что формат вопрос-ответного участия человек, поставить задачу, дождаться ответы, скорректировать результаты и так далее. А бизнесу нужно автономное достижение цели. Чатбот - это умный, как бы автоответчик для нас. Он может написать письмо для какой-нибуд транспортной компании. Вот подправлять его придётся вам Шамин. А агент - это некоторый сотрудник цифровой с какими-то полномочиями. Ему можно поставить задачу: "Решия проблему с задержкой там что-то логистики, транспортировки". И он сам поймёт, о чём речь. Он сам свяжется с транспортной компанией по почте, по API или как угодно и отправит клиенту письмо или наоборот заказчику, этому нашему подрядчику письмо и разберётся с вопросами.
Вот у такого агента есть три основных свойства. Первое - это независимость, автономность. Он действует сам на каждом этапе без ваших там пинков. Теперь сделай это, теперь сделай это, теперь это, теперь это перепроверь. Второе, он отвечает на изменение среды. То есть есть какой-то триггер в среде, аа, на которой он инициирует свою работу, на которую он реагирует. А вот, а, и третье, он достигает, пытается достичь какой-то цели. То есть он не просто там пишет какие-то письма в транспортную компанию, а он может сделать там какие-то действия, предложить другую транспортную компанию для нас, выпить оттуда скидку за задержку и так далее, и так далее. Вот. То есть это сотрудник, который решает какую-то очень узкую задачу, при этом у него есть какие-то полномочия.
А дальше я попробую раскрыть, каким образом это происходит. А каким образом происходит работа такого сотрудника? А модель LM - это мозг. Он может предугадывать токены. Вот как из предыдущих лекций. Он, по идее, принимает какие-то решения, делает текст, оценивает результаты и так далее. Вот. Но этот центр принятия решения как процесса в компьютере. Ему нужно сделать какую-то обвязку. Арнес помому, а чтобы ему приходили правильные решения, а потом его output, ему приходил правильный контекст, он делал какие-то решения, и эти решения были дальше каким-то образом воплощены. А вот есть ещё другие необходимые а компоненты этого агента, кото без которых он не сможет работать. Это память, как краткосрочно. Это контекст сессии, про который много говорили на предыдущих двух лекциях, и долгосрочные- это какие-то постоянные хранилища, которые содержит информацию, э, которая переживает в запуске завершения разных сессий.
А дальше, чтобы быть агентом, то есть, чтобы выполнять какую-либо задачу, агенту нужно ещё некоторые вещи, а уже более менее технические и больше привязанные к самой задаче. Это планировщик, а, который берёт большую задачу и разбивает её на кусочки. А, во-вторых, это инструменты. А то, что позволяет агенту изменять окружающую реальность, а доступ, MCP серверы, доступ к файловой системе, базам данных и так далее, и так далее. Ну и, собственно говоря, сами данные, которые находятся в долгосрочной или краткосрочной памяти, это контексты, документы, правила, примеры и так далее. без памяти. Агент, ну, собственно, беспомощен, потому что он не понимает вообще, что делать и как быть.
А вот, а как работает агент? А есть очень распространённый шаблон взаимо, ну, работы агента React, наверное, уже многие время услышали. Аа он рассуждает и действует. А он, значит, планирует своё действие, выполняет, выполняет действия, наблюдает какие-то результаты, которые случились, и рассуждает про эти результаты. И после этого запускает снова цикл вот этот вот plan обзерврект или говорит, что вот всё о'кей. А вот планирование, что нам сейчас будет нужно делать? А, возможно, вот это, возможно, вот это. собственно, выполнение этого действия, анализы и так далее. И потом мы приблизились к цели или нет? А значит, чем это отличается от prompt chaining, то есть вот цепочки запросов в чат, которые, например, отправляет человек тем, что цепочка эта фиксирована, она строголинейна, а цикл агента, он на каждом этапе может применять другое действие, собственно, совершая разные попытки, делая разные гипотезы.
А вот это то, как работает внутри агент. За этим достаточно много техники, которую мы покрывать не будем в рамках этого цикла лекций. А-а, но тем не менее принципиальный подход именно так. Это подход на уровне, ну, как бы смысла действий. Запланировать, сделать, посмотреть, подумать снова и потом снова запланировать. А вот, значит, и цикл Реакт - это попытка дать искусственному интеллекту способность мыслить медленно, последовательно, пошагово, а в мире, который о котором всегда не хватает информации, совершить один шаг, потом что-то посмотреть, что случилось, совершить следующий и так далее. Собственно говоря, мы сами действуем примерно так в той ситуации, когда у нас не хватает информации. Если мы идём в магазин, то нам достаточно линейного выполнения задач. А там одеться, выйти, закрыть дверь, спуститься в лифте, дойти до магазина, на зелёный переходить дорогу и так далее. И в принципе все шаги нам известны. Нам должны быть остаточно денег, условия, если дождь зансик и так далее. Но когда мы делаем задачи неизвестные заранее для нас, например, как сделать красивое и понятное описание, а что такое межатное взаимодействие, то приходится экспериментировать. Сначала я вот придумал какой-то план, смотрел на него, дал на оценку гемений, посмотрел, не понравился, придумал другой, что же выделять, что главное, как сделать проще. Вот и это вот цикл реакций. Подумал, сделал, посмотрел, снова подумал и сделал.
А вот агенты бывают разные по степени автономности, полностью управляемые, когда каждый шаг требует подтверждения человека полуавтономной, но и достаточно независимый. А от чего зависит этот как бы эта степень автономности? Если агент управляет какими-то крайне важными вещами, типа там какие-то финансы или какие-то дорогие операции, то человеческий контроль важнее. Если он делает что-то достаточно, а, а весовое, например, или менее важное, то нужно обходиться с меньшим количеством контроля. Вот.
А, итак, двигаемся дальше. Агенты могут краткий заход в сторону их их взаимодействия. Агенты могут а работать как вообще в одиночке. А это простейший агент, который работает по React и так далее. Они могут работать по конвейеру, когда последовательность задач более-менее понятна, но при этом в рамках каждой задачи мы даём агенту некоторую автономность. Агенты могут быть устроены иерархически. Регистраторы даёт задачу исполнителя. Исполнители, возможно, сами являются в рамках своей задачи регистраторами, дают задачу дальше и так далее. Подагенты, это маленькие, ещё более маленькие подзадачи для агенты, которые запускаются в отдельном окне. То есть это агенты, но ещё меньше. И команды агентов, независимые агенты, которые могут делать что-то каждый самостоятельно, независимо общаться между собой. А, собственно, про них самый большой интерес и про них будет в следующих секциях.
Вот практические примеры. агент, который делает какое-то резюме, агент исследователь, агент, который занимается плоем, например, для разработки софта, для review, поддержка и так далее. Но это больше про разработку софта. Но, в принципе, в какой бы области вы не работали, а можно придумать какие-то агенты, которые выполняют части вашей работы. А каж, ну, агенты хороши только там, где понятна цель. Если цель непонятна, то агент использовать аа стрёмно и вообще незачем. Вот. А примеры агентов, а, то есть вот эти вот роли агентов часто копируют какие-то роли, а, в которые есть в компании в бизнесе. Вот.
А, итак, при этом всём существует достаточно много рисков, связанных с работой агентов. Когда агенты взаимодействуют между собой или даже единственный агент пытается что-то сделать, а он может войти в бесконечный цикл. Он подумал, сделал, посмотрел, снова подумал, сделал. И эти действия, действия 1 2 3, начинают повторяться из-за какой-то логики внутри рассуждений, из-за какой-то ошибки внутри рассуждения агента, которая, скорее всего, вызвана ошибкой в предоставляемом контексте или в том, что он теряет информацию о каких-то предыдущих действиях или в чём-то ещё. И эти бесконечные циклы могут приводить к большим утратам денег на токены. То есть достаточно легко найти информацию про то, какая-то какой-то молодой стартап потратил за выходные 10.000 долларов на на токены за счёт того, что вот агент вошёл в бесконечный цикл. А вот если агент совершает а ошибку на этапе планирования, то дальше все его шаги будут неверные. А вот, разумеется, галлюцинации никуда не деваются, с ними нужно как-то бороться. вероятность жирца нации есть всегда. А вот то есть довольно часто агент, ой, не агент, а тот же чатботс при в ответ на просьбу найди мне примеры там тех же использования агентов для этой лекции, мне выдавали какие-то фантазии, которые выглядели очень убедительно. Только говорит: "Я не могу тебе выдать ссылку на на этот факт, потому что я это придумал". Вот тогда я прошу, тогда не придумай, ты найди. Вот. Кроме того, безопасность, а в смыс в том смысле, что не дать агенту испортить своими действиями какие-либо важные активы, ресурсы, которые у нас есть, чтобы он не перечислил слишком много денег, чтобы он не поудалял данные какие-то важные для нас и прочее, и прочее. Вот. А, и безопасности нужно уделять очень много внимания, в принципе, когда вы думаете про то, как спроектировать агента или агентов, а потому что, а, ладно, там мы потратим деньги лишние на токены, но если мы испортим наши данные или подведём нашего клиента, то, э, это будет гораздо хуже, чем потеря этих денег.
Вот. Значит, например, в 2003 2023 году, а в оставленные на ноч агенты, вот если вы знаете, gitub issue 6 в Open AI, а агенты тратили 500.000 долларов за ночь, потому что для работы с кодом не были выставлены какие-то ограничения. А или, например, Rйрм Lchain, который потратил 5.200 долларов на, а, то, на том, что агент пытался вызвать MCP, который обращал, отдавал ему 429 ошибку, то есть рейлими, подожди немножко, но агент не ждал, не интерпретировал эту ошибку правильно, а повторял снова и снова, а что вызывало постоянное сжигание токенов. 14.000 раз был вызван этот эти MCP, и счёт составил там, ну, довольно большие деньги а в рамках токенов. То есть там, где планировали тратить на токены там 4 доллара, получилось 400. Там, где планировали там тратить 5-10, получилось 5.000. Это довольно частая ошибка. Вот именно вот этот вот повторение. А вот есть история с агентом Реплит, когда агент столкнулся с бага, пытался его исправить, получил ошибку, пытался исправить и попал в бесконечный цикл, исчерпал базово доступные кредиты. И вернувшись там разработчик увидел, что там что-то слишком большие деньги были потрачены. Деньги эти не такие большие, это не миллионы долларов, но для небольшской компании, для одного человека они и они обидны.
Ну и самое главное то, что нужно лучше планировать и ограничивать агентов и их возможности. Значит, жёсткие рамки, количество повторений. Само собой, если мы не смогли сделать за 10 циклов Реакт нашу задачу, то, скорее всего, нам не хватает либо данных, либо задач нерешаемо и так далее. Ну, ограничение бюджета. То есть я на сессию агента одну на один запуск не могу тратить больше 5 долларов, 50 долларов. Вот Human. А когда мы перед потенциально какими-то вредоносными действиями, перед важными действиями требоваем подтверждение человека, а вот исполнение кода в изолированной среде, наверное, все про это знают, потому что агент может, а, очень хитро обходить те ограничения, которые ему выдаются. Вот. Ну, разумеется, логирование, чтобы было понятно, что вообще происходит. А критерии успеха перед финальным ответом, потому что если они расплывчатые, то агент может их достигать очень долго. Ну и связанный с МакстепS параметр, это не отправился за Макстеп шагов, то, в общем, давай иди к человеку и говори, что не смог, делай сам.
А вот значит фреймворки, а вот это, наверное, единственная техническая маленькаямаленькая часть, так, про которую я расскажу. Вот нграф - это по факту, а стандарт уже в индустрии агентского взаимодействия. А он позволяет и мониторить, и логировать, и деньги считать. Под него есть множество уже проектов и всего всего всесего. Есть QI, есть Pidentic, есть Google, а Development Kit для агентов и прочее. Вот. А здесь нужно очень сильно отличать два сценария при выборе фреймворков. А это если вы один или в небольшой компании, а то само лучшее, что вы можете сделать для выбора фриворка, сделать на нём QC простого агента и посмотреть, насколько вам понятно, насколько вам это интересно, насколько вас этот результат может устроиться. Если же вы в большой организации, то вам нужно учитывать огромное количество вещей: и стоимость, и безопасность, и compliance, и, а, персональные данные и так далее, и так далее. И тут нужно отдельная исследовательская работа, скажем так.
Вот это было проагенты. У них есть возможности, у них есть цикл Реакта, у них есть процессор, это модель, у них есть память, а у них есть риски, у них есть стоимость. Теперь переходим к немножко философской теме небольшой, каким образом решаются сложные задачи с помощью агента. А опять вот эта вот история, что как выглядит искусственный цели будущего, которые захватывает мир и так далее, это множество там тысячи миллионы небольших узконаправленных агентов. А они работают не как единый нос, который в себя всё включает, а они работают как рой, вот муравейник, пщелиной улей и так далее. Давайте немножечко рассмотрим про плины улия. Это очень такой интересный пример. У каждой пчёлки есть свои своя роль. Обязательно есть матка, которая вот самое главное, которая цель, она задаёт цель всему улью. Вот выживаем, у нас экспансия, мы защищаемся или что-то ещё делаем. А это разведчик, пчелоразведчик, который только ищет и не умеет собирать нектар. Это пчелосборщик. А значит, она летает по координатам, которые узнала у разведчика, и несёт домой пельцу. Но при этом она не умеет делать. И те пчёлы, которые работают внутри ули по какому-то сложному процессу внутри, делают из нектара мёд ещё кучу каких-то полезных других полезных людям вещей. Есть ещё там трутни, есть ещё, не знаю, там пчёлозащитники, кажется, есть какие-то и так далее, и так далее. А при этом обратите внимание, что каждая отдельная пчела выполняет довольно простую функцию. А если взять всего лишь одну пчелу, то безулья она, ну, ничего не сможет сделать. Она может найти цветы, но передать информацию о них будет некому. А она может принести, если это там сборщик, нектар, ну, куда нести и так далее. И главная мысль этого раздела то, что каким-то образом волшебным из системы, состоящей из простых, вернее, система из простых вот этих пчёлок оказывается больше, чем любая из них. При этом, а, сложность самой системы больше, чем сложность отдельной пчелы. Но при этом нигде никакой пчелы вообще нет такого места, где была бы записана общая концепция всей архитектуры улья и его жизни. Вот это очень важно понимать.
Сложность и новые функции. Результат находится не в рамках одного агента, который делает узкую задачу, хорошо, а в рамках взаимодействия агентов, то есть связи агентов, возможно, между агентами в коммуникации более важны, чем то, что каждый отдельный агент делает. Вот это называется эмержентность из системного мышления, системной инженерии. Термин - это такое свойство системы, которое возникает при определённом способе сложить её элемент. У каждого элементатного свойства нет. А их вот все сложили, оно появилось. Это работает при разработке программ систем. Это работает при разработке агентских взаимодействий. Вот именно взаимодействие агентов или там общемита для передачи информации создаёт ценность для нас. Вот. А для человечества это хорошая новость, да, потому что отдельный рой, в котором есть много отдельных агентов, гораздо безопаснее сутыру, единственного искусственного интеллекта за счёт изоляции ошибок. Ошибка остаётся в рамках отдельного агента. Она подвержена исправлению в узкой, а в узкой в рамках узкой задачи. Другие агенты не будут воспринимать ошибочную информацию или, ну, они же её будут предварительно валидировать, скорее всего, от неисправного агента. И поэтому ошибка чаще всего изолируется. И умным является сам процесс взаимодействия агентов, а не они агенты. Агенты тоже могут быть неповыми, но важно то, как они работают. А это а про то, каким образом можно делать сложные системы из простых компонентов. В коммуникации между агентами важнее зачастую самих агентов.
А так, значит, ага, вроде с интернетом всё нормально. Павел вроде больше не подлагивает. А тогда я продолжаю дальше, а, немножко больше уже в чуть-чуть в сторону от философии к реализации. A toa протокол. А если мы вспомним историю компьютерных сетей, то в семидесятых годах компьютеры, например, Абе могли общаться только с компьютерами EB. У них были свои протоколы, свои провода, и, э, они не могли общаться с компьютерами для других марок, например, с компьютерами ДЕК или там ещё с какими-то. А, и мир был, ну, как бы раздроблен, они не могли общаться между собой. Потом появился протокол CPIP, и потом сверху на нём ещё другие протоколы, связанные с интернетом, которые позволили обмениваться устройством вне зависимости от того, какого вообще типа это устройство. Это у нас телефон, компьютер или вообще какая-нибудь маленькая плата на нашем устройстве. Вот, собственно, интернет таким образом и появился за счёт универсального языка, обмена информацией, IPTP, а, его развития.
Вот. А то же самое, э, так, такую же роль играет AT протокол. А это то, каким образом агенты понимают, какие агенты вокруг них есть и какие задачи эти другие агенты могут выполнять. А MCP - это совсем не AA. Он предназначен для другой задачи. Это как агенту использовать инструменты заранее написанные, доступ к файлам, доступ к API и прочее. это, ну, как бы руки агента, аway - это род агента, который позволяет ему общаться с другими. Это довольно сложный протокол, а, который был, а-а, создан, кажется, Гуглом, и он в рам он выпущен под открытой лицензией, которую могут использовать все. А вот он сделан Google и передан в Linux Foundation. Так, в мартешего года, кажется, раньше что-то не так. Вот, значит, при этом ключевой принцип, также как и при HTTP и взаимодействии, а это непрозрачность. агенты не раскрывают друг другу свою внутренность, так же как взаимодействующие сервера или там наш браузер и какой-то сервер, не, а раскрывают друг другу свою логику внутреннего взаимодействия. Это ээ позволяет каждому быть в своём защищённом, как бы инкапсулированном и безопасном контексте, а не позволяя снаружи туда проникнуть.
Вот у протокола есть своя концептуальная архитектура. Это уровень данных, уровень операции и, собственно говоря, транспорт. А есть задачи, есть сообщения, есть их части, есть артефакты, есть описание агента и есть некоторые расширения. Есть операции для управления этими задачами. отправить сообщение, получить задачу, перечислить задачи, отменить какой-то стрим послать, ээ получить подробную информацию про агента. Ну и то, каким образом эти эти данные пересылаются между агентами, SSE, HTTP, RG, PCE, PC. Ну, в общем, слой может быть любой транспортный. Вот. А каким образом агенты находят друг друга и понимают, кому можно отправить задачу с помощью а agent card? Это сон, который описывает, что умеет агент. Этот агент может, значит, делать там поиск в интернете, что угодно. А он может там парсить PDF-файлы. Значит, вот тебе PDF-файлы и отдай мне результат. А вот список навыков агента, схемы аутентификации и, ну, и возможности. А когда мой агент, который решает какую-то задачу, ему нужно распасти там ПДФ, он находит в списке доступных агентов. Вот я умею партить PDF. И это даёт ему задачу. Процесс обнаружения других агентов и функции называется Discovery, Agent Discovery. И он полностью автоматирован.
Вот агенты обмениваются между собой задачами. Каждая задача - это свой собственный контекст, что очень важно. Они не перемешиваются. А у них есть история сообщений, у него есть артефакты. В каждом агент задача отрабатывают асинхронно, а в соответствии со своим жизненным циклом. Есть у него основные состояния. Отправлена задача, задача в процессе, задача завершена с разными статусами. А задача может быть rejected, ну, типа я слишком занят, мои мощности перегружены и пока не могу вам это. Есть промежуточный статус input required и авторизация требуется. А когда агент натыкается на ситуацию, когда он не может разрешить решить задачу из-за нехватки входных данных, он может послать вопрос постановщику задачи, то есть моему агенту, чтобы уточнить что-либо. Вот. И и мой агент, как клиент другого агента, как заказчик может получать статусы, может получать какой-то стрим состоянии сообщений, получается уш уведомлений и так далее. А есть три вида, э, собственно, кроны таск данных, которыми агенты обмениваются. Message а-а, понятно. место состоит из частей и часть - это, ну, текст, файл, в общем, нечто завершённое и артефакт, то, что получилось в результате. То есть это не пар какого-то сообщения, это более важная часть, которую можно передать другому агенту уже как, например, результат, один из один из результатов. Он может приходить по кусочкам, что может быть тоже удобно.
Вот. А задача для агентов - это стройки контракта. Верно, как вы, устраиваясь на работу, хочется верить, договариваетесь о своих божностных функциях, точно также агент обещает делать вот это, а вот всё остальное он делать не будет и не обещает. А вот точность описания, то есть управление через смыслы очень важно. А четыре элемента в этом описании должно быть цель, какие-то ограничения. А почему мы считаем, что задача решена? Ну и, собственно говоря, контекст, всё остальное, все данные необходимы для задач. Если не хватает, то input required. Так, кто-то подням руку или нет? Есть ещё, но мы его здесь не рассматриваем. Away более распростран а, собственно говоря, здесь мы подходим к очень важной части, которая касается, ну, вообще говоря, всех, а не только инженеров. Это преобразование смыслов. А сначала при разработке цепочки агентов, роя агентов нужно спроектировать преобразование смыслов. То есть вот у нас задача, вот её детализация, вот её критика, вот варианты решения и так далее. И только потом под эти, а, ээ, преобразование смыслов создавать агентов. Каждый агент в конечном итоге - это некоторый промт, который решает задачу. В этот промт приходят какие-то входные данные, и он что-то делает и наружу. А это преобразование смыслов доступно для проектирования любому человеку, который каким-либо образом хорошим разбирается в каком в какой-либо предметной области, будь то, не знаю, аналитика, разработка софта, проектирование, маркетинг, бухгалтерия или что угодно. А чем уже и чётче определённый агент, тем выше его качество. А сразу делать агенты, не проработав архитектуру смыслов, ну, не имеет смысла, потому что если у нас хаос, то мы можем его сделать автоматизированным, и он ничего не даст. Здесь находится ответ на вопрос менеджмента многих компаний. Давайте внедрять агентов. Давайте внедрять. И пока мы не определили для чего, как и какие смыслы эти агенты будут преобразовывать, это запрос на автоматизацию того хаоса, который есть в компании. И ни к чему хорошему он не приведёт.
Понятные роли крайне важны, так же как понятные должностные инструкции в организации. Самая простая аналогия агента - это сотрудник. Когда у нас 10 сотрудников, они как-то между собой работают. А когда у нас 350 сотрудников, они тоже работают. Но при этом их нужно как-то разделять по более мелким отделам, потому что общение 350 человек каждый с каждым, 350 агентов каждый с каждым, ну, ни к чему хорошему не приведёт. Будет больше потрачено времени на коммуникации, чем на результат. А вот и а у цепочки или у Роя агентов а есть два уровня тестирования качества. Один уровень - это а по качество каждого отдельного агента. То, что он делает, то, ну, что заявлено с такими-то ограничениями и прочее. И
второе — это качество работы всего роя, потому что вполне может случиться так, что каждый агент отрабатывает хорошо, а все вместе они отрабатывают плохо. Так тоже бывает. Наоборот, к сожалению, не бывает. Если каждый агент работает плохо, то все вместе будет точно плохо и хорошо может получиться лишь случайно на некоторых типах входных данных.
Как это применяется на практике? А, в принципе, вы можете взять любой процесс, который вам хорошо знаком, и расписать его как карту, как архитектуру преобразование смыслов, а для того, чтобы потом можно было положить это каким-то образом на агенты. Кто-то подключился или, в общем, что-то делает непонятное. А вот, а предварительная оценка заявок, а анализ чего бы то ни было. А значит, ну, это больше техническая вещь, когда разные агентские инструменты работают, а взаимодействие между разными бизнесами.
Вот важная часть для безопасности агентов, потому что мало ли кому я отправляю свои данные. А в ядро протокола ИТО безопасность встроена на разных уровнях. Базовая взаимная, а запрос дополнительных прав в процессе выполнения, которое может у клиента запросить, а аудит и прочее. Поскольку заточен, ну, заточен в том числе и под enterprise взаимодействия, то безопасность, аудит очень-очень важны и встроены внутрь.
Вот внутризадачная авторизация — очень интересная вещь, когда, а, например, давайте вот пофантазируем, аа я агент какой-либо компании обращаюсь к агенту банка с запросом перевода, а или с запросом, вот, например, пример информации о данных там моего о данных клиента моей компании. А вот, в принципе, у меня нет информации о том, как эти данные получить, но, например, а, и банк мне об этом сообщает, я могу сходить к своему руководителю, к человеку или к другому агенту и попросить его дать мне такие данные, такой сертификат, а, который позволит, ээ, банку предоставить информацию о своём клиенте. А вот, то есть я как агент могу запросить дополнительные права, и их мне могут как предоставить, так и не предоставить. Вот.
А, разумеется, здесь тоже есть, как и у агента, так и у взаимодействия множества агентов, есть аа подводные камни, риски. А это чем больше агентов, тем сложнее их взаимодействие. А если помните, из классической книги как пости котов, который уже очень много лет, там есть такой закон: добавление большего количества разработчиков в запаздывающий проект увеличивает срок проекта. Примерно так же, чем большее количество агентов не улучшает результат, не обязательно улучшает результат. Вот задержка на коммуникацию тоже является проблемой и риском. А её нужно отдельно, отдельно решать, а потому что агенты могут работать долго.
А трассировка, отладка. Почему этот трой агентов на эту задачу отреагировал именно таким образом? Где тот неочевидный, неявный баг на уровне взаимодействия или отдельного агента, который сделал решение не самым лучшим? Вот версионирование — отдельная задача. А потому что иногда требуется также, как с версионированием API, которые иногда нужно, версионирование агентов тоже может потребоваться. Ну и безопасность, связанная с доверием. Внутренние действия агентов, эни как никак не управляются протоколом. А для разработки есть множество SDK и инструментов и курсов, в том числе и курсов Hard Skills. И но это scope для этой этой лекции. Вот.
А значит, немножечко примеров. Вот тут ссылки на примеры межатского взаимодействия. А оптимизация supply and chain, вернее, ошибок supply and chain. В чём, ну, тут пример кода, это вот я скорее сюда перемотаю. Что здесь важно? То, что были какие-то проблемы в поставках и среднее время разрешения поставок в компании было вот много часов, три, больше 3 часов. А, то есть грузовики, какие-то фуры ждут по 3 часа, пока там людишки что-то там, какие-то бумажки друг другу носят. А в результате внедрения агентской системы для разрешения этих исключительных ситуаций, в общем, проблем этой бюрократии, а, произошло улучшение. Вот среднее время разрешения проблемы снизилось меньше чем до получаса. А улучшилась SL, то есть если раньше в него влезали 72% поставок, сейчас почти 100, что очень хорошо. Человеческого вмешательства требуется в три раза меньше. А, ну вот и и прочее, и прочее. И самое главное, упала цена на эту обработку ошибок, потому что раньше она включала работу человека, теперь стала включать работу человека гораздо меньше и больше инфраструктуры. И это не просто там, ну, это целые команды людей, которые передавали друг другу вот эти тикеты электронные. Теперь а часть этих тикетов и решения принимаются агентами. Ссылка на этот пример есть в презентации. Где-то вот здесь ещё один пример внесения вот оркестрации агентов. А вот можете посчитать интересные тоже вещи. О деталях не буду рассказывать, лучше на вопросы больше времени. Ну и вот ещё один пример, аа, а про парадокс продуктивности и вот как они эту штуку тоже сделали и улучшили свою жизнь. Вот. И сейчас идёт речь, если только сайт энтерпрайзов, то, что это следующий как бы уровень развития операционной системы для взаимодействия.
А вот и финальная часть перед вопросами, а экономика машин. Это тоже чуть-чуть пока ещё фантастики, но это очень близко. Агенты могут взаимодействовать между собой по открытым протоколам. Агенты могут публиковать себя не в локальном файлике на моей машине, а в каких-то общих реестрах, и обращение одного агента к другому может оплачиваться отдельно. Вот мне распавься эту пдфку, вот себе там 50 или 3 цента. И, пожалуйста, вот мне результат. А это очень интересная концепция, которая позволит, а, очень освободить очень много человеческих рук. Это одна из задач или вызовов или проблем. Вот микротранзакции, которые агенты могут друг другу платить. Агенты — это вот те самые цифровые пчёлы, которые делают каждую свою задачу быстрее, дешевле и качественнее, конкурируют между собой. Вот.
Ну и про роль человека. А что остаётся человеку? А здесь есть ответ. По крайней мере, для инженеров он более-менее есть. А для тех, кто хорошо разбирается в каких-либо областях, он тоже более-менее есть. А ни один агент не знает, что ему делать. Ни один агент не имеет видение. А человек, как тот, кто знает, что делать и для чего, может эти агент, может этими агентами управлять, создавать, а, и как-то их улучшать, обслуживать, вот, или вести их какой-то своей великой цели. И здесь для человека более ценным является его понимание смыслов, то есть глубина понимания бизнеса, предметной области, ограничений, целей и так далее. И каждый человек в состоянии ставится, собственно говоря, э вот с руководителем собственной команды агент. А человечество вот к этому шагу не приблизилось, ну, вернее, приблизилось, оно ещё его сделало в очень небольших объёмах, но оно будет делать его дальше. Вот. И мы, каждый из нас может вложить свой вклад, а, свой смысл и свой интеллект в то, что делать некоторое из этих машин, которые между собой взаимодействуют. Вот. А чтобы это сделать, приходите на наши курсы для разработчиков. А как использовать AI конкретно в разработке? и как использовать AI для разработки тех самых агентских систем, а с помощью Langchain React создавать отдельные отдельные агенты и взаимодействующих агентов с учётом всех необходимых для энтерпрайза вещей: поддержание качества, логирование, мониторинг, деньги, сколько это всё стоит, безопасность. А ведём курс. Вот очень грамотный человек в этой области Сергей. И и я тоже там, где дело касается архитектуры. Приходите, записывайтесь.
А вот а теперь перейдём к вопросам при регистрации. Для начала я отвечу на два вопроса, которые я заранее подобрал. А это вопросы больше про организацию, компаний Enterprise, которые работают с, а, а, которые хотят работать с агентами или уже работают, чем какие-то индивидуальные. Мне на них более интересно ответить, как преодолевать корпоративное сопротивление при внедрении инструментов, потому что многие не хотят искучиться и пользоваться. А есть люди, которых можно зажечь, есть люди, которых нельзя этим зажечь. Есть люди, которые смотрят в будущее и видят там себе применение. Есть люди, которые отбиваются от этого. А сейчас при внедрении AI нужно быть готовым к тому, что некоторые не смогут эту концепцию, в принципе, принять. Некоторые это примут, а-а, будут принимать дольше, чем остальные. Нужно понимать, что чем больше компания, тем меньше стимула у отдельного человека автоматизировать свою работу. Первое, из страха, собственно, заменить себя самого, что как бы адекватно для отдельного человека, но не выгодно для компании. А иногда проще сделать рядом похожую компанию. вырастить, если на это есть бюджет, чем преодолевать сопротивление текущей компании. Действительно, сейчас один сотрудник с, а с использованием там скилов или агентов, который может понимать, как использовать AI, он его эффективность увеличивается в разы, в какой бы области он не работал. А вот, а, учить, просвещать, вдохновлять, заставить вряд ли получится. На самом деле это сложнейшая вещь, которая и про изменение самой организации, и про изменение сознания людей. Если за изменение организации я как руководитель могу быть ответственным и могу на него влиять, то на изменение, на сознание людей я влиять могу крайне мало. Это нужно понимать. Лучший сценарий в моей голове, когда компания изменилась таким образом, что тем, кто не использую это я, в ней просто не остаётся места. И либо люди учатся, либо люди не учатся, и тогда они становятся ненужны в этой организации.
Вот ещё один вопрос про руководителей, про компании. Как изменится структура работы руководителя и уровня сетевого технического директора через год с учётом госместного внедрения АИгент? А, во-первых, людей потребуется гораздо меньше, а, потому что каждый из них будет более эффективен. А я думаю, что через год CTO всё ещё будут учиться сами, а как использовать искусственный интеллект саных разных областях своей работы, так и учить других людей внутри компании и внедрять это всё. А я не жду каких-то больших изменений, особенно в русскоязычном пространстве по а-а по изменению, по масштабному изменению многих компаний. Будут изменяться некоторые, они будут лучше конкурировать, возможно, вытеснять тех, кто не изменяется. А вот структура, как в целом, а руководитель уровня сетевого коммуникации больше всего, больше всех остальных действий так и останется. Просто тематика коммуникацией будет гораздо больше включать в себя AI. внедрение в процессы, обучение людей, подбор правильных людей уже с AI скилами. Пожалуй, пожалуй, так. А уже несколько лет ходят такие там слухи или ожидания о том, что будут отдельные единичные люди, которые, ну, предприниматели, которые исполняющих агентов искусственного интеллекта запустят единорогов. А, ну, наверное, некоторые двигаются по этому пути, но пока ещё не доросли мы до этого.
Вот так вопрос. Я в мира схемку Нет, в мира не воишки, потому что не очень удобно MCP для мира. Там либо очень мелких деталей нужно делать. Вот. Но мы планируем перейти из мира в другие в другой способ создания презенташек, чтобы это было с помощью а. Нет, это скорее всего будет просто какие-то странички в виде презентации. Это проще всего, поскольку, ну, я сам-то инженер всё-таки. и сделать презу в виде, ну, там, условно, сайтика, проще всего, потому что все эти Canva и остальные, э, они не позволяют настолько тонко управлять тем, что люди видят, и всё всё-таки эти, ээ, возможности отображения там ограничены. Вот легче найти новую организацию, а, учительничать, мочить. Артём говорит: "Не очень нравится мне это вот это вот эта фраза". Вот мне мне нравится фраза создать такую организацию, которая в которой люди либо найдут себя смысла, либо уйдут сами. Вот. А как вот да, спасибо, Юлий за за ссылку. Двигаемся дальше. Как самому создать MCP-сервер? Ну, использовать fast MCP на Питоне самое простое, наверное, уже стандарт. Для этого, ну, очень много технический вопрос. Autoscope. Самый эффективный метод экономии токенов. Самого эффективного нет. Всё зависит от контекста. При модели рогентов для каждого агента по-своему может быть. Кшировать токены можно не только в, господи, можно на уровнем, но есть множество способов оптимизации, и за 3 минуты я про это, э, не отвечу. Самое главное, нужно писать промты для этих агентов таким образом, чтобы они выполняли задачу дёшево. Это тоже один из один, наверное, лучший способ. Если оказывается, что на эту задачу эти промты слишком дорогие, возможно это не та задача или не тот масштаб вы дополнения этой задачи. Вот. При этом оптимизация вида поставить модель себе на инфраструктуру оказывается самой дорогой. Как разбить украйны контекст, чтобы не перебирать скагну и не забивать всё через рак. А, собственно, это вопрос управления смыслами, вопрос того, как разбить нашу приметную область на понятия и как эти понятия преобразовывать. Собственно, про это и есть вся вот то, что я назвал архитектурой смысла. Очень индивидуально для каждой задачи. Желательно, чтобы у нас были агенты достаточно простые, с небольшими контекстными окнами, которые решают свою задачу. Хорошо, интересно. О'кей, запись будет. Это под предыдущую лекцию вопрос. Вот рак — это кэширование на как это к ширование на стороне. Основа про кэширование, то есть много вопросов про оптимизацию. Если способ сделать более быстрым трящим токены и более частые повторяющие есть способ — это как посмотрите либо предыдущую лекцию, либо просто спросите много подходы по выстраиванию. Это вот я сегодня просто про концепцию рассказал. Это будет в более поздних лекциях. Безопасность мы сегодня чуть-чуть задели. Насколько выше больше расход на общении с на агентах, чем с ичатом? Да не насколько. Там же одинаковый месонизм. Как понять разницу? Непонятно. Хочу шарить. Ну вот, может быть, улучшилось ваше шаринги. Document driven development. Вообще вот сейчас безопасности при интеграциях, чтобы агент не получил лишний доступ к данными. А, ну если отвечать, опять-таки, это это очень много. И тут и как с PII работать, и с compliance, и часто компании ставят вообще перед тем, как данные, возможно, вовне отправлять, а какие-то специальные небольшие агентики, которые убирают и заменяют специальными токенами. плейсхолдерами, все там имена, возможны счета, названия компании там и прочее, чтобы на стороне ЛМ сторонней это было неопределимо. Вот. А чтобы не получил вешний доступ куда-нибудь, у агента в некоторых случаях не должно быть просто физического, технического доступа к тому, что что нельзя, потому что это последний вот этот вот уровень самый строгий. Если мы не хотим, чтобы агент переводил деньги, у него не должно быть такого MCP, у него не должно быть такой вообще технической возможности. Вот как реагирует рынок насекацию? Ну, насколько я знаю, хорошо реагируют рынок кого, чего непонятно, может быть, труда. А вот, ну, в целом хорошо, по крайней мере, это популярно. И то, и я вроде рассказал. с помощью AI, ну и гарантировать результат в 100% случаев на больших числах не можем. Мы должны понимать, где у нас результат получился, а где он не получился или плохой. А это данность, с этим нужно жить. Как выставить процесс, чтобы экономить на клад-код? Команда из трёхчетырёх разработчиков. Ну, господи. Э, спек дриндизайн маленький. Developen development, маленькие задачи чёткие постановки, э, максимально всё чётко. Чёткость сейчас приобретает очень большое значение, как поменять применять связку context, автоматизация написания. Да, тут же вопрос не в связке, вопрос в том, какие смыслы в какие мы преобразуем. А делаем мы это с помощью сонета, с помощью там, не знаю, гени 3.1 или это уже, ну, это уже вторично, на самом деле. А нужно смотреть не на LM конкретную, не на модель, не на любые технические инструменты, а сначала на то, какие смыслы в какие мы преобразуем, а потом уже и это класть на более удобную модель. Это, то есть, есть вопросы и от инженера про технику, а на самом деле он про постановку задачи, про смыслы там юзкейсы, да, это нужно предметную область принимать для этого там отдельные там описания должно быть, чтобы там какие-то направления развития нашего продукта, чтобы с кейсы новые хорошо получились и так далее. Вот, ээ, вот про это нужно думать сначала, а когда вы про это подумаете, то у вас будет там это будет работать почти на любом на на любой модели. И, наверное, это вот то первично понимание преобразования смыслов, чем то, каким образом оно реализовано. Так, практический пример, значит, а, пока не знаю, возможно, появляются, но вот такие публичные, которые можно использовать, вроде как нет. Так, примеры использования в бизнесе. Ну, снова это способы оптимизации. В каком бизнесе? Да для чего и casш, и Retrieval Advent. Это аа это разный инструмент. То же самое, что спросите, как применять гвозди в бизнесе. Ну, вообще-то существует множество способов, а в некоторых бизнесах это и не нужно. Тема в целом. Можно ли уровнем галюционирования качественно управлять? Ну, снизить до нуля теоретически нельзя, но валидировать, причём модели там, причём разными моделями вполне можно. Если какой-то конкретный агент должен, да, конкретно я надеюсь с пользователями, задавая ему там какие-то вопросы или получая подтверждение. Gнтикнь создание агентской среде. Тут я не знаю, что сказать. Перспектива речного тестировщика найти новую работу. Я вот про про работы я рекомендации давать боюсь, особенно по такому такой маленькой карточке. Если у вас опыта нет, нету нету опыта, но думаю, что принципы вообще совсем одинаковые. Преобразование смыслов важнее организовать работу с агентами и знать точно для чего как. Ну, снова я в рамках этой лекции для меня важно донести, что важно сначала спроектировать как какие шаги в нашей задаче, а потом уже класть на на любую технику. Какая техника, приходите на курс. Задачи между агентами. Снова то же самое. Это у нас есть предметная область, в которой есть какие-то процессы. Эти процессы можно выделить на куски. Это можно делать совершенно по-разному. А предметную область нужно порезать на понятия. Это тоже можно делать совершенно по-разному. И на и на основе этих понятий и этих кусков процессов можно уже дальше строить агенты. Адкод или сонеet или что угодно, вообще неважно. Как доверять агентам, какие компетеционные меры. Ну, тоже уровень безопасности. У меня должно быть доступа к тому, что нельзя делать humanop, ну и прочее. Анализигента, ну, в том же самом и прочее. Есть инструменты для отладки, для логирования, которые можно исследовать для мониторинга. Как создать модель, при которой я даю задачу одну и которая скат задачу. Ну, это типичный оркестратор, аэ, ну вот покупается в эту сторону. Почему агенты очень популярны? Ну, потому что это сейчас основное направление развития индустрии, а то и человечества. Потом запускают проекты. Ну, я концепцию какую-то рассказал сейчас. Организация взаимодействия каждой задача того вопрос про поружение в контекст. Передача информации между агентами. Каждый агент даёт своему исполнителю только то, что ему нужно. Да, команду за агентов, как вкатываться возможности менеджеров. А так связку антропи в качестве архитектора в качестве пси вроде неплохо для разработки. Antropic неплох для архитектора. В то же время Open A тоже неплох в качестве архитектора. Вот. Ну не знаю, почти за на все вопросы ответил. Спасибо, что дослушания. Вот ещё есть, а да, вот, э, экономия токенов — это реже всего переход на локальные модели. Локальные модели нужно поддерживать, это, вообще-то, дорого. Развие и инфраструктуры блокчейно. А, ну, я слышал, ну, какая информация просто закрытая, я не могу про неё рассказывать. А, ну есть проекты в этой области. Если агенты децентрализованы, как организуется работа со знаниями? Нужно единый банк знаний достаточно общего протоколаной памяти между агентами. Речь даже не про распределённую память, а про то, что а каждый агент даёт своему агенту, исполнителю или подрядчику нужное количество контента для выполнения задачи этого подрядчика. А не, то есть это не общий банк. знаний, да, это, ну, вот там технически это вот передача сообщений между агентами. Если мой планировщик, который разбил задачу на подзадачи и даёт одну подзадачу отдельному агенту, он даёт ему только тот контекст, который этому агенту для этой задачи нужен. И всё. Дмитрий, пожалуйста. >> Да, Павел, спасибо. Это мой вопрос. Я хотел бы уточнить. Вот у нас, например, есть разные разрозненные роли и разные разрозненные документы, да, там, например, там confinн Gra какие-то локальные файлы, там эксеельки, пдфки. А, и вот если мы создаём, ну, вот этот рой, да, и мы ему изначально какие-то похожие на существующие, значит, роли поведения, нужно ли иметь центральный какой-то банк знаний, где бы мог агент взять этот, э, свой, короче, контекст знаний, либо же это должен быть какой-то детрализованный и под его роль, скажем так, сформированный кусочек этой информации с его с его точки зрения, >> э-э, в моих фантазиях, я сейчас не говорю про best practices и прочее, потому что, наверное, их ещё тут и не особо-то сложились они. А централизованная вся информация полезна, если у вас есть какой-то достаточно высокоуровневый агент, которому она вся нужна. Например, централизованная информация про весь бизнес может быть нужна тому агенту с его погентами, аа который занимается развитием бизнеса, например, может быть. А, но такие вещи нужны редко, и я думаю, что развитие пойдёт по-другому пути. Там, где каждому агенту будет предоставляться только информация, которая ему нужна. А и а скорее, ну и скорее всего она будет предоставляться даже не через отдельные документы, которые где-то лежат, а через то, что агент-ркестратор возьмёт нужный кусок информации, зная, где лежит, и передаст конкретному, ну, другому агенту, погенту. Вот эта информация должна где-то лежать, чтобы её тот оркестратор мог там найти, наверное. А, ну, способов организации здесь, ну, в принципе, может быть много. Наверное, я очень равчето ответил. Ну, >> пока так. >> Да, спасибо за ответ. >> А вот, о'кей, хорошо. А-а, наверное, давайте на этом заканчивать. Презентация будет доступна в описании к видео к видео на Ютубе. А моей целью сегодня было очень максимально просто рассказать про взаимодействие агентов и что это может дать, не вдаваясь в технику вообще. На следующей лекции а я попробую такими же простыми словами рассказать про, а, внедрение AI в организации и про то, как этот AI может изменить процессы в организации. А всем желаю хорошего вечера. Надеюсь, вам было и понятно.