Сравнение AutoGen и CrewAI: создание команд агентов и подсчёт их стоимости

В течение длительного времени в области практического применения больших языковых моделей взаимодействие с ИИ представляло собой простой цикл: кто-то вводит запрос, модель отвечает, и чат продолжается. Это хорошо работает для ответов на вопросы. Однако такой подход начинает давать сбои, когда нужно выполнить конкретную задачу, такую как написание и отладка программы, подготовка исследовательского отчета или выполнение многоэтапной работы, в которой задействовано несколько инструментов и источников данных.

Для преодоления этой проблемы существуют многокомпонентные системы. Вместо того чтобы передавать всю информацию в один монолитный запрос, задача делилась на роли: инженер, критик, исследователь, писатель. Каждая роль становится агентом — оболочкой вокруг ЯЗЫКА больших моделей, имеющей собственный образ, память и обязанности. Агенты общаются друг с другом, передают частичные результаты, критикуют друг друга и постепенно улучшают работу до её завершения. Этот процесс больше похож на управление небольшой, очень быстрой командой, чем на обращение к оракулу.

В этой области доминируют две платформы, которые здесь сравниваются: AutoGen, выпущенный Microsoft Research в виде открытого кода, и CrewAI — более новая платформа, разработанная с учётом корпоративных рабочих процессов. Третий инструмент, AgentOps, добавляет слой наблюдаемости, позволяющий видеть, что делают агенты и сколько это стоит.

Роли вместо одного большого запроса

Концептуальный сдвиг происходит ещё до появления каких-либо инструментов. В схеме с одним агентом один системный промпт выполняет две функции одновременно: определяет персонажа и предвосхищает возможные запросы к модели. Фреймворки с несколькими агентами распределяют нагрузку. Каждый агент получает более четкое описание задачи, включающее персонажа, цель и, иногда, предысторию, которая влияет на его подход.

Это имитирует способ работы человеческих команд. Старший инженер не является одновременно рецензентом качества, менеджером проекта и техническим писателем. Разделение этих функций между агентами приносит три практических преимущества:

• Специализация повышает качество. Агент, чья единственная задача — проверка кода на наличие проблем с безопасностью, будет анализировать его более систематично, чем универсал, выполняющий несколько задач одновременно.
• Циклы обратной связи становятся явными. Перенаправление результатов работы одного агента другому, чья задача — их оценить, создаёт целенаправленный цикл проверки вместо ожидания того, что тот же самый модель сама обнаружит свои ошибки.
• Возможна параллельная работа. В более сложных системах агенты могут одновременно заниматься разными частями более крупной цели, причём агент для исследований и агент для написания выполняют отдельные подзадачи.

Самая сложная проблема, которую каждая платформа решает по-своему, — это коммуникация. Как агенты обмениваются информацией? Они ведут один общий диалог или ведут изолированные переговоры, которые лишь иногда пересекаются? Ответы на эти вопросы различаются у AutoGen и CrewAI, и именно эти различия определяют всё остальное.

AutoGen: всё — это диалог

AutoGen от Microsoft рассматривает каждое взаимодействие агентов как разговор. Основное решение при его создании заключалось в том, что агенты должны общаться друг с другом на естественном языке, как это делают люди в чате. Это делает его интуитивно понятным: любой, кто видел, как два коллеги в канале Slack обмениваются мнениями для усовершенствования идеи, уже имеет представление о принципах работы агентов AutoGen, способных вести диалог.

Попробовать в AutoGen Studio

Прежде чем писать хоть какой-то код на Python, AutoGen Studio предоставляет графический интерфейс для экспериментов. Его устанавливают с помощью pip, он загружает ключ API из переменной среды и запускается посредством одного командного запроса. Затем открывается интерфейс браузера. Там вводится задача, после чего прокси-агент пользователя взаимодействует с одним или несколькими помощниками-агентами до её выполнения.

Этот шаблон стоит изучить, поскольку он встречается повсюду. Предположим, задача — отобразить динамику популярности поискового термина со временем. Помощник-агент начинает генерировать фрагменты кода для подзадач. Затем агент-прокси пользователя запускает эти фрагменты в изолированной среде и оценивает, правильным ли является результат. Если код не работает или вывод неверен, прокси отправляет обратную связь, помощник вносит коррективы, и цикл «код → выполнение → оценка → корректировка» продолжается до тех пор, пока прокси не будет удовлетворен.

