Ответы на вопросы после митапа по AI

Pavel Veinik

Login
Ответы на вопросы после митапа по AIКраткая история IT: От ткацкого станка до нейросетей

Агенты: настройка, оркестрация и типы

- A где взять или создать эти файлы что с агентами? это готовые тепллейты?

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

  1. Агенты как код (Code-First Approach) Это самый гибкий и распространенный подход в кастомной разработке. Агент определяется непосредственно в коде, обычно на Python.

    • Как это работает: Вы импортируете классы из фреймворка (например, LangChain или LlamaIndex) и определяете агента как объект. Вы задаете ему LLM, набор инструментов (tools) и основной промпт (system prompt), который описывает его логику и роль.
    • Инструменты: LangChain, LlamaIndex, DSPy.
    • Пример (псевдокод на Python с LangChain): 
      from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_tool_calling_agent
from langchain_core.prompts import ChatPromptTemplate

# 1. Выбираем модель
llm = ChatOpenAI(model="gpt-4.5-turbo")

# 2. Определяем инструменты (tools)
tools = [some_api_tool, file_read_tool]

# 3. Создаем промпт-темплейт
prompt = ChatPromptTemplate.from_messages([
    ("system", "Ты — AI-ассистент, который помогает работать с файлами."),
    ("human", "{input}"),
    ("placeholder", "{agent_scratchpad}"),
])

# 4. Собираем агента
agent = create_tool_calling_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

# "Файл" в данном случае — это сам скрипт .py
    • Где взять: Примеры есть в документации фреймворков и на GitHub. Но обычно их пишут с нуля под конкретную задачу.

  2. Агенты как конфигурация (Config-First Approach) Этот подход популярен в мультиагентных системах, где важно легко настраивать и переиспользовать агентов без изменения кода.

    • Как это работает: Вы описываете свойства каждого агента (роль, цель, инструменты, модель) в структурированном формате, например, YAML или JSON. Основной код просто загружает эти конфигурации и создает на их основе объекты агентов.
    • Инструменты: CrewAI, AutoGen. CrewAI особенно хорош в этом, так как четко разделяет определение агента и логику выполнения задач (tasks).
    • Пример (конфигурация агента в CrewAI): 
      from crewai import Agent

# Этот код может быть загружен из YAML
financial_analyst = Agent(
    role='The Best Financial Analyst',
    goal='Impress all customers with your financial data analysis',
    backstory=(
        'The most seasoned financial analyst with lots of expertise in '
        'financial markets...'
    ),
    verbose=True,
    # tools=[...],
    # llm=...
)
    • Где взять: Фреймворки поставляются с готовыми примерами. Существуют онлайн-конструкторы и маркетплейсы (например, в FlowiseAI или на Hugging Face), где можно найти и адаптировать готовые темплейты.

Что может пойти не так и как этого избежать:

  • Проблема: Использование готового темплейта без адаптации. Агент будет работать неэффективно, так как его промпт и инструменты не заточены под вашу уникальную задачу.
  • Решение: Всегда рассматривайте темплейты как отправную точку. Тщательно переписывайте role, goal и backstory, а также создавайте кастомные инструменты, которые нужны именно вам.

Полезные материалы:

- Лью трафик из Facebook на партнёрские программы. Интересно узнать про возможности ИИ агентов в плане самостоятельного создания системы автоматизации, подтягивание данных из источника трафика, хранения данных - в таком ключе

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

Она будет состоять из нескольких специализированных агентов, оркестрированных в единый рабочий процесс (workflow).

Архитектура мультиагентной системы для арбитража трафика:

  1. Агент-аналитик (Analytics Agent)

    • Задача: Постоянно подключаться к API рекламных сетей (Facebook Ads) и партнерских программ для сбора ключевых метрик: cost, clicks, impressions, conversions, revenue.
    • Инструменты (Tools):
      • Коннектор к Facebook Marketing API.
      • Коннекторы к API партнерок (Postback/API).
      • Функция для записи сырых данных в базу данных.
    • Технологии: Для коннекторов используются Python- библиотеки (facebook_business). Данные можно складировать в простые хранилища типа Google Sheets, Airtable или, для больших объемов, в ClickHouse.

  2. Агент-хранитель (Data Storage Agent)

    • Задача: Структурировать и сохранять данные, полученные от аналитика. Он отвечает за чистоту данных, их форматирование и запись в базу данных или озеро данных (data lake).
    • Инструменты:
      • Инструменты для работы с базами данных (SQLAlchemy для SQL, pandas для обработки).
      • Функции для валидации данных (например, с помощью Pydantic).
    • Технологии: В качестве БД отлично подойдет PostgreSQL или ClickHouse для аналитических задач. Можно использовать облачные решения вроде BigQuery.

  3. Агент-оптимизатор (Optimization Agent)

    • Задача: Это мозг системы. Он анализирует данные, собранные в БД, и принимает решения об оптимизации рекламных кампаний.
    • Логика работы:
      1. Регулярно запрашивает агрегированные данные: ROI, CPC, CPM, CR по разным креативам, аудиториям, гео.
      2. На основе правил (rule-based) или простых ML- моделей (например, регрессии для предсказания ROI) определяет, какие кампании масштабировать, а какие остановить.
      3. Формулирует команды для агента-исполнителя. Например: "Остановить кампанию X", "Увеличить бюджет кампании Y на 20%".
    • Инструменты:
      • SQL-ридер для запросов к БД.
      • Инструмент для выполнения Python-кода для анализа (pandas, scikit-learn).

  4. Агент-исполнитель (Action Agent)

    • Задача: Выполнять команды, полученные от оптимизатора. Он напрямую взаимодействует с API рекламных сетей.
    • Инструменты:
      • Инструменты для изменения статуса кампаний, бюджетов, таргетинга через Facebook Marketing API.
      • Инструмент для отправки уведомлений (например, в Telegram).

