Это перевод моей статьи в LinkedIn
Главная мечта современных инвесторов в ИИ — это автономный ИИ сотрудник, который может полностью заменить некоторых специалистов и работать без постороннего вмешательства.
На мой взгляд это уже вполне достижимая цель, которая реализуема с текущим уровнем технологий.
Приведу пример на близкой мне области — программирование (но вообще применим к большинству digital профессий). Сделаем автономного ИИ middle backend разработчика.
Сделаем мы его на локальной серверной машине, внутри контура компании.
Сразу скажу что Я не буду выкладывать свой код, настройки или workflows для открытого доступа. Моя цель — верхнеуровнево показать рабочее для меня решение, потому что вижу не то что пробел, а вообще отсутствие материалов такого рода, даже с подобным поверхностным уровнем детализации.
Подготовка
Для начала нам понадобится полный Job Description сотрудника, данные, которые ему необходимо знать, задачи, которые ему необходимо выполнять, а также каналы связи по которым с ним можно взаимодействовать. Благо удаленка дала свои плоды и все научились взаимодействовать с сотрудниками цифровыми способами.
Формализуем доступы — к Git-у — ssh ключи, к Confluence и Jira — API ключи, токены для telegram, slack или что ещё (будь то почта или любые другие каналы связи). Записываем всё это в произвольный json конфиг файл в директории где будет работать сотрудник (корень запуска агента).
Установим докер на сервер и там запустим n8n, векторную БД и какую-нибудь реляционную БД типа PostgreSQL .
Для n8n дадим доступ к рабочей директории.
Настройка
Настроим каналы связи — в n8n добавим триггеры на нужные каналы связи, чтобы сообщения улетали в нашего агента и он мог возвращать ответы. Но дергать мы будем не обычную LLM модель, а именно через хук или кастомную ноду дергать локального агента.
Агент
Самая сложная часть это разработка агента. Но уровня агентности какого-нибудь Cursor хватает за глаза, главное сделать методологически правильные промпты.
Ещё один важный шаг это настройка MCP тулов для агента — поиск и скрапинг информации, работа с Jira, Confluence, Git и т.д. Чтобы у нашего ИИ сотрудника были руки и глаза.
Также обязательно нужен механизм RAG для мемоизации важных вещей типа как правильно решить задачу такого вида или как правильно найти такую то информацию. Что именно важно может решить сам агент простым промптом типа:
выдели важные успешные решения из текущей сессии для их запоминания
Это нужно чтобы наш ИИ сотрудник накапливал опыт. Реляционная база данных нужна для накопления «правил поведения», когда руководитель чем то не доволен и говорит «так больше не делай», или наоборот «делай вот так».
Методология
Самая важная и, скорее всего, объемная часть работы — формализовать методологию работы нашего сотрудника (по хорошему это всё уже должно быть описано в Job Description).
Делится работа на 2 этапа
наполнение RAG-а важными знаниями. Грубо говоря засовываем в RAG процесс онбоардинга.
настройка расписания — в n8n настраиваем cron триггеры, допустим в 9 утра зайти в Jira и посмотреть новые таски, назначенные для меня, проанализировать и либо начать выполнение, либо отписаться в комментариях.
Как это всё работает
Разберем на примере нашего ИИ middle разработчика:
Заходит по расписанию в Jira, стягивает свои таски.
Проверяет таску на полноту и выполнимость, если чего-то не хватает — сообщает в комментариях.
Проверяет необходимое окружение — доступ по сети, доступ к коду, возможность работы с Git и т.д.
Выполняет задачу. С нормальным описанием Cursor уже сейчас для меня закрывает 100% задач уровня middle разработчика (если у Вас нет, значит либо страдает полнота контекста, либо качество промпта).
Тестирует локально с помощью какого-нибудь Playwright MCP или Postman.
Заливает результат в дев, проверяет пайплайн деплоя.
Если ошибки, отписывает в комментариях, может написать девопсу, откатывает таску на другой шаг.
Если всё без ошибок, снова проверяет на деве.
Двигает таску, отписывается в комментариях, группе или где ещё (как настроили каналы связи и методологию).
Вместо дейликов, может собрать с Jira информацию о вчерашних тасках, с Git-а об изменениях для этих тасок и отправить отчет. Также может сообщить о зафейленных тасках и почему так получилось.
Может отвечать на сообщения в telegram, slack и других каналах связи.
Даже может на основе мемоизации опыта и исследовании кода подсказывать решения джунам или тестировщикам.
В принципе всё, на текущем этапе это уже довольно надежный и качественный middle разработчик лучше среднего по рынку.
Заключение
Конечно многое зависит от используемой агентом модели, но никто не мешает тестировать разные варианты, подыскивая хорошее соотношения качества/цены/скорости.
Также очень важно проработать методологию работы, чтобы учитывать разные варианты поведения модели.
Не стоит забывать о механизмах защиты агента от зацикливания или ухода в бесконечные бессмысленные рассуждения. Но если агент хорошо проработан, там это уже есть.
Хоть это и псевдо архитектура, у меня уже получается запускать локально многие описанные вещи.
На этом всё, спасибо за внимание.
Источник: habr.com
