Мы делаем бизнес-модули на ELMA 365: договоры, контрагенты, корреспонденция, доверенности, облигации. Всё больше этой работы делают ИИ-агенты. Они правят формы и скрипты, гоняют проверки, пишут документацию и отчёты.
Звучит как реклама. Но первые недели выглядели иначе. Два агента одновременно работали в одной папке проекта. Один часами гонял браузер, второй тихо делал свою задачу. А коммит любого из них мог подхватить мусор, оставленный соседом.
Это первая статья из семи. В ней я расскажу, как мы перестроили работу, чтобы агенты приносили пользу и не ломали чужое. Спойлер: главное оказалось не в моделях и не в промптах. А в правилах, которые мы писали, наступая на грабли.
Исходная точка: агент делает много, но не всё
Я двадцать с лишним лет руковожу ИТ. Привык, что у каждого сотрудника есть зона ответственности, права доступа и понятный порядок сдачи работы. С агентами я сначала про это забыл.
Кажется, что агент — это просто быстрый разработчик. Дал задачу, получил результат. Но у агента нет памяти о вчерашнем разговоре. Он не знает, что соседняя сессия сейчас редактирует ту же форму. Он уверенно путает серверы, если переменные в настройках названы неудачно.
У нас ровно так и вышло. Есть два сервера разработки. Имена переменных в конфигурации исторически перепутаны: переменная с «очевидным» названием указывает на другой сервер. Агент несколько раз подряд делал задачу не там. В одном случае он собрал и проверил исправление целиком, а потом выяснилось, что сервер не тот. Я написал ему что-то вроде «ты опять всё путаешь». Работу переделали с нуля, и на правильном сервере виджет оказался устроен совсем иначе.
После этого в инструкции для агентов появилась отдельная строка: читай адрес, а не имя переменной. И общий вывод: агенту нужна не свобода, а рамка. Чёткая, записанная, проверяемая.
Правило первое: одна задача — своя копия проекта и свой журнал
Первая рамка — изоляция. С октября каждая задача живёт в собственной ветке и собственной рабочей копии проекта (git worktree). Все рабочие копии лежат в одной служебной папке внутри проекта. Работать в основной копии нельзя, только смотреть.
Это решает проблему соседей по папке. Два агента больше не делят черновики, временные скрипты и выгрузки. Каждый коммит содержит только своё.
Но есть нюанс, который мы записали отдельно. Рабочая копия изолирует файлы. Живые объекты на сервере она не изолирует. Если два агента правят один и тот же процесс в ELMA 365, отдельные папки им не помогут. Поэтому перед правкой на сервере агент фиксирует, какой объект он «занимает», и проверяет, не поменял ли его кто-то другой.
Вторая половина правила — журнал задачи. В нём записан каждый изменённый объект: форма, виджет, процесс, файл, тестовая запись, временный доступ. И не только «что поменял», а как именно:
-
состояние до правки и версия объекта;
-
каким способом шла правка: через интерфейс, API или утилиту;
-
результат и то, что реально легло на сервер после;
-
что создано временно и как это убрано.
Скриншот сам по себе доказательством не считается. Нужна выгрузка или ответ сервера. Неудачные и частичные записи тоже попадают в журнал. Особенно они.
Зачем столько бюрократии? Потому что через две недели никто не помнит, кто и зачем поменял кнопку на форме согласования. Ни человек, ни агент. А журнал помнит.
Правило второе: прод только для чтения
15 октября я записал распоряжение без вариантов. Рабочая система только для чтения. Агенты не сохраняют, не публикуют, не создают и не удаляют там ничего. Никогда. Даже «просто проверить».
Читать при этом можно и нужно. Пользователи жалуются на документы, которые живут именно в рабочей системе. Агент открывает запись, задачу, историю процесса и видит то же, что видит человек.
Чтобы «только чтение» было не обещанием, а техникой, сессия браузера в рабочей системе ставит фильтр запросов. Он пропускает только чтение, вход и поиск, а всё остальное обрывает ещё до того, как страница что-то отправит. После работы сохранённая сессия удаляется.
Исправления собираются и проверяются на сервере разработки. В рабочую систему они попадают только через процесс поставки компании-партнёра. Для этого мы ведём реестр: на каждое изменение карточка с объёмом, шагами для теста и прода и списком проверок, которые можно сделать в проде только чтением.
Это медленнее, чем «быстренько поправить в проде». Зато у прода остаётся один ответственный путь изменений.
Правило третье: «опубликовано» — это ещё не «работает»
Здесь мы наступили на самые болезненные грабли.
Мы добавили в процессы согласования договоров и доверенностей защиту от повторного согласования. Если человек уже согласовал документ на одном шаге, второй раз его не дёргают. Всё скомпилировалось, тесты на заглушках прошли, публикация прошла успешно.
А потом выяснилось, что новый договор падает на первом же шаге согласования. Любой новый договор. Причина оказалась в поведении платформы, которого не было в тестах. Список версий файла возвращает только вытесненные версии. У файла, загруженного один раз, этот список пуст. Код на это не рассчитывал.
Хорошо, что это был сервер разработки. Исправили на следующий день. Но вывод мы записали в правила жёстко. Компиляция, проверка пакета, тесты на заглушках и чтение объекта после записи доказывают только своё. Ни одна из этих проверок не заменяет прохождение реального бизнес-процесса.
Теперь после публикации изменение имеет статус «опубликовано, проверка не завершена». Чтобы его снять, нужно:
-
Перечитать с сервера всё, что изменилось, ровно в той версии, которая опубликована.
-
Сравнить это с тем, что принимали до публикации.
-
Пройти затронутый процесс заново, на свежих тестовых данных и реальными кнопками форм.
-
Убедиться, что всё временное убрано.
И отдельная строка, которую я повторяю чаще всего: проверка «сервер отвечает» — не доказательство. Код завершения импорта — не доказательство. Завершившийся дочерний процесс — тоже. «Собрано», «импортировано», «опубликовано» и «проверено» — четыре разных слова, и агент обязан их различать в отчёте.
Для процессов у нас есть обязательная матрица случаев. Нормальное завершение. Пустой список участников. Повторные участники. Возврат на доработку и повторная отправка. Отмена. Если задача трогает файлы или пользователей, к этому добавляются замена файла, переназначение, замещение. «Не применимо» без объяснения не принимается.
Правило четвёртое: проверяет не тот, кто сделал
Агент, который написал код, плохо видит свои ошибки. Как и человек. Только агент ещё и очень убедительно пишет, что всё готово.
Поэтому работа не принимается, пока её не подтвердит независимый проверяющий. Это отдельный агент, который эту работу не делал. Он получает точную версию результата и проверяет её сам. Не перечитывает отчёт автора, а пишет свои проверки.
В журналах это выглядит буднично: тесты автора, отдельные проверки ревьюера и отметка, что всё прошло именно на той версии, которую проверяли. Если ревьюер ошибся в собственной проверке, это тоже записано, вместе с исправленным повтором.
У нас даже слияние в основную ветку идёт без меня. Но только если точную версию изменений подтвердил независимый проверяющий и прошла автоматическая сборка. Изменился код после проверки — проверка недействительна.
Это не про недоверие к агентам. Это про то, что подтверждение должно быть привязано к конкретному результату, а не к ощущению «вроде готово».
Эпизод: агент остановился перед последним кликом
Теперь две истории, ради которых я, честно говоря, и затеял серию.
Первая. Мы долго разбирались, можно ли вносить изменения в конфигурацию через файлы, а не только через визуальный конструктор. Агент выгружал решение, правил, пытался загрузить обратно. Утилита загрузки падала на одной и той же ошибке. Агент сузил её до минимального запроса и подготовил письмо в поддержку вендора с точными шагами воспроизведения. Это, кстати, полезно всем, кто работает с той же платформой: находка, а не жалоба.
Оставался ещё один путь. Тот же пакет можно было провести через мастер обновления конфигурации в админке. Агент дошёл в нём до шага, после которого начинается настоящее применение. И остановился. Сработал защитный механизм самой сессии, и агент не стал его обходить.
В его отчёте осталась запись: оставлено человеку, не агенту. Если хотите ответ на этот вопрос, кнопку должен нажать человек.
Похожая история случилась с привязкой серверов для штатной выкладки. Агент сам открыл нужный диалог и прошёл всё вокруг. На поле с токеном доступа сработала защита: агенту нельзя самому класть секрет в хранилище другой системы. Обходить её он не стал. Закрыл диалог без сохранения и проверил, что после него ничего не осталось. В отчёте честно написал: это поле должен заполнить человек, остальное я доделаю.
Я сначала раздражался. Потом понял, что это ровно то поведение, которое я хочу. Агент может довести меня до кнопки. Но кнопку, после которой меняется настоящая система или в чужом месте остаётся секрет, нажимаю я.
Эпизод: агент сверил задание с реальностью
Вторая история мне нравится ещё больше.
Мы планировали перейти на штатный механизм выкладки ELMA 365 между серверами. Я написал подробное задание. Его основа: основной сервер разработки — источник правды, оттуда изменения переносятся на тестовый. В задании прямо было сказано, что основной сервер недавно обновили и он новее.
Агент не стал сразу строить перенос. Первым шагом он посмотрел версии платформы на обоих серверах. И выяснилось, что всё наоборот. Основной сервер отставал от тестового больше чем на год релизов.
Мало того. На тестовом сервере лежали месяцы ручных доработок, которых на основном не было. Перенос «как написано в задании» затёр бы эту работу более старой версией решения. Да ещё и на версию платформы, с которой эту сборку никто не проверял.
Агент написал отчёт с заголовком «противоречит исходному заданию». Предложил два честных варианта: сначала выровнять версии или развернуть направление переноса. И попросил меня решить, какой сервер считать источником правды. Сам решать не стал.
После этого я добавил ещё одно жёсткое правило про тот сервер. Но главное здесь другое. Задание пишет человек, и человек ошибается. Хороший исполнитель сначала сверяет вводные с реальностью. От агента я теперь жду того же, что от сильного инженера: проверь, на что опираешься, прежде чем что-то двигать.
Как агент докладывает: «Что нужно от вас»
Отчёты агентов поначалу были ужасны. Таблицы, пути к файлам, идентификаторы версий, выдержки из логов. Я читал их подолгу и в конце не понимал главного: от меня что-то нужно или нет?
В начале октября я ввёл формат, который мы оставили навсегда. Отчёт короткий, на простом русском. Первый блок — «Что нужно от вас»: только реальные решения или действия, по строке на каждое. Если ничего не нужно, так и написано. Второй блок — «Что сделано», две-четыре короткие строки. Без таблиц, путей и внутренних названий.
Вместе с форматом пришло правило про распределение работы. Всю техническую работу агент делает сам: коммиты, уборку, повторные выгрузки, проверки, документацию. Он не присылает мне команду «выполните, пожалуйста». Не спрашивает «закоммитить?». Спрашивает только о настоящих решениях: архитектура, бизнес-выбор, всё необратимое и всё, что касается рабочей системы.
Подробности при этом никуда не исчезают. Они уходят в документацию проекта и журнал задачи. В чат идут выводы.
Лучший эффект оказался неожиданным. Когда агенту нельзя спрятать проблему в таблицу, он вынужден её сформулировать. «Это поле должен заполнить человек» — одна строка, и сразу ясно, что делать.
«Доделай, убери за собой, объясни суть»
Это правило появилось одновременно с форматом отчёта. Каждая задача заканчивается тремя вещами, а не одной.
Доделай. Не останавливайся на плане или половине результата. Если оставшиеся шаги можно сделать самому, делай.
Убери за собой. Всё, что задача создала и что не является результатом. Временные файлы, тестовые решения и записи на серверах, сохранённые сессии браузера, выгрузки. Если что-то на сервере меняли только ради теста, верни как было и докажи это повторной выгрузкой, совпадающей с исходной байт в байт. Если удалить что-то невозможно, скажи об этом прямо.
Последнее важнее, чем кажется. Например, в ELMA 365 нельзя удалить бизнес-процесс. Это ограничение платформы, а не лень агента. Брошенный черновик процесса агент переименовал с пометкой «не используется» и записал это в отчёт. Честно оставленный след лучше тихого.
Объясни суть. Человеку нужен смысл. Что теперь можно делать, чего нельзя и почему, что осталось.
Конституция для агентов
Вокруг ELMA 365 у нас уже несколько проектов. Чтобы правила не расползались, общее мы вынесли в отдельный документ, который внутри называем конституцией. Каждый проект ссылается на неё и может добавлять свои правила, только более строгие, не мягче.
Если пересказать её простыми словами, получится примерно так.
Кто владелец и что решает только он. Есть короткий список вещей, которые агент не делает без меня. Запись в общий сервер разработки, который мы делим с партнёром. Любые действия в рабочей системе. Выбор, куда и когда выпускать изменения. Доступы и учётные записи. Распоряжение владельца разрешает ровно то действие, которое в нём названо, и ничего сверх.
Всё остальное агент доводит до конца сам. В октябре я прямо сказал: заканчивайте работу, не дожидаясь меня. На нашем дополнительном сервере для экспериментов агенты могут устанавливать и проверять что угодно в рамках задачи, без отдельного разрешения каждый раз. При этом агент никогда не открывает файл с секретами и не держит в руках значения токенов.
Утверждение без доказательства не считается. Нельзя написать «проверено», если проверка не наблюдалась. Нельзя задним числом нарисовать «прошло» для старой работы, у которой не было исходного состояния. Чего не было, записывается как «не было».
Проверяет не автор. Об этом я уже писал выше.
Остановки разложены по классам. Это моя любимая часть. Без неё агенты останавливаются и спрашивают по любому поводу. Поэтому у каждой типичной остановки есть класс и способ обработки:
-
сбой сети или лимиты сервиса — подожди и повтори, меня не спрашивай;
-
упавшие тесты, конфликт слияния, устаревшая ветка — исправь сам, это не повод для остановки;
-
нет внешнего доказательства — запиши, что пытался сделать, держи этот пункт открытым и продолжай остальную работу;
-
действие требует моего решения — назови, какое именно правило сработало, и работай дальше над тем, что можно;
-
если решение уже понятно и остался только шаг человека — скажи, какой именно шаг;
-
инцидент — эскалация сразу.
Это сильно сократило число вопросов «можно я…?». Агент больше не спрашивает разрешения починить упавший тест. И не стесняется остановиться у кнопки, которая меняет живую систему.
Что из этого можно забрать себе
Не обязательно строить такую же систему целиком. Вот что я бы внедрил в первую очередь, если вы только начинаете работать с агентами в low-code или в обычной разработке.
Отдельная рабочая копия на каждую задачу. Это дёшево и сразу убирает целый класс странных коммитов.
Рабочая система только для чтения. Не договорённостью, а техникой: фильтром запросов или ролью без прав записи.
Различайте «опубликовано» и «работает». Пусть отчёт говорит, какая именно проверка прошла и что она доказывает.
Независимая проверка. Второй агент, который не писал код, ловит удивительно много.
Формат отчёта, который начинается с «Что нужно от вас». Вы удивитесь, сколько времени он экономит.
И правило последнего клика. Решите заранее, какие кнопки нажимает только человек. Запишите это. И радуйтесь, когда агент у такой кнопки останавливается.
Дальше в серии будет конкретика: как мы правим виджеты из файлов, как проверяем процессы согласования, где платформа нас удивила и что из этого вышло.
А у вас есть кнопки, которые вы никогда не отдадите агенту? Какие?
ссылка на оригинал статьи https://habr.com/ru/articles/1099004/