Как это всё оркестровать: Для управления взаимодействием этих агентов идеально подходят фреймворки CrewAI или LangGraph.

  • CrewAI: Позволяет легко определить роли и задачи каждого агента и запустить их в последовательном или параллельном режиме.
  • LangGraph: Дает больше контроля над логикой. Вы можете построить граф состояний (state machine), где каждый узел — это действие одного из агентов. Это позволяет создавать циклы, условия и более сложные сценарии.

Что может пойти не так:

  • Бесконечные циклы: Агент-оптимизатор может постоянно менять бюджеты туда-сюда. Решается введением пороговых значений и "периода охлаждения" после внесения изменений.
  • Качество данных: Некорректные данные из API приведут к неверным решениям. Нужна строгая валидация на уровне агента-хранителя.
  • Безопасность: Агенты будут управлять реальными бюджетами. Ключи API должны храниться в защищенном месте (secrets manager), а у агента-исполнителя должны быть строгие лимиты на максимальные расходы.

Полезные материалы:

- Как оркестровать агентов?

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

1. Иерархическая оркестрация (Hierarchical Orchestration) Это классическая модель, похожая на структуру в компании: есть менеджер (Master Agent) и команда исполнителей (Worker Agents).

  • Как это работает:
    1. Пользователь дает задачу главному агенту- оркестратору.
    2. Оркестратор декомпозирует задачу на подзадачи.
    3. Он распределяет подзадачи между специализированными агентами-исполнителями (например, один пишет код, другой ищет информацию, третий тестирует).
    4. Исполнители возвращают результаты оркестратору.
    5. Оркестратор собирает все части вместе и формирует финальный ответ.
  • Плюсы: Простота, понятная логика, централизованный контроль.
    • Минусы: Оркестратор может стать узким местом. Если он неправильно декомпозирует задачу, вся система работает неэффективно.
  • Инструменты: CrewAI идеально реализует эту модель через свои концепции Agents, Tasks и Process. Вы определяете агентов, задачи для них и процесс (последовательный или параллельный), по которому они будут выполняться.

2. Графовая оркестрация (Graph-Based Orchestration) Это более гибкий и мощный подход, основанный на концепции графа состояний (state machine).

  • Как это работает: Рабочий процесс представляется в виде графа, где узлы (nodes) — это агенты или инструменты, а ребра (edges) — это переходы между ними на основе определенных условий.
    • Например: после того как Агент-кодер закончил работу, система проверяет результат. Если код без ошибок, управление передается Агенту-тестировщику. Если есть ошибки — возвращается обратно Агенту- кодеру на доработку.
  • Плюсы: Позволяет создавать циклы, ветвления и сложные, нелинейные рабочие процессы. Отлично подходит для задач, требующих итераций и исправлений.
  • Минусы: Сложнее в настройке и отладке.
  • Инструменты: LangGraph — это стандарт де-факто для такой оркестрации. Он позволяет строить циклические графы, что невозможно в стандартных цепочках LangChain (LCEL).

3. Мультиагентные чаты (Multi-Agent Conversations) В этом подходе агенты общаются друг с другом в общем чате, совместно решая задачу.

  • Как это работает: Нет строгого центрального оркестратора. Есть группа агентов, и следующий говорящий определяется либо по очереди, либо с помощью специальной функции-селектора, которая решает, чей вклад сейчас будет наиболее полезен.
  • Плюсы: Подходит для задач, требующих брейншторма, дискуссий и коллективного принятия решений (например, симуляция совещания команды разработки).
  • Минусы: Может привести к хаосу или зацикливанию, если не управлять диалогом.
  • Инструменты: AutoGen от Microsoft — ключевой фреймворк для этого подхода. Он позволяет настраивать сложные схемы взаимодействия между агентами в рамках "групповых чатов".

Лучшие практики на 2026 год:

  • Начинайте с простого: Для большинства задач достаточно иерархической модели в CrewAI.
  • Используйте LangGraph для итераций: Если ваша задача предполагает циклы действие -> проверка -> доработка (например, написание и отладка кода), LangGraph — ваш выбор.
  • Используйте AutoGen для симуляций: Если вам нужно смоделировать сложное взаимодействие нескольких сторон, посмотрите в сторону AutoGen.
  • Четко определяйте роли: Независимо от подхода, каждый агент должен иметь очень узкую, четко определенную роль и набор инструментов. Это снижает вероятность ошибок и повышает предсказуемость системы.

Полезные материалы:

- Основная проблема - большое количество агентов. Что для чего и как все это организовать в систему инструментов

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

Вот как организовать множество агентов в управляемую систему:

1. Каталогизация и типизация агентов Прежде всего, нужно классифицировать агентов по их функциям. Не думайте о них как о монолитной массе. Разделите их на уровни и типы.

  • Тип 1: Функциональные агенты (Functional Agents)

    • Описание: Это рабочие лошадки. Каждый такой агент выполняет одну очень конкретную задачу и обернут вокруг одного или нескольких инструментов.
    • Примеры:
      • CodeWriterAgent (инструмент: запись в файл)
      • CodeTesterAgent (инструмент: запуск pytest)
      • DatabaseQueryAgent (инструмент: выполнение SQL-запросов)
      • EmailSenderAgent (инструмент: send_email через API)
    • Как управлять: Эти агенты должны быть максимально переиспользуемыми. Их стоит хранить в общем репозитории, чтобы разные команды могли использовать их в своих процессах.

  • Тип 2: Агенты-оркестраторы (Orchestrator/Manager Agents)

    • Описание: Эти агенты не выполняют работу сами. Их единственная задача — управлять другими агентами. Они декомпозируют сложную задачу и координируют работу функциональных агентов.
    • Пример: SoftwareDevelopmentManagerAgent получает задачу "создать API эндпоинт". Он последовательно вызывает CodeWriterAgent, CodeTesterAgent и, если тесты прошли, CodeCommitterAgent.
    • Технологии: Для их создания используются фреймворки вроде CrewAI или LangGraph.

  • Тип 3: Агенты-маршрутизаторы (Router/Dispatcher Agents)

    • Описание: Это привратники системы. Когда поступает новый запрос, этот агент решает, какому агенту-оркестратору или функциональному агенту его передать.
    • Пример: Входящий запрос "проверь почту и ответь на письма от клиента X". Маршрутизатор отправит его EmailOrchestrator, а не CodeDevelopmentOrchestrator.
    • Технологии: Маршрутизация обычно реализуется с помощью LLM, который на основе семантики запроса выбирает нужный маршрут. В LangChain для этого есть готовые механизмы.

