Где хранить контекст ИИ-агента: пять слоёв вместо огромного промпта

У меня правила проекта лежали в Markdown, текущая задача в чате, часть решений в Obsidian, пара полезных деталей в Telegram. Самая нужная информация, конечно, была в голове.

Потом я подключал нового агента и удивлялся, почему он ничего не знает.

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

Я разделил контекст на пять слоёв. Красивая архитектура тут ни при чём: так проще обновлять одну вещь и не тащить весь архив в каждую задачу.

Слой 1. Команда на сейчас

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

Подготовь план изменения формы заявки. Код пока не меняй.

Команда не обязана повторять устройство проекта. Она ссылается на остальные слои и уточняет текущий шаг.

Хорошая команда ещё и ставит точку остановки. В примере выше агент должен вернуть план и не переписывать сразу половину лендинга.

Слой 2. Текущая задача

Здесь живёт то, что меняется чаще всего: цель, границы, ограничения, проверки и критерий готовности.

Минимальный вариант:

# Текущая задача

## Цель
Добавить форму заявки в правую боковую панель.

## Scope
- components/LeadForm.tsx
- components/SidePanel.tsx
- tests/lead-form.spec.ts

## Ограничения
- существующую палитру не менять;
- новые backend-сервисы не добавлять;
- удаление и миграции не выполнять.

## Проверки
- lint;
- unit-тест формы;
- smoke отправки с тестовыми данными.

## Definition of Done
Форма открывается из текущей CTA-кнопки, валидирует поля и не ломает мобильную версию.

У меня такой файл называется current-task.md. В другом проекте это может быть задача в трекере. Главное, чтобы существовала одна актуальная версия задачи.

Слой 3. Правила проекта

Это договорённости, которые редко меняются от одной задачи к другой:

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

Для Codex таким входом часто служит AGENTS.md, для Claude Code CLAUDE.md. Ещё правила могут жить в README, документации или настройках конкретного инструмента.

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

Слой 4. Долгая память

В долгой памяти полезны устойчивые факты:

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

Текущий статус задачи туда класть не стоит. Через пару дней он устареет и начнёт мешать.

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

Иначе память превращается в склад, где всё сохранено, но нужную коробку никто не найдёт.

Слой 5. Красная граница

Есть данные, которые не становятся контекстом вообще:

API keys
access tokens
пароли
seed-фразы
платёжные данные
приватные ключи

Агенту можно сообщить, где взять значение во время выполнения, не показывая само значение:

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

Доступы лучше выдавать минимальные и временные. Если агенту достаточно читать репозиторий, ему не нужен deploy key. Если задача не касается production, production вообще не должен появляться в доступном окружении.

Минимальная структура файлов

Для небольшого проекта я бы начал так:

project/
├── AGENTS.md          # вход и правила для агента
├── README.md          # запуск и назначение проекта
├── .ai/
│   ├── current-task.md
│   ├── decisions.md
│   └── handoff.md
└── docs/
    └── architecture.md

current-task.md отвечает за работу сейчас. decisions.md хранит принятые решения и причины. handoff.md помогает другому агенту или человеку продолжить с текущей точки. Архитектура остаётся в документации и не копируется в каждую задачу.

Это пример, стандартом его считать не надо. Если команда уже работает в Jira, Linear или YouTrack, текущая задача может жить там. Если проект маленький, достаточно AGENTS.md и одного файла задачи.

Как агент получает нужный набор

Перед задачей я не отправляю ему весь Obsidian. Порядок примерно такой:

1. Прочитать правила проекта.
2. Прочитать текущую задачу.
3. Подтянуть только связанные решения и документацию.
4. Составить план и назвать неизвестные.
5. После подтверждённого изменения выполнить проверки.
6. Обновить текущий статус и короткий handoff.

Если контекст противоречит сам себе, агент должен остановиться и спросить, а не выбирать самый удобный вариант. Это правило стоит записать прямо в AGENTS.md или его аналог.

Что получается на практике

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

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

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