Этот цикл автоматизирует ту часть процесса ревью кода, которая требует участия человека. В обычной сессии разработчик пишет код, запускает его, наблюдает за его сбоями и лично исправляет ошибки. Здесь прокси берет на себя шаг запуска и проверки, поэтому человек может уйти, пока два агента разбираются с проблемой. Этот метод не идеален, поскольку измененные библиотеки или устаревшие функции иногда мешают агентам, но для хорошо определенных проблем он оказывается чрезвычайно эффективным. Генерация изображений, визуализация данных и небольшие приложения часто готовы уже после нескольких итераций.

Постоянно появляется одна рекомендация: запускать AutoGen и AutoGen Studio внутри Docker каждый раз, когда генерируемый код может взаимодействовать с операционной системой. Агенты предназначены для написания и выполнения произвольного кода, поэтому контейнер защищает хост-систему от побочных эффектов. Этот совет становится еще более актуальным по мере того, как агентам предоставляется больше автономии.

Навыки как дополнительные способности

Студио поставляется с лишь несколькими встроенными инструментами, такими как загрузка веб-контента или генерация изображений. Его настоящая сила заключается в пользовательских навыках. Навык представляет собой обычную функцию на Python с четким именем и хорошо написанной документацией, и фреймворк читает эту документацию, чтобы определить, когда и как её вызвать.

В примере реализации описывается навык describe_image, который отправляет изображение на модель с возможностями визуального восприятия и получает обратно его описание. После регистрации у главного ассистента это позволяет формулировать довольно конкретные запросы: создать обложку книги по заданному названию, а затем использовать навык image-description для проверки правильности написания названия. Генераторы изображений крайне плохо справляются с читаемым текстом, поэтому это образует естественный цикл проверки. Ассистент создаёт изображение, навык визуального анализа проверяет надпись, и если она неверна, ассистент пытается снова. Создание небольших, хорошо задокументированных инструментов обеспечивает удивительно стабильное функционирование системы.

В основе всего этого лежит определённая философия проектирования. Вместо того чтобы рассчитывать на то, что агенты будут писать совершенно новый код для каждой задачи, часто более надёжно предоставить им готовую библиотеку проверенных инструментов. Код, написанный LLM в реальном времени, может сломаться при изменении библиотек или зависимостей, тогда как тщательно протестированные и упакованные инструменты работают предсказуемо. Вопрос о том, должны ли агенты писать код динамически или использовать готовые инструменты, рассматривается позже в контексте планирования и действий, и это один из наиболее важных факторов при проектировании системы агентов.

Чистый код с pyautogen

После Studio следующим шагом является написание кода на Python с использованием пакета pyautogen. Важны два ключевых элемента:

• ConversableAgent — универсальный агент, который взаимодействует напрямую с LLM.
• UserProxyAgent представляет человека-пользователя и может выполнять код в рабочей директории.

Минимальная настройка соединяет их и запускает диалог, например, с просьбой предоставить решение задачи FizzBuzz в одной строке. При запуске прокси запрашивает отзыв после того, как ассистент что-то предлагает. Нажатие Enter без отзыва означает, что нужно продолжить и самостоятельно запустить код. Если отсутствует необходимый пакет, такой как Pygame, прокси устанавливает его перед запуском программы. Такое самостоятельное обеспечение — небольшой, но значимый признак свободы, которая может быть предоставлена этим системам, с одновременными плюсами и минусами.

Полезные задачи на программирование для оценки моделей включают проверку того, является ли число простым, создание игры Snake и клонирование игры Asteroids с использованием Pygame. Они являются самодостаточными, поддающимися тестированию и достаточно разнообразными по уровню сложности, чтобы выявить различия между моделями или конфигурациями.

Добавление критика с помощью вложенных чатов

Помощник вместе с прокси полезны, но многопроцессные системы демонстрируют наилучшие результаты благодаря специализированным персонажам. Второй помощник может выполнять функции рецензента кода, при этом системное сообщение обеспечивает тщательную проверку, строгое соблюдение стандартов и акцент на проблемах безопасности и качества.

Вместо того чтобы сразу включать рецензента в основной диалог, AutoGen предоставляет возможность использования вложенных чатов. Прокси пользователя регистрирует вложенный чат, который активируется каждый раз, когда агент-инженер генерирует новый результат. Код автоматически передается рецензенту в отдельном диалоге; рецензент отвечает с комментариями, которые затем возвращаются в основной поток обсуждения. Таким образом, этап рецензирования вставляется без лишнего вмешательства рецензента в каждый этап диалога, и он высказывается только тогда, когда есть что проверить.