2. Создание "системы инструментов" (Tool System) Ваши агенты — это по сути обертки над инструментами. Поэтому порядок нужно наводить именно на уровне инструментов.

  • Центральный реестр инструментов (Tool Registry): Создайте единое место, где хранятся все доступные инструменты. Каждый инструмент должен иметь:

    • Четкое, атомарное назначение.
    • Подробное описание (docstring), чтобы LLM понимала, когда его использовать.
    • Типизированные входы и выходы (Pydantic-модели).
    • Версионирование.

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

3. Использование правильных фреймворков

  • Для управления жизненным циклом агентов и их взаимодействием используйте CrewAI (для иерархических структур) или LangGraph (для сложных, циклических процессов).
  • Для мониторинга и отладки используйте платформы вроде LangSmith, Helicone или WandB. Они позволяют трассировать вызовы, анализировать стоимость и оценивать производительность каждого агента в цепочке.

Что может пойти не так:

  • Дублирование функциональности: Две команды создают похожих агентов для одной и той же задачи. Решается центральным реестром и каталогизацией.
  • Сложность отладки: Когда в цепочке 10 агентов, найти ошибку сложно. Решается системами трассировки (LangSmith), которые показывают весь путь запроса.

Полезные материалы:

- Как спроектировать систему автономных агентов, которые работают независимо друг от друга в изолированных средах (по аналогии с процессом разработки ПО, где разработчик создает ветку, а QA проверяет изменения на отдельном стенде с нуля)? Также как в такой системе избежать бесконечных циклов улучшений, возникающих из\-за того, что LLM-агенты постоянно предлагают доработки после ревью друг друга?

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

Часть 1: Изолированные среды для агентов

Аналогия с Git-ветками и стендами для QA абсолютно верна. Сегодня для этого используются контейнеризация и динамически создаваемые окружения.

Архитектурное решение:

  1. Агент-Оркестратор (CI/CD-подобный)

    • Это главный агент, который управляет всем процессом. Он не пишет код сам, а действует как тимлид и DevOps- инженер.

  2. Динамическое создание песочниц (Sandboxing)

    • Когда "Агент-разработчик" (DeveloperAgent) получает задачу, оркестратор не дает ему работать в основной кодовой базе.
    • Вместо этого он создает для него изолированную среду:
      • Запускает Docker-контейнер с нужным окружением (например, Python 3.12, Node.js 22).
      • Копирует (или монтирует) в этот контейнер только ту часть кодовой базы, которая нужна для работы. Это аналог git checkout -b new-feature-branch.

  3. Работа в песочнице

    • DeveloperAgent работает внутри этого контейнера. У него есть инструменты для чтения, записи и выполнения кода, но только в пределах своей песочницы. Он не видит "production" окружение.

  4. Передача на ревью и тестирование

    • Когда DeveloperAgent завершает свою работу, он сообщает об этом оркестратору.
    • Оркестратор коммитит изменения (сохраняет состояние контейнера или создает diff) и создает новую, чистую песочницу для Агента-тестировщика (QAAgent).
    • В эту новую песочницу он загружает исходный код + изменения от разработчика.
    • QAAgent запускает тесты в своей изолированной среде. Он не зависит от состояния, в котором DeveloperAgent оставил свою среду. Это аналог проверки на чистом стенде.

Инструменты для реализации:

  • Контейнеризация: Docker или Podman для создания изолированных окружений.
  • Безопасные песочницы для кода: E2B (evals-in-browser) или CodeBox — это специализированные сервисы, которые предоставляют API для создания безопасных песочниц для выполнения кода агентами. Они управляют жизненным циклом окружений за вас.
  • Оркестрация: LangGraph отлично подходит для создания такой сложной логики с условными переходами.

Часть 2: Как избежать бесконечных циклов улучшений

Это классическая проблема ревью-войн между LLM. Решается она введением строгих правил, ограничений и внешнего арбитра.

  1. Ограничение количества итераций

    • Самый простой и надежный способ. В оркестраторе (например, в LangGraph) вы ставите счетчик. Если цикл "разработка -> ревью -> доработка" повторяется больше N раз (например, 3 раза), процесс принудительно останавливается.
    • Результат передается человеку для финального решения. Это предотвращает бесконечные циклы и лишние затраты на вызовы LLM.

  2. Введение роли "Архитектора" или "Принимающего решения"

    • В цепочку добавляется третий агент — ArchitectAgent.
    • DeveloperAgent предлагает изменения. ReviewerAgent дает обратную связь.
    • ArchitectAgent смотрит на оба мнения и принимает финальное решение: Принять, Отклонить или Отправить на доработку с конкретными, финальными замечаниями. Его решение является окончательным и не может быть оспорено другими агентами.

  3. Критерии приемки (Acceptance Criteria)

    • Изначальная задача должна содержать очень четкие критерии приемки.
    • Агент-ревьюер должен оценивать код не на основе своего мнения, а строго по этим критериям. Например: "Код должен соответствовать PEP8", "Покрытие тестами должно быть не менее 85%".
    • Если все критерии выполнены, ревью считается пройденным, даже если у LLM есть идеи для улучшения.

  4. Снижение креативности моделей

    • Для агентов-ревьюеров можно использовать более низкое значение параметра temperature (например, 0.1 или 0). Это делает их ответы более детерминированными и менее склонными к добавлению "лишних" предложений.

