Как разделить данные и настройки AI-агентов

Почему память, правила и project memory должны жить отдельно от AI-инструмента.

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

Введение

Открываю утром Claude Code. Вижу: аккаунт отключён.1 2

Вместе с доступом к модели отваливается весь привычный способ работы: память, скиллы, инструкции, локальные настройки, MCP-серверы, часть проектного контекста.

Видно сразу: система жила внутри инструмента.

В прошлой статье я показывал, зачем выносить настройки AI-агентов в репозиторий. Это только первый этаж. Второй — разделить данные и обработчиков.

Claude, Codex, Cursor, Gemini, любой другой агент — не место, где живёт твоя система. Это исполнитель.

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

Короче, это и отделяет рабочую систему от той, что держится на честном слове и одном живом аккаунте.

Главная ошибка: делать из агента хранилище

Ошибка выглядит безобидно.

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

А это одна точка входа.

Правила живут в ~/.claude/CLAUDE.md, проектные настройки — в .claude/settings.json, часть памяти осталась только в истории конкретного тулла.3 4 Несколько слоёв смешаны в один.

Внутри одной сущности у тебя сразу всё: знания, способы их применения, временное состояние, интерфейс, привязка к аккаунту и вендору.

Удобно, пока работает. Схема хрупкая.

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

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

Где это ломается на практике

Это не редкий аварийный режим. Выскакивает на ровном месте, и хватает трёх обычных сценариев.

1. Аккаунт заблокировали

Приходит без подготовки.

Я не планировал миграцию и не собирался менять воркфлоу. Просто хотел продолжить работу — а вместо этого выясняю, почему инструмент меня больше не пускает.1 2

Если вся система жила внутри одного аккаунта — собираешь рабочую среду заново.

Если данные лежат в git-репозиториях — регистрируешь новый аккаунт, ставишь инструмент, подтягиваешь настройки, продолжаешь. Текущий чат-контекст всё равно потеряешь. Но это один сеанс, а не вся среда.

2. Поменял компьютер или переустановил систему

Драмы меньше, случается чаще.

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

Anthropic пишет прямо: при сбросе конфигурации Claude Code удаляются settings, MCP server configurations и session history.5 То, что лежит только в локальном состоянии тулла, — не источник правды.

3. Работаешь не с одной моделью

Ежедневная история.

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

Если настройки, persona, skills и project memory прибиты к одному туллу — начинается ручная синхронизация: перенеси файл, обнови правило, поправь вторую копию, потом третью.

Конфигурация расползается. Claude отвечает так, Codex иначе, Cursor вообще живёт по старым правилам.

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

Какие слои реально надо разделить

Я не предлагаю тащить в git вообще всё. Временное состояние может жить внутри агента, это нормально. Ненормально, когда внутри агента лежит единственная копия правил, памяти и проектной структуры.

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

Как это выглядит на уровне файлов

У меня разложено так:

~/ai-settings/AGENTS.md, skills/, agents/, docs/ai/ — глобальный слой. Всё, что должно быть одинаковым между инструментами и проектами.
project/AGENTS.md — проектный слой инструкций, договорённости именно про этот репозиторий.
project/.claude/settings.json, project/.mcp.json — проектные настройки инструмента и подключений, которые едут вместе с проектом.
project/docs/adr/, project/memory.md, project/README.md — память проекта: решения, раннбуки, особые команды, принятые компромиссы.
~/boilerplate/ или отдельный шаблонный репо — стартовые структуры новых проектов.
~/.claude/settings.local.json, .env, локальные абсолютные пути, временные override — локальный слой, без коммита.
История чатов, кэш, временные разрешения, краткоживущая память сессии — внутреннее состояние инструмента.

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

Что не хранить в git

Разделять слои — не значит валить в репозиторий всё подряд.

Не коммить:

API-ключи, токены, .env, credentials.json, *.pem, *.key;
machine-specific пути и локальные override, которые работают только на одной машине;
временные разрешения, локальные кэши, экспорт чатов и промежуточные артефакты;
всё, что относится только к текущему сеансу и не нужно команде или будущему тебе.

Нужен файл только на этом ноутбуке или только в этой сессии — он не часть общего слоя. Для этого и есть .gitignore, локальные settings-файлы и разделение project/global/local scope.

Почему Git и GitHub здесь не просто «потому что все так делают»

Git тут не из-за романтики терминала. Он нормальный механизм для хранения версии данных: в распределённой системе контроля версий каждый clone содержит полную историю репозитория, то есть твои настройки и документы реально существуют как восстановимая копия.6

GitHub поверх этого снижает трение. Держишь публичные и приватные репозитории, клонируешь на новую машину, публикуешь изменения, а не хочешь жить в терминале — берёшь GitHub Desktop, который закрывает базовый воркфлоу: clone, commit, push, sync между компьютерами.7

Git отвечает за версионность и восстановление, GitHub — за доступность и синхронизацию, GitHub Desktop — за то, чтобы это не требовало любви к командной строке.

Ближе GitLab или self-hosted Gitea — пожалуйста. Единый источник правды всё равно живёт в системе контроля версий, а не внутри настроек одного AI-клиента.

Что это даёт с точки зрения самих инструментов

Схема не спорит с инструментами — повторяет их же логику.

Anthropic сам разделяет instructions и settings по уровням: user, project и local. Причём project instructions и project settings рассчитаны на общий воркфлоу через source control.3 4 Ровно тот сценарий, под который это и сделано.

AGENTS.md тоже живёт как переносимый слой: стандарт описывает один markdown-файл как общее место для инструкций агенту и отдельно оговаривает приоритет — ближайший к файлу AGENTS.md важнее.8 Cursor умеет использовать AGENTS.md как простую альтернативу .cursor/rules.9 Gemini CLI позволяет объявить AGENTS.md в context.fileName, а не держаться только за GEMINI.md.10

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

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

Это уже архитектура.

Как выглядит восстановление на практике

Пропал доступ или переехал на новую машину — восстановление короткое.

Ставишь новый инструмент или заходишь в новый аккаунт.
Клонируешь репозиторий с глобальными настройками и раскатываешь его через установочный скрипт или ручную синхронизацию.
Клонируешь нужный проект.
Поднимаешь project layer: AGENTS.md, .claude/settings.json, .mcp.json, memory.md, docs/adr/ и другие файлы рядом с кодом.
Открываешь проект в любом доступном агенте и продолжаешь.

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

Как это раскладываю у себя

Покажу свою раскладку. Не образец, у меня просто так сложилось.

Три основных репозитория.

1. `ai-settings`

Открытый репозиторий с глобальным слоем: persona, стиль общения, coding standards, writing voice, глобальные скиллы, субагенты и установочные скрипты.11

Один источник правды для того, как агент должен работать. Не в каком приложении, а именно как: как спорить, как не галлюцинировать, как писать код, как оформлять коммиты, как вести себя в ревью, как сокращать ответы, как экономить контекст.

Главное — слой не привязан к модели. Сегодня сверху Claude, завтра Codex, послезавтра ещё кто-то. Библиотека правил та же.

2. `popovs-boilerplate`

Второй открытый репозиторий. Тут шаблоны проектов.12

Это другой тип данных — стартовая форма будущего проекта, а не правила поведения агента. У меня вынесены несколько типовых заготовок: полноценный fullstack, API-only, статический сайт и docs-репозиторий.

Смешать это с ai-settings — получится каша. Persona агента и структура нового FastAPI-проекта — разные вещи, даже если ходят в паре.

3. Приватный инфраструктурный репозиторий

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

Третий тип данных. Не про стиль и не про код проекта — про среду, куда всё это поедет жить. Поэтому он тоже лежит отдельным слоем.

Минимальная версия этой схемы

Своей инфраструктуры пока нет и несколько типов проектов не держишь — не начинай с трёх репозиториев.

Минимум:

один репо под глобальные настройки;
один репо под сам проект вместе с его памятью и локальными правилами.

Для старта большинству этого хватает. Boilerplate можно сначала держать шаблонной папкой или одним стартовым репо. Отдельный шаблонный слой имеет смысл выносить, когда действительно появилось несколько повторяющихся типов проектов. Приватный infra-репо нужен ещё позже — когда появилась инфраструктура, которую надо описывать и переиспользовать.

Что делает агент в такой схеме

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

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

Сценарий:

Я создаю папку проекта.
Открываю её в Claude Code или Codex.
Вызываю skill.
Skill спрашивает тип проекта, публичность репозитория и базовые параметры.
Подтягивает нужный boilerplate, накладывает сверху актуальный слой ai-settings, а если надо — добавляет инфраструктурный контекст.

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

Отдельно про память проекта

Чаще всего недооценивают проектную память.

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

Проектная память должна жить внутри проекта. AGENTS.md, memory.md, decision log, docs/adr/, changelog по архитектурным решениям — неважно что. Важно, что данные лежат рядом с кодом и едут вместе с проектом. Открыл репозиторий в другом агенте — поднимаешь не пустую папку, а рабочую среду с историей решений.

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

С чего начать, если всё сейчас смешано

Всё смешано — не устраивай архитектурную реформу за один вечер. Так проще переусложнить себе задачу и бросить на полпути.

Четыре шага.

Шаг 1. Вынеси глобальные настройки в отдельный репозиторий

Persona, общие правила, свои любимые скиллы, шаблоны команд — всё, что должно быть одинаковым между проектами.

Шаг 2. Вынеси boilerplate отдельно

Не смешивай стартовые шаблоны проектов с personality-файлами агента. Другой класс данных.

Шаг 3. Храни память внутри каждого проекта

Архитектурные решения, проектные соглашения, локальные раннбуки, особые команды, принятые компромиссы — рядом с кодом.

Шаг 4. Коммить и пушь изменения по ходу работы

Именно на этом всё и ломается. День настраивал, не закоммитил — бэкапа нет. Есть локальная версия без защиты от потери.

Как итог

Агент — исполнитель. Хранилище правил, памяти и шаблонов держи отдельно.

Данные внутри одного инструмента или аккаунта — это vendor lock-in там, где его могло не быть. Разложил по слоям — новый аккаунт, новый компьютер и новый агент перестают быть катастрофой.

Отдельный репозиторий под настройки, отдельный под boilerplate, память внутри проекта, приватный слой под инфраструктуру — уже взрослая схема.

Временный чат-контекст переживёшь. Единственную копию рабочей системы — нет.

А я пойду коммитить настройки — на всякий.

Источники

Claude Account Disabled After Payment for Claude Code Max 5x Plan — публичный кейс с отключением аккаунта после оплаты.
Claude Pro account disabled without warning — ещё один публичный репорт про внезапную деактивацию аккаунта.
How Claude remembers your project — уровни project/user instructions и работа через source control.
Claude Code settings — раздельные settings, subagents, MCP и project-local файлы.
Claude Code troubleshooting — сброс удаляет settings, MCP-конфигурации и session history.
Git Book: About Version Control — почему каждый clone в distributed VCS является полным бэкапом.
Creating your first repository using GitHub Desktop — publish, private repo и sync между компьютерами через GUI.
AGENTS.md — открытый стандарт общего слоя инструкций для coding-агентов.
Cursor Rules — AGENTS.md как простой project-level слой в Cursor.
Gemini CLI: Provide context with GEMINI.md files — возможность указать AGENTS.md через context.fileName.
tsergeytovarov/ai-settings — пример репозитория, где глобальные настройки вынесены в отдельный слой.
tsergeytovarov/popovs-boilerplate — пример отдельного слоя для шаблонов и стартовых структур проектов.