При выполнении задачи вроде создания игры Snake с использованием Pygame разница по сравнению с обычной работой инженера с прокси заметна. После выполнения кода появляется специалист, предлагающий список улучшений, что фактически воспроизводит процесс рассмотрения pull-реквестов, который ежедневно проводят команды из людей.

Кэширование для контроля затрат

Обмен сообщениями между несколькими агентами быстро становится дорогостоящим. Каждый обмен потребляет токены, а сложные задачи могут требовать десятков итераций. AutoGen включает систему кэширования: по умолчанию состояние разговора сохраняется на диске в папке .cache, что позволяет возобновить длительную или прерванную задачу без необходимости оплаты тех же токенов дважды.

Это поведение можно явно настроить, обернув вызов чата в менеджер контекста, который предоставляет параметр cache_seed. Важность этого аспекта легко недооценить. При разработке агентов часто возникает необходимость повторного запуска или аудита предыдущей сессии вместо её повторной генерации — будь то для отладки или для того, чтобы показать заинтересованным сторонам, как именно агент пришёл к определённому результату.

Групповой чат и проблема передачи информации

Вложенные чаты имеют структурную слабость, напоминающую детскую игру «телефон». Информация передаётся от одного агента к другому по цепочке, и при каждой передаче детали теряются, искажаются или интерпретируются по-новому. Если рецензент никогда не видит полную исходную задачу, а только то, что инженер решил передать, его отзыв может не учитывать суть проблемы.

Решением AutoGen является групповой чат. Объект GroupChat обеспечивает единый пул агентов и сообщений, схожий с командным каналом, вместо серии точечных ретрансляторов. GroupChatManager координирует порядок ответов, чтобы агенты не отвечали одновременно. Ключевой особенностью является то, что каждый участник может видеть всю историю переписки, а не только ту информацию, которая ему прямо передана.

Повторное использование примера с инженером и критиком с групповым чатом обеспечивает более целостное сотрудничество. Комментарии критика основаны на том же полном контексте, что и у инженера, и инженер может напрямую отвечать на конкретные замечания, вместо того чтобы работать с их перефразированием. Как и следовало ожидать, ценой этого является избыточность изложения. Групповые разговоры потребляют больше токенов, поскольку каждый агент фактически прослушивает каждый обмен сообщениями, что имеет значение при оплате за токен в крупных масштабах.

Чему учат ранние примеры

В совокупности сессии в студии и эксперименты с необработанным кодом выдвигают несколько принципов, применимых к любому проекту с использованием агентов. Задача должна быть достаточно простой, чтобы можно было проверить её успешное выполнение, поскольку цикл прокси работает только тогда, когда существует способ определить, верен ли результат. Выполнение должно быть изолированным, так как та же самостоятельность, которая делает цикл полезным, позволяет ему устанавливать пакеты и запускать произвольные программы. Проверки легко добавить после того, как будут определены роли, поэтому критик почти всегда стоит попробовать. Кроме того, затраты следует учитывать с самого начала проектирования: кэширование, повторная обработка данных и оценка количества шагов, необходимых для выполнения задачи, являются частью создания системы, а не последующими доработками.

Существует также урок о том, где следует прилагать усилия. Написание хорошего сообщения системы для критика или четкого документирования способности значительно больше влияет на поведение, чем добавление новых агентов. Оба фреймворка поощряют точные, конкретные описания того, для чего предназначен каждый агент.

CrewAI: структура вместо импровизации

В то время как AutoGen ориентирован на свободные диалоги, CrewAI более структурирован и имеет четкую направленность, ориентированную на бизнес- и производственные среды. Вместо свободного диалога он требует трех четких определений: агентов с их ролями, целями и предысторией; задач, которые им поручаются; и команды, объединяющей их в рамках определенной стратегии обработки.

Что входит в состав агента

Агент CrewAI настраивается с помощью нескольких параметров:

• role: краткое описание функции агента, например, «Старший исследователь шуток».
• goal: описание на естественном языке того, чего стремится достичь агент, часто в шаблоне для повторного использования с разными входными данными.
• backstory: повествование, формирующее персонажа, которое предоставляет контекст и характеристики личности, подобно системному промпту для персонажа.
• memory и verbose: флаги, определяющие, будет ли агент сохранять контекст между взаимодействиями, и будет ли он выводить свои рассуждения в консоль.
• allow_delegation: возможность агента передавать задачи другим участникам команды.

Задачи определяются отдельно. Каждая из них содержит описание работы, поле expected_output, описывающее, каким должен быть результат для агента и читателя, ссылку на ответственного агента, а также опции, такие как выполнение асинхронно или запись результата в файл.

