CrewAI: role-based agent teams

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

from crewai import Agent

analyst = Agent(
    role="Аналитик конкурентной разведки B2B SaaS",
    goal="Собрать проверяемые факты о ценах и фичах {competitor}",
    backstory=(
        "Десять лет в product-аналитике. Не принимает цифру"
        " без ссылки на источник и даты проверки."
    ),
    tools=[search_tool, scrape_tool],
    allow_delegation=False,
    max_iter=15,
    verbose=True,
)

Правило конкретности: «Senior-аналитик рынка B2B SaaS» даёт измеримо более сфокусированные ответы, чем «полезный ассистент», потому что роль активирует соответствующий пласт обучающих данных модели. Бэкстори работает как поведенческая политика — фраза «не принимает цифру без источника» реально снижает долю голословных утверждений в выводе.

Два параметра защищают бюджет. allow_delegation=True разрешает агенту передавать подзадачи коллегам — мощно, но непредсказуемо: агенты могут устроить долгую переписку. Для конвейеров с фиксированными ролями делегирование обычно выключают. max_iter ограничивает число циклов «мысль → действие» одного агента: без лимита застрявший агент будет крутиться, пока не кончатся деньги. Плюс max_rpm — потолок запросов в минуту, спасающий от rate limit провайдера.

Task — единица работы с двумя обязательными смысловыми полями: что делать (description) и как выглядит готовый результат (expected_output). Второе поле — главный рычаг качества в CrewAI: без явного контракта на выход агент решает сам, что считать «готово».

from crewai import Task, Crew, Process

research = Task(
    description="Собери цены и ключевые фичи {competitor}.",
    expected_output="Markdown-таблица: фича, тариф, источник, дата.",
    agent=analyst,
)
summary = Task(
    description="Сведи данные аналитика в выводы для продукта.",
    expected_output="5 выводов с рекомендациями, 300-400 слов.",
    agent=writer,
    context=[research],  # выход research попадёт во вход
)

crew = Crew(
    agents=[analyst, writer],
    tasks=[research, summary],
    process=Process.sequential,
)
result = crew.kickoff(inputs={"competitor": "Acme CRM"})

Процесс sequential — конвейер: задачи идут в порядке списка, context явно указывает, чьи результаты видит задача. Процесс hierarchical добавляет менеджера: вы задаёте manager_llm, CrewAI создаёт агента-руководителя, который сам распределяет задачи, оценивает результаты и просит переделать. Это supervisor-топология из первого урока в готовом виде.

Компромисс тот же: hierarchical гибче, но менеджер — ещё один LLM со своим ненулевым шансом ошибиться маршрутом, плюс его вызовы удорожают прогон на 20–40%. Начинайте с sequential; переходите на hierarchical, только когда порядок задач реально неизвестен заранее.

Один флаг memory=True в конструкторе Crew включает сразу три подсистемы памяти. Short-term memory — векторное хранилище (по умолчанию ChromaDB с эмбеддингами) внутри одного прогона: когда райтер пишет выводы, релевантные фрагменты работы аналитика подтягиваются в его контекст автоматически, даже если не были переданы через context. Long-term memory — SQLite-база результатов задач между прогонами: после каждой задачи CrewAI сохраняет оценку качества и извлечённые уроки, и при следующем запуске похожей задачи агент получает подсказку «в прошлый раз сработало вот это». Entity memory отслеживает сущности — людей, компании, продукты — и их атрибуты, накапливая структурированное досье по мере работы команды.

Практические следствия. Первое: память — это токены; каждая подтяжка из хранилища увеличивает контекст агента, поэтому на дешёвых конвейерах с явной передачей через context память часто выгоднее держать выключенной. Второе: long-term memory делает прогоны нед етерминированными между собой — вчерашний запуск влияет на сегодняшний. Для регрессионных тестов и эвалов это яд, поэтому в CI память чистят или отключают. Третье: entity memory особенно полезна в длинных исследовательских сценариях, где одна и та же компания всплывает в пяти задачах — без неё каждый агент собирает досье заново.

Отдельно от памяти живёт механизм knowledge: статические источники знаний (файлы, документы), которые подключаются к агенту или всей команде и индексируются один раз. Правило разграничения простое: то, что агенты УЗНАЛИ в работе, — память; то, что вы ЗНАЛИ заранее, — knowledge.

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

CrewAI выигрывает в скорости старта: рабочий прототип команды из трёх ролей собирается за вечер, ролевая модель понятна нетехническим стейкхолдерам, а декларативный YAML-конфиг агентов удобно ревьюить. Плата — контроль: пока сценарий укладывается в «список задач по порядку» или «менеджер раздаёт работу», всё отлично, но точечно вмешаться в цикл (нестандартный маршрут, свой формат hand-off, откат на два шага назад) сложно. Для событийной логики CrewAI добавил Flows — декораторы @start и @listen поверх событийной модели, — и это признание того, что одних Crew для продакшена мало.

LangGraph выигрывает там, где нужны гарантии: явный граф переходов, который можно юнит-тестировать, checkpointer с возобновлением после сбоя, time-travel для отладки, interrupt для человеческих ворот. Плата — многословность: то, что в CrewAI одна строка process=Process.hierarchical, в LangGraph — самостоятельно написанный супервизор.

Рабочее правило курса: прототип и демо ролевой команды — CrewAI; продакшен с циклами, персистентностью и SLA — LangGraph; гибрид (Crew как узел внутри StateGraph) — легальный ход, потому что kickoff вызывается из обычной Python-функции узла.