Полезные материалы:

- Мне нужно сделать агентов... Очень много агентов

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

Вот как выглядит системный подход к этой задаче в 2026 году.

1. Фабрика Агентов (Agent Factory Pattern)

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

  • Как это работает:

    • Вы определяете базовый шаблон агента (например, Агент для работы с API).
    • Вы создаете конфигурационные файлы (например, в YAML), где описываете уникальные параметры для каждого экземпляра:
      • Название API.
      • URL эндпоинта.
      • Спецификация OpenAPI для автоматической генерации инструментов.
      • Примеры использования.
    • Фабрика читает эти конфиги и автоматически создает нужное количество агентов, каждый со своим набором инструментов.

  • Пример: Вам нужно 50 агентов для работы с 50 различными внутренними API. Вы создаете 50 YAML-файлов и один скрипт-фабрику, который генерирует всех агентов. Если нужно добавить 51-го, вы просто добавляете еще один YAML.

2. Агенты, создающие других агентов (Agentic Meta-Programming)

Это более продвинутый подход, где вы используете LLM для создания и настройки других агентов.

  • Как это работает:

    1. Вы создаете Агента-Конструктора (AgentBuilderAgent).
    2. Вы даете ему задачу в свободной форме, например: Мне нужен агент, который умеет работать с API погоды Weather.com. Он должен уметь получать погоду по городу и предупреждать о дожде.
    3. AgentBuilderAgent сам находит документацию API, анализирует ее, пишет Python-код для инструментов, генерирует промпт для нового агента и сохраняет его конфигурацию.
    4. В результате вы получаете готового к работе Агента-Погоды (WeatherAgent), созданного автоматически.

  • Инструменты: Для этого уже существуют специализированные решения. Например, LlamaFactory или кастомные цепочки в LangChain, которые генерируют код и конфигурации.

3. Управление и мониторинг в масштабе

Когда у вас сотни агентов, ключевой проблемой становится их мониторинг, обновление и контроль.

  • Центральный Реестр Агентов (Agent Registry):

    • Все созданные агенты должны регистрироваться в центральном реестре. Это может быть база данных или простой Git-репозиторий с их конфигурациями.
    • Реестр хранит метаданные: версия, автор, набор инструментов, история запусков.

  • Системы Наблюдаемости (Observability):

    • Необходимо использовать платформы вроде LangSmith или Helicone.
    • Они позволяют отслеживать каждый вызов каждого агента, анализировать стоимость, задержку (latency) и успешность выполнения задач. Вы сможете быстро находить медленных или неэффективных агентов.

  • Управление Промптами (Prompt Management):

    • Не храните промпты прямо в коде. Используйте системы управления промптами, такие как PromptLayer или встроенные возможности LangSmith. Это позволяет версионировать промпты, тестировать разные варианты и обновлять их для группы агентов одновременно, не трогая код.

Что может пойти не так:

  • Проблема: Расползание конфигураций. Конфиги агентов хранятся в разных местах, что делает невозможным их централизованное обновление.
  • Решение: Сразу внедряйте центральный реестр. Любой новый агент должен быть зарегистрирован там через CI/CD пайплайн.

Полезные материалы:

- Настройка агентов для разработки

Настройка агентов для разработки ПО — одна из самых востребованных и сложных задач. В 2026 году это уже не один агент, а целая команда (crew) специализированных агентов, работающих в связке.

Вот как выглядит state-of-the-art подход к их настройке.

Архитектура команды агентов (Dev Crew):

  1. Агент-Архитектор (Architect Agent)

    • Роль: Создает общую структуру проекта, определяет компоненты, API контракты и структуру данных.
    • Промпт (ключевые моменты): "Ты — опытный solution architect. Твоя задача — декомпозировать задачу на логические компоненты. Опиши структуру файлов, основные классы и функции. Не пиши код реализации, только скелеты и комментарии // TODO:."
    • Инструменты:
      • Инструмент для создания иерархии папок и пустых файлов.
      • Инструмент для записи в файлы (чтобы создавать скелеты кода).

  2. Агент-Разработчик (Developer Agent)

    • Роль: Пишет код реализации на основе спецификаций от архитектора.
    • Промпт: "Ты — senior-разработчик. Твоя задача — реализовать логику в файлах, созданных архитектором. Следуй существующему стилю кода. Пиши чистый, эффективный и документированный код. Обрати особое внимание на обработку ошибок."
    • Инструменты:
      • Чтение файлов (read_file).
      • Запись/изменение файлов (write_file, insert_code_snippet).
      • Поиск по кодовой базе (code_search).
      • Обязательно: доступ к безопасному окружению для запуска кода (песочница, см. ниже).

  3. Агент-Тестировщик (QA Agent)

    • Роль: Пишет unit- и интеграционные тесты для кода, созданного разработчиком.
    • Промпт: "Ты — QA-инженер. Твоя задача — написать тесты для предоставленного кода, используя фреймворк pytest. Обеспечь максимальное покрытие. Тесты должны проверять как позитивные, так и негативные сценарии."
    • Инструменты:
      • Те же, что и у разработчика, плюс инструмент для запуска тестов и анализа отчета о покрытии (run_tests).

  4. Агент-Рецензент (Code Reviewer Agent)

    • Роль: Проверяет код на соответствие стандартам качества, ищет баги и узкие места.
    • Промпт: "Ты — принципиальный, но справедливый рецензент кода. Проанализируй предложенные изменения. Обрати внимание на чистоту кода (SOLID, DRY), безопасность, производительность и читаемость. Предоставь обратную связь в виде конкретных предложений по улучшению."
    • Инструменты: Только для чтения (read_file, code_search). У него не должно быть прав на запись.

