Мультиагентная система delivery

Роли агентов, общий контекст через RAG и мелкая нарезка задач

Это не набор “умных ботов”, а производственная цепочка. Каждый агент отвечает за свою роль, работает с очень маленьким контекстом, часто стартует в новой сессии, получает одинаковую базу знаний через RAG и действует по собственному HEARTBEAT.md, который срабатывает раз в 5 минут.

Ключевые архитектурные правила
У агентов маленький контекст Нельзя надеяться на длинную “память” одной сессии. Сессии регулярно пересоздаются, часто на каждую задачу.
После системного аналитика задачи становятся мелкими Высокая гранулярность нужна, чтобы builder, qa, ops и reviewer работали быстро, независимо и предсказуемо.
RAG выравнивает контекст Все требования, аналитика, история задач и артефакты task-tracker подтягиваются при старте каждой новой задачи.
У каждого агента свой HEARTBEAT.md Раз в 5 минут агент получает свой короткий operational prompt: что проверить, что взять в работу, что обновить в task-tracker и что доложить дальше по цепочке.
RAG
единый слой знаний для всех ролей: бизнес-постановка, системная аналитика, решения reviewer, политики ИБ, статусы задач и результаты тестов
Task tracker
операционный центр системы: хранит нарезку задач, статусы, артефакты, отчёты и контроль прохождения по ролям
Reviewer
сквозной контроль качества: проверяет системную аналитику и работу каждого агента, ловит ошибки соответствия и дефекты handoff

Роли агентов в системе

У каждого агента узкая зона ответственности. Это снижает требования к контексту, повышает воспроизводимость и позволяет пересоздавать сессии без потери управляемости.

Анализ

Системный аналитик

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

Контроль

Информационная безопасность

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

Качество

Reviewer

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

Инфраструктура

Ops инженер

Подготавливает тестовый стенд, переносит тестовые сборки, обеспечивает среду для проверки и снижает риск “у меня локально работало”.

Разработка

Builder

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

Проверка

QA

Пишет и прогоняет тесты, валидирует acceptance criteria, фиксирует дефекты и возвращает результат обратно в task-tracker и reviewer-контур.

Схема взаимодействия агентов

Главная идея, это не хранить весь процесс в одной длинной беседе, а разложить его на роли, артефакты и короткие задачи. Общий смысл системы держится не в оперативной памяти агентов, а в RAG и task-tracker.

Бизнес-постановка цель, ограничения, результат Системный аналитик системные требования и декомпозиция Reviewer ревью аналитики и handoff InfoSec политики, риски, ограничения Task tracker мелкие задачи и статусы RAG / единый слой знаний аналитика • ИБ • задачи • артефакты • тесты • отчёты новая сессия → тот же релевантный контекст Builder имплементация задач QA тесты и acceptance Ops инженер стенд и тестовые сборки Reviewer loop контроль каждого handoff

Почему здесь обязательно нужен RAG

Если сессии регулярно пересоздаются, а у агентов маленький контекст, то “держать всё в голове” невозможно. Значит, контекст должен жить в системе, а не в конкретной беседе.

Источник истины

Аналитика и задачи живут вне сессии

Системные требования, решения reviewer, результаты ИБ, тестовые артефакты и история задач сохраняются и индексируются.

Равный старт

Каждый агент начинает с одинакового контекста

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

Масштабирование

Можно безопасно дробить работу

После системного аналитика задачи становятся маленькими и независимыми, а качество не падает, потому что RAG и reviewer держат общую картину.

Как работает HEARTBEAT.md у каждого агента

Чтобы короткоживущие агенты не выпадали из процесса, у каждой роли есть свой HEARTBEAT.md. Он срабатывает раз в 5 минут и задаёт простой operational rhythm: что проверить, что взять в работу, что обновить и кому передать результат дальше.

Ритм

5-минутный цикл

Агент не держит длинную беседу “живой”. Он регулярно стартует заново, читает свой HEARTBEAT.md и возвращается к работе по короткому циклу.

Инструкция роли

У каждого своя проверка

System analyst проверяет входящие постановки, InfoSec сверяет ограничения, Builder смотрит свои implementation-таски, QA берёт тесты, Ops готовит стенд, Reviewer контролирует handoff.

Связка с RAG

Heartbeat не заменяет знания

HEARTBEAT.md говорит, что делать сейчас. RAG даёт одинаковый контекст. Task-tracker хранит факт работы и артефакты. Вместе это делает короткие сессии управляемыми.

Пример нашего task-tracker

Task-tracker нужен не только для статусов. Он служит точкой маршрутизации между агентами и контейнером для артефактов, которые потом возвращаются в RAG. Ниже есть и схема, и реальный screenshot рабочего `/tasks/`, где видна карточка задачи, переданной Claude.

Рабочий контур
http://66.42.121.18/tasks/
Что хранится в карточках system requirements, security notes, reviewer comments, implementation notes, test results, deployment handoff
Todo готово к взятию
SA-241
Разбить бизнес-постановку на системные требования и acceptance criteria
role: analyst rag: business brief
SEC-241
Проверить требования на соответствие внутренним правилам ИБ
role: infosec rag: policies
In progress в работе
BLD-242
Имплементировать один узкий сценарий из системной аналитики
role: builder granularity: high
REV-242
Проверить соответствие реализации аналитике и замечаниям ИБ
role: reviewer rag: linked tasks
Done артефакты сохранены
QA-243
Написать и прогнать тесты, сохранить результаты в карточке
role: qa artifacts: tests
OPS-243
Поднять тестовый стенд и перенести тестовую сборку
role: ops handoff: qa->ops
Реальный screenshot /tasks/

Живой пример карточки, переданной Claude

Ниже реальный screenshot страницы /tasks/. В кадре видна настоящая Claude-задача #23 со статусом In Progress: «Claude: добавить запись микрофона, вариант B (один общий файл)».

Реальный screenshot task-tracker с карточкой Claude-задачи #23
Это не макет. Это реальный кадр рабочего task-tracker по адресу /tasks/, где задача была передана Claude через карточку на доске.

На чём будем собирать агентный слой

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

Skills library

andrej-karpathy-skills

Базовый набор skill-based паттернов, который можно положить в основу ролей system analyst, builder, qa, ops и reviewer. Это ускоряет сборку рабочих агентов и помогает унифицировать их операционное поведение.

github.com/forrestchang/andrej-karpathy-skills

Agent enhancement

Superpowers

Набор усилений для агентной работы: удобные режимы, вспомогательные capability-блоки и практики, которые помогают делать агентов полезнее в реальных delivery-процессах, а не только в демонстрационном режиме.

github.com/obra/superpowers

Итог Все роли в этой схеме, от аналитика до QA и reviewer, планируются к запуску на базе комбинации andrej-karpathy-skills и superpowers, поверх нашего RAG, HEARTBEAT.md и task-tracker процесса.