Лекция о самообучающихся AI агентах: оптимизация, процессы самосовершенствования и проактивность.
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
- Самообучение AI агентов требует системного подхода к сбору и анализу обратной связи.
- Оптимизация обвязки и памяти — ключевые направления для улучшения работы агента в рамках курса.
- Fine-tune модели — сложный и дорогой процесс, который не рассматривается подробно в курсе.
- Правильная организация файловой системы агента существенно влияет на его эффективность и интеллект.
- Проактивность агента — важная цель, достигаемая через автоматизацию и инициативу.
What the video covers
- Обзор принципов самообучения AI агентов и получение обратной связи для улучшения.
- Три основных слоя улучшения: fine-tune модели, обвязка (промты, скилы, инструменты) и память агента.
- Особое внимание уделяется оптимизации обвязки и памяти, fine-tune модели рассматривается как дорогостоящий и сложный процесс.
- Рассмотрение важности правильной организации файловой системы агента для повышения эффективности работы.
- Обсуждение циклов самосовершенствования: observe, inspect, eval и автоматизация ежедневных улучшений.
- Проактивность агента как высшая ступень развития, когда агент самостоятельно проявляет инициативу.
- Примеры практических сценариев, таких как управление контекстом сессий и оптимизация размера файлов.
- Рекомендации по работе с файлами и памяти, включая использование живых и мёртвых файлов.
- Введение в концепцию personal brain OS как операционной системы для AI агента.
- Обсуждение вызовов и ограничений, связанных с масштабированием и поддержкой больших систем агентов.
Chapters
- 00:00Введение в самообучающихся AI агентов
- 04:07Оптимизация обвязки: промты, скилы и инструменты
- 09:03Работа с файлами и памятью агента
- 13:02Автоматизация и ежедневные улучшения агента
- 18:24Структурирование знаний и управление скилами
- 23:17Циклы самосовершенствования и тестирование
- 28:48Проактивность и инициативность AI агента
- 36:10Заключение и ответы на вопросы
Full Transcript — Download SRT & Markdown
Speaker A
Всем ещё раз добрый вечер. Мы продолжаем наше занятие про самообучающихся AI агентов и, собственно, переходим к нашей непосредственной лекционной, так сказать, части, где мы поговорим вообще о самообучении. И давайте начнём вообще с понимания того, как это работает, да? То есть, а
Speaker A
вот у вас есть, да, реальные, ну, там пользователи, которые взаимодействуют, там, работают с вашим агентом, или вы, например, с ним работаете, и там агент какие-то логи, да, создаёт, делает определённые выводы, да, там, ну, которые сохраняются.
Speaker A
И вот дальше, да, у нас есть как бы первый этап — это, собственно, получение обратной связи. Хорошо ли отработал агент и или что он должен был сделать вместо этого, да? То есть это первый этап, да? То есть мы должны каким-то
Speaker A
образом это собрать. И вот сейчас дальше, да, там в течение нашего сегодняшнего занятия мы как раз будем это тоже разбирать. Просто пока хочу вам такую общую схему, да, вообще показать.
Speaker A
А и собственно, то есть первое, мы должны понять, а он вообще хорошо сделал или плохо сделал, как нам это понять, да, там как нам это определить. Потом, когда мы понимаем, например, что он что-то сделал не так, нам нужно понять, а какой
Speaker A
слой и какой компонент в нём, собственно, нужно заменить. И фактически у нас есть три вот таких слоя, да. Это мы можем или менять модель, или fine-tune модель. Мы можем менять harness обвязку, там промты, скилы, инструменты.
Speaker A
И мы можем также менять память, да? То есть там, например, вот скажем, а вот если брать такой какой-то очень такой типичный, например, скажем, вот сценарий, да, вот, допустим, как это работает в самом-самом таком упрощённом варианте, да, это, допустим, вы что-то
Speaker A
там ставите, допустим, крон-задачу вашему агенту, о этот крон исполняется, вы получаете результат этого крона, и он вам, да, там не нравится, он неправильный какой-то, скажем, например, а явно у агента не хватает контекста, да, чтобы чтобы на этот крон как-то
Speaker A
какой-то вам правильный ответ дать. И, соответственно, это вот это получение обратной связи, вы понимаете, что да, он отработал плохо, потому что у него просто нет контекста, да. И, соответственно, дальше вопрос, да, как нам это поменять? Мы понимаем, что а-а
Speaker A
раз у него нет контекста, то а это речь про, например, состояние сессии, да? И мы ставим просто изменяем, например, изолированную сессию для крона. Мы ставим на main, главную сессию. И теперь, когда мы запускаем, тот же самый крон, только он уже срабатывает не
Speaker A
в изолированном контексте, а в main, и всё, всё дальше в порядке становится, да? То есть, ну, это просто к примеру, да, вот в принципе вообще как идёт такой цикл некоторый мм улучшения, да, агента.
Speaker A
Значит, теперь давайте подробнее про вот эти три области улучшения, да, которые у нас в принципе есть. Это, ну, самое дорогое и самое, что мы не будем заниматься на этом курсе — это fine-tune модели. Да, там мы можем менять
Speaker A
модели, но, скорее всего, тоже мы этого делать не будем, если у вас 5 ише. Но там в некоторых случаях, да, люди делают fine-tune модели под конкретную задачу.
Speaker A
Это, кстати, сейчас вообще такая, знаете, начинается очень популярная, а, особенно в компаниях практика, когда вы, мы просто берём и можно дистиллировать, например, взять опус и посмотреть, как он делает какую-то конкретную задачу и дистиллировать вот выполнение этой конкретной задачи в маленькую, там,
Speaker A
например, там 20 или 30БМ. Так что это это это это такой довольно интересный вариант. А, но мы этого не будем делать, потому что это сложно. А сложно, дорого, и это такая прямо отдельная история. Значит, harness обвязка — это промты, изменения, да, там
Speaker A
изменение скилов, изменение инструментов, там, может быть, какие-нибудь скрипты, да? То есть это вот как раз то, что мы больше всего будем делать, да? То есть мы больше всего будем работать как раз по сути с обвязкой.
Speaker A
И также есть ещё оптимизация, а, памяти, да, то есть как раз вот там, где хранятся какие-то факты, да, там наши все вот эти файлы, а файловая как бы система вашего агента. То есть вот это всё тоже очень очень здорово можно
Speaker A
оптимизировать. Тоже мы сегодня поговорим, как. Так, сейчас буквально на секундочку исчезну. Момент. Да. Так, я вернулся, значит. А, да, то есть вот эти такие три области больше всего мы будем работать именно с оптимизацией обвязки и плюс, может быть,
Speaker A
да, там с памятью тоже поработаем. А как вообще работает, ну, как бы такой самосовершенствующий и проактивный OpenClo, да? То есть можно сказать, что всё начинается с, а, первой ступени — это правильная работа с файлами, да? То есть это правильная
Speaker A
правильное вот это делание файловой системы вашего агента. А, плюс там правильно поработать живыми и мёртвыми файлами. Поговорим об этом, что это такое. И, возможно, в некоторых случаях имеет смысл сделать графы навыков вместо обычных скилов. Это тоже в некоторых
Speaker A
случаях интересная штука. То есть это вот первая на первая наша ступень будет такая настройки, когда мы оптимизируем все вот эти вещи. Вторая ступень — это, собственно, непосредственно процессы самосовершенствования. То есть, например, там классический цикл observe, inspect and eval. Это означает, что
Speaker A
цикл как бы сначала аэ наблюдай, да, потом, собственно, инспектируй, как бы анализируй результат, внедряй его, да, куда-то имплементируй и L как бы это тестируй. А-а ну соответственно, это как бы тестируй и анализируй как бы результаты.
Speaker A
И плюс можно сделать там различные автоматические ежедневные или еженедельные улучшения и даже запустить вашего агента как такую лабораторию. Тоже сейчас об этом поговорим.
Speaker A
А, и третья ступень — это проактивность, да? То есть, соответственно, это мы делаем так, чтобы агент сам сам проявлял инициативу. И, ээ, соответственно, тоже об этом сегодня поговорим. То есть, по сути, это вот три наши сегодня главные темы. Это сначала
Speaker A
мы поговорим про такую оптимизацию его файловой системы, потому что это очень важная составляющая. Потом какие есть алгоритмы и вообще способы самосовершенствования его. И потом поговорим про проактивность. И давайте начнём как раз с а файловой системы, потому что это,
Speaker A
пожалуй, такая одна из самых мм важных вещей. И мне в этом плане очень нравится цитата, что модели достаточно умны, они просто забывчивы. И это, кстати, на самом деле абсолютно верная фраза, потому что если выстроить модели хорошую память, правильную память, то
Speaker A
это, конечно, её интеллект по-настоящему раскрывается. Сейчас момент. И в то же самое время, если вы пустите, например, это на самотёк, да, то есть, скажем, а вот как вот довольно такая известная была история Мэта Ванхоорна, ну, это такой человек
Speaker A
вообще тоже популярный в AI, когда он рассказал, как он, ну, просто вообще перестал следить. Да, что вообще у него там происходит с файлами и памятью его агента, да, и у него там вся система разрослась быстро, до 21 файлов. И
Speaker A
просто в какой-то момент это просто всё перестало вообще влезать в контекстное окно. И harness, да, ну, OpenC, он просто взял как бы стал обрезать очень сильно все эти файлы. И человек даже не понимал, что вот его прекрасные эти
Speaker A
большие файлы, которые как бы полны информации, на самом деле они обрезаются и большая их часть просто не попадает в OpenClo. Кстати, просто имейте это в виду, что такое может произойти. У меня, кстати, такое тоже было, когда я вот
Speaker A
только себе создал OpenC, и я там с ним первые, наверное, недели две-три поработал. И потом я полез смотреть, а что у него там сейчас, какая ситуация с файлами. И там просто все файлы гигантского размера.
Speaker A
А, и все эти файлы нужно оптимизировать, конечно, по размеру. И из чего строится вот эта такая personal brain OS? Но это имеется в виду, что как бы файловая система как операционная система агента. В принципе, это уже уже так работает. А уже уже так
Speaker A
работает, как бы, в самом OpenClo. И вот Елена спрашивает: "А где их смотреть, эти файлы?" А, ну, во-первых, вам не обязательно их смотреть, да? То есть вам совершенно не обязательно вручную их править, да? Вы можете просто у кодекса сказать, что там сходи,
Speaker A
посмотри. Но, в принципе, вот эти все ключевые
Speaker A
никогда их не правлю. Ну, то есть я просто там спрашиваю или самого Openклона. Лучше такие вещи кодекса спрашивать, чтобы он пошёл там посмотрел и сказал, что у него происходит.
Speaker A
А, и в принципе вот система, которая есть у OpenClow, она уже на самом деле а рассчитана под такой формат файловой как бы системы агента. И там уже есть, да, там SoulmD, User MD. Некоторые люди, некоторые люди к этому добавляют ещё
Speaker A
третий файлик и называют его типа principles MD, да? То есть это принципы MD и как бы разница, да, между вот этой там, например, а, скажем, Soul MD или, а, Principles MD, она такая немножко субтильная, потому что, а, ну, вот те
Speaker A
люди, которые любят как бы принцип SMD создавать, они говорят, что вот в этой вот в этом файлике мы описываем именно а по каким принципам агент должен принимать решения. То есть они считают, что это как бы вот отдельная вещь. Я м
Speaker A
как бы немножко не сказать, что я прямо так такого мнения придерживаюсь. То есть мне кажется, вы можете в принципе это прописать и в SOLMD, и Agents MD.
Speaker A
Это так или иначе как бы тоже сработает. А инструкция, как действовать, это AGSMD, стандартный файл, навыки, да, которые есть у вашего агента.
Speaker A
И вот мы сегодня тоже поговорим про графы навыков. Это тоже такая интересная штука. А дальше идёт как бы знание, да, то, что он знает. И вы уже у вас как бы уже там более-менее настроенная память.
Speaker A
И вот эта пара, да, система тоже projects areas resources archives который, помните, мы тоже обсуждали на занятии про память. А вот что к этому можно добавить, чего у вас ещё скорее всего нету - это аа журнал, что он пережил, да? То есть,
Speaker A
например, можно создать decisions MD- это файлик, в котором он будет складывать свои решения, альтернативы и результаты и failors, то есть ошибки MD, а где он складывает, собственно, свои какие-то ошибки, их причины возникновения и предотвращения. И вот тут такой важный момент, что
Speaker A
практический опыт показывает, что лучше всего эти файлы делать такими, а чтобы агент их мог только только добавлять туда, но не удалять, потому что агенты, ну, опять-таки практика показывает, что агенты склонны, например, вот Failers MD, они могут такие: "Ну да, это давно произошло, и мы
Speaker A
сейчас это просто удалим". им, да, как бы, а лучше тогда им просто не дать чёткую инструкцию. Ты не можешь ничего удалять из этих файлов, только добавляй.
Speaker A
А если что-то стало уже неактуальным, а то, соответственно, тогда сделай, а-а, поставь это как бы, что это уже как бы не актуально, да, что это устаревшая информация. И вот Дмит спрашивает: "И как ограничить редактирование файлов только а на добавление?" Смотрите, это,
Speaker A
ну, как бы есть два подхода, да? То есть, ну, давайте так. Есть простой подход, есть более замороченный, сложный подход. Значит, простой подход заключается в том, что, ну, вы можете просто хорошо прописать про Мpт. Ну, то есть просто в его,
Speaker A
например, в его Agence MD, а или, ну, в принципе, наверное, наверное, в Agents MD это лучше всё прописать. Можно ещё в Tools ND, но лучше всего agent MD.
Speaker A
И там прямо просто прописать, что так и так. Вот в этих вот в этих файлах ты можешь делать только ты можешь только добавлять, но ты не можешь ничего оттуда удалять. И на самом деле, а, мдели типа там GPT 5,6, они прекрасно с
Speaker A
этим справятся. То есть они в целом прекрасно поймут, ну, вот ваш вот этот приказ.
Speaker A
Да, то есть, то есть тут как бы проблем с этим не будет. Но если вы прямо хотите сделать так, чтобы это было запрещено на программном уровне, да, чтобы это чтобы этого, ну, не происходило, то здесь есть несколько разных путей, скажем так, это сделать.
Speaker A
Вот что мне вот так сейчас ходу приходит в голову. Например, вы можете поставить хук. Хук - это, ну, как бы исполняющаяся вещь перед, например, например, перед каким-то действием. Оно может быть после действия, оно может быть там в разных
Speaker A
ситуациях. Вы можете создать хук. То есть, например, если агент что-то делает, то есть он хочет совершить какое-то действие, у него срабатывает хук, который проверяет, что это за действие. И вы можете в этом хуке прописать, что если это действие, а,
Speaker A
например действие скажем, удаление как каких-то какой-то каких-то строк, да, там из, например, вот этого файла, да, там на надо просто подумать, как это лучше как бы технически сформулировать, а то, соответственно, как бы это запрещено, например, сделать. То есть можно толь,
Speaker A
то есть как бы ну там всё равно как бы есть способы, я думаю, как это можно такое обойти, потому что он может как бы не удалять, а менять. Ну, то есть там разные есть варианты, но это, например, как один
Speaker A
пример. Там другой пример, если вы уж прямо реально хотите, если уж вы прямо реально хотите, ну, вот чтобы чтобы это так было, то, ну, тогда просто не ведите это одним файлом, да, просто ведите это, например, э, скажем, там каждая какая-то ошибка или каждое
Speaker A
там решение - это отдельное создание файла. И там буквально просто ему прописать тогда в его аа вот этом OpenCla Jon, что ты не можешь удалять файлы из этой папки, да? Ну, например, ну, то есть это такая штука, это такая
Speaker A
инженерная задачка, да, но на самом деле в большинстве случаев просто прописать промт будет достаточно. То есть он современные модели хорошо этому следует.
Speaker A
А Не, Дмит пишет: "А кто выполняет хуки?" А, смотря, что это за хук. То есть как бы хук может быть просто скрипт, да? То есть, скажем, скрипт, который проверяет, допустим, это является ли это там, скажем, таким-то действием в такой-то папке. Если
Speaker A
является, то просто на уровне кода это не выполняется, да, это действие. То есть это такой это, то есть хуки - это обвязка, это не инструкция агенту, а именно обвязка, которая запрещает что-то делать на уровне кода. А другой вариант,
Speaker A
можно, но при этом в Хуке, в Хуке при этом можно, кстати, встраивать и lм вызовы.
Speaker A
То есть вы можете встроить, что обвязка вызовет LM и спросит, это типа нормальное действие или нет. Но это уже очень замороченные системы, то есть такое прям я не думаю, что ради ради вот такого это стоит разводить, но в
Speaker A
принципе в принципе можно. А и чем ещё тоже интересна эта философия, да, вот если вы правильную вот такую файловую систему создадите, а по сути папка, да, - это и есть ваш агент. Это такая довольно забавная идея, но это на
Speaker A
самом деле реально так. Вот буквально ваш агент - это просто папка этих файлов. Вы можете эту папочку перенести в другого OpenC, и он станет вашим агентом. И всё. То есть вот это такая довольно забавная концепция, но это реально так, да? То есть это вот агент,
Speaker A
это буквально это вот эта папочка с этими файлами. А Дмитрий пишет: "А я что-то подзабыл, а как их создавать прямым указание в чат". Ну, во-первых, все базовые файлы, они уже созданы, да?
Speaker A
То есть и у него есть как бы прописано, для чего ему эти файлы нужны. То есть он об этом знает. То есть вот эти все Soulm MD, user MD, agents MD, а-а, это всёвсёвсё как бы у него по умолчанию
Speaker A
есть и он это знает, как использовать. Но если вы хотите какие-то дополнительные создавать, то попросите его, да, просто создать такой файл и попросите его там, например, в AgentMD прописать, а что это, собственно, за файл, да, для зачем он нужен.
Speaker A
Ещё одна очень важная вещь, да, то есть, если мы тоже говорим про наведение порядка, да, как бы вот в этой всей штуке это а конечно бюджетирование, да, вашего контекста. То есть, во-первых, имеет смысл навести порядок ваших вот этих всех системных
Speaker A
файлов, потому что вы уже сколько у нас уже больше месяца, да, работаете с OpenCla. И имеет смысл посмотреть, а у вас вот эти вот agents MD, Memory MD, Soul MD, они вообще какого у вас размера? Как бы в идеале и хорошо бы их
Speaker A
иметь там в районе там меньше 200 строк на файл, но это в идеале. Скорее всего, у вас больше. А там есть какой-то лимит. Сейчас я просто у меня из головы он вылетел. М лимит на какое-то количество символов, после
Speaker A
которого они вообще начинают обрезаться. Там, по-моему, семь или восемь, по-моему. Ну, где-то в этом диапазоне 7-8.000 символов или до 10.000 символов.
Speaker A
Ну, в общем, после этого он вообще обрезается. До такого тоще нельзя доводить, но желательно и не раздувать, то есть, а, это такой же принцип, как с, а например там ну собственно agents MD в агентах кодинга или clД MD в аген у
Speaker A
клода. А, то есть принцип такой, что вам лучше, чтобы в этих файлах было больше ссылок на другие файлы. То есть не писать, да, что там, а, гору информации, а лучше, если есть какие-то там дать ссылки там, а вот про
Speaker A
это читай в этом файле, а про это читай в этом файле, и он получит ваш вот этот agents MD автоматически в контекст, и если ему надо, он пойдёт и прочитает этот файл, да, то есть, если ему это нужно будет. Поэтому оптимизация вот
Speaker A
этих файлов, да, это хорошая штука. Опять-таки, вам не нужно делать это вручную. Просто, ну, с кодексом обсудите это. Пусть он посмотрит, сколько у вас сейчас занимает места. Пусть в интернете поищет там лучшие принципы практики оптимизации таких файлов. То есть это не
Speaker A
секретная информация, это уже в интернете её много. А и также есть файлы, да, которые, соответственно, агент подтягивает по требованию, да, там меory файлы, а там всякие джейсоны.
Speaker A
А и вот здесь интересная штука - это графы навыков. Сейчас мы об этом тоже поговорим, да. Это когда вы можете ещё такое прогрессивное как бы раскрытие скажем так групп навыков, то есть скилов сделать.
Speaker A
Но сейчас мы к этому а придём. Пока давайте про вот эти вещи поговорим, которые мы сейчас обсудили. То есть как это сделать на практике. Что я вам рекомендую сделать? Значит, первое, сделайте аудит файловой вашей системы, да? Правильно ли ведутся у вас все
Speaker A
файлы, каким размером вообще у вас файлы? И заведите журнал решений и ошибок, да? То есть вот вот такая вещь.
Speaker A
Давайте попробуем это сделать. Я сейчас, А, ну можно это такие вещи, на самом деле, ну давайте так, давайте это можно как бы и самим OpenClow вашим обсудить, но давайте я сейчас я сейчас пойду и лучше через кодекс это
Speaker A
сделаю. Так. М. Давайте, значит, надо подумать, с какой прежде всего, с какой моделью будем работать, потому что теперь это прямо большой вопрос. А, скорее всего, я, наверное, попробую хай, потому что вот пока я пробовал такие как бы не слишком сложенные задачки, но
Speaker A
которые требуют всё-таки хорошего размышления, я ставил хай. Хай - это прямо он уже надолго уйдёт, это уже займёт много времени. Поэтому хай или medдиум вот для таких задачек, я думаю, вполне себе подойдёт. И давайте попробуем, значит, его сделать несколько
Speaker A
вещей. Сейчас мы ему надиктуем. А вообще можно, ну ладно, давайте мом скриншот кинуть, но ладно. А знаете что?
Speaker A
Давайте попробуем. Давайте ему попробуем сейчас. Во. Аsot. То есть apps - это вы нажимаете, ну вот на маке это оба команда нужно одновременно нажать, и он делает скриншот. А как бы это не просто скриншот, а это именно скриншот. И плюс
Speaker A
вся дополнительная информация как бы из из этой программы. Вот сейчас я из своид сделал. И что я ему скажу?
Speaker A
Посмотри, что у меня здесь написано в разделе аудит файловой системы и журналы решений и ошибок. Значит, что тебе нужно сделать? Во-первых, проведи аудит файловой системы, как у меня реализовано. Вот тут на скрине ты тоже найдёшь, а какие там принципы есть для
Speaker A
этого. и сделай аудит файловой системы. Правильно ли у меня все вот эти ключевые системные файлы, не слишком ли они разросшиеся, да, не нужно ли их оптимизировать. А после этого сделай в моём OpenC, то есть подключись к нему по SSH,
Speaker A
соответственно, и всё это делай прямо на нём. И создай decisions MD file, failers MD.
Speaker A
в Decisions MD. Пусть он записывает решения свои, альтернативы и результаты. Failers MD ошибки, какие у тебя были причины их и как ты их, как их надо предотвращать.
Speaker A
А припиши в agents MD своём файле, для чего эти Decisions MD и failers MD нужны, как они работают. обязательно пропиши, что туда информация только добавляется, но не удаляется, да? Аа потому что, чтобы у нас как бы сохранялась вся история.
Speaker A
И также создай ежедневные кроны анализа этих журналов. То есть каждый день ты должен вечером анализировать decisions и failures и думать, например, что бы можно было бы улучшить, какие, может быть, скилы создать, скилы изменить, может быть, какие-то инструкции у себя
Speaker A
поменять, да, что каждый вечер думай, какие можно вещи, исходя из вот этих новых записей, да, там записи тоже, наверное, лучше датировать каким-то днём. И, э, соответственно, какие уроки из этого можно извлечь. Если ничего не надо извлечь, пусть Крон просто молчит
Speaker A
мне. А если что-то можно, напиши мне в Telegram и предложи, чтобы ты поменял. И сейчас я ему ещё раз скажу. И, соответственно, всё это делай на моём OpenClop, подключившись через SSH к нему.
Speaker A
Всё. И мы, соответственно, его вот так отправляем. И он сейчас у нас всё это создаст.
Speaker A
А дальше, да, у нас есть такое ещё понятие, как система живые файлы и мёртвые файлы, да? То есть, что это такое? Значит, мёртвый файл - это любой файл, который ждёт, пока человек его, собственно, откроет. И он может, например, там лежать в
Speaker A
ноутбуке просто у вас где-то в облаке просто этот файл лежит. Или, например, это там мёртвый файл, это который только вот просто он этот файл, который, например, вы как-нибудь кинули в историю чата, но да, но больше он нигде как бы
Speaker A
для вашего агента не сохранился. А есть живые файлы. Это те файлы, у которых вот ваш агент знает о их существовании, они ему всегда доступны, и он их читает, обновляет и использует их. И вот примеры, да, например, этого, это, скажем, вот вы с ним о чём-то
Speaker A
общаетесь, да, и, допустим, вы с ним провели какое-то исследование, и обязательно ему скажите, да, то есть, что, а, сохрани его как бы в какой-нибудь MD файл, да, то есть не дайте ему просто вот остаться частью вашей истории чата, опять-таки, а это не
Speaker A
обязательно напоминать, да? То есть вы можете, например, там в Agent MD ему добавить, чтобы если мы с тобой там болтали, провели какое-нибудь исследование, ты сохрани его как Markфайл, да? То есть, чтобы я тебе об этом не напоминал.
Speaker A
А опять-таки вот как в decisions MD, да, то, что если тоже случается какая-то ошибка, обязательно её задокументировать. Ну вот как раз для этого мы decision MD и делаем. А если, например, вот вот это вообще очень важная такая мысль, если у вас
Speaker A
появляется какая-то, знаете, такая идея, типа, ну, хорошо бы, чтобы он вот это знал или хорошо бы, что он как-нибудь вот так отвечал. Вот всё. Как только вы вот какой-то такой ответ от него получили, всё, в этот момент вы прямо
Speaker A
сразу надо ему про это написать сразу, что так, давай-ка, а я хочу вот так.
Speaker A
Подумай, что ты должен в себе изменить, чтобы это сделать. То есть никогда, знаете, не оставляйте это вот в себе. Не оставляйте это, потому что если вы оставите это в себе, вы как бы только такое копите недовольство, да, в
Speaker A
отношении собственно OpenCla потому что вам начинает вас начинает раздражать, что как он вам что-то отвечает, хотя в ваших руках всё это настроить, абсолютно в ваших руках.
Speaker A
Просто если вам что-то не нравится, сразу это меняйте. А так что у нас тут?
Speaker A
Елена спрашивает: "Есть ли смысл в отдельных MD-файлах по темам?" А зависит от того, что это за темы, да? То есть, если у вас какие-то крупные темы есть, да, точно, точно имеет смысл.
Speaker A
А это это 100% имеет смысл. Э, но только важно, чтобы эти файлы были, чтобы они, знаете, как бы не в вакууме, да, существовали, чтобы просто где-то там какой-то MD файл лежит. Запомните, вот есть очень простой принцип. Если нигде
Speaker A
на этот файл нет ссылки, можете сказать, что это файл не существует. То есть, если просто в какой-то момент OpenClore где-то создаст просто какой-нибуд MD файл, просто его положит где-то, и больше нигде на него ссылки никакой не будет, всё это, считайте, этот файл
Speaker A
исчез, потому что OpenCla его больше никогда не увидит. А если у вас open создаёт какие-либо файлы, он обязательно обязательно должен тогда прописать у себя там или в Agent MD, что у тебя есть вот такие файлики, там пиши вот это. А
Speaker A
там, ну, некоторые вещи в Soul можно прописать. То есть это зависит от того, что это за файлики. То есть, ну, обязательно где-то в каких-то его системных вот этих файлах должна быть обязательно ссылка на эти файлы.
Speaker A
Так что у нас он там как, да? М, вон пишет: "Bр, первый вывод аудита.
Speaker A
Системные файлы в целом небольшие, но Agents MD заметно разросся, а, и на 228 строках смешивает неизменяемые правила, справку по харбит, платформенное форматирование и локальную маршрутизацию. А другие файлы по размеру безопасны, а user MD почти пуст, а MD осталось много шаблонного текста.
Speaker A
Продолжаю проверять. То есть, видите, он пошёл как бы, ну, аудит, да, как бы делать.
Speaker A
А, да. Вот, например, скажем, Димитрий очень верно мыслит. Он пишет, что хорошее замечание, чтобы где-то индектировал новые MD файлы. Вы можете тоже в Agent ND ему это прописать, что типа если мы с тобой, а, создаём, например, новый MD файл, обязательно его
Speaker A
где-нибудь проиндексируй. То есть это потому что без этого всё, он очень быстро, ну, как бы просто превратится вот этот в мёртвый файл, на самом деле.
Speaker A
А как это всё, соответственно, на практике? реализовать. Это можно, например, обновить ваши скилы, чтобы они в том числе создавали живые файлы, да? То есть, скажем, а, например, если у вас есть какой-нибудь скилл про исследование, да, вот если вдруг есть
Speaker A
такой скилл у вас, то измените этот скилл, пусть он в конце этого исследования создаёт Markфайл, да? То есть вот или там, а, обновите опять-таки Agenc MD, чтобы он всегда вот какие-нибудь там ссылки на файлы давал.
Speaker A
То есть это вот ваша задача- это продумать, как это будет работать. И вот мне кажется, в как бы в какой-то момент, мне вот кажется, мы придём к такой ситуации, когда вот всё, что мы с вами вот это проговариваем, оно будет по
Speaker A
умолчанию в Open Claw, да, по умолчанию. Но вот чем очень ценно, что вы сейчас делаете, это очень ценно тем, что вы получаете такой уровень знаний, который не будет уже там, я думаю, даже людей, которые там типа через год или полтора будут
Speaker A
этим заниматься. А потому что вы вот сейчас начинаете на самом деле понимать, как работают агенты внутри.
Speaker A
И это очень интересное знание, потому что, ну, когда OpenClow и вот такие все агенты разрастутся так сильно, чтобы просто их вообще понять, а, ну, нужно огромное количество времени на это потратить, да, как вот сейчас, чтобы стать там, не знаю, каким-нибудь там
Speaker A
синьором допустим разработчиком да ну, кучу уже времени на это надо потратить, но только если там, я не уверен, что имеет смысл остановиться именно синим разработчиком, но становиться синиором вот таким AI инженером. Это точно имеет смысл, на мой взгляд, и потому что вы будете просто
Speaker A
понимать, как на самом деле агенты работают внутри. И вот вот это понимание, оно из вот таких маленьких пазлов как бы складывается.
Speaker A
А немид спрашивает: "А вопрос норм практика, если по крону будет ночью чиститься сессии?" А мне кажется, да. А мне кажется, это вообще совершенно нормальная практика. Единственное, что я вот что я не ставлю на ночь никогда, это что требует какого-то
Speaker A
аа м как а, скажем так, любые вещи, которые могут потребовать моего решения. То есть я люблю, вот если там, например, допустим, он там проанализировал что-то и хочет понять, сейчас ему это где-нибудь там складировать или не складировать, то обычно такие вещи я на ночь не ставлю.
Speaker A
То есть, если он меня что-то спросит, а вот всё, что не требует моего участия, да, ночью, без проблем. И вот Димитри ещё пишет: "Я даже немного изучал, как работает Млинги, векторизация, матрица весов, attention". А, да, это вообще, кстати, очень такая важная штука. Я тоже
Speaker A
это и изучал, и изучаю, и фантюню иногда модели. И вообще вот мой вам предикт, скажем такой, скорее всего, а, ну, вот, скорее всего, люди типа нас, да, то есть, которые как бы на острие вот такого вообще развития AI, скорее всего, где-то
Speaker A
к концу этого года или, может быть, началу следующего года мы с вами прямо массово начнём тренировать свои собственные модели. Маленькие, небольшие модельки. То есть большие, конечно, мы не сможем тренировать, но небольшие модели, я думаю, вот мы обычные как бы
Speaker A
люди, то есть в плане, ну, обычные, скажем так, энтузиастый, мы будем постоянно это делать, потому что всё идёт к этому. Это станет проще, агенты кодинга нам в этом очень помогут, и они уже в этом м уже очень могут помогать.
Speaker A
Ну, кро кроме б он он наоборот в этом не будет помогать. Он он вас на опус переключит. Вот. Но это вот я вам прямо гарантирую, что к этому всё потихонечку идёт, потому что прямо есть в этом потребность.
Speaker A
А так что давайте посмотрим пока ещё делает аудит. Ну вот, конечно, вот сл медленный, более медленный, даже в тест-режиме. А дальше графы навыков. Что это такое, да? Вот что такое граф а навыков?
Speaker A
Это идея в том, что, ну, как бы есть как бы обычные, да, у вас скилы, да, там вы понимаете, как работает скилл, да, то он там подгружается и всё прочее.
Speaker A
А в некоторых случаях можно делать не один скилл, а целую, э, скажем так, целую группу скилов, объединённых одной темой. То есть, например, скажем, у нас в скилах, да, лежит, например, а, скилл про трейдинг, но на самом деле это не
Speaker A
один скилл, а это целая группа разных таких скажем так, скилов, объединённых в один такой граф. Граф - это имеется в виду, что они между собой перекликаются в этом смысле. Вот что такое граф, на самом деле. А, то есть они друг на друг друга
Speaker A
ссылаются. И а вот давайте я покажу, как это визуально выглядит сейчас. Что? Просто так будет так будет проще всего понять сейчас.
Speaker A
Вот например скажем э вот представьте, да, вот у вас там skills, да, и там с skкил про скил про Telegram-канал, да. Вот давайте откроем этот скилл. Что это такое?
Speaker A
А мы это открываем, и мы видим, что на самом деле, да, это не просто навык, а это скорее скилл, который объясняет, что значит загрузить, когда нужно написать или отредактировать пост для Telegram-канала. И дальше написано: "Всегда начинай с индексMD". Он говорит,
Speaker A
что здесь есть и с чего начать под твою задачу. Да. И пошёл читать индекс MD.
Speaker A
Такой прочитал такой: "Ага, а граф навыков Telegramканал, что здесь есть, да? Там и дальше он пишет: "Напиши пост про X". И дальше, видите, ссылка мог написание поста, да? О'кей. Он такой: "Понял, меня попросили, значит, теперь я должен прописать, прочитать мог
Speaker A
написание поста". То есть, видите, такая перелинковка постоянно идёт. И вот там мок написание поста, порядок работы над любым постом. Три шага, каждый опирается на свой узел там. А, и видите, например, там он, например, пишет намер, да, там, ну, это в тексте. А первые две строки
Speaker A
решают, раскроет ли пост вообще? Хук решает первые две строки. Хоп. Ссылка на файлик. Я и пошёл прочитал, почему, что такое, что это за хук, почему это так нам важно. Хук, там правила хука, то есть, то есть, понимаете, это не просто, да, какой-то,
Speaker A
а один скилл, который, ну, вот просто набор файлов, а это набор файлов, и все они между собой перелинкованы, да? То есть они, каждый из этих файлов на друг друга вот так направляет AI. И для сложных вещей комплексно, это сейчас
Speaker A
такой простой, да, пример, но если брать какие-то комплексные задачи, да, где у где у много есть разных точек, то есть где вот знаете, нельзя просто так типа взять, что прочитай вот это, если там тебе релевантно, то теперь прочитай вот
Speaker A
это, да, это, ну, так работают простые скилы. Но если брать какие-то комплексные темы, ну, типа там вот, ну, то же самое на самом деле там написание в Telegram, да, это большая комплексная тема, как хорошо писать в Telegram. И
Speaker A
тут может быть вот таких вот эмдишек просто куча, и они все будут перелинкованы между собой. И он в процессе будет понимать, а ему как бы нужно по этим линкам переходить или не нужно, релевантно это для его задачи или
Speaker A
нет. Это такая вот такая интересная штука вот называется граф скилов. И, но это это актуально для реально более как бы сложных сложных таких задач. Вот. Ну и работает, соответственно, как я вот я показал, да, то есть, что он
Speaker A
в любом случае он, ну, сначала он читает skкил MD в любом случае, потому что это просто так у, ну, как бы они так устроены просто все обвязки, а, но по нол MD его отправляет в indeкс MD и дальше соответственно а
Speaker A
уже индекс MD его по разным направлениям, а эти направления ещё между собой тоже по по такому вики-принципу, да, они между собой перелинкованы.
Speaker A
Вот. И, соответственно, в вы тоже в своём OpenClome можете это ресовать, просто сделать для каких-нибудь сложных ваших сложных задач вот такую систему графов, да? То есть где где у вас не один скилл, а где скилл, который внутри, вот он все файлы вот так у него
Speaker A
перелинкованы. Аа а не не Дмитрий пишет: "А для тренировки своих моделей не нужно быть лнженером?
Speaker A
Не будет это профанацией. А, смотря, смотря, смотрите, смотря о каких моделях мы говорим. Маленькие модели, а для маленьких моделей единственное, что реально важно - это датасет. Если вы можете подготовить хороший датасет, а для этого не обязательно быть LL-инженером, чтобы подготовить хороший
Speaker A
датасет, можно просто с Клодом поговорить, как можно подготовить хороший датасет. И главное найти, собственно, хороший датасет. А если вы это сделаете, дальше процесс как бы самой тренировки модели на хорошем датасейте, маленькой модели, он реально простой. Ничего в этом сложного нету. Я
Speaker A
тренировал свои модели. Ничегошеньки сложного в этом нету. Ну то есть как бы это реально довольно простой. Вы даже удивитесь, насколько это простой процесс. Но, конечно, дьявол начинается в деталях. То есть в деталях там вот реально прям много всего. А, да. Вот. Но я думаю, мы к
Speaker A
этому реально все придём. А, да. И вот дальше, собственно, у нас вот тут он ответил на аудит. Значит, аудит выполнен. И вот он нам пишет, что MD большой. Ну, как бы это правда, что 228 срок - это не критично, это ещё не
Speaker A
перегруз. А здесь всё, всё дальше у меня нормальное. Здесь нормальное. А сейчас посмотрим. Сейчас момент.
Speaker A
Вот он, собственно, пишет предполагаемый дизайн. А значит, memory decisions MD data контекст решение. А memory failers MD data симптомы. Па-папа. И дальше он, значит, это правило будет закреплено в Agents MD. Крон читает только записи после последнего анализа. Если полезных
Speaker A
выводов нет, возвращает reply там. А давайте сделаем сейчас момент. Да. А, да. Всё это, всё это делай и всё это реализуй сейчас.
Speaker A
Да, всё это делай и всё реализуй. А, да, соответственно, вот он, э, он пошёл реализовывать.
Speaker A
И теперь давайте посмотрим дальше, да? То есть мы про это поговорили. Теперь м значит, сейчас так. Так, да, тут всё мы обсудили. Теперь вторая тема, да, наша сегодняшняя - это самосовершенствование.
Speaker A
Openк. Как у него может идти, собственно, самосовершенствование? Это четыре обычно это четыре этапа, да? То есть первый - это observe, да? То есть это, а, просто записывание каждого запуска, да? То есть там, а, он там выполнил какую-то задачу, записал её,
Speaker A
там скилл какой-то там использовал, записал успех, записал ошибку, записал фидбэк записал, то есть всёвсё-всё он теперь как бы у вас может записывать, а тоже вы тоже в нём всё это можете настроить. Конечно, нужно понимать, что а это как бы будет медленнее всё, да, и
Speaker A
побольше тратить ресурсов вашего как бы OpenC там. Ну, частично можно, конечно, это скриптами оптимизировать, но всё равно как бы определённо будет тратиться как бы на прямо постоянное логирование.
Speaker A
Другое дело, что вам не обязательно прям вообще всё постоянно логировать. Может быть, например, у вас есть какой-нибудь важный, например, новый там скилл или важный какой-то новый там процесс, который вы с ним делаете. Вот пусть он по нему всё всё логирует. Просто вы
Speaker A
должны с ним это обговорить и настроить. А дальше это инспекция, да? То есть как бы, например, накопились какие-то провалы, аа вы м или случилось какой-то один там важный сбой, и вы идёте, собственно, искать, точнее, он идёт искать повторяющиеся паттерны. И для
Speaker A
этого тоже можно поставить кронзадачу анализа логов. Ну, здесь не обязательно каждый день. Я бы такое поставил там раз в неделю, раз в 2 недели. То есть, чтобы он, ну, как бы периодически ходил и это смотрел. Потом происходит точечная правка, да? То есть не нужно
Speaker A
там полностью всё переписывать. Обычно обычно просто что-то какой-то мм причина выясняется, что что не так и как это можно точечно подправить. А и, соответственно, он, а, как бы сейчас вот в OpenClo это как бы такой уже встроенный автоматический процесс, что
Speaker A
он создаёт такую вещь, как Proposal MD, да, для вашего скила. он у вас появляется, вот помните, я вам показывал в вот этом дэшборде там в разделе аа skills workshop, да, у вас там появится, что типа он предлагает как бы улучшение,
Speaker A
да, ну и соответственно, а, ну и, соответственно, дальше вы можете это улучшение принять. И также до этого и м имеет смысл сделать, то есть до принятия это изменения, чтобы он сделал ещё и тесты, да, то есть прогнал как бы
Speaker A
по какому-то тестовому чек-листу, но это в вашем скиле даже записано. То есть в скилах надо всегда ивалы, а, прописывать, чтобы как этот скилл тестируется на изменения, чтобы понять, что мы вот сейчас сделали какие-то новые вещи, что мы не сделали хуже, да, то
Speaker A
есть какие тесты надо, а, надо надо запустить. А ещё одна такая же интересная вещь - это двухконтурная архитектура, да? То есть вы можете разделить вот как раз логирование, да, и аналитику, да, таких на два таких контура, по сути. То есть
Speaker A
внутренний контур - это вот там каждый запуск, да, например, там а там что-то происходит, да, а там скилл используется или там что-нибудь ещё. обязательно оставляется какой-то след, лог, файл, какой-то комментарий и и потом, соответственно, какой-то внешний контур, то есть какие-то кроны,
Speaker A
например, там раз в день, раз в неделю, раз там в месяц идут и читают, собственно, логи, а вот эти накопившиеся и, собственно, а предлагают как бы находят какие-то закономерности и предлагают полезное их исправление. Ну, то есть, по сути, как раз то, что вот я вам здесь
Speaker A
предложил, это и есть вот эта двух двухконтурная, так называемая архитектура. Ещё один подход - это можно сделать вообще такую агенталабораторию.
Speaker A
Ну, тоже, понимаете, вот как бы тут это вот как реально как там, знаете, старые машины, да? То есть как бы кому-то очень нравится просто вот валяться под под капотом, да, там и что-нибудь делать с этой старой машиной. А
Speaker A
я не говорю, что каждому из вас нужно делать агента лабораторию, но если вам это нравится, если вам хочется что-то такое сделать, ну почему нет, как бы может быть вы потом в будущем, там через год, два-три станете каким-нибудь топовым и инженером из-за этого. А
Speaker A
что такое агент-лаборатория, да? То есть это, например, вы можете ему сказать, что прежде чем что-либо менять, построй сам себе как бы, ну, условную лабораторию, да, где ты будешь проводить эксперименты, да, то есть, чтобы у тебя там был, например, место, где ты будешь
Speaker A
там бенчмарки запускать, а, делать все замеры. В некоторых случаях это может потребовать запуска изолированного, э, сендбокса. И об этом мы, кстати, поговорим вот уже через два занятия. То есть, ну, это у нас будет тема нашего, а какого это будет? Седьмой, девятого.
Speaker A
Девятого, по-моему, девятого занятия, если не ошибаюсь. Ну, то есть мы поговорим об этом, что это такое, да?
Speaker A
Да, то есть это можно настраивать такие изолированные и изолированные как бы мм области, да, где где он может любые эксперименты проводить и чтобы не было никаких последствий.
Speaker A
А потом там, чтобы он, например, там делал сам диагностику, гипотезы придумывал, как он протестирует эти гипотезы, да, и дальше он там, например, делал какие-то тесты, измерения, сравнивал с Baseline. Бейлайн - это имеется в виду, что это, ну, какие-то
Speaker A
базовые показатели, да? То есть как бы вот он замерил изначально, как было, и вот он потом и с этим сравнивает. И он делает гит комиты после каждого успеха, а если ухудшение, то идёт назад. Это на самом деле вот это агент лаборатории -
Speaker A
это то, что Карпаты предложил. Вот если вы неё слышали, у него такая вещь была от research. Вот это оно. То есть как бы а это у него по сути такая же система работает, что когда э он у него есть как бы замеры, он
Speaker A
ставит гипотезы, как нужно что-то изменить, а чтобы получить лучший результат, меняет это, запускает тесты.
Speaker A
если улучшение двигается вперёд, если ухудшение отка откатывается назад и, соответственно, ведёт журнал отчётов до после там что как происходило. То есть вот это такой же подход вы можете в сделать и в и собственно в Open Claw.
Speaker A
Ну, обычно это нужно для каких-то, ну, серьёзных задач, да? То есть это это не задачи, которые вы можете легко просто так выставить, например, скажем, а, ну вот представим, что вы чего-то не знаете. Ну, то есть, допустим, вы не знаете, в какое время ваш
Speaker A
OpenCl для бизнеса должен, например, делать анонсы в Твиттере. Ну, вы же этого не знаете, да? И вы не знаете, там, какой из них будет приносить там больше вам, ну, нужной вам реакции, да, например. И вы можете настроить вот
Speaker A
такой как бы процесс, когда он такой: "О'кей, там первая гипотеза, лучшие посты там делаются тогда-то, да, там, о'кей, тестируем". И он там делает пост, замеряет как бы там, э, сколько на этот пост было лайков, там, реакций и прочего. И вот он так вот просто
Speaker A
методично проводит эти, э, проводит эти, например, измерения. То есть, допустим, он сначала там один пост делал в 10:00 утра, там получил какой-то бейзлайн, потом, ну, то есть там данные как бы сколько сколько лайков, сколько ретвитов, сколько всего получил этот
Speaker A
пост, да? Потом он, например, берёт какой-то аналогичного типа пост и постит его в 10:30, да, и смотрит тоже там, ну, смотрит дни, недели. То есть это это такая сложная тема. То есть это как бы это кажется легко, но
Speaker A
можно это продумать так, чтобы это как бы интересно работало. Но ещё раз повторюсь, это для тех людей, кто вот любит под капотом поваляться и в этом всё очень поразбираться. Но если вы, знаете, вот у меня есть моя личная,
Speaker A
знаете, римская империя такая, знаете, ну, есть такая шутка, что мужчины думают про Римскую империю каждый день. И моя личная Римская империя - это, если знаете, есть такая вещь, как Prediction Markets. Это рынки предсказаний.
Speaker A
И на рынках предсказаний это такая супер интересная вообще область для АЕ-агентов. Я об этом очень часто думаю, потому что по сути, что такое рынки предсказаний, да? Это рынки, где реальные люди делают ставки против реальных людей. То есть это не казино,
Speaker A
да? Это не там, где, а, там, вы играете против казино, значит вы все, всё равно вы проиграете, потому что казино в итоге всё равно выигрывает. Ну, как бы в среднем. А когда и человек играет против реального человека, это всё намного
Speaker A
интереснее становится. То есть вот представьте что всё, что вам нужно, чтобы зарабатывать много денег - это создать систему, которая будет находить, например, какие-то инфоповоды, которые для какой-нибудь узкой группы людей, которые находятся в каком-то информационном пузыре, покажутся чрезвычайно важными, и они пойдут,
Speaker A
например, на те же самые рынки предсказаний и поставят там на что-то деньги. Ну, то есть представьте, например что допустим происходит что-то в Америке и какая-нибудь там узкая группа, допустим, ярых трамповцев, допустим мм они с как бы они им покажется, что вот это
Speaker A
какое-то событие на что-то очень сильно повлияет. Не знаю, что там Трамп что-нибудь объявит. И они идут на какой-нибудь там сайт вот этого предикшн маркета и делают ставку на это событие.
Speaker A
А если вы сможете вычислять, что эти люди находятся в в информационном пузыре, а это теоретически, математически возможно, как бы, и можно как раз через вот такие автосистемы это делать. И тогда вы сможете на этих людях просто деньги зарабатывать, потому что
Speaker A
вы будете точно знать, что они находятся в информационном пузыре. Они движимы как бы свои как бы ну каким-то заблуждением, и поэтому они делают определённые ставки, и вы стате против них, и вы на этом зарабатываете. Есть на самом деле
Speaker A
есть такие люди, кто уже на этом зарабатывают. Очень умные люди, которые вот я только думаю про эту Римскую империю, а они уже на этом зарабатывают.
Speaker A
И вот как раз для АИ агентов это супер интересная штуковина. А, ну это так просто то, о чём я часто думаю. Ну и, соответственно, как бы как вам вот это реализовать, да, у вас на практике, ну, настроить какую-то
Speaker A
собственную систему улучшения хотя бы одного из ваших скилов. То есть там придумать, какой из ваших скилов лучше всего можно каким-то вот таким автоматическим образом улучшать, да, чтобы он записывал где-то каждый раз, когда этот скилл используют. Аа потом поставить крон, чтобы проводились там
Speaker A
раз в какое-то время инспекции, да, там улучшения, да, и всё прочее. У вас, кстати, будет домашнее задание как раз именно про это. И тут я могу посоветовать то, что а это вот как раз то домашнее здание, которое имеет смысл
Speaker A
сдать там, ну, не в последний, да, там час перед занятием, но там, может быть, там за день, за два до а до занятия, потому что как раз вам нужно побольше времени поэкспериментировать. Вот давайте сейчас я вам прочитаю, как у вас
Speaker A
будет выглядеть этот как раз текст аа домашней работы. Сейчас вот вам нужно настроить процесс само улучшение в вашем OpenC. Это может быть самоулучшение скила, промтов или любых процессов внутри OpenClow. А это задание имеет смысл сдавать после нескольких дней самоулучшения, чтобы агент мог
Speaker A
рассказать, какая проблема была до изменения, что изменилось после улучшения, как проверилось, что стало лучше и какие признаки или метрики сравнивались. Да, то есть это, ну, то есть вот хотя бы там 4-5 дней поактивнее как бы поиспользовать, чтобы он по само
Speaker A
улучшался, например, по этому скилу. А, и последняя, а, тема, которую тоже мы сегодня обсудим - это про активность, да? То есть вообще, что такое проактивность, да? Вот если если смотреть мм такую лесенку, да, активности, да, там вот самое пассивное - это просто чатбот, да,
Speaker A
который просто вам отвечает в чате на вопросы, да? Следующая ступенька - это исполнитель, который делает задачу по вашей команде. Это, ну, например, там агент кодинга. Вот вы ему сказали там, иди делай, и он пошёл делать.
Speaker A
Третий - это вот уже уровень open cl, да, это наблюдатель, он следит и докладывает, да? То есть у него есть харбит, который как бы его будет периодически он смотрит, что происходит, и кроны, которые ему запускают тоже какие-то действия.
Speaker A
И есть следующая ступенька, да, когда он не просто, да, вот не просто вот так сидит, да, как бы и там раз в 30 минут что-нибудь там хоп, просто посмотрел там или крон какой-то у него сработал.
Speaker A
А если в нём выстроена система, что он сам предлагает дальнейшие действия, да, и наконец там самая высшая ступенька, это уже прямо доверенный оператор, когда сам действует на согласованных границах.
Speaker A
Но это реально сложная ступенька. У меня пока не один агент, хотя немножко немножко у меня есть там один агент, который до этого почти почти добрался до этой ступеньки. Но вот в целом даже если вы вот просто перешагнёте просто от обычного OpenC к
Speaker A
тому, кто будет анализировать и предлагать действия, да, то есть это уже будет такая очень интересная история.
Speaker A
И, значит, какая вообще такая вот, если говорить про архитектуру проактивности, да, то любое любое любая проактивность в Open Clow, она делается следующим образом, да? То есть, во-первых, ну, в любом случае должен быть какой-то триггер. То есть это проактивность не
Speaker A
существует без триггера, да? Там в любом случае там или крон вы какой-то поставите, или вбит что-то запишите, или какие-то события происходят, там ваш openla какой-нибудь вебхуookк там получает из интернета, да, там, то есть что-то должно быть триггером. Это в
Speaker A
любом случае. А следующий момент, это происходит сбор сигнала, да? То есть вы, соответственно, а там или почту прочитали, или получили какой-нибудь РСSс, или что-нибудь, да? То есть это, а, это и происходит сбор сигнала. И вот тут вот я специально такую фразу
Speaker A
использовал: летальные тряды - это вообще такая очень важная вещь, которая а они вообще важно знать, когда вы работаете с любыми агентами типа Open Летальная триада - это, а, так называется, когда вы даёте вашему агенту а неконтролируемый доступ к,
Speaker A
э, да, Точнее так, доступ к неконтролируемой информации, да? То есть, например, там вот письмо из почты, если он читает вашу почту, это доступ к неконтролируемой информации. При этом, если аа у агента есть права различные действий, да, то есть, что он может
Speaker A
всякое делать. И при этом, если, то есть вот если он, значит, получает вот эти вот эти как бы из из как бы непроверенного источника и может на их основании действовать, а и имеет доступ при этом к, ну, как бы внутренней
Speaker A
внутренним данным, да? То есть если то есть вот если у него есть доступ к внутренним данным, он получает а информацию извне непроверенную и при этом может действовать. Вот эти, если три вещи совпадают, всё очень плохо, то тогда как раз такие агенты, они потом
Speaker A
очень подвержены взломам. Поэтому просто, э, учите, что если он будет у вас там собирать везде сигналы, да, там по РСС, по сайтам ходить, почту читать, прочее, то нужно его как или его как бы ограничить в действиях возможных, или,
Speaker A
э, ну, чтобы у него просто не было такого такого масштаба доступа ко всему. То есть может его в какой-то там изолировать в какой-нибудь отдельный снбокс. Но это тоже надо смотреть, куда он, смотря ходить будет.
Speaker A
Потом, да, то есть когда когда он собрал, да, какой-то сигнал, да, то вам нужно ответить на эти пять вопросов. Что нужно делать каждый раз, да? То есть вот, например, там каждый раз, когда, например, допустим, у вас там какой-то триггер или что-то
Speaker A
случилось, он что-нибудь собрал где-нибудь сигнал, да, что делать при этом каждый раз? Как часто это вообще делать? Какое изменё а изменение достойно сообщения? сообщение, чтобы он вам отправил. А когда он должен остановиться, когда он должен спросить вас о чём-то, да? То есть вот на это вы
Speaker A
должны как бы ответить и дальше сделать как бы решение, да, что, например, там, если нет, как бы нечего ответить, то он должен молчать. Если, например, это что-то несрочное, то он там может в каком-нибудь там дайджет сообщении, который периодически вам высылает там
Speaker A
раз в несколько часов, если это что-то критичное, то он прямо должен вам сразу сказать. Если это вызывает необративное, как необратимое какое-то действие, то он должен обязательно сначала просто черновик как бы этого оформить, а потом вас спросить, да, то есть, ну, нужно по
Speaker A
решению. И вы, соответственно, в Telegram на это отвечаете. И вот по сути вся проактивность, она про правильное выставление вот этих всех всех всесх вещей. И если вы это всё очень правильно придумаете, да, то есть, а как часто он
Speaker A
должен что делать, какое изменение, а насколько он вас должен об этом уведомлять, да? То есть если вот такие более сложные вот эти все структуры продумать, то у вас получится настоящие, ну, такие настоящие проактивные действия. Плюс к этому вы можете
Speaker A
добавлять как раз те самые внешние файлики, да? То есть, например, скажем, а представьте себе так, что, допустим, вы, ну, вот, например, скажем, вы можете сделать так, чтобы, допустим, раз в неделю он записывал что-нибудь о вас в ваш, а, usermd, да, там, что вы, не
Speaker A
знаю, там интересуетесь AI, да, например, и потом же вы можете ему ещё добавить, чтобы, допустим, раз в неделю он читал, допустим, новую информацию о вас, которая добавилась в user MD, и на основе этой информации придумывал проактивности, которые он будет делать, да, вот по вот
Speaker A
этому по вот этому по вот этой схеме. И дальше представьте себе такую картину, что вы с ним просто болтайте, просто болтайте и зада там что-нибудь его просите про AI там всякое поискать. Он себе такой запоминает: "Ага, ты значит
Speaker A
AI любишь. О'кей. Запишем. Потом через неделю а другой крондит. Ага, записалось. Что он значит AI любит.
Speaker A
Хорошо, давай тогда мы будем поставим ему крон. Что, например, он проснулся, а я ему сразу высылаю подборку новостей про AI. И вот когда это происходит без вашего ведома, да, то есть вы как бы вы не просили его сделать каждое утро вам
Speaker A
подборку про AI, но вы выстроили вот эту систему, да, что он с одной стороны собирает сам о вас данные, сам как бы их анализирует и сам на основе их придумывает, а какие бы активности проактивные делать, и тогда он будет вас
Speaker A
удивлять. Это реально, это абсолютно такое магическое, знаете, чувство, когда просто это утром просыбаешься, а тебе там приходит сообщение, типа, ну вот я, знаешь, для тебя я сделал подборку, ты же любишь прояй. И вот тут вы понимаете, что вот это круто, вот это реально
Speaker A
проактивность. То есть попробуйте вот что-то такое создать, попробуйте, но это требует времени, это не сработает сразу.
Speaker A
Вы должны как бы расставить вот эти как бы такие, знаете, ружья, да, везде развесить, и в какой-то момент оно выстрелит, и это будет очень круто. Но вы должны вот всё сделать для этого, чтобы такая проактивность в принципе существовала, чтобы он собирал какую-то
Speaker A
информацию о вас, чтобы он эту информацию потом а как-то сам анализировал и на основе этой информации сам решал, как какую проактивность ему делать.
Speaker A
А, ну и также важно, конечно, выявить вообще, ну вот он будет действовать или нет, да?
Speaker A
То есть, скажем, если, например, а там, скажем, допустим, он у него сработал хардбит, есть какие-то изменения? Ну, конечно, там, если нет, то не надо ничего говорить, да? А если, например, есть какие-то изменения, он должен себя спросить, меняет ли это то, что
Speaker A
человеку следует делать, да, вот что он там может сейчас видит календарь, да, что вы сейчас делаете. Если нет, то куда-нибудь записать, например, там в сводку какую-нибудь сводку дня или сводку там, смотря какие он вам, если он присылает какие-то сводки, то туда он
Speaker A
это может дописать. А если, например, меняет ли это то, что человек следует делать? Да, да, критично это вот прямо сейчас. Если аа да, то это прямо вот прямо надо прямо написать, да, обязательно человеку. А если как бы нет,
Speaker A
то нужно проверить, нужно ли делать какое-то необративное действие, да, там что-то письмо, ответ сделать, платёж, публикацию. И если нужно, то нужно сделать черновик этого или подготовить, что можно подготовить и спросить человека, да? То есть, ну, например, скажем, а там пример такого может быть
Speaker A
так: он пробуждается по харбиту и такой: "О'кей а пришло письмо о том, что у вас уводит ваш там домен, да? Меняет ли это то, что человеку следует сделать?" Да. Критично ли это прямо сейчас? Да, там и, ну, как
Speaker A
бы да, но при этом может быть сразу ещё накидать, например, там какой-нибудь там план действий, да, что в таком случае делатся, и это отправляется, соответственно человеку.
Speaker A
Вот. Ну и, соответственно, как это реализуется на практике в Open Clow - это то, что попробуйте настроить вот такую проактивность, да? То есть про активность, как я вот тут описал, то, что пусть он о вас собирает куда-нибудь информацию, да, это будет просто, в
Speaker A
принципе, такой процесс, когда он у вас собирает информацию, и потом, чтобы какой-то Крон читал новую информацию, которую он у вас собрал. И на основе этой новой информации он Пусть он сам придумывает, какие проактивные вещи он может для вас делать, и вы прямо очень
Speaker A
удивитесь, насколько это как бы круто будет. Так что это такая очень классная штука. Вот. Ну и, соответственно, домашнее задание я вам уже озвучил. И сейчас я посмотрю, что у нас по вопросам. Так, вопросов больше не вижу.
Speaker A
Вроде я на всё а ответил. И тогда это будет всё. Это наше последнее было занятие именно про OpenC, потому что, мне кажется, вот вот на на этом месте в целом, ну, вот так глобально вы всё более-менее знаете. Дальше только
Speaker A
практика. То есть как бы вот всё, всё, а всё, что вы как бы пойдёте, ну, как бы всё, что вы пойдёте дальше, это уже исключится через практику. То есть вам нужно просто самим в этом копаться, разбираться. Тут уже я мало что вам
Speaker A
смогу дать. Поэтому мы следующего занятия переходим на Paper Clip, то есть будем запускать свою собственную такую команду аа команду агентов. Но я вам рекомендую оставить вашего OpenClod хотя бы до конца курса. Пусть он живёт, пусть он вас радует, вы с ним общаетесь, по
Speaker A
точно ещё что-нибудь э от него вот так узнаете. Вот. А так что буду ждать ваши домашней работы и теоретические тесты тоже не забудьте будет. И, соответственно, увидимся с вами через неделю и будем уже общаться на новую тему. Счастливо.
Topics:AI агентысамообучениеоптимизация памятиfine-tune моделипромтыскилыфайловая системапроактивностьOpenCloавтоматизация











