Memory Bank для 1С-проекта: как дать ИИ-агенту внешнюю память и не потерять контроль

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

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

От повторного объяснения — к управляемому контексту

Для 1С-проектов потеря контекста особенно заметна. Один и тот же бизнес-термин может обозначать разные объекты в УНФ, ERP, ЗУП или доработанной конфигурации. Правдоподобный ответ про регистр, документ или реквизит легко окажется неприменимым именно в этой базе. Еще сложнее с неявными правилами: дорабатывать только расширением, не запускать обработку в рабочее время, не менять схему обмена без владельца интеграции.

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

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

Не смешивать память, поиск и MCP

Вокруг ИИ часто используют несколько похожих слов, хотя они отвечают на разные вопросы.

• Длинный промпт отвечает на вопрос «что вложили в контекст сейчас?». Это ручной снимок, который быстро устаревает.
• RAG отвечает на вопрос «где найти подтвержденный факт?». Он ищет фрагменты документации, кода, задач или описания метаданных.
• Memory Bank отвечает на вопрос «что уже решили и что нельзя забыть?». В нем лежат короткие записи о проекте и текущей работе.
• Инструменты и MCP отвечают на вопрос «как проверить факт или выполнить разрешенное действие?». Доступ к данным сам по себе не становится памятью и не подтверждает правильность вывода. 

Рабочая последовательность выглядит так: сначала агент читает Memory Bank и понимает границы задачи; затем через поиск или разрешенный инструмент проверяет нужные факты; после этого готовит результат. Значимые изменения — например, новое архитектурное правило или действие с данными — утверждает человек.

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

Что действительно стоит сохранять

Полезна только та запись, которая предотвращает неверный следующий шаг. Обычно в Memory Bank попадают:

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

Не стоит превращать память в архив всего, что видел агент. Секреты, персональные данные, полные логи, дубли документов и непроверенные гипотезы повышают риск и ухудшают поиск. Формулировка «агент считает, что регистр называется так» — это не факт. До проверки ее нужно хранить как вопрос или черновик, а не как активное правило.

Как собрать Memory Bank: инструкция для первого учебного проекта

Ниже — минимальная структура из практики вебинара. Ее можно создать в отдельной папке репозитория, например practice_memory_bank/. Не подключайте к ней боевую 1С-базу и не копируйте реальные выгрузки: для первого упражнения достаточно синтетического проекта и одной учебной задачи.

practice_memory_bank/
_00;^72;^72; README.md
_00;^72;^72; project.md
_00;^72;^72; glossary.md
_00;^72;^72; maintenance.md
_00;^72;^72; decisions/
^74;   ^92;^72;^72; ADR-001.md
_00;^72;^72; tasks/
^74;   ^92;^72;^72; TASK-042/
^74;       _00;^72;^72; TASK-042.md
^74;       _00;^72;^72; SUMMARY.md
^74;       ^92;^72;^72; HISTORY.md
^92;^72;^72; review/
    ^92;^72;^72; review-checklist.md

Шаг 1. Опишите правила в README.md

Это первый файл, который читает агент. Укажите, что папка является памятью проекта; какие данные в нее запрещено добавлять; кто утверждает значимые записи; какие файлы читать перед началом задачи; как предложить изменение. Для учебного контура достаточно правила: агент читает project.md, глоссарий, актуальные ADR (карточки архитектурных решений) и папку задачи, а изменения важных записей передает на ревью как решение.

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

Шаг 2. Зафиксируйте границы в project.md

Напишите простое описание проекта: его назначение, среду, владельца и ограничения. В учебном примере это «Проект Альфа» с синтетическими данными; у агента нет доступа к 1С, Git, трекеру или внешней документации, пока его явно не выдали.

Если позже появится интеграция, добавьте для нее таблицу: название, назначение, разрешенные и запрещенные действия, владельца, способ проверки результата и уровень доступа. Например, MCP метаданных может только читать сведения об объекте; он не должен менять базу или выгружать чувствительные данные.

Шаг 3. Создайте glossary.md

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

