ИИ-агент - разработчик без права на последний клик: как мы выстроили работу на ELMA 365
Мы создаём бизнес-модули на ELMA 365: от договоров и карточек контрагентов до корреспонденции, доверенностей и облигаций. В разработке всё чаще участвуют ИИ-агенты: они редактируют формы и скрипты, запускают проверки, готовят документацию и отчёты. Но быстро стало ясно: чтобы такая помощь приносила пользу, мало выбрать подходящую модель и составить хороший запрос. Нужны понятные правила работы и границы полномочий.
Этот материал - о том, как мы выстроили разработку на ELMA 365 с участием агентов и какие меры помогли защитить проект от случайных изменений. Практика показала: важнее всего оказались не возможности ИИ, а дисциплина процессов.
Когда два агента делят один проект
Поначалу мы воспринимали агента как очень быстрого разработчика: поручил задачу - получил результат. Однако у него нет человеческой памяти о вчерашних обсуждениях и понимания того, чем занят коллега в соседней сессии. Если несколько агентов работают в общей папке, один может долго проверять функциональность, пока другой изменяет файлы. В итоге в коммит легко попадают чужие черновики, временные скрипты или результаты экспериментов.
Были и ошибки другого рода. У нас есть два сервера разработки, а названия переменных в конфигурации исторически вводили в заблуждение: переменная с будто бы очевидным именем указывала не на тот сервер. Агент несколько раз выполнял работу в неправильной среде. Однажды он закончил исправление и проверил его, но затем выяснилось, что всё сделано не там. На нужном сервере соответствующий виджет оказался устроен иначе, поэтому задачу пришлось начинать заново.
После этого мы добавили в инструкции конкретное требование: ориентироваться на фактический адрес сервера, а не на название переменной. Вывод оказался простым: агенту нужна не безграничная самостоятельность, а чёткая и проверяемая рамка. Подробнее о принципах, которые мы применяем, рассказываем в материале о разработке на ELMA 365 с ИИ-агентами.
Отдельная копия для каждой задачи
Первое правило - изоляция. Для каждой задачи мы создаём отдельную ветку и собственную рабочую копию проекта через Git worktree. Такие копии хранятся в служебной папке внутри проекта. Основную рабочую директорию использовать для изменений нельзя - она нужна только для просмотра.
Так агенты не вмешиваются в работу друг друга: у каждого свои файлы, временные материалы и коммиты. Однако отдельная копия проекта защищает только файловую часть. Объекты, размещённые на сервере ELMA 365, не становятся изолированными автоматически. Если несколько исполнителей одновременно редактируют один процесс или форму, разнесение по папкам не решит проблему.
Поэтому перед изменением серверного объекта агент должен зафиксировать, с чем именно он работает, и убедиться, что этот объект не менялся параллельно. Каждая задача также сопровождается журналом. В нём отмечают все затронутые сущности: формы, виджеты, процессы, файлы, тестовые записи и временные доступы.
Важно сохранять не только перечень изменений, но и подробности: каким было исходное состояние объекта, каким способом его редактировали - через интерфейс, API или утилиту, что в итоге записалось на сервер и какие временные материалы создали или удалили. Скриншота недостаточно: подтверждением должны служить выгрузка либо ответ сервера. В журнал попадают и неудачные или частично завершённые операции - именно они особенно важны при разборе непредвиденных последствий.
Такая фиксация может казаться лишней бюрократией. Но спустя пару недель сложно вспомнить, кто и зачем менял кнопку на форме согласования. Записи в журнале помогают восстановить ход работы и человеку, и команде, и следующему агенту.
Рабочая система - только для чтения
Ещё одно правило мы сформулировали без исключений: в рабочей системе агенты ничего не меняют. Запрещено сохранять, публиковать, создавать и удалять объекты - даже если требуется "только проверить". При этом чтение разрешено и часто необходимо. Например, когда нужно изучить документ, задачу или историю процесса, с которыми работают пользователи.
Одного запрета в инструкции мало, поэтому мы добавили техническое ограничение. Браузерная сессия в рабочей системе фильтрует запросы: пропускаются действия чтения, входа и поиска, а операции изменения блокируются до отправки со страницы. Так правило действует не только на словах, но и на уровне механизма выполнения запросов.
Разделение ролей помогает избежать опасной ситуации, когда агент сам вносит изменение и сам же объявляет его успешным. В нашей схеме он может подготовить работу, проверить её в допустимой среде и отчитаться, но последний шаг - публикация или изменение в рабочей системе - остаётся за человеком. Это и есть принцип "сотрудника без права на последний клик".
Опубликовано - ещё не значит работает
Для внедрения ELMA 365 важно различать публикацию изменения и подтверждение результата. Статус "опубликовано" говорит о том, что действие состоялось, но сам по себе не доказывает, что бизнес-сценарий работает как задумано. Проверять результат должен другой участник - не тот, кто выполнял изменение.
Независимая проверка позволяет заметить несовпадение с постановкой, побочные эффекты и ошибки в трактовке задачи. Это особенно важно, когда агент действует уверенно: убедительная формулировка в отчёте ещё не равна подтверждённому результату. Поэтому проверяющий сверяет фактическое состояние объекта с требованиями и данными журнала.
Отчёт агента - часть результата
В завершении задачи агент должен не просто сообщить, что "всё готово". В отчёте следует перечислить, что изменено, что проверено, где именно выполнялась работа и какие действия остались человеку. Отдельно нужно описать временные объекты и способы их удаления, а также указать на ошибки или незавершённые операции.
Такой формат делает автоматизацию бизнес-процессов ELMA 365 прозрачнее: команде проще оценить результат, продолжить работу или откатить изменение. Он полезен и для разработки приложений на ELMA 365, где в одной задаче могут затрагиваться интерфейсы, серверные процессы и интеграции.
ИИ-агенты для бизнеса способны брать на себя рутинные действия и ускорять подготовку изменений, но их эффективность зависит от организации работы. Изоляция задач, журналирование, ограниченные права и независимая проверка не мешают автоматизации - они позволяют применять её безопаснее. Именно такие правила дают возможность постепенно расширять участие агентов, не передавая им контроль над критическими операциями.