Объект Crew объединяет агентов и задачи вместе с настройками того, как будет происходить сотрудничество — последовательно или иерархически, а также предоставляет опции для обмена информацией, кэширования и ограничения количества запросов в минуту для контроля использования API.

Забавный пример: команда шуток

Чтобы сделать это конкретным, создаётся команда из двух агентов, занимающихся шутками. Старший исследователь шуток анализирует, что делает тему смешной, и отмечает соответствующие социальные тенденции, в то время как автор шуток преобразует эти исследования в реальные шутки. Исследователь может делегировать задачи, а автор — нет. Это разумное разделение обязанностей, поскольку автор должен выполнять последний этап в процессе создания шутки, а не выступать центром, который распределяет работу дальше.

Если рассмотреть тему вроде шуток о инженерах ИИ, команда генерирует по-настоящему забавный контент с помощью процесса сначала исследования, затем написания, вместо использования одного монолитного запроса. Хотя это и кажется глупым, это иллюстрирует, почему разделение понимания темы и создания творческого результата может привести к более продуманному выводу. Подготовительная работа исследователя служит основой для автора, подобно миниатюрному этапу поиска информации, встроенному в рабочий процесс.

AgentOps: отслеживание расходов

Разработчики агентов постоянно сталкиваются с одной и той же проблемой: сколько стоит их работа и куда девается время? Если многокомпонентные системы агентов оставлять без контроля, они могут привести к внушительным счетам, поскольку каждая передача данных между агентами, делегирование задач и вызов инструментов в конечном итоге суммируются. AgentOps — это платформа для мониторинга поведения агентов на основе больших языков моделей, отличная от традиционных инструментов MLOps, которые не были созданы для автономных, конверсационных агентов.

Добавить её в проект CrewAI не составляет труда: установите пакет, получите ключ API, внесите его в настройки среды и инициализируйте библиотеку в начале скрипта. Затем каждая работа команды фиксируется в панели управления, отображающей:

• общую продолжительность работы и среду, в которой она выполнялась,
• количество токенов входного запроса и результата для каждого вызова большой языковой модели,
• время выполнения каждого отдельного вызова,
• приблизительную стоимость всей работы в долларах.

Последний пункт вызывает удивление при первом прочтении. Одна лишь реализация шутки, которая кажется тривиальной для человека, стоит немалую сумму — долю доллара — если учесть все промежуточные этапы обработки, делегирование задач и вызовы инструментов. Для тех, кто создаёт системы агентов с коммерческими целями, это важное напоминание о реальности: оркестрация агентов — мощный инструмент, но он не бесплатен, а возможность отслеживания превращает абстрактные затраты в конкретные цифры, которые можно заложить в бюджет и оптимизировать.

Команда по разработке игр

Для прямого сравнения с примерами кодирования AutoGen в CrewAI используется небольшая команда по разработке игр из трёх агентов:

1. Старший инженер по программному обеспечению пишет реализацию на Python для любой запрошенной игры.
2. Инженер по контролю качества программного обеспечения проверяет код на наличие дефектов: от отсутствия импортов и неравномерности скобок до уязвимостей в безопасности и ошибок в логике.
3. Главный инженер по контролю качества может делегировать задачи, но несет окончательную ответственность за подтверждение того, что готовый код соответствует первоначальным требованиям.

Задачи выполнены в соответствии с такой же структурой: один человек создает первоначальную реализацию, второй проверяет ее на дефекты, а третий объединяет обе версии в окончательную, исправленную версию. Эта трехэтапная процедура проверки — написание, анализ и завершение — представляет собой более сложную версию подхода AutoGen, основанного на взаимодействии инженера и критика, реализованного в CrewAI через декларативное разделение задач и агентов.

Когда скрипт запускается интерактивно и запрашивает, какой тип игры нужен и как она должна вести себя, код обычно оказывается значительно более отлаженным по сравнению с тем, который создается одним автономным программистом без руководства. Одной из причин этого является то, что контроль со стороны главного инженера по качеству позволяет обнаружить проблемы, которые в противном случае могли бы остаться незамеченными.

Последовательная обработка против иерархической

CrewAI предлагает два способа организации работы команды над задачами, и правильный выбор имеет большое значение.

Последовательная обработка — это стандартный и самый простой вариант. Задачи выполняются одна за другой в определенном порядке, причем каждый агент заканчивает свою работу перед тем, как передать ее следующему. Этот подход подходит для процессов, в которых этапы действительно зависят друг от друга в фиксированном порядке: сначала исследования, затем написание кода, или сначала реализация, затем проверка и окончательная доработка.

Иерархическая обработка предполагает наличие менеджера над командой, обычно это собственное подключение к LLM, используемое исключительно для координации; такой менеджер контролирует агентов и задачи, вместо того чтобы заставлять их действовать синхронно. Переключение между режимами происходит легко: достаточно указать Process.hierarchical вместо Process.sequential и задать параметр manager_llm, как правило, это экземпляр ChatOpenAI с параметром temperature равным нулю для более стабильных решений по контролю.

На бумаге иерархический режим должен давать преимущество, поскольку роль менеджера отражает способ функционирования крупных человеческих организаций. Однако эксперименты показывают обратное. Согласно AgentOps, выполнение одной и той же игровой задачи под управлением иерархического менеджера стоило в два с лишним раза дороже, причем код при этом не становился значительно лучше. Это показатель, заставляющий задуматься. Добавление координации, надзора и слоев агентов не всегда улучшает результаты, и многокомпонентные системы так же легко могут попасть в дорогостоящие и неэффективные циклы, когда никто внимательно не следит за ними.

Ловля вышедших из-под контроля агентов

Этот вывод связан с тонкой причиной неудач: повторяющимися шаблонами мышления. Агент, не уверенный в собственном результате, может постоянно возвращаться к вариантам одной и той же идеи вместо того, чтобы принять решение и двигаться дальше, тратя ресурсы без реального прогресса.

В AgentOps существует визуализация Repeat Thoughts, предназначенная именно для этой цели — она показывает, с какой частотой процесс рассуждений агента возвращается к похожему контенту в ходе выполнения задачи. Чрезмерное повторение является сигналом о необходимости изменения каких-то структурных аспектов. Возможно, описания задач слишком неоднозначны, возможно, для уровня сложности задачи задействовано слишком много агентов, или же режим обработки требует дополнительного анализа. Подобные диагностические инструменты позволяют отличить случайные эксперименты от систематической работы высокого качества. Лучше заметить проблемы сразу, чем ждать слишком большого счета.

Стили коммуникации рядом друг с другом

Вопрос, заданный в начале о том, как агенты передают информацию друг другу, теперь имеет конкретные ответы. AutoGen предлагает два варианта. Встроенные чаты передают материал через вспомогательные разговоры, что сохраняет порядок в основном потоке общения, но создаёт риск потери деталей при каждой передаче. Групповой чат позволяет всем видеть полную историю общения, что улучшает целостность информации, но требует больше ресурсов. CrewAI избегает необходимости выбора, явно определяя процесс передачи: каждая задача указывает своего агента и ожидаемый результат, а настройки процесса определяют, будут ли результаты передаваться дальше по цепочке или через менеджера. Один подход способствует возникновению совместной работы, а другой — использованию чётко структурированной цепочки действий, которую можно заранее просмотреть.

Ни один из вариантов не устраняет необходимости контроля за расходами. Оба требуют большего количества вызовов модели, чем один запрос, и оба могут входить в циклы. Именно поэтому инструменты для отслеживания так же важны, как и выбор фреймворка.

Выбор между двумя вариантами

Ни одна из платформ не является абсолютным победителем. Каждая отражает разные взгляды на то, сколько структурных элементов должна иметь многопроцессная система. AutoGen позволяет формировать структуру непосредственно в ходе диалога, тогда как CrewAI требует от создателя заранее определить все детали.

AutoGen подходит, когда:

• необходима максимальная гибкость, и агенты могут импровизировать свой подход в процессе открытого диалога;
• задача выигрывает от исследовательского взаимодействия, такого как мозговой штурм или итеративная отладка, при которой правильная последовательность действий неизвестна заранее;
• полезен удобный визуальный интерфейс вроде AutoGen Studio для нетехнических экспериментов перед написанием кода.

CrewAI подходит, когда:

• требуются предсказуемые, контролируемые процессы с четким распределением ролей и обязанностей, как в корпоративных рабочих процессах, где важна последовательность больше, чем импровизация;
• Встроенная память, кэширование и ограничение скорости работы предпочтительнее реализаций, написанных вручную;
• Важна высокая степень наблюдаемости, учитывая почти безупречную интеграцию с AgentOps.

На практике многие реальные проекты используют элементы обоих подходов: декларативную ясность CrewAI для хорошо понятных частей работоспособности системы и конверсационную гибкость AutoGen для более сложных, исследовательских задач.