# От GitHub Issue до продакшена: Как построить конвейер, который заставит AI-агента менять ваш сайт
Каноническая страница: https://plainews.ru/posts/ai-agent-github-issue-site-pipeline
Опубликовано: 2026-05-24T07:02:36.075Z

Как заставить LLM-агента автоматически преобразовывать тикеты из GitHub Issues в работающие веб-страницы. Пошаговый гайд по пайплайну.
Если вы устали вручную переводить баг-репорты и пожелания пользователей в задачи для разработчиков, вам нужен такой AI-агент. Я настроил конвейер, который автоматически берет любой тикет из GitHub Issues и пытается превратить его в готовую, работающую веб-страницу на вашем сайте.

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

## Зачем вообще нужно, чтобы AI чинил ваш сайт по тикету?

Основная проблема в разработке — разрыв между фидбеком пользователя (в виде сырого текста в тикете) и готовым, развернутым кодом. Обычно это требует участия менеджеров, аналитиков и разработчиков.

Автоматизация этого процесса с помощью LLM-агентов позволяет сократить цикл от "пожелания" до "рабочего демо" до минут. Вместо того чтобы просто генерировать код, агент должен пройти весь жизненный цикл: понять запрос, спланировать изменения, написать код, протестировать его и выкатить на *прод*.

Ваша задача — не просто заставить LLM писать код. Ваша задача — построить **рабочую систему (пайплайн)**, которая будет принимать сырые данные (Issue) и выдавать структурированный результат (рабочую страницу).

## Как выглядит конвейер: от Webhook до GitHub Actions

В основе этой системы лежит архитектура, которая превращает GitHub в триггер, а агента — в исполнителя.

Пошаговая логика выглядит так:

1. **Триггер:** Пользователь создает Issue в репозитории.
2. **Сбор данных:** GitHub Webhook ловит это событие.
3. **Обработка:** Webhook запускает внешний сервис (например, Docker-контейнер), который содержит AI-агента.
4. **Действие:** Агент анализирует текст Issue и решает, что нужно сделать с сайтом.
5. **Выкатывание:** Если решение принято, агент генерирует изменения в коде и запускает процесс деплоя через GitHub Actions.

### 🛠️ Шаг 1. Настройка приема тикетов (The Trigger)

Для начала нужно, чтобы внешняя система знала о новом Issue. Это делается через **GitHub Webhooks**.

Вам нужно настроить webhook для нужного репозитория. Он должен быть привязан к событию issues (или issue_comment, если вы хотите реагировать на комментарии).

В вашем коде-сервисе (который будет принимать webhook) вы должны уметь парсить JSON-тело, чтобы извлечь:

- issue_number: Номер тикета.
- issue_title: Заголовок (главная суть запроса).
- issue_body: Тело тикета (самые подробные требования).

### 🤖 Шаг 2. Архитектура агента и промптинг (The Brain)

Самый важный элемент — сам агент. Он не может просто "думать"; ему нужны стартовые промпты, которые определяют его роль и границы.

В идеале, вам понадобится не один, а **цепочка из нескольких специализированных агентов**. Каждый агент должен отвечать за определенный этап:

1. **Планировщик (Planner Agent):** Получает Issue и генерирует план действий (например: "Нужно создать новый компонент /feature/issue-123 и обновить Header.jsx").
2. **Генератор кода (Coder Agent):** Получает план и генерирует конкретные фрагменты кода (React, Python и т.д.).
3. **Тестировщик (QA Agent):** Проверяет сгенерированный код на соответствие плану и на наличие ошибок.

**Ключевой момент:** Используйте несколько профилей (как в источнике — 8 разных профилей Codex-агента). Это позволяет вам адаптировать агента под разные задачи: один профиль для фронтенда (React), другой для бэкенда (API), третий для написания документации.

В стартовый промпт (System Prompt) критически важно прописать не только роль, но и **ограничения**.

``json {   "role": "Coder Agent",   "system_prompt": "Ты — опытный фронтенд-разработчик React. Твоя задача — принимать требования пользователя и генерировать чистый, готовый к коммиту код. Ты обязан придерживаться структуры компонента src/components/. Не генерируй код, который не является React-компонентом. Всегда добавляй JSDoc-комментарии.",   "guardrails": "Нельзя использовать внешние API без явного указания в плане. Всегда проверяй валидность JSX." } ``

### 🚀 Шаг 3. Деплой и финализация (The Action)

Полученный код должен попасть на сайт. Здесь на помощь приходит **GitHub Actions**.

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

**Логика в пайплайне:**

1. Webhook передает агенту требования.
2. Агент генерирует патч-файл или список изменений.
3. Ваш сервис (на стороне сервера) записывает эти изменения в локальную ветку репозитория.
4. Сервис инициирует запуск GitHub Actions, передавая ему команду git push с новыми изменениями.

Это превращает AI-агента из простого кодогенератора в полноценного **DevOps-исполнителя**.

## Подводные камни: Где ломается идеальный конвейер

Если вы решите строить такую систему, будьте готовы к следующим проблемам:

### ⚠️ 1. Эскалация полномочий (The Jailbreak Risk)

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

**Решение:** Всегда обрабатывайте действия агента через **санитайзер**. Перед тем как выполнить команду git push или curl, прогоните ее через отдельный, не-LLM-зависимый модуль, который проверяет, находится ли действие в списке разрешенных API-вызовов.

### ⚠️ 2. Состояние мира (State Management)

LLM-агенты работают в контексте, а не в реальном времени. Если в Issue затронута сложная зависимость (например, изменение API, которое влияет на 5 других модулях), агент может проигнорировать контекст и выдать нерабочий код.

**Решение:** Делите задачи на микро-шаги. Не просите агента "починить сайт", просите "сгенерировать компонент X в файле Y, используя API Z".

### ⚠️ 3. Стоимость и предсказуемость

Использование мощных моделей (вроде GPT-4 Turbo) для каждого запроса может быть очень дорогим. Как показано в источнике, для экспериментальной, но предсказуемой работы часто достаточно самых дешевых и быстрых моделей (например, GPT-3.5 или их мини-варианты).

**Вывод:** Для эксперимента и проверки концепции (PoC) выбирайте минимально необходимый уровень "разумности" модели, чтобы держать расходы под контролем.

## Что попробовать дальше

1. **Внедрить механизм регрессионного тестирования:** После того как агент сгенерировал код, не деплойте его сразу. Запустите набор unit-тестов (Jest, Pytest) на этом коде, прежде чем он попадет на продакшен.
2. **Создать систему откатов:** Обязательно заложите в пайплайн автоматический механизм отката (rollback). Если деплой провалился, система должна автоматически откатить код до предыдущей стабильной версии.
3. **Управление контекстом:** Вместо того чтобы передавать весь Issue, извлекайте из него только *сущности* (Entities): *Что* меняется, *Где* меняется, *Для кого* меняется.

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

## Источники

- Habr AI: Пользователь пишет issue, агент меняет сайт. Да, я это сделал