Ключевые аспекты настройки:

  • Безопасная песочница (Sandbox): Это самое важное. Агенты не должны выполнять код на вашей основной машине. Используйте специализированные сервисы, такие как E2B или CodeBox, которые предоставляют изолированные Docker-окружения через API. Агент получает доступ к терминалу внутри контейнера и может безопасно устанавливать зависимости, запускать код и тесты.

  • Доступ к инструментам (Tool Access): Не давайте всем агентам все инструменты. Настраивайте их роли так, чтобы у каждого был только минимально необходимый набор. Рецензенту не нужна возможность записи в файлы.

  • Оркестрация: Для управления этой командой лучше всего подходит LangGraph, так как процесс разработки цикличен (написал -> протестировал -> нашел баг -> исправил). Вы можете настроить граф, который будет передавать управление между агентами до тех пор, пока все тесты не пройдут и рецензент не одобрит код.

  • Модель: Используйте самые мощные и современные модели (уровня GPT-4.5/5, Claude 3.5/4), так как написание качественного кода — сложная задача. Для агента-рецензента можно использовать более быструю и дешевую модель (Claude 3.5 Sonnet), так как его задача — анализ, а не генерация.

Что может пойти не так:

  • Проблема: Агент "забывает" контекст и начинает писать код, несовместимый с остальной частью проекта.
  • Решение: Перед началом работы давать агенту не только файл, который он должен изменить, но и краткую сводку (summary) по всему проекту. Для этого можно использовать техники RAG (Retrieval-Augmented Generation) по кодовой базе.

Полезные материалы:

- Хочу посмотреть на настройку агентов

Давайте рассмотрим практический пример настройки одного конкретного агента с нуля, используя фреймворк CrewAI, который очень популярен в 2026 году благодаря своей простоте и декларативному подходу.

Мы создадим агента-исследователя, задача которого — найти информацию в интернете и составить краткий отчет.

Шаг 1: Определение цели и роли

Прежде всего, нужно четко понять, что должен делать агент.

  • Цель (Goal): Найти 3 последние научные статьи на arXiv по теме "Large Language Models" и составить краткую сводку по каждой.
  • Роль (Role): Опытный AI-исследователь.

Шаг 2: Выбор и настройка инструментов (Tools)

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

  • Инструмент 1: Поиск в интернете. Мы можем использовать готовые инструменты из библиотек- партнеров, например, SerperDevTool для быстрого поиска в Google или DuckDuckGoSearchRun из LangChain.
  • Инструмент 2: Чтение веб-страниц. После того как поиск вернул ссылки, агенту нужно прочитать их содержимое. Для этого подойдет инструмент, который принимает URL и возвращает текст страницы.
  • Инструмент 3 (опционально): Поиск на arXiv. Можно создать кастомный инструмент, который будет работать напрямую с API arXiv для более точного поиска.

Ша- 3: Написание промпта (Backstory & System Prompt)

Это личность и инструкция для нашего агента. В CrewAI это делается через параметры role, goal и backstory.

  • Role: "AI Research Specialist"
  • Goal: "Find the latest 3 papers on 'Large Language Models' on arXiv and provide a one-paragraph summary for each."
  • Backstory: "You are a world-class AI researcher with a PhD from Stanford. You are an expert in sifting through scientific papers to find the most relevant and impactful information. You always provide concise, accurate, and easy-to-understand summaries. You cite your sources."

Шаг 4: Сборка агента в коде (Python + CrewAI)

Теперь объединим все это в коде.

# 1. Устанавливаем зависимости
# pip install crewai crewai_tools

# 2. Импортируем необходимые классы
from crewai import Agent, Task, Crew, Process
from crewai_tools import SerperDevTool, WebsiteReadTool
from langchain_openai import ChatOpenAI

# 3. Настраиваем инструменты
# (нужен API-ключ SERPER_API_KEY в переменных окружения)
search_tool = SerperDevTool()
read_tool = WebsiteReadTool()

# 4. Настраиваем LLM (используем последнюю модель)
llm = ChatOpenAI(model="gpt-4.5-turbo")

# 5. Создаем нашего агента
researcher = Agent(
    role="AI Research Specialist",
    goal="Find the latest 3 papers on 'Large Language Models' on arXiv and provide a one-paragraph summary for each.",
    backstory=(
        "You are a world-class AI researcher with a PhD from Stanford. "
        "You are an expert in sifting through scientific papers to find "
        "the most relevant and impactful information. You always provide "
        "concise, accurate, and easy-to-understand summaries. You cite your sources."
    ),
    verbose=True,
    allow_delegation=False, # Этот агент работает один
    tools=[search_tool, read_tool],
    llm=llm
)

# 6. Создаем задачу для агента
research_task = Task(
    description=(
        "Search for the 3 most recent papers on arXiv related to 'Large Language Models'. "
        "For each paper, provide its title, authors, and a short summary."
    ),
    expected_output="A formatted report with 3 entries. Each entry should contain the paper title, authors, and a summary paragraph.",
    agent=researcher
)

# 7. Собираем команду (в нашем случае из одного агента) и запускаем
crew = Crew(
    agents=[researcher],
    tasks=[research_task],
    process=Process.sequential
)

result = crew.kickoff()
print(result)

Что может пойти не так:

  • Плохое описание инструментов: Если бы мы назвали SerperDevTool просто search, LLM могла бы не понять, что он ищет в интернете, и пыталась бы использовать его для поиска по локальным файлам.
  • Слишком общий промпт: Без четкого backstory и goal агент мог бы вернуть не научные статьи, а блоги или новости.
  • Отсутствие нужных инструментов: Если бы мы не дали ему read_tool, он бы нашел ссылки, но не смог бы их прочитать и сделать саммари.

