Создайте в n8n процесс изменения кода с согласованием человеком и проверкой тестами

Общая схема процесса

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

Важно различать согласование вызова инструмента и согласование результата. В n8n проверка человеком может приостановить работу AI Agent перед выполнением выбранного инструмента. Проверяющий видит предложенный инструмент и его параметры: при согласовании вызов выполняется, а при отказе отменяется, и агент получает уведомление. Это поведение описано в руководстве n8n по участию человека в процессе.

OneMux предоставляет доступ к AI-моделям через единый OpenAI-совместимый API. Это один из возможных способов подключения модели для такой схемы, но не проверенная интеграция с n8n. Сверьте документацию OneMux API и настройки узла n8n с конечной точкой и параметрами, которые планируете использовать.

Что понадобится перед началом

• Экземпляр n8n с AI Agent, подходящим подключением чат-модели и доступом к каналу проверки человеком, например Slack или n8n Chat.
• Интеграция с репозиторием или собственный сервис, способный читать указанную ревизию и применять патч к ветке, не используемой в production. Предоставьте учётным данным для записи только необходимые права на этот репозиторий и ветку.
• Среда запуска тестов, изолированная от production-систем и учётных данных. Она должна принимать точный идентификатор коммита и возвращать статус, а также ссылку или указатель на результаты.
• Аккаунт OneMux и доступ к API, если вы выбираете OneMux для вызовов модели. Актуальные параметры подключения смотрите в кратком руководстве, а доступные модели — в каталоге моделей.
• Репозиторий с известной командой запуска тестов, защищённой основной веткой и человеком, уполномоченным проверять предлагаемые изменения.

Это схема реализации, а не готовый к импорту процесс. Инструменты работы с репозиторием, интеграция со средой запуска тестов, выбор модели и конкретные поля n8n зависят от вашего окружения. В частности, предоставленная документация не подтверждает, что определённая модель OneMux поддерживает вызов инструментов в формате, необходимом для n8n AI Agent. Проверьте эту поддержку, прежде чем полагаться на такую схему.

Постройте процесс вокруг конкретной ревизии

Практическая последовательность может быть такой:

1. Получение запроса. Возьмите репозиторий, описание задачи, целевую рабочую ветку, базовый коммит и разрешённую команду тестирования из доверенной конфигурации процесса.
2. Чтение и подготовка предложения. Позвольте агенту изучить нужные файлы на уровне базового коммита и подготовить патч. Доступ для чтения не должен позволять изменять репозиторий.
3. Проверка записи. Направьте вызов инструмента применения патча на проверку человеком в n8n. Проверяющий согласует или отклоняет предложенный вызов.
4. Применение и идентификация. После согласования сервис записи проверяет, что ветка по-прежнему указывает на согласованный базовый коммит, применяет согласованный патч и возвращает ID нового коммита. Если базовый коммит изменился, операция должна завершиться без записи; необходимо запросить новое предложение и согласование.
5. Проверка тестами. Запустите настроенные тесты именно для нового коммита в изолированной среде. Зафиксируйте команду, коммит, статус и указатель на результаты.
6. Отчёт. Отправьте проверяющему и инициатору запроса сведения о коммите и результатах тестов. Неудачное или отменённое тестирование, как и отсутствие результата, не считается успешной проверкой.

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

Настройте подключение модели

В n8n выберите конфигурацию чат-модели, которая поддерживает настраиваемую OpenAI-совместимую конечную точку и вызов инструментов в формате, необходимом AI Agent. Используйте конечную точку, метод аутентификации и идентификатор модели, указанные в актуальной документации OneMux. Храните учётные данные в системе учётных данных n8n, а не в промптах или сообщениях процесса.

Прежде чем подключать доступ к репозиторию, отправьте небольшой тестовый запрос и убедитесь, что ответ приходит в формате, ожидаемом узлом n8n. Затем проверьте безвредный вызов инструмента. OpenAI-совместимость не означает взаимозаменяемости всех конечных точек, параметров и форматов вызова инструментов: совместимость в данном случае зависит от поддержки необходимых запросов и ответов обеими сторонами. Для этой статьи такая конфигурация не тестировалась.

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

Добавьте проверку человеком перед записью в репозиторий

В узле AI Agent откройте коннектор Tools и найдите Human review в Tools Panel. Выберите канал согласования и настройте для него учётные данные. Подключите инструмент записи в репозиторий к коннектору инструмента на этапе проверки. При необходимости держите инструменты только для чтения отдельно, а другие инструменты, способные изменять состояние внешних систем, разместите за собственной проверкой или эквивалентным контролем.

Согласно документации n8n, проверяющий может получить имя инструмента и параметры, заданные AI. Например, настройте сообщение для проверки так:

Proposed tool: {{ $tool.name }}
Proposed parameters:
{{ JSON.stringify($tool.parameters, null, 2) }}

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

Документированные значения $tool.parameters включают поля, настроенные с помощью выражений $fromAI(); не предполагайте, что сообщение раскрывает все фиксированные учётные данные, скрытые значения конфигурации или последующие последствия. Ограничьте фиксированные настройки и предоставьте проверяющим отдельный способ их изучить. Не помещайте секреты в параметры инструмента: они могут появиться в сообщениях для согласования.

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

Repository writes require human approval. Propose a patch against the
specified base commit and request the write tool only for that patch.
If approval is denied, do not retry the write or use another tool to make
the change. Tell the requester it was denied and ask for clarification.
Report test results only when supplied by the test runner.

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

Проверьте согласованное изменение

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

npm test

Эта команда приведена только для примера; используйте реальные инструкции проекта по тестированию. Считайте код репозитория, скрипты установки зависимостей и вывод тестов недоверенными. Запускайте их с ограниченным доступом к сети и файловой системе, без секретов production и с ограничениями по времени и ресурсам. Успешное прохождение набора тестов показывает лишь то, что выбранные проверки прошли в данной среде; оно не доказывает безопасность или корректность изменения.

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

Устранение неполадок и ограничения эксплуатации

В запросе на согласование недостаточно контекста

Проверьте, какие входные данные задаёт AI и какие из них видны в $tool.parameters. Включите идентификатор патча, ветку и базовую ревизию во входные данные инструмента, доступные для проверки, либо предоставьте защищённый неизменяемый артефакт для проверки. Если проверяющий не может определить точное содержимое записи, её следует отклонить.

Агент не может вызвать инструмент

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

Ветка изменилась или тесты не завершились

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

Заключение

Граница контроля здесь чёткая: человек согласует конкретную запись в репозиторий, а изолированная среда проверяет полученный коммит. n8n обеспечивает документированную приостановку и согласование на уровне инструмента; остальные меры защиты обеспечиваются вашим сервисом репозитория, средой запуска, правами доступа и процессом проверки. Используйте OneMux как уровень доступа к модели только после подтверждения того, что выбранная конечная точка и параметры работают с вашей конфигурацией n8n.

Источники

• n8n: Human-in-the-loop for tools — поведение при согласовании инструментов, настройка, каналы проверки и переменные сообщений для проверки.
• Документация OneMux — актуальные сведения о подключении к API.