Что такое ИИ-агент на практике: три правила, спасающие проект на ELMA 365 от хаоса

Автор оригинала больше двадцати лет руководит ИТ-командой и делает модули на ELMA 365: договоры, контрагенты, корреспонденция, доверенности, облигации. Первые недели с агентами обернулись хаосом: два агента работали в одной папке, коммит любого из них подхватывал черновики соседа, а перепутанные имена переменных отправляли задачи не на тот сервер. Выводы команда зафиксировала в виде трёх правил, каждое из которых родилось из конкретного провала.

Что понадобится

• Доступ к платформе ELMA 365 с серверами разработки и рабочей (продуктивной) системой
• Git и поддержка git worktree (механизм, который позволяет держать несколько рабочих копий одного репозитория)
• ИИ-агент с доступом к браузеру и возможностью выполнять команды (например, Cursor, Windsurf или аналогичный)
• Файл инструкций для агента в корне проекта (текстовый файл с правилами, которые агент читает перед каждой сессией)
• Около 2 часов на первичную настройку изоляции и журнала

Три правила, которые спасают проект от агентного хаоса

1. Одна задача получает свою копию проекта и свой журнал

Каждая задача живёт в собственной ветке и собственной рабочей копии через git worktree. Все рабочие копии лежат в одной служебной папке внутри проекта. Работать в основной копии запрещено, только смотреть.

Команда для создания изолированной копии:

git worktree add ../worktrees/task-123 -b task-123

Это решает проблему «соседей по папке»: два агента больше не делят черновики, временные скрипты и выгрузки. Каждый коммит содержит только своё.

Но рабочая копия изолирует файлы, а не живые объекты на сервере. Если два агента правят один и тот же процесс в ELMA 365, отдельные папки не помогут. Поэтому перед правкой на сервере агент фиксирует, какой объект он «занимает», и проверяет, не менял ли его кто-то другой.

Вторая часть правила: журнал задачи. В нём записан каждый изменённый объект:

• Состояние до правки и версия объекта
• Способ правки: через интерфейс, API или утилиту
• Результат, который реально лёг на сервер
• Что создано временно и как убрано

Скриншот доказательством не считается. Нужна выгрузка или ответ сервера. Неудачные записи тоже попадают в журнал.

2. Продуктивная система только для чтения

Рабочая (продуктивная) система закрыта для записи. Агенты не сохраняют, не публикуют, не создают и не удаляют там ничего. Даже «просто проверить» с записью запрещено.

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

Технически это реализовано через фильтр запросов в сессии браузера. Фильтр пропускает только чтение, вход и поиск, а всё остальное обрывает до отправки. После работы сохранённая сессия удаляется.

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

3. «Опубликовано» не равно «работает»

Команда добавила в процессы согласования договоров и доверенностей защиту от повторного согласования. Компиляция прошла, тесты на заглушках (заглушка, имитация внешней системы для тестов) прошли, публикация завершилась без ошибок. А потом любой новый договор падал на первом шаге.

Причина: список версий файла в ELMA 365 возвращает только вытесненные версии. У файла, загруженного один раз, список пуст. Код на это не рассчитывал.

После этого случая в правилах появился жёсткий чеклист. После публикации изменение имеет статус «опубликовано, проверка не завершена». Чтобы снять этот статус:

1. Перечитать с сервера всё, что изменилось, ровно в той версии, которая опубликована
2. Сравнить с тем, что принимали до публикации
3. Пройти затронутый процесс заново на свежих тестовых данных и реальными кнопками форм
4. Убедиться, что всё временное убрано

Ключевая строка из инструкций: «собрано», «импортировано», «опубликовано» и «проверено» это четыре разных слова, и агент обязан их различать в отчёте. Код завершения импорта не доказательство. Ответ сервера «ок» не доказательство. Только прохождение реального бизнес-процесса.

Что делать с этим прямо сейчас?

Если вы автор Дзена или копирайтер. Понимание того, что такое ИИ-агент и как он работает в реальных проектах, даёт вам экспертный контент. Тема «ИИ-агенты в российских платформах» почти не раскрыта на русском языке.

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

Если вы разработчик на ELMA 365. Начните с git worktree и журнала задачи. Добавьте фильтр запросов для продуктивной сессии браузера. Зафиксируйте в инструкции агента строку про адреса серверов. Эти три шага закрывают большинство описанных проблем.

Три правила из этой статьи укладываются в одну мысль: агенту нужна не свобода, а рамка, записанная, проверяемая и одинаковая для всех сессий. Кто выстроит эту рамку первым, тот получит от ИИ-агентов пользу, а не хаос в продуктивной системе.