Эта пошаговая настройка — основа для создания любого, даже самого сложного агента.

Полезные материалы:

- Какой подход лучше? Каждый специалист в своей области и у каждого свой агент, или же каждый фуллстэк и сразу охватывают и фронт и бэк?

Подход со специализированными агентами почти всегда превосходит подход с агентами-фуллстэками.

Вот детальное объяснение, почему это так.

Подход 1: Специализированные агенты (Specialized Agents)

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

  • Архитектура:

    • FrontendDeveloperAgent: Умеет работать только с React, CSS и имеет инструменты для запуска Node.js-сервера.
    • BackendDeveloperAgent: Работает с Python (FastAPI), SQLAlchemy и имеет инструменты для подключения к БД.
    • DatabaseAdminAgent: Умеет писать и применять SQL-миграции.
    • ArchitectAgent: Проектирует API-контракты между фронтендом и бэкендом.

  • Плюсы:

    1. Предсказуемость и надежность: Агент с одной функцией и двумя инструментами с меньшей вероятностью совершит ошибку или сойдет с ума, чем агент с 20 инструментами. Его поведение легче контролировать и отлаживать.
    2. Эффективность контекста: В системный промпт и контекстное окно модели попадает только релевантная информация. Это снижает шум и позволяет LLM лучше сконцентрироваться на задаче.
    3. Оптимизация моделей: Вы можете использовать разные LLM для разных задач. Например, мощную и дорогую модель (Claude 3.5 Opus) для ArchitectAgent, а более быструю и дешевую (GPT-4.5-Flash или Llama 3.1) для FrontendDeveloperAgent, так как генерация UI-кода часто является более шаблонной задачей.
    4. Масштабируемость и переиспользование: Легко добавлять новых специалистов в команду или использовать существующих агентов в других проектах.

  • Минусы:

    • Требуется оркестратор для управления взаимодействием между агентами.

Подход 2: Агенты-фуллстэки (Full-Stack Agents)

В этой модели один агент пытается делать все сразу.

  • Архитектура:

    • FullStackDeveloperAgent: Ему даются все инструменты для работы с фронтендом, бэкендом, базой данных, CI/CD и т.д.

  • Плюсы:

    • Кажущаяся простота на старте: не нужно настраивать сложную оркестрацию.

  • Минусы:

    1. Перегрузка контекста: Системный промпт становится огромным. В контекстное окно попадает слишком много инструментов, и LLM начинает путаться, какой из них использовать. Это основная причина неудач таких агентов.
    2. Непредсказуемость: Агент может начать творить и решать задачу не тем способом, которым вы ожидали. Например, вместо того чтобы исправить SQL-запрос на бэкенде, он может попытаться реализовать сложную логику фильтрации на фронтенде.
    3. Сложность отладки: Когда такой агент совершает ошибку, очень трудно понять, на каком этапе его рассуждений она произошла.
    4. Низкая эффективность: Невозможно подобрать одну LLM, которая была бы одинаково хороша во всем. Модели, тюнингованные для генерации кода, могут быть не лучшими в планировании или анализе данных.

Вывод и лучшая практика на 2026 год:

Всегда начинайте с декомпозиции задачи и создания команды (crew) узкоспециализированных агентов. Используйте оркестратор (например, CrewAI или LangGraph) для управления их совместной работой.

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

Полезные материалы:

- Как управлять общими инструкциями для разных агентов?

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

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

1. Централизованный репозиторий инструкций (Prompt snippets)

Создайте отдельное место (например, папку в Git- репозитории) для хранения фрагментов (сниппетов) общих инструкций.

  • Структура:

    /prompt_library
    /global
        - security_rules.md  # Правила безопасности
        - communication_style.md # Стиль общения
    /dev_agents
        - coding_standards.md # Стандарты кода
        - testing_policy.md   # Политика тестирования

  • Пример security_rules.md:

    **Security Rules:**
1. Never log sensitive data (passwords, API keys) to the console.
2. Sanitize all user inputs to prevent injection attacks.
3. Use environment variables for all secrets. Do not hardcode them.

2. Шаблонизаторы промптов (Prompt Templating)

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

  • Как это работает:

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

  • Инструменты:

    • LangChain (ChatPromptTemplate): Имеет встроенные мощные механизмы для работы с шаблонами. Вы можете создавать шаблоны из файлов или строк и легко комбинировать их.
    • Jinja2: Популярный шаблонизатор для Python. Можно использовать его для создания очень сложных и динамических промптов.

Пример реализации на Python с LangChain:

from langchain_core.prompts import ChatPromptTemplate

# 1. Загружаем общие инструкции из файлов
with open("prompt_library/global/security_rules.md", "r") as f:
    security_rules = f.read()

with open("prompt_library/dev_agents/coding_standards.md", "r") as f:
    coding_standards = f.read()

# 2. Определяем базовый шаблон для агента-разработчика
developer_prompt_template = ChatPromptTemplate.from_messages(
    [
        (
            "system",
            """You are a senior Python developer.
Your goal is to write clean, efficient, and secure code.

---
GENERAL SECURITY RULES:
{security_rules}
---
PYTHON CODING STANDARDS:
{coding_standards}
---

Your specific task is: {task}
""",
        ),
        ("human", "{input}"),
    ]
)

# 3. Динамически создаем финальный промпт
final_prompt = developer_prompt_template.invoke(
    {
        "security_rules": security_rules,
        "coding_standards": coding_standards,
        "task": "Create a login endpoint using FastAPI.",
        "input": "Start working on the task.",
    }
)

