Что такое сеть ИИ-агентов простыми словами: как мы собрали команду из пяти ролей для разбора техзадания

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

Если объяснить, что такое ИИ-агент простыми словами: это не просто модель, которая отвечает на вопрос, а программа, которая сама решает, какой инструмент вызвать, читает результат, думает и делает следующий шаг. А сеть ИИ-агентов — это несколько таких программ с разными ролями, которые обмениваются сообщениями и вместе решают задачу, которую поодиночке не тянут.

Первый подход: один агент, который «умеет всё»

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

На маленьких документах работало. На настоящем ТЗ агент начинал плыть уже к середине. Терял начало, путал разделы, пропускал таблицы с параметрами, склеивал требования из разных глав в одно. Классическая картина, когда контекст растёт быстрее, чем модель успевает удерживать фокус. Мы перепробовали всё, что положено: разбить документ, добавить резюме промежуточных шагов, вынести часть работы в отдельные вызовы. Стало лучше, но ощущение было, что мы латаем дырявую лодку.

В какой-то момент стало очевидно: одна голова не тянет. Нужна команда.

Как написать ИИ-агента, который знает своё место

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

Это дало сразу два эффекта. Во-первых, промпт роли стал короче и жёстче: меньше слов, меньше двусмысленности, меньше поводов у модели «уплыть». Во-вторых, каждую роль стало можно тестировать отдельно. Мы собрали набор реальных фрагментов ТЗ и гоняли по ним конкретного агента, пока он не переставал ошибаться на знакомых сценариях.

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

Пять ролей нашей команды

В финальной версии в разборе ТЗ участвует команда ИИ-агентов из пяти ролей.

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

Второй — извлекатель требований. Идёт по размеченным разделам и достаёт формулировки: функциональные, нефункциональные, регуляторные. Каждое требование получает ссылку на страницу и цитату, чтобы человек мог быстро проверить. Здесь нам понадобилась модель посерьёзнее — российский GigaChat Pro в контуре клиента справляется, а на локальных задачах мы пробовали и открытые модели вроде Qwen.

Третий — сверщик. Берёт список требований и ищет внутренние противоречия. Классика: в третьей главе просят одно, в приложении Б — противоположное, а в техническом регламенте — третье. Человек это ловит на четвёртый день чтения, агент — за один прогон.

Четвёртый — сопоставитель с архивом. Идёт в наш pgvector, где лежат прошлые ТЗ и результаты по ним, и говорит: похожий блок мы уже делали для другого заказчика, вот наши прошлые оценки. Именно этот агент экономит больше всего человеко-часов, потому что заменяет память старших коллег, которые «помнят, что похожее было».

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

Как они разговаривают

Здесь мы наступили на грабли, о которых сейчас пишут все, кто выходит на production с командой ИИ-агентов. Первый вариант был красивым: пусть агенты общаются как люди, свободным текстом, координатор пересылает сообщения. Через неделю мы утонули в интерпретации. Один агент писал «противоречие вероятно», другой это воспринимал как «противоречие подтверждено», третий вообще пропускал такой пункт.

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

Оркестрация — на нашей внутренней платформе, поверх FastAPI и PostgreSQL. Никакого волшебства: очередь задач, статусы, повторные попытки, дедлайны на каждый шаг. Похожие подходы сейчас закладывают в Microsoft Agent Framework Harness, который в начале августа вышел в GA, и в Google Gemini Enterprise Agent Platform. Логика та же: агент — это не свободный дух, а сервис с контрактом, за которым нужно наблюдать.

Где мы провели границу

Соблазн был большой: сделать агентом каждое действие. Мы удержались.

Простая проверка страницы на наличие таблицы — не агент, а обычная функция. Разбор PDF — не агент, а библиотека, которая честно достаёт текст и координаты ячеек. Поиск по эмбеддингам — не агент, а вызов pgvector. Мы оставили роль ИИ-агента только там, где нужно принимать решение: что делать дальше, какой инструмент выбрать, стоит ли переспросить.

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

Что изменилось в работе людей

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

Расход на модели, разумеется, вырос — команда ИИ-агентов ест токены жаднее, чем один вызов. Но если считать на конечный результат — стоимость разбора одного ТЗ — экономика оказалась в нашу пользу с большим запасом.

Что мы поняли про многоагентные системы

Многоагентные фреймворки сейчас выходят один за другим: Cloudflare провёл свою Agents Week, Google открывает Gemini Enterprise Agent Platform, MuleSoft тащит агентов в свою интеграционную шину, AWS предлагает семантический слой поверх Iceberg. За этим легко потерять простую вещь: инструментов много, а задача проектирования никуда не делась.

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

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

Похожие статьи

• ИИ-агент, который сначала думает, а потом делает: Plan-and-Execute на разборе тендерной документации
• Сколько стоит ИИ-агент: почему честный ответ начинается с проектирования, а не с прайса
• «А ваш ИИ-агент это умеет?» — вопрос, из-за которого мы разложили агента на скиллы
• ИИ-агент, который работает сам на ноутбуке: как мы выбирали open-source модель после августовских релизов