Transcription
Приветствую. Сегодня у нас тема ну очень интересная из мира ИИ. Будем говорить про создание целых команд и агентов, таких, которые могут, ну, вместе работать над задачами. Да.
Привет. Тема действительно горячая. Мы возьмём за основу материал из одного YouTube руководства. Там обещают показать, как собрать такую команду буквально за пять шагов с помощью инструмента QI. QI. Ага. Звучит почти слишком просто, правда? Вот и посмотрим, что там на самом деле под капотом и насколько это всё реалистично.
Ну да, основная идея там использовать командную строку и конфигурационные файлы, текстовые такие файлы, чтобы быстро запустить группу ИИ, которые могут, ну, например, провести исследование и, скорее, составить отчёт. Интересно. Наша задача, значит, пройтись по этим шагам, как они показаны в видео, и, ну, понять механику, как это работает, где сильные стороны, может, где-то есть нюансы.
Отлично, давай погружаться. Значит, пять шагов. Руководство утверждает, что начать можно вот прямо очень быстро. Первый шаг, я так понимаю, - это подготовка инструментов.
Совершенно верно. Всё начинается с установки UV. UV. Что это такое? А это такой современный менеджер пакетов для Python. Ну, программа, которая помогает ставить другие программы, библиотеки, которые нужны для проекта. А, понятно. Инструмент для управления инструментами. Логично.
Именно. Видео там показывают команду для Мака. Но автор говорит, что и для Windows, и для Linux команды тоже есть. Ну, в описании к видео. И что важно, всё делается через командную строку, прямо в редакторе кода в IDE. В примере они используют курсор IDE, но, в принципе, подойдёт любой редактор с терминалом.
Так, хорошо, поставили UV. Что дальше? Какой второй шаг?
Шаг второй. Ставим сам CRW AI. Используем вот этот UV, который только что установили. Команда там UV Tool Install Crew AI. Это, по сути, добавляет сам фреймворк Crew AI в систему и его команды, которые нам дальше как раз и понадобятся.
Окей, подготовились. UV стоит, QI стоит. Шаг третий, создание самой команды. Вот тут, наверное, самое интересное начинается, да?
Тут уже в дело вступает команда самого Crew AI. Пишем create crew. Прямо так. Cru ai create? Да. Терминал после этого спросит имя для команды. Ну, видео они используют research crew. Забавный момент там есть. Если имя вот так с нижним подчёркиванием, то в коде потом имя класса будет в CamelCase, то есть ResearchCrew. А, ну это стандартная практика в коде в часто, да?
И вот после ввода имени начинается такой короткий интерактивный диалог. Система задаёт вопросы. Диалог не просто команда выполнилась и всё. А что спрашивает именно диалог? Сначала нужно выбрать LLM провайдера. Ну, источник мозгов, так сказать, для ИИ агентов. А какие там варианты? В примере, они выбирают Open AI. Потом нужно выбрать конкретную модель. В источнике указано GPT 4.1. GPT 4.1. Ну да, мощная модель, да. И последний вопрос про API ключ от Open AI. Можно его сразу ввести, если он есть, а можно пропустить и добавить потом. Автор видео как раз пропускает этот шаг.
Хмм, интересно, чтобы показать, как добавить вручную, наверное. Скорее всего, да. Показывают, что можно начать даже если ключа прямо сейчас нет под рукой. И что происходит после этого диалога? Что генерируется?
А вот тут CRI берёт и создаёт всю базовую структуру проекта. Прямо в редакторе кода появляется новая папка Research Crew. Внутри неё основной файл main.py. Он для запуска. Потом папка config. Там лежат файлы конфигурации Agents.yaml и Tasks.yaml. Ага. YAML файлы для настроек, да. И ещё подпапка crew, а в ней файл research_crew.py. Вот в нём уже определяется сама команда, агенты, задачи. И что важно, по умолчанию создаётся сразу два агента: исследователь, researcher и аналитик-отчётчик. Reporting analyst. Сразу два готовых. Ну как готовых, их скелеты, так сказать. И для них две задачи. Одна для исследования, другая для написания отчёта по результатам исследования. И они настроены на последовательное выполнение. Сначала один, потом другой. Одной командой и сразу каркас проекта с двумя агентами, задачами, файлами. Звучит очень удобно, конечно.
Хорошо, шаг четвёртый. Тогда это тот самый API ключ, который пропустили. Куда его вписывать?
Тут всё стандартно, на самом деле. Нужно пойти на сайт OpenAI, ну, platform.openai.com, там в настройках создать API ключ, если его ещё нет, скопировать его, а потом вернуться в папку проекта, вот эту. Research Crew. Там найти файл .env. Точка env - это который для переменных окружения. Да, именно стандартный файл для всяких настроек, секретов, чтобы они в коде не светились. И вот в этот .env файл нужно добавить строку OPENAI_API_KEY = и дальше сам ключ. OPENAI_API_KEY = ваш ключ. И сохранить файл, конечно.
Понятно. Ключ хранится отдельно, безопасно. Логично. И что? Остался пятый шаг. Запуск.
Да, финал. Сначала в терминале нужно перейти в папку проекта команда cd research_crew, а потом просто выполнить crew ai run. Crew ai run и всё. Да, эта команда довольно умная. Она сначала проверяет зависимости проекта, ну, какие библиотеки нужны. Для этого она смотрит файл pyproject.toml, он тоже генерируется. Потом она создаёт изолированное виртуальное окружение. Это чтобы вот этот проект со своими библиотеками не конфликтовал с другими на компьютере. А, это хорошо. Практика хорошая. Да. И, наконец, она запускает выполнение самой команды. Через тот самый main.py.
И что мы видим в терминале? Как это выглядит?
Ну, в видео там забавный момент. Первая попытка запуска падает с ошибкой. Ой, а почему? А потому что автор забыл сохранить файл .env после того, как вставил ключ. Там в редакторе точка осталась на вкладке. Ну, индикатор несохранённых изменений. Ха, бывает. Мелочь. А, приятно, что показали. Да, это частая ошибка, но вот он сохраняет файл, запускает crew ai run ещё раз, и всё идёт как надо. В терминале прямо видно логи. Вот начал работать первый агент Senior Data Researcher. Он выполняет свою задачу, исследует тему AI LLM, выдаёт результат такой final answer. Угу. Потом сообщение task completed и запускается второй агент Reporting Analyst. Он берёт результат первого агента. То есть они обмениваются информацией, да? Результат первого передаётся второму. Второй агент на основе этого пишет отчёт. Опять final answer от него. Task completed и сообщение crew complete. И всё. Отчёт где-то появляется. В папке проекта появляется файл report.md. Markdown файл с готовым отчётом.
Слушай, ну это и правда похоже на пять шагов. Почти без кода. Только ключ скопировать, да пару команд в терминале для старта. Впечатляет. Но это ведь базовый пример, да? Самая мякотка, наверное, в том, как это всё настроить под свои нужды.
Так, что же всё это значит? Давай копнём глубже. Вот эти файлы, что там внутри? Начнём с main.py. Что он определяет?
Да, main.py - это, по сути, точка входа. Как в видео показано, там главная часть - это функция run. И вот внутри неё мы задаём входные данные для нашей команды. В базовом примере это была тема исследования topic = AI LLM и текущий год. Ну, чтобы в отчёте был актуальный год. Ага. Эти данные упаковываются в словарь inputs. И этот словарь передаётся команде, когда мы её запускаем, методом kickoff. Вот так. ResearchCrew.kickoff(inputs=inputs). То есть kickoff - это старт команды с параметрами, да? И самое классное, что вот эти input.topic, current_year, их можно использовать как переменные внутри конфигурации агентов и задач. Автор как раз показывает, он просто меняет в main.py тему на GRPC AI, перезапускает, и команда уже исследует GRPC AI. Очень гибко. То есть main.py - это как бы панель управления для запуска команды с разными параметрами. Ну, можно и так сказать. Место, где задаются входные данные для конкретного запуска.
Понятно. А где описывается сама структура команды? Какие агенты, какие задачи, как они между собой связаны? Вот это всё где?
А это уже в файле имя команды .py. В нашем случае research_crew.py, который лежит в папке crew. Там определяется класс команды. У нас это ResearchCrew. Он наследуется от базового класса CrewBase из библиотеки CrewAI. И внутри этого класса используются такие специальные штуки, декораторы. @agent и @task. Декораторы - это что такое? Это такие маркеры в Python, начинаются с символа @. Они как бы помечают функции. @agent ставится над функцией, которая создаёт агента, а @task над функцией, которая создаёт задачу. Например, @agent над def researcher(self) и @task над def research_task(self). И что внутри этих функций? А внутри как раз самая важная ссылка на конфигурацию из YAML-файлов. Например, для агента-исследователя там будет что-то вроде config = self.config.get_config('agents', 'researcher'), то есть возьми настройки для researcher из файла agents.yaml. И ещё в классе команды можно указать, куда сохранять финальный отчёт, как в примере output_log_file = 'report.md'. Ага. То есть Python код определяет саму структуру. Вот агент, вот задача, они связаны вот так. А настройки бери из YAML. А вся конкретика, что именно делает агент, какая у него цель - это всё в YAML.
Именно. Вот здесь становится действительно интересно. Вся логика поведения, все промпты для LLM, они вынесены в эти файлы. Расскажи про них подробнее. Agents.yaml и Tasks.yaml. Почему YAML? Почему не JSON, например?
Ну, YAML часто выбирают для конфигурации, потому что он считается более читаемым для человека, чем JSON. Меньше скобок, кавычек, проще редактировать вручную. Логично.
Итак, что в Agents.yaml?
В Agents.yaml мы описываем каждого агента. Для каждого агента есть как минимум три ключевых поля: роль, его роль. Например, старший исследователь данных по теме {topic}. Заметь, вот она, переменная topic из main.py используется прямо тут. А, удобно, да? Потом goal - цели агента. Что он должен достичь? Например, найти самую актуальную информацию по теме {topic}. И backstory - это как бы контекст для LLM, чтобы она лучше вжилась в роль. Типа ты опытный исследователь с десятилетним стажем в области ИИ. Забавно. Прямо ролевая игра для ИИ в каком-то смысле. Да. Это помогает модели лучше сфокусироваться на задаче.
А что в Tasks.yaml?
А там описываются задачи. Для каждой задачи тоже есть ключевые поля. Description - подробное описание того, что нужно сделать. Опять же, можно использовать переменные типа {topic}. Expected output - очень важное поле. Что конкретно ожидается на выходе? В каком формате? Чем детальнее, тем лучше результат. То есть прямо указываем, какой отчёт мы хотим видеть. Да, например, подробный отчёт в формате Markdown, включающий основные концепции, ключевых игроков и последние тренды по теме {topic}. И последнее ключевое поле agent. Какому агенту из agents.yaml поручается эта задача? Например, agent: researcher.
Понятно. Агент, его цель, его задача, ожидаемый результат. Всё в текстовых файлах.
Именно. И вот эти файлы YAML - это и есть главная площадка для кастомизации. Хочешь изменить поведение, идёшь и редактируешь текст в YAML. Можно менять роли, цели, можно делать описание задач супердетальными, можно добавлять новых агентов, новые задачи. Автор видео даже упоминает, что можно попросить чат GPT написать хорошие промпты для ролей и задач, а потом просто скопировать их сюда. Интересный лайфхак, да? И ещё момент. Агентов может быть меньше, чем задач. Один агент вполне может выполнить несколько задач последовательно, если их ему назначить в Tasks.yaml. То есть настройка - это реально редактирование текста. Не нужно глубоко лезть в Python код, чтобы поменять логику работы команды. Для базовых и средних изменений, да, основная логика поведения агентов задаётся через эти текстовые промты в YAML. Это действительно сильно снижает порог входа.
Хорошо. Но насколько сложными могут быть такие команды? Вот этот базовый пример с двумя агентами, он понятен. А что насчёт более комплексных задач? В видео же был второй пример про скоринг лидов. Lead scoring crew. Верно.
Пример Lead Scoring Crew. Он как раз показывает, что подход масштабируется, и там уже всё серьёзнее. Во-первых, в main.py там передаётся гораздо больше входных данных. Не просто тема, а прямо транскрипт звонка с клиентом, название компании, имя контакта, продукт, который обсуждали, год, скоринг и так далее. Некоторые со значениями по умолчанию. Ого. То есть на вход уже идёт реальный рабочий материал. Да. Во-вторых, сама команда намного сложнее. Там уже целых пять агентов. Пять. А какие роли? Первый - transcript cleaner. Его задача почистить транскрипт. Ну, убрать всякие э-э, угу, артефакты распознавания речи. Полезно. Второй - lead extractor. Он из очищенного транскрипта должен извлечь ключевые факты: имя компании, контактное лицо, индустрию, боли клиента, что ему нужно. Третий - insight prioritizer. Этот агент берёт извлечённые факты и анализирует их глубже. Ищет инсайты, какие-то скрытые потребности, возможные блокеры для сделки. Что осталось непонятным, какие следующие шаги рекомендовать? То есть уже аналитика пошла, да? Четвёртый - lead scorer. Вот он как раз оценивает лид по шкале: горячий, тёплый, холодный. И пятый - report builder. Собирает все результаты предыдущих агентов и пишет итоговый структурированный отчёт. Пять агентов, целый конвейер по обработке информации и звонка. И для каждого надо полагать свои настройки в естественно. Конфигурации в agents.yaml и tasks.yaml для этой команды гораздо более детализированные. Описание ролей, целей, задач - всё намного подробнее. Особенно expected output для задач. Там чётко прописано, что должен выдать каждый агент.
А как происходит выполнение? Также crew ai run.
Да, запуск аналогичен. Переходим в папку Lead Crew, выполняем crew ai run. Команда берёт тот транскрипт, который указан в main.py. Там есть пример, и начинает работать. Агенты выполняются последовательно, передавая результат друг другу. Сначала чистка транскрипта, потом извлечение фактов, потом анализ инсайтов, потом скоринг и в конце отчёт.
Звучит мощно. А появилось ли что-то новое в этом примере с точки зрения механики CrewAI, кроме того, что агентов стало больше?
Да, появилось, и это очень важный момент, использование инструментов. Инструментов, да. Вот тот четвёртый агент lead scorer, который оценивает лид, он не просто анализирует текст с помощью LLM, он использует специальный внешний инструмент для расчёта оценки. Внешний инструмент, то есть можно подключать что-то своё, не только возможности языковой модели.
Вот именно. CrewAI позволяет агентам вызывать внешние функции, написанные на Python, или даже обращаться к каким-то API.
Расскажи подробнее, как это работает, сложно ли добавить свой инструмент.
Совсем не сложно, как показано в видео. В структуре проекта появляется папка Tools. В ней можно создать свой Python-файл, ну, скажем, custom_tools.py. Внутри этого файла пишется обычная функция на Python, например, calculate_lead_score. Она принимает на вход какие-то данные от агента, например, словарь с информацией о лиде. Внутри функции реализуется нужная логика. В примере со скорингом там просто расчёт балла по весам: за наличие бюджета плюс 10 баллов, за чётко выраженную потребность плюс 20 и так далее. А, то есть кастомная логика, которую сама LLM не сделала бы или сделала бы плохо, да? Или, например, обращение к базе данных или вызов какого-то внешнего API. Всё, что угодно, что можно написать на Python. Функция что-то вычисляет или получает и возвращает результат агенту. И чтобы CrewAI понял, что это инструмент, эту функцию нужно пометить декоратором @tool. Tool.
Понятно. А как агент понимает, что ему нужно использовать именно этот инструмент и когда?
Тут два момента. Во-первых, в конфигурации самого агента agents.yaml для lead_scorer есть секция tools. Там прямо перечисляется, к каким инструментам у этого агента есть доступ. Например, tools: - calculate_lead_score, то есть агент знает о существовании инструмента, да? А во-вторых, в его промтах, в goal, backstory и особенно в описании его задачи в tasks.yaml, ему объясняется, что для оценки лида нужно использовать инструмент calculate_lead_score и какие данные ему нужно собрать и передать в этот инструмент. То есть LLM, которая управляет агентом, обучается распознавать ситуацию и вызывать нужный инструмент с правильными параметрами.
Совершенно верно. Агент понимает: "Ага, мне нужно посчитать скоринг. У меня есть инструмент calculate_lead_score. Я собрал вот такие данные, вызываю инструмент с этими данными".
Это просто потрясающе. Это же радикально расширяет возможности. Можно подключать свою логику, свои расчёты, интегрироваться с внутренними системами компании, с внешними сервисами. Получается, агенты - это не только про текст.
Именно так. Инструменты - это ключ к созданию действительно мощных и полезных команд, которые могут выполнять сложные, многогранные задачи, выходящие за рамки простого анализа и генерации текста.
Какой же результат работы этой сложной команды скоринга получился в видео? Что в итоговом отчёте?
Отчёт Lead Report получается очень структурированным и подробным. Видео показывает пример. Сначала идёт таблица с квалификацией лида по разным параметрам: бюджет, сроки, потребность. Потом раздел с ключевыми инсайтами, которые нашёл третий агент. Угу. Затем блокеры и риски, которые он выявил. Отдельно, что осталось непонятным, Unknowns. Дальше детальный расчёт скоринга от четвёртого агента. Прямо с весами, которые использовались, и итоговый балл. В примере что-то около 89. Прямо видно, как балл получился. Да. И в конце текстовые резюме с итоговой оценкой и категорией лида, например: "Очень сильная срочная потребность. Рекомендуется немедленно связаться". Категория: горячий лид. Впечатляет. То есть из сырого транскрипта звонка получился полноценный аналитический отчёт с оценкой и рекомендациями. И всё это работа команды и агентов.
Да, это отличная демонстрация того, как можно автоматизировать довольно сложный аналитический процесс, разбив его на логические шаги и поручив каждый шаг специализированному агенту и используя кастомные инструменты там, где нужна специфическая логика или вычисление.
Да уж, пример со скорингом гораздо интереснее, чем просто исследование темы. Хорошо, давай тогда подводить итог нашему разбору. Судя по тому, что мы увидели в материале, CrewAI предлагает такой фреймворк, да, для создания вот этих мультиагентных систем. Основной инструмент - командная строка и конфигурация через YAML файлы.
Да, именно фреймворк. Он даёт структуру и базовые механизмы. И начальная настройка, вот эти пять шагов выглядит действительно простой. А дальше возможности кастомизации через YAML и что особенно важно, через добавление своих инструментов на Python. Это позволяет строить уже довольно сложные рабочие процессы.
Совершенно верно. В чём, на твой взгляд, главная ценность такого подхода, вот именно CrewAI и подобных инструментов?
Если связать это с общей картиной, я бы сказал, что главная ценность - это, ну, своего рода демократизация создания мультиагентных систем. Демократизация в каком смысле? В том смысле, что не нужно быть гуру в области ИИ и писать тонны сложного кода с нуля, чтобы начать экспериментировать с командами агентов. CrewAI берёт на себя вот эту базовую механику: как агенты общаются, как передают задачи, как выполняется последовательность. То есть снижает порог входа.
Да, значительно. Это позволяет людям, разработчикам, аналитикам, даже менеджерам сосредоточиться на самом главном, на проектировании. Какие роли нужны, какие задачи, как должен выглядеть поток информации, какие инструменты подключить. И это открывает огромные возможности для автоматизации, для тех задач, которые рутинные, но состоят из многих этапов: сбор информации, её реструктуризация, анализ, подготовка отчётов, принятие каких-то решений на основе данных, как в примере со скорингом лидов.
Да, снижение порога входа - это всегда мощный катализатор для инноваций. Люди начинают пробовать то, что раньше казалось слишком сложным. И вот тут в завершении наша традиционная мысль для размышления. Подумайте вот о чём. Мы увидели, как относительно просто можно настроить команду ИИ агентов с помощью таких инструментов, как CrewAI, и увидели гибкость кастомизации через YAML и особенно через инструменты. И вопрос такой: какие сложные многоэтапные рабочие процессы есть в вашей сфере? Что-то, что сейчас требует много ручного труда или сложной координации между разными людьми или отделами? Можно ли это переосмыслить с помощью команды ИИ агентов?
Да, подумайте о комбинациях. Какие уникальные роли могли бы быть у ИИ агентов? Не просто исследователь и писатель. Может быть, ИИ генератор идей, и критик, и ИИ редактор, или ИИ аналитик данных, и ИИ прогнозист, и визуализатор. А какие кастомные инструменты им можно было бы дать? Интеграцию с вашими внутренними CRM или ERP системами, анализ каких-то специфических данных, характерных только для вашей отрасли, может, генерацию не только текста, но и, скажем, программного кода или изображений. Где в ваших процессах есть вот та самая неэффективность, рутина или сложность, которую могла бы взломать правильно спроектированная команда ИИ? И какие совершенно новые возможности или продукты могли бы появиться, если бы такая команда у вас заработала? Вот об этом и предлагаем подумать.
Спасибо, что были с нами. Да, спасибо. До новых встреч.