Разделение контекста агента на три уровня для решения проблемы 700-строчного монолита

При создании постоянных автономных агентов возникает распространённая проблема: контекст агента начинается с одного файла, но разрастается до 700+ строк, смешивая правила идентичности, текущую стратегию, ссылки на инструменты, обновления цен и процедуры публикации. Этот монолит становится неуправляемым — редактирование того, на чём нужно сосредоточиться на этой неделе, находится в том же файле, что и правила «никогда не делай этого», что вызывает сомнения и ошибки. Команда, создающая 6-агентную систему, которая запускается с нуля, столкнулась именно с этой проблемой: к второй неделе запускающий механизм достигал ограничений по аргументам, а сессии завершались без явных ошибок.

Разделение на три слоя

Решение заключалось в разделении контекста агента по типу задачи и частоте изменений на три отдельных файла:

• CLAUDE.md — Идентичность: кто такой агент, жёсткие правила, личность. Почти никогда не меняется. Можно кэшировать.
• BRIEFING.md — Миссия: на чём сосредоточиться прямо сейчас, текущая стратегия, цены, цели. Меняется еженедельно.
• PLAYBOOK.md — Операции: как механически выполнять задачи: процедуры, CLI-команды, ссылки на инструменты. Меняется при изменении инструментов.

Каждый фрагмент информации находится строго в одном слое. Если ссылка на инструмент есть в PLAYBOOK, её нет в BRIEFING. Дублирование приводит к скрытым противоречиям.

Почему эта архитектура работает

Практичное редактирование: Все знают, какой файл редактировать. На чём сосредоточиться? BRIEFING. Как публиковать? PLAYBOOK. Никогда не делать этого? CLAUDE.md. Никаких догадок и поиска по 700 строкам.

Техническая эффективность: Когда агент перезапускается (что происходит часто), идентичность остаётся стабильной. Один и тот же CLAUDE.md используется в каждой сессии, что позволяет слоям кэширования видеть идентичный префикс промпта для почти бесплатных попаданий в кэш. BRIEFING и PLAYBOOK поступают через вызовы инструментов при первом запуске — агент читает их перед началом основной работы, поэтому они не являются избыточными. Аргумент запуска остаётся небольшим навсегда, даже если PLAYBOOK разрастается до 2000+ строк.

Дисциплина: Монолит принимает любой контент где угодно. Эта спецификация заставляет задаться вопросом: это касается характера, миссии или механики? Ответ на этот вопрос меняет то, как вы думаете о системе.

Шаблоны внедрения

Шаблон A (Простой): Прочитать все три файла при запуске, объединить и внедрить. Работает, если общий размер укладывается в ограничение аргументов вашего запускающего механизма.

Шаблон B (Постоянные агенты): Внедрить только CLAUDE.md при запуске. CLAUDE.md содержит указание: первым действием прочитать BRIEFING.md и PLAYBOOK.md. Агент сначала вызывает инструменты для загрузки документов миссии и операций, прежде чем начать какую-либо работу. Промпт запуска остаётся небольшим, даже если плейбуки растут. Это вариант по умолчанию для агентов, которые перезапускаются.

Команда использует Шаблон B. В каждой сессии агент просыпается, читает BRIEFING, читает PLAYBOOK, затем выполняет задачи. Свежий контекст каждый раз, кэшированная идентичность, никакого беспокойства об ограничениях аргументов.

Результаты после внедрения

• Редактирование занимало секунды вместо минут — не было страха сломать несвязанные элементы.
• Правки BRIEFING между сессиями просто работали — агент читал свежий BRIEFING при следующем перезапуске.
• PLAYBOOK вырос до 2000+ строк без какого-либо беспокойства о запуске.
• Внедрение новых агентов стало быстрее — есть чёткая структура для заполнения.

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