Внешняя память агента: почему без неё ИИ в 1С бесполезен на длинной дистанции

Проблема, которую замечают не сразу

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

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

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

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

У меня эта система живёт около года, журнал по 1С разросся до восьмисот с лишним строк, и она окупилась многократно. Ниже — как она устроена, что в неё писать, а главное — что писать бесполезно.

Два вида памяти

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

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

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

Смешивать их в одном файле — верный способ получить документ, который никто не читает. Инструкция должна быть короткой и исполняемой, справочник — полным и структурированным.

Ядро системы: журнал

Главный файл — журнал по теме. У меня отдельный по 1С, отдельный по мобильному приложению, отдельный по сайту.

Структура жёсткая и состоит из двух частей.

Часть первая: «что мы умеем»

Наверху — накопленное знание, отжатое от хронологии. Проверенные приёмы, таблицы команд, грабли платформы, места, где лежат учётные данные.

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

Пример записи оттуда, которая экономит больше всего времени:

/LoadConfigFromFiles не компилирует, exit 0 на битом коде. Единственная настоящая проверка — /CheckModules -Extension <имя> -Server.

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

Часть вторая: журнал сессий

Ниже — хронология, новые записи сверху. Порядок важен: агент читает файл сверху вниз и должен сначала увидеть свежее.

Структура записи одинаковая:

• Дата и одна строка сути — «персональная скидка складывалась со статусной»;
• Симптом — что увидел пользователь. Не «баг в расчёте», а «клиент со статусом 15% и кампанией 30% получил на кассе 45%»;
• Что оказалось — реальная причина, с именами модулей и процедур;
• Починка — что именно изменили, где, с какими последствиями;
• Грабли этой сессии — отдельный подраздел, самый ценный во всей записи;
• Открытые хвосты — что не доделано и однажды выстрелит.

Симптом обязателен в формулировке пользователя. Через три месяца вы будете искать по журналу именно так — по тому, как проблема выглядела снаружи, а не по тому, как называлась в коде.

Самое ценное — отрицательные результаты

Вот главная мысль статьи, и она контринтуитивна.

Обычная документация описывает, как надо. Память агента должна в первую очередь описывать, как не работает — потому что агент будет предлагать эти способы снова. Каждую сессию. Уверенно.

У меня есть запись из одного вечера, потраченного впустую:

Внешняя обработка через /Execute — НЕ работает. 1cv8 ENTERPRISE /Execute file.epf просто открывает обработку: тело модуля объекта не исполняется, ПриОткрытии — метод формы, которой у обработки без формы нет. Собрать .epf с формой не удалось: /LoadExternalDataProcessorOrReportFromFiles падает «Исключение XDTO при чтении Form.xml» даже на нетронутом дампе, сделанном той же платформой.

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

Формулируйте отрицательный результат так, чтобы он закрывал не только конкретную команду, но и очевидный обходной путь. «/Execute не работает» — недостаточно, агент тут же предложит собрать обработку с формой. Нужно сразу: и это не работает, и вот почему, и вот что работает вместо.

Правила ведения, без которых система умирает

Система документов деградирует по предсказуемым сценариям. Правила ниже написаны против каждого из них.

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

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

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

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

Не удалять устаревшие решения — менять им статус. Архитектурное решение, которое отменили, остаётся в файле с пометкой «заменено таким-то». Иначе через полгода кто-нибудь предложит ровно то, от чего вы уже отказались, и никто не вспомнит почему.

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

Критерий, по которому я оцениваю, хорошо ли отработала сессия, звучит так:

Если в следующем разговоре спросят «а как мы решили вопрос X?» и ответа нет в документах — работа предыдущей сессии сделана плохо.

Обвязка вокруг журнала

Журнал — ядро, но одного его мало. Что ещё оказалось нужным:

Обзор проекта. Бизнес-контекст, который не выводится из кода: чем занимается компания, как устроены процессы, какие константы откуда взялись, где подводные камни. Агент, не понимающий бизнес, пишет технически корректный и бесполезный код.

План работ. Что делается сейчас, что сделано, что дальше. Отвечает на первый вопрос каждой сессии — «на чём мы остановились».

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

Архитектурные решения. Каждое нетривиальное решение — отдельная запись с датой и обоснованием. Не «используем X», а «используем X, потому что Y, альтернатива Z отклонена из-за W».

Глоссарий. Внутренние термины: типы карт, статусы, названия воркеров. Без него агент выдумывает синонимы, и вы получаете три названия для одной сущности.

Runbook. Операционные процедуры и разбор инцидентов. Сюда попадает всё, что начинается с «а что делать, если».

Шаблоны запросов. Удачные формулировки задач, которые сработали. Отдельная тема, о ней ниже.

Процедурная память: инструкции вместо объяснений

Декларативная часть отвечает на «что». Процедурная — на «что делать, когда».

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

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

Требования к таким инструкциям:

• короткие, страница максимум;
• исполняемые — команды, а не рассуждения;
• с явными запретами, а не только с рекомендациями;
• со списком «можно без спроса» — иначе агент начнёт спрашивать разрешения на чтение логов.

Последний пункт неочевиден, но важен. Если написать только запреты, агент станет параноидальным и будет согласовывать каждый SELECT. Явно разрешённая зона нужна не меньше запрещённой.

Что писать бесполезно

Раздел, сэкономивший бы мне несколько месяцев, если бы кто-то написал его раньше.

Не пишите то, что агент прочитает в коде. Структура каталогов, список функций, сигнатуры — всё это он посмотрит быстрее, чем вы напишете, и его версия не устареет.

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

Не пишите разбор конкретного бага, который закрыт навсегда. Ценна не история починки, а грабля, которая из неё вытекает. Не «в модуле X была опечатка», а «поле Код у этого справочника не существует физически, в объектной модели молча возвращает пустую строку».

Не пишите общеизвестное. «1С — учётная система» в журнале не нужно.

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

Что это даёт

Несколько эффектов, которые проявились не сразу.

Новая сессия стартует за минуту. Агент читает план и последние записи журнала и сразу понимает, где мы. Никакого «расскажи мне про проект».

Ошибки не повторяются. Записанная грабля — это грабля, на которую больше не наступят. Мой список из одиннадцати граблей платформы работает именно так.

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

Знание переживает смену инструмента. Модели меняются, интерфейсы меняются, а журнал в текстовых файлах лежит и работает с любым следующим агентом.

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

Выводы

1. Память — часть проекта, а не часть модели. Ждать, что агент запомнит, бессмысленно. Стройте внешнее хранилище.

2. Вести его должен агент. Обязанность обновлять документы фиксируется в правилах проекта. Ручное ведение не выживает.

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

4. Разделяйте «что мы знаем» и «что делать». Справочник и инструкция устроены по-разному и деградируют по-разному.

5. Критерий качества один. Если ответ на вопрос «как мы решили X» отсутствует в документах — сессия отработала плохо, каким бы хорошим ни был написанный код.

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

Опыт годовой работы с ИИ-агентом над боевыми базами УТ 11.5, мобильным приложением и Rust-бэкендом розничной сети.