Главное правило для 1С: бизнесовое название не доказывает техническое имя объекта. В учебном примере «заказ клиента» — это термин задачи, но не имя документа в конкретной конфигурации. Пока имя не подтверждено разрешенным первичным источником, его нельзя записывать как факт.

Шаг 4. Оформите устойчивое правило в ADR

ADR — это Architecture Decision Record, то есть карточка архитектурного решения. Она нужна не для описания каждого действия, а чтобы через месяц не спорить заново, какое правило выбрали, почему и где оно действует. Для такого решения создайте файл вроде decisions/ADR-001.md. В начале укажите YAML-поля: id, title, status, decision, rationale, scope, evidence, owner, updated, review_by, access. Затем коротко опишите контекст и последствия.

Пример учебного решения: «доработки выполняются только расширением». Пока оно основано лишь на учебном кейсе, его статус — draft; оно не становится производственным правилом. После подтверждения владельцем и ссылкой на первичный источник статус можно изменить на active. Замененное ADR не удаляют, а помечают superseded и связывают с новым решением.

Шаг 5. Заведите папку одной задачи

Для каждой длительной задачи создайте tasks/TASK-XXX/ и три файла.

• В TASK-XXX.md пишите цель, связанные ADR, проверенные факты со ссылками на источники, предположения, открытые вопросы, текущий результат, следующий безопасный шаг и состояние задачи.
• В SUMMARY.md оставляйте только одну актуальную выжимку: цель, ключевые ограничения, сделанное, точку остановки и следующий шаг. Этот файл нужен, чтобы продолжить работу в новой сессии, не перечитывая весь журнал.
• В HISTORY.md фиксируйте каждый значимый шаг: запрос, выполненное действие, затронутые файлы или системы, проверяемый результат и то, что делать дальше. Одной краткой записи на шаг достаточно.

Для учебной TASK-042 корректный следующий шаг звучит так: запросить у ревьюера разрешенный первичный источник для проверки метаданных. Нельзя писать код, называть технический объект фактом или менять базу до такой проверки.

Почему это не противоречит правилу «не хранить каждый шаг»

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

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

• ADR-001.md хранит устойчивое правило проекта: например, «доработки выполняются через расширение». Его меняют редко и только после ревью.
• TASK-042.md хранит текущее состояние одной задачи: подтвержденные факты, предположения, вопросы и следующий безопасный шаг.
• SUMMARY.md — это не журнал, а одна короткая актуальная выжимка. При передаче задачи в новую сессию агент читает ее первой, чтобы понять контекст без полного лога.
• HISTORY.md — краткий аудит значимых действий: что запросили, что сделали, какой получился результат и где остановились. В него не записывают внутренние рассуждения модели, полные логи или каждый промежуточный поиск.

Например, запись «запрошен у архитектора источник для проверки метаданных; доступа пока нет» полезна для HISTORY.md. Но несколько страниц о том, какие варианты имени регистра предлагала модель, не нужны ни в истории, ни в SUMMARY.md. Когда источник появится, подтвержденный факт попадет в TASK-042.md; если он изменит постоянное правило проекта, ревьюер подготовит отдельный ADR.

Шаг 6. Проверяйте и принимайте изменения

Агент не переписывает правила проекта молча: он предлагает решение— новую запись, изменение статуса или открытый вопрос. Владелец либо ревьюер проверяет источник, доступ, отсутствие чувствительных данных, владельца и срок следующего пересмотра. Только после этого изменение принимают в Memory Bank.

Раз в неделю или после важной вехи обновляйте активные задачи, пересматривайте ADR с наступившей датой review_by, удаляйте из SUMMARY.md дубли и устаревшие детали, но сохраняйте историю. Для этого в maintenance.md удобно вести короткий список проверок и дату следующего ревью.

Память не дает полномочий

Memory Bank сообщает контекст, но не дает право проводить документы, менять права, запускать регламентные задания или обращаться к боевой базе. Контекст, инструменты и доступы должны оставаться раздельными.

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

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

Выводы

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

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