Преимущества этого подхода:

  • Централизованное обновление: Если вам нужно изменить правила безопасности, вы меняете один файл (security_rules.md), и это изменение автоматически применяется ко всем агентам, которые его используют.
  • Консистентность: Все агенты работают по единым правилам, что делает поведение системы более предсказуемым.
  • Читаемость: Промпты агентов остаются чистыми и короткими. В них содержится только уникальная для этого агента логика, а все общее вынесено.
  • Версионирование: Так как инструкции хранятся в Git, у вас есть полная история их изменений.

Что может пойти не так:

  • Проблема: Слишком много общих инструкций "раздувают" контекст, и LLM начинает их игнорировать.
  • Решение: Не включайте в шаблон все подряд. Для каждого типа агента создавайте свой набор релевантных общих инструкций. Агенту-копирайтеру не нужны правила по написанию SQL-запросов.

Полезные материалы:

- При запуске субагентов постоянные запросы на подтверждение несмотря на выданные разрешения

Эта проблема часто возникает в фреймворках, где безопасность является приоритетом, и связана она с делегированием задач и управлением правами доступа. Давайте разберемся в механике и способах решения.

Почему это происходит: Механика делегирования

Когда один агент (менеджер) делегирует задачу другому агенту (исполнителю), возникает вопрос: с чьими правами исполнитель должен выполнять эту задачу?

  • Сценарий 1 (Безопасный по умолчанию): Исполнитель имеет только свои, минимальные права. Если менеджер просит его сделать что-то, на что у него нет разрешения (например, записать файл), исполнитель должен запросить подтверждение у пользователя. Это стандартное поведение во многих системах, чтобы предотвратить несанкционированные действия.

  • Сценарий 2 (Наследование разрешений): Исполнитель временно получает права от менеджера на время выполнения конкретной задачи.

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

Решения в зависимости от фреймворка:

  1. CrewAI: Управление делегированием В CrewAI за это отвечает параметр allow_delegation у агента.

    • allow_delegation=True: Означает, что этот агент (например, менеджер) может передавать задачи другим агентам.
    • allow_delegation=False: Этот агент — рабочая лошадка, он не может никому ничего делегировать и должен выполнить задачу сам, используя свои инструменты.

    Как решить проблему:

    • Четко определите роли. Убедитесь, что у агента, который должен выполнить действие (например, записать файл), есть соответствующий инструмент в его списке tools.
    • Проверьте логику оркестратора. Часто менеджер неправильно формулирует задачу. Вместо Эй, исполнитель, запиши этот файл, он может говорить Эй, исполнитель, разберись с этой задачей, и исполнитель пытается делегировать ее дальше, что требует подтверждения.
    • Явная передача ответственности. В задаче (Task) для исполнителя должно быть четко указано, что именно он является ответственным за финальное действие.

  2. AutoGen: Управление правами в чате В AutoGen это чаще связано с настройками UserProxyAgent — агента, который представляет пользователя и запрашивает подтверждения.

    • human_input_mode: Этот параметр у UserProxyAgent контролирует, как часто запрашивать подтверждение.
      • ALWAYS: Спрашивать всегда (по умолчанию).
      • TERMINATE: Никогда не спрашивать, автоматически одобрять и завершить при ошибке.
      • NEVER: Никогда не спрашивать, автоматически одобрять все действия. Это то, что вам нужно, но используйте с осторожностью!

    Как решить проблему (на свой страх и риск):

    import autogen

# ... (config_list, llm_config)

user_proxy = autogen.UserProxyAgent(
   name="Admin",
   human_input_mode="NEVER", # Автоматически одобрять все действия
   code_execution_config={
       "work_dir": "coding",
       "use_docker": False
   }
)

Лучшие практики и безопасность на 2026 год:

  • Никогда не отключайте подтверждения полностью в production. Автоматическое одобрение (human_input_mode="NEVER") допустимо только для отладки или в полностью изолированных песочницах.
  • Гранулярные разрешения. Вместо того чтобы давать агенту право на "все", давайте ему доступ к очень конкретным инструментам. Вместо инструмента execute_shell_command создайте execute_safe_python_script, который имеет ограничения.
  • Инструменты с внутренним подтверждением. Более продвинутый подход — встроить логику подтверждения в сам инструмент. Например, инструмент delete_file может принимать дополнительный параметр confirm=True, без которого он не сработает. Агент-менеджер должен явно принять решение и добавить этот флаг в вызов.

Что может пойти не так:

  • Отключив подтверждения, вы можете случайно позволить агенту выполнить деструктивное действие, например, удалить не те файлы или потратить реальные деньги через API.

Полезные материалы:

- Слепошарые субагенты-ревьюеры

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

Вот как решают проблему слепых ревьюеров.

1. Предоставление полного и релевантного контекста

LLM не может оценить то, чего не видит. Передавать на ревью только измененный фрагмент кода — это главная ошибка.

  • Что нужно передавать в контекст:

    1. Измененный файл целиком (Diff): Не просто добавленные/удаленные строки, а весь файл с изменениями. Это позволяет агенту понять, как изменения вписываются в существующую логику.
    2. Связанные файлы и зависимости: Если изменяемая функция вызывает другие функции или использует классы из других файлов, эти файлы (или хотя бы их сигнатуры и docstrings) также должны быть в контексте.
    3. Изначальная задача (Task/Ticket Description): Агент должен знать, какую бизнес-задачу решал разработчик. Без этого он не сможет оценить, правильно ли реализована логика.
    4. Общие стандарты кодирования (Coding Standards): Ссылка на PEP8, внутренний стайлгайд и т.д.

  • Как это реализовать: Используйте RAG (Retrieval- Augmented Generation). Перед тем как запустить ревьюера, специальный скрипт-ретривер находит все релевантные файлы и информацию и формирует полный контекст.

2. Конкретизация промпта и роли ревьюера

Общий промпт "проверь этот код" дает общий результат. Промпт нужно делать максимально детальным и структурированным.

  • Плохой промпт: Ты — ревьюер. Проверь код.
  • Хороший промпт (структурированный): 
    Ты — Senior Python-разработчик и ревьюер кода.
Твоя задача — провести ревью предоставленного кода по
следующим, строго определенным критериям.

**Изначальная задача:**
{ticket_description}

**Изменения в коде (diff):**
{code_diff}

**Связанные файлы:**
{related_files_content}

**Твой процесс ревью (шаг за шагом):**
1.  **Соответствие задаче:** Убедись, что код полностью
    решает изначальную задачу.
2.  **Корректность логики:** Проверь код на наличие
    логических ошибок, edge-кейсов и багов.
3.  **Безопасность:** Проанализируй код на предмет
    уязвимостей (SQL-инъекции, XSS, и т.д.).
4.  **Читаемость и стиль:** Убедись, что код соответствует
    стандартам PEP8 и легко читается.
5.  **Тесты:** Проверь, что для нового кода написаны тесты
    и они покрывают основные сценарии.

Предоставь свой ответ в формате JSON со следующими
ключами: `score` (от 1 до 10), `issues` (список найденных
проблем с указанием файла и строки), `summary` (краткое
заключение).

3. Использование специализированных моделей

Для задач анализа кода лучше всего подходят модели, которые были специально дообучены на больших объемах кода.

  • Лучшие модели на 2026 год:
    • Проприетарные: последние версии GPT-4.x-Code-Series, Claude 3.x Opus.
    • Open-Source: последние итерации CodeLlama или Mistral-Code.

4. Итеративное ревью (Chain of Thought)

Вместо того чтобы просить агента выдать результат сразу, можно заставить его рассуждать по шагам.

  • Как это работает: Сначала вы просите агента проанализировать код по первому критерию (соответствие задаче) и записать свои мысли. Затем — по второму (корректность логики) и так далее. Это заставляет модель глубже вникать в код и повышает качество финального ревью. Такой подход легко реализуется в LangGraph.

Что может пойти не так:

  • Проблема: Даже с полным контекстом агент упускает сложные бизнес-логические ошибки.
  • Решение: LLM все еще не идеальны. Систему автоматического ревью следует рассматривать как первый уровень проверки (линтер на стероидах), который ловит 80% проблем. Финальное ревью от человека для критически важного кода все еще необходимо.

Полезные материалы:

- Как часто используете агента? Много ли времени уходит на адаптацию под новую задачу?

Часть 1: Как часто используются агенты?

Сегодня AI-агенты из экспериментальной технологии превратились в стандартный инструмент в арсенале разработчика, но их применение сильно зависит от контекста.

  • Ежедневное использование (рутинные задачи):

    • Генерация и рефакторинг кода: Инструменты вроде GitHub Copilot и более продвинутые агенты, встроенные в IDE, используются постоянно, десятки раз в день. Это уже стало мышечной памятью.
    • Написание тестов: Очень частый кейс. Разработчик пишет основную логику, а рутинную задачу по написанию unit-тестов делегирует агенту.
    • Анализ данных и запросы: Аналитики и дата- сайентисты ежедневно используют агентов, которые умеют писать SQL-запросы или Python-скрипты для обработки данных по запросу на естественном языке.

  • Периодическое использование (сложные задачи):

    • Создание новых проектов/сервисов: Команды мультиагентных систем (dev crews) используются в начале проекта для быстрого создания каркаса приложения (scaffolding). Это происходит не каждый день, а при старте нового проекта или большой фичи.
    • Автоматизация процессов: Агенты для автоматизации маркетинга, обработки документов или других бизнес- процессов запускаются по расписанию (например, раз в час или раз в день) или по триггеру. Разработчики взаимодействуют с ними только при настройке или отладке.

  • Редкое использование (специфические задачи):

    • Аудит безопасности: Запуск агентов для поиска уязвимостей в коде.
    • Миграция кодовой базы: Написание агента для автоматического переноса кода со старого фреймворка на новый.

Вывод: Агенты используются постоянно, но это не один супер-агент, а множество разных — от маленьких помощников в IDE до сложных систем, работающих в фоне.

Часть 2: Много ли времени уходит на адаптацию под новую задачу?

Время на адаптацию кардинально сократилось по сравнению с 2023-2024 годами благодаря развитию фреймворков и паттернов проектирования.

Факторы, влияющие на время адаптации:

  1. Новизна задачи:

    • Типовая задача (15-30 минут): Если задача похожа на то, что уже делали (например, создать еще один агент для работы с новым API), то процесс очень быстрый. Вы просто берете существующий шаблон, меняете конфигурацию (URL, промпт) и инструменты.
    • Новая задача (2-8 часов): Если нужно создать агента для совершенно новой области (например, агента для управления Kubernetes-кластером), то потребуется больше времени на:
      • Исследование и создание кастомных инструментов.
      • Написание и отладку промпта (prompt engineering).
      • Тестирование на разных сценариях.

  2. Наличие готовых инструментов:

    • Если для задачи есть готовые интеграции (например, в LangChain Community есть инструмент для работы с нужным сервисом), адаптация занимает минуты.
    • Если нужно писать инструмент с нуля (например, парсер для сложного формата файла), это может занять несколько часов.

  3. Зрелость вашего внутреннего фреймворка:

    • Если у вас уже есть "фабрика агентов", центральный реестр инструментов и библиотека промптов, то добавление нового агента — это в основном работа с конфигурациями.
    • Если вы каждый раз пишете все с нуля, это будет долго.

Вывод: Для опытной команды адаптация агента под новую, но похожую на предыдущие, задачу — это быстрый процесс. Создание принципиально нового агента требует времени, но это скорее R&D-задача, а не рутинная операция. Главное — инвестировать в создание переиспользуемых компонентов (инструментов, промптов, шаблонов).

Полезные материалы: