Transcription
Привет. Во-первых, хочу вас поздравить с наступающим или с наступившим Новым годом, в зависимости от того, когда выйдет это видео, и пожелать вам и вашим родным и близким здоровья и счастья.
Ну а мы с вами перейдём к разбору так-менеджер для иагентов, который позволит вам освободить больше времени и больше делегировать и-агентов и делать сложные задачи фактически с помощью нескольких промтов. Поэтому давайте посмотрим на практики. Я буду выполнять одну из задач, которая нам нужна на проекте. И на её примере мы как раз посмотрим, как можно декомпозировать исходные требования в задаче, как этими задачами можно управлять и какие инструменты есть.
Кстати, если вы хотите изучить не только как работают и агенты, но и различные технологии фронт-end, backend, Python, то у нас на платформе стартовала большая новогодняя распродажа. На ней вы можете приобрести все курсы со скидками до 15%. Ссылка на нашу платформу, как обычно, в описании.
Итак, давайте начнём с проблематики. Когда мы с вами заставляем агенту выполнять какие-то простые задачи, в целом ничего необычного нет. Мы пишем просто промт, который нам необходим, и он нам выполняет его. Проблема, когда мы хотим, чтобы агент реализовывал более сложные задачи, которые требуют многих шагов. Как пример, мы недавно имплементировали систему тарифов в нашем проекте Neurus. И здесь уже просто обычным бронтом не обойтись. Нужны какие-то минимальные требования. Из этих требований сформировать список задач, а затем эти задачи имплементировать.
В примитивном варианте мы, конечно, можем использовать markdown. Как пример. После обсуждения с кодексом создали вот такой документик, где были описаны список того, что нам необходимо сделать. Обзор текущего биллинга, дальше, соответственно, изменение контрактов, сиды тарифов, изменение локи списаний, ну, то есть наборы задач, которые необходимо сделать. И он помечал каждую из них галочкой при выполнении. В целом, опять, такой подход нормально работает, когда задача не супер сложная и на самом деле задач не очень много. Но когда задач становится больше, нужно как-то приоритизировать, понимать, какая зависит от какой. Вот здесь уже для агентов нужны дополнительные тулы. И сегодня мы с вами посмотрим, как избавиться от лишних Markdown файлов и сделать таск-менеджер для агента, который бы он пользовался и выполнял по нему задачи.
Для решения этих задач есть несколько инструментов. Достаточно популярный таскмастер, который работает, в принципе, со всеми агентами, но у меня были проблемы, например, работы с ним с кодексами. Он хранит все задачи для агентов JSON файлов. Достаточно простая UI, которая отображает это. Но мне больше понравился проект, который называется Bits. Bits дополнительно, кроме того, что можем визуально в терминале посмотреть наши задачи, есть дополнительные вьюхи: Terminal UI, так и WebUI. Получаете классический канбанборд, где вы можете посмотреть все задачи текущие, над которыми работает ваш агент. И мне это больше понравилось. Проект чуть менее популярный. У него всего 6.000 звёзд против 24.000 звёзд у Taskmaster. Ну, Taskmaster, во-первых, активно продаёт свой Taskmaster for Teams, который платный, конечно же, и при каждом запросе ты должен ему говорить: "Нет, я хочу использовать локально". В этом плане Bits чуть-чуть лучше. И мне понравилось, что Bits хранит всё в свои файлы базы данных, а не разбрасываются кучей JSON'ов.
Для того, чтобы начать с ним работать, нужно установить его. Можете посмотреть, что внутри скрипта, исполнить его с помощью bash. И дальше нам нужно инициализировать наш репозиторий, который теперь должен поддерживать Bits. Для этого открываем Zsh и делаем. После того, как он сконфигурирован, у нас появляется несколько дополнительных вещей. Я использую здесь редактор Zsh. Последнее время, когда здесь появился debug, он стал ещё лучше. А интеграция с кодексом мне прямо понравилась. Если интересно, могу сделать детальный обзор. Работает он супербыстро, так как ты уже делал обзор на предыдущую версию, но в новой версии с интеграцией с кодексом и AI'ем это прямо огонь.
Так вот, что у нас появилось? У нас появился Bits, который теперь содержит конфигурацию, содержит метаданные, дополнительные, ну, короче, стандартные файлы. Вот в этом `.bits` директории будут храниться наши таски. Также здесь появилось дополнительное описание MD, соответственно, как работать с Bits, соответственно, `bits sync`. И здесь нужно дополнительно ему дать инструкцию о том, что он должен использовать Bits для того, чтобы с задачами работать. Теперь, когда мы будем говорить "создать задачу", он будет использовать непосредственно инструмент Bits и будет трекать задачи там.
Итак, первый шаг, после того, как мы установили Bits - это сформировать требования. Поэтому давайте перейдём к формированию требования, а оттуда уже сгенерим задачу непосредственно в Bits.
Итак, перед тем, как декомпозировать на задачу, нам нужно, собственно, сформулировать то, что мы хотим. В рамках этой задачи мы хотим реализовать импорт автоматический фида Авито по ссылке для того, чтобы на данных объявления агент мог изучить те товары, которые продаёт продавец на Авито, и затем, когда обращается клиент в мессенджер Авито, непосредственно отвечать ему, потому что у нас уже реализована интеграция с мессенджером. Теперь агенту понимать контекст, когда ему пишет: "А сколько стоит вот этот шкаф, можно ли на него сделать скидку?". Он должен понимать, какие вообще есть шкафы. Может быть, есть шкаф подешевле и предложить ему необходимые вещи. Я уже заранее приложил пример файла, который у нас есть в XML'е, то есть это пример, который с Авито может приходить. Наша задача - реализовать автозагрузку этого фида. Поэтому сначала мы просим его взять и в, ну, давайте здесь я немножко причешу. Я заранее написал промт, чтобы не экономить ваше время. То есть нам нужно сделать требование для следующей функциональности. Сохранить папку `tasks` в виде отдельного файла. Перед описанием изучи структуру проекта и существующий функционал. Что важно, здесь у меня уже проект подготовлен для работы AI, поэтому в папочке `docs` есть описание архитектуры, есть описание базы данных, соответственно, описание того, как мы работаем с секретами, с контрактами. Ну, то есть всё это подготовлено. У меня есть отдельное видео, где я рассказываю про эффективную работу AI агентов с нашим кодом. Как раз в рамках него я показываю, как правильно документацию сделать. Здесь уже документация есть. То есть агент при старте плюс-минус понимает, о каком проекте идёт речь, зачем мы вообще это делаем и что внутри. В `agent.md` есть соответствующие ссылки на эти файлы. Здесь также давайте приложим пример. Собачка пример файла. Отлично. Соответственно, нужно сделать импорт этого XML файла по ссылке с периодичным обновлением. Фид становится для агента. И после парсинга сохраняется векторная база, которая уже реализована. При обновлении старая запись удаляется (hard delete), чтобы не загружать базу, и загружается новая.
Теперь давайте мы ему отправим, и его будет первостепенная задача - это сначала сформировать требования. Мы ещё даже не перешли к задаче. Нам нужно, чтобы мои поверхностные требования декомпозировались в уже полноценные требования. Можно, кстати, задать ему шаблон, если вы пользуетесь каким-то шаблоном бизнес-требований. И уже из этих бизнес-требований мы будем использовать Bits для того, чтобы формировать задачи. Сейчас какое-то время он отработает, и я скорректирую промт, покажу результат, и мы с вами перейдём к созданию задачи.
Итак, после некоторых размышлений было создано требование "Avito XML Import". После ознакомления в целом мне всё подошло. При этом важно, конечно же, пройтись после того, как он сгенерит, детально пройтись и скорректировать, если что-то не подходит. Здесь он указал всё то, что нужно, сформировал контракты, цель, область работ, все термины для того, чтобы в дальнейшем мы с ним могли проще коммуницировать. Описал новые сущности, связи с векторной базой данных, схемы XML и парсинга, что содержится в объявлении, метаданные чанков, API контракты, соответственно, просто список контрактов, которые будут endpoints: `POST /change`, а также запуск ручной синхронизации, расписание синхронизации, алгоритм обновления. В конце он задал дополнительный набор вопросов, которые нужно ответить для того, чтобы мы правильно с ним сошлись к единому пониманию, что это, собственно говоря, происходит.
Итак, первое: какой идентификатор используем? Avito ID. Второе: полное обновление или soft delete? Нужен hard delete для данных объявлений Авито. Четвёртое: какой минимальный дефолтный интервал обновления? 12 часов. И пятое: нужно ли ограничить тип агентов только Авито? Нет, потому что теоретически ему может отвечать по тому же товарному фиду, например, на сайте, поэтому нет. Скорректируй требования по ответам. Вообще хорошая практика ему даже в первичном промте говорить, что типа "задавай вопросы, если у тебя есть какие-то сомнения". Так как у меня это где-то прописано в доках, он по умолчанию это сделал и в конце все необходимые открытые вопросы задал и скорректировал. Теперь он видит, соответственно, согласовал это, сделал, и теперь мы получили готовую базу, по которой, готовую, точнее, требование, по которому мы можем теперь планировать задачи для имплементации.
Ну и, конечно, необходимо понимать, а что, собственно говоря, написали наши агенты. Поэтому всё равно без изучения разработки никуда. Если вы хотите недорогие и небольшие курсы, которые позволят вам освоить ту или иную технологию, то переходите на нашу платформу. Ссылка на курсы и платформу в описании.
Теперь давайте декомпозируем наши требования на задачи. Кстати, после генерации рекомендуется сделать `bits doctest fix`, которые по фиксу при коммите, то есть дополнительные, которые нам нужны для автоматической синхронизации нашей базы. Кстати, нужно делать `bits sync` для того, чтобы синхронизироваться, если вы не одни работаете над какими-то задачами и вам нужно синхронизировать базу задач для AI.
После того, как мы это сделали, я открою даже в терминале, чтобы у нас было чуть больше пространства, и попрошу его разбить. "Разбей на задачи с помощью Bits требования и укажем здесь требования". У нас XML называется вот эти. Теперь он будет использовать инструмент Bits. Ну, в принципе, можно было даже не говорить ему про Bits, если у вас в `bits.md` явно прописано, что необходимо использовать этот инструмент. Теперь он, так как я создал нового агента, соответственно, сейчас пройдётся заново, восполнит контекст того, что есть. Нашёл, соответственно, Bits, как работает и начинает с ним работать. Тасков у нас пока нету. `bits list` ему ничего не вернёт, поэтому ему нужно будет создать новые задачи. Теперь он разбирается, как делать `bits create help`. На самом деле, можно было бы дополнительно документацию тоже подложить, чтобы он каждый раз не разбирался с CLI. Ну и, соответственно, создаёт сначала Epic. Это, как мы приняли и в обычном таск-менеджере, объединение наших задач. В данном случае будет иметь title "Avito XML Feed Import". И чтобы нам было интереснее, я покажу сразу же ещё один инструмент, с помощью которого мы с вами будем отслеживать его изменения. Это BVI, как раз терминальный вьюер. Здесь мы сразу с вами будем видеть, что у нас появился Epic. Вот он, соответственно, какой-то из них. Вот это, по-моему, называется у нас Epic, да, соответственно. И здесь создаются сейчас наборы TAS. Как мы видим, оно обновляется прямо в лайфе для того, чтобы мы могли следить за тем, что обновляется. Есть опять-таки UI, такой же инструмент. Ну, BVI - это, соответственно, Bits Viewer, который позволяет просматривать. Мне как больше нравится. Открываешь соседний вклад терминала, и вот он, пожалуйста, работает.
Сейчас он просто накидывает все эти задачи, как видим, с одним и тем же приоритетом, но декомпозирует наши требования на уже небольшие части. Что нужно, чтобы нам нужно импортировать этот файл? Нам нужно, соответственно, контракты API. Нам нужно API для того, чтобы менеджер логтрик, тесты, периодическая синхронизация. То есть пайплайн синхронизации, как он будет работать. SQRS для, соответственно, работы с фидом. Ну и вот наш IC, на который будут ссылаться все эти задачи. В каждую из них, как мы видим, добавляется description, который говорит, что вот у нас, соответственно, есть, например, задача "model agent feed migrations", соответственно, "added persistent with field requirements", бла-бла, ну, соответственно, набор полей. Полное описание, которое он сформировал уже из требований. В каждой задаче у нас есть score, некоторая score, которая показывает нам, я, честно говоря, даже никогда с ней не работал, ну, в общем, какой-то скор задачи, которую можно быстро реализовать, помечается как "low effort", то есть это минимальный эффект и, соответственно, большие возможности для того, чтобы быстро его реализовать. Основные причины реализации, все причины реализации, анализ графов. То есть в данном случае у нас вот этот Avito XML Feed зависит от эпика, который называется "Avito XML Feed Import". Вот этот эпик, у него есть зависимость от наших задач, и мы можем до каждого из них посмотреть граф зависимости, потому что наши задачи, на самом деле, они не плоские. Когда мы хотим реализовать какую-то из вещей, нам нужно сначала предварительно сделать, например, модель. Уже на основе этой модели мы можем entity, на основании entity можем спроектировать наше API. И вот здесь, что важно, он проектирует прямо полную зависимость графов друг от друга, задач друг от друга.
Он, скорее всего, закончил, да? Соответственно, всё. Теперь у нас есть полностью задачи, какие нам необходимо сделать для того, чтобы начать с ними работать. Как мы видим, самая последняя задача требует вот куча всего предварительно сделанных задач для того, чтобы её можно было реализовать.
О'кей. Теперь у нас есть задача. Мы можем, соответственно, попросить его приоритизировать для того, чтобы можно было правильно сказать, что мы будем делать в первую очередь, что будем выполнять во вторую очередь. И он будет, соответственно, по каждой из задачи выставлять приоритет. Теперь он будет выставлять, что вот это мы делаем первое - контракты. Потом, соответственно, здесь ещё также нам нужно fit secrets, потом модель и так далее. То есть после того, как мы приоритизируем все вот эти задачи между собой, у нас получается полностью задача, зависимость между собой, какая какую блокирует, какой приоритет нужно сделать внутри и, соответственно, зачем.
Так как у него есть теперь контекст не только требований, но и задач, он может уже с учётом этих знаний приступать к реализации, что мы, собственно, и сделаем. Теперь про выполнение. Я люблю проверять не финальный результат, когда у нас уже всё готово, а потом ты говоришь: "Блин, ты пошёл совсем не туда", а позадачно. Поэтому можно попросить: "Начни с первой задачи и бери только её". Тем самым мы говорим: "Всё, вот твои задачи. Мы их приоритизировали. Теперь у тебя, соответственно, есть задача первая". Наша первая задача, вот он как раз сказал, принятие - это 01 задачка. Давайте посмотрим, что у нас там есть в этой задаче. 01. Вот это первое "agent feed". В Prisma нам должно добавить с определёнными полями и, соответственно, добавить релейшн. То есть мы сейчас сделаем Prisma, изменим схему Prisma для того, чтобы получить первое изменение. Можно, конечно, его сразу говорить: "А сделай всё". Как раз именно такая декомпозиция задач позволяет ему не терять контекст, понимать, на каком он этапе и что делает дальше. Но опять, мне как-то комфортнее, когда я всё-таки поэтапно проверяю, что он делает. И в BVI это делать достаточно удобно. Когда он сделает, я буду видеть сразу же дельту всех изменений. И как только он закончит, мы получаем изменения наших текущих моделей и контрактов, но в данном случае пока только Prisma. Когда он его будет реализовывать, соответственно, "Updating Prisma DNAMS agent feed model". После того, как я удовлетворюсь этой моделью, посмотрю, что все поля действительно такие, можно переходить к следующей задаче.
Готово. Теперь я могу открыть этот файл и посмотреть на список изменений. Вот у нас здесь есть `agent_feed`, который был добавлен. Есть `agent_id`, ссылочка на нашего `agent_id` из `enabled`, да, у нас есть, соответственно, агент со ссылкой на агент. Всё правильно. Когда модифицирован `sync_at` и `refresh_interval` в минутах. Дефолтный 720, как мы просили. Включён-выключен, что мы могли его включать-выключать. Логично, хотя этого не просил. Ну и, соответственно, `feed_type`. А `feed_type` у нас пока только один - это Avito XML. Но, в принципе, поддержка других фидов, не только Авито, это хорошая штука, которую можно сразу заложить. Поэтому супер, всё сделано корректно. Теперь он, соответственно, будет отмечать задачу как готовую. Вот она, 0.1. Как мы видим, статус у него поменялся вот здесь на "Done". И здесь у нас мы теперь понимаем, и он понимает, что было сделано. Теперь мы можем применить миграции, проверить, что всё о'кей, и переходить тем самым к следующей задаче.
Если хотите посмотреть на таски в более красивом виде, есть UI, который устанавливается также глобально и затем запускается. Можно даже перезаписать порт через порт. В результате вы получаете вот такой дашборд, где видно все issues. Вот она наша закрытая. Assign на кого назначена. Приоритет. Каждую issue, конечно же, мы можем открыть. Внутри располагается description. Здесь можно edit, короче, всё, что если вы хотите самостоятельно дополнить какие-то таски, чтобы AI получше правильные задачи, это тоже можно делать. Также список декомпозиции на эпики. Вот мы сейчас делаем один эпик "Avito XML Feed", которые сделали одну задачу. Ну а также борд, где показываются наши текущие задачи. У нас сейчас три задачи, которые готовы для взятия в работу, потому что мы сделали модели, а эти ещё не готовы. И как раз из репозитория агент будет брать и их выполнять.
Я надеюсь, что это видео было вам полезно. И ещё раз вас с наступающим или наступившим Новым годом.