ИИ-агент — сотрудник без права на последний клик. Как мы организовали разработку на ELMA 365 с ИИ-агентами

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

Звучит как реклама. Но первые недели выглядели иначе. Два агента одновременно работали в одной папке проекта. Один часами гонял браузер, второй тихо делал свою задачу. А коммит любого из них мог подхватить мусор, оставленный соседом.

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

Исходная точка: агент делает много, но не всё

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

Кажется, что агент — это просто быстрый разработчик. Дал задачу, получил результат. Но у агента нет памяти о вчерашнем разговоре. Он не знает, что соседняя сессия сейчас редактирует ту же форму. Он уверенно путает серверы, если переменные в настройках названы неудачно.

У нас ровно так и вышло. Есть два сервера разработки. Имена переменных в конфигурации исторически перепутаны: переменная с «очевидным» названием указывает на другой сервер. Агент несколько раз подряд делал задачу не там. В одном случае он собрал и проверил исправление целиком, а потом выяснилось, что сервер не тот. Я написал ему что-то вроде «ты опять всё путаешь». Работу переделали с нуля, и на правильном сервере виджет оказался устроен совсем иначе.

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

Правило первое: одна задача — своя копия проекта и свой журнал

Первая рамка — изоляция. С октября каждая задача живёт в собственной ветке и собственной рабочей копии проекта (git worktree). Все рабочие копии лежат в одной служебной папке внутри проекта. Работать в основной копии нельзя, только смотреть.

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

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

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

• состояние до правки и версия объекта;

• каким способом шла правка: через интерфейс, API или утилиту;

• результат и то, что реально легло на сервер после;

• что создано временно и как это убрано.

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

Зачем столько бюрократии? Потому что через две недели никто не помнит, кто и зачем поменял кнопку на форме согласования. Ни человек, ни агент. А журнал помнит.

Правило второе: прод только для чтения

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

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

Чтобы «только чтение» было не обещанием, а техникой, сессия браузера в рабочей системе ставит фильтр запросов. Он пропускает только чтение, вход и поиск, а всё остальное обрывает ещё до того, как страница что-то отправит. После работы сохранённая сессия удаляется.

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

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

Правило третье: «опубликовано» — это ещё не «работает»

Здесь мы наступили на самые болезненные грабли.

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

А потом выяснилось, что новый договор падает на первом же шаге согласования. Любой новый договор. Причина оказалась в поведении платформы, которого не было в тестах. Список версий файла возвращает только вытесненные версии. У файла, загруженного один раз, этот список пуст. Код на это не рассчитывал.

Хорошо, что это был сервер разработки. Исправили на следующий день. Но вывод мы записали в правила жёстко. Компиляция, проверка пакета, тесты на заглушках и чтение объекта после записи доказывают только своё. Ни одна из этих проверок не заменяет прохождение реального бизнес-процесса.

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

1. Перечитать с сервера всё, что изменилось, ровно в той версии, которая опубликована.

2. Сравнить это с тем, что принимали до публикации.

3. Пройти затронутый процесс заново, на свежих тестовых данных и реальными кнопками форм.

4. Убедиться, что всё временное убрано.

И отдельная строка, которую я повторяю чаще всего: проверка «сервер отвечает» — не доказательство. Код завершения импорта — не доказательство. Завершившийся дочерний процесс — тоже. «Собрано», «импортировано», «опубликовано» и «проверено» — четыре разных слова, и агент обязан их различать в отчёте.

Для процессов у нас есть обязательная матрица случаев. Нормальное завершение. Пустой список участников. Повторные участники. Возврат на доработку и повторная отправка. Отмена. Если задача трогает файлы или пользователей, к этому добавляются замена файла, переназначение, замещение. «Не применимо» без объяснения не принимается.

Правило четвёртое: проверяет не тот, кто сделал

Агент, который написал код, плохо видит свои ошибки. Как и человек. Только агент ещё и очень убедительно пишет, что всё готово.

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

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

У нас даже слияние в основную ветку идёт без меня. Но только если точную версию изменений подтвердил независимый проверяющий и прошла автоматическая сборка. Изменился код после проверки — проверка недействительна.

Это не про недоверие к агентам. Это про то, что подтверждение должно быть привязано к конкретному результату, а не к ощущению «вроде готово».

Эпизод: агент остановился перед последним кликом

Теперь две истории, ради которых я, честно говоря, и затеял серию.

Первая. Мы долго разбирались, можно ли вносить изменения в конфигурацию через файлы, а не только через визуальный конструктор. Агент выгружал решение, правил, пытался загрузить обратно. Утилита загрузки падала на одной и той же ошибке. Агент сузил её до минимального запроса и подготовил письмо в поддержку вендора с точными шагами воспроизведения. Это, кстати, полезно всем, кто работает с той же платформой: находка, а не жалоба.

Оставался ещё один путь. Тот же пакет можно было провести через мастер обновления конфигурации в админке. Агент дошёл в нём до шага, после которого начинается настоящее применение. И остановился. Сработал защитный механизм самой сессии, и агент не стал его обходить.

В его отчёте осталась запись: оставлено человеку, не агенту. Если хотите ответ на этот вопрос, кнопку должен нажать человек.

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

Я сначала раздражался. Потом понял, что это ровно то поведение, которое я хочу. Агент может довести меня до кнопки. Но кнопку, после которой меняется настоящая система или в чужом месте остаётся секрет, нажимаю я.

Эпизод: агент сверил задание с реальностью

Вторая история мне нравится ещё больше.

Мы планировали перейти на штатный механизм выкладки ELMA 365 между серверами. Я написал подробное задание. Его основа: основной сервер разработки — источник правды, оттуда изменения переносятся на тестовый. В задании прямо было сказано, что основной сервер недавно обновили и он новее.

Агент не стал сразу строить перенос. Первым шагом он посмотрел версии платформы на обоих серверах. И выяснилось, что всё наоборот. Основной сервер отставал от тестового больше чем на год релизов.

Мало того. На тестовом сервере лежали месяцы ручных доработок, которых на основном не было. Перенос «как написано в задании» затёр бы эту работу более старой версией решения. Да ещё и на версию платформы, с которой эту сборку никто не проверял.

Агент написал отчёт с заголовком «противоречит исходному заданию». Предложил два честных варианта: сначала выровнять версии или развернуть направление переноса. И попросил меня решить, какой сервер считать источником правды. Сам решать не стал.

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

Как агент докладывает: «Что нужно от вас»

Отчёты агентов поначалу были ужасны. Таблицы, пути к файлам, идентификаторы версий, выдержки из логов. Я читал их подолгу и в конце не понимал главного: от меня что-то нужно или нет?

В начале октября я ввёл формат, который мы оставили навсегда. Отчёт короткий, на простом русском. Первый блок — «Что нужно от вас»: только реальные решения или действия, по строке на каждое. Если ничего не нужно, так и написано. Второй блок — «Что сделано», две-четыре короткие строки. Без таблиц, путей и внутренних названий.

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

Подробности при этом никуда не исчезают. Они уходят в документацию проекта и журнал задачи. В чат идут выводы.

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

«Доделай, убери за собой, объясни суть»

Это правило появилось одновременно с форматом отчёта. Каждая задача заканчивается тремя вещами, а не одной.

Доделай. Не останавливайся на плане или половине результата. Если оставшиеся шаги можно сделать самому, делай.

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

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

Объясни суть. Человеку нужен смысл. Что теперь можно делать, чего нельзя и почему, что осталось.

Конституция для агентов

Вокруг ELMA 365 у нас уже несколько проектов. Чтобы правила не расползались, общее мы вынесли в отдельный документ, который внутри называем конституцией. Каждый проект ссылается на неё и может добавлять свои правила, только более строгие, не мягче.

Если пересказать её простыми словами, получится примерно так.

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

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

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

Проверяет не автор. Об этом я уже писал выше.

Остановки разложены по классам. Это моя любимая часть. Без неё агенты останавливаются и спрашивают по любому поводу. Поэтому у каждой типичной остановки есть класс и способ обработки:

• сбой сети или лимиты сервиса — подожди и повтори, меня не спрашивай;

• упавшие тесты, конфликт слияния, устаревшая ветка — исправь сам, это не повод для остановки;

• нет внешнего доказательства — запиши, что пытался сделать, держи этот пункт открытым и продолжай остальную работу;

• действие требует моего решения — назови, какое именно правило сработало, и работай дальше над тем, что можно;

• если решение уже понятно и остался только шаг человека — скажи, какой именно шаг;

• инцидент — эскалация сразу.

Это сильно сократило число вопросов «можно я…?». Агент больше не спрашивает разрешения починить упавший тест. И не стесняется остановиться у кнопки, которая меняет живую систему.

Что из этого можно забрать себе

Не обязательно строить такую же систему целиком. Вот что я бы внедрил в первую очередь, если вы только начинаете работать с агентами в low-code или в обычной разработке.

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

Рабочая система только для чтения. Не договорённостью, а техникой: фильтром запросов или ролью без прав записи.

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

Независимая проверка. Второй агент, который не писал код, ловит удивительно много.

Формат отчёта, который начинается с «Что нужно от вас». Вы удивитесь, сколько времени он экономит.

И правило последнего клика. Решите заранее, какие кнопки нажимает только человек. Запишите это. И радуйтесь, когда агент у такой кнопки останавливается.

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

А у вас есть кнопки, которые вы никогда не отдадите агенту? Какие?