память ai-агента в GitHub

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

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

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

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

в современных инструментах вроде Claude Code, Cursor или веб-интерфейсов спасает механизм prompt caching (кэширование промптов). если предыдущая часть диалога не менялась, провайдер считывает её из быстрого кэша, что стоит в десять раз дешевле обычной передачи входных токенов. но у кэша есть строгое ограничение по времени жизни (TTL).

в официальной документации Claude API указано: время жизни кэша по умолчанию составляет всего 5 минут. существует опциональный расширенный TTL на 1 час, но и он не спасает, если вы отошли пообедать, переключились на другую задачу или вернулись к проекту на следующее утро. как только время жизни кэша истекает, первое же сообщение в старый чат приводит к полной перезаписи кэша. вы платите за чтение всего огромного архива переписки по полной ставке записи в кэш (в 1.25 раза дороже базового входа).

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

деньги — только половина беды. вторая проблема — качество рассуждений, известная как context rot (гниение контекста).

современные модели заявляют огромные контекстные окна: 200 тысяч, 1 миллион или даже 2 миллиона токенов. но способность модели физически вместить текст не означает способность одинаково внимательно его обработать. исследования показывают эффект «потери середины» (lost in the middle): модель отлично видит системный промпт в начале и вашу последнюю реплику в конце, но безнадёжно теряет фокус в середине раздутого контекста.

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

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

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

лучшее внешнее хранилище для кода и задач разработчика — GitHub. там уже живут ваши репозитории, ветки, история коммитов и pull request. превращать GitHub в память для AI-сессий позволяет связка из трёх простых сущностей.

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

вторая сущность: handoff-комментарий в этой же Issue. это компактный срез сессии перед закрытием чата. не протокол переписки, а короткая выжимка: что фактически сделано, какие файлы изменены, на чём именно остановились, что проверено тестами и какой один шаг нужно сделать следующим.

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

агент подтягивает 2–3 тысячи токенов чистого, выверенного контекста вместо 100 тысяч токенов сырого диалога. сессия стоит копейки, модель держит максимальную концентрацию, а прогресс виден всей команде прямо в репозитории.

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

для этого создан открытый скилл github-handoff. он работает на базе обычного markdown-контракта и доступен в публичном репозитории: https://github.com/harnessmachine/github-handoff. как упаковывать регулярные процедуры в подобные инструменты, мы подробно разбирали в статье «скилл как первый шаг к AI-автоматизации».

главная фишка скилла — сведение всей рутины к одной естественной фразе: «зафиксируй прогресс» (или «сохрани сессию», «сделай handoff»).

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

во-первых, определяет текущий репозиторий по открытой папке или git remote.

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

в-третьих, анализирует только что завершённую сессию, выделяет факты и оставляет один структурированный handoff-комментарий.

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

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

в боевом сценарии рабочий процесс состоит из двух коротких действий: сохранения и возобновления.

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

после этого вы спокойно открываете новый чат, где передаёте полученный запрос: продолжить работу по задаче, восстановив контекст из последнего handoff.

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

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

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

железные правила безопасности для handoff:

никаких секретов и ключей. токены API, пароли от тестовых баз данных, приватные URL вебхуков и содержимое файлов .env никогда не должны попадать в handoff-комментарий. если агент работал с переменными окружения, в handoff фиксируется только факт: добавлена переменная в .env.example.

никаких полных дампов переписки. handoff — это выжимка решений, а не стенограмма разговора. если агент пытается скопировать в Issue простыню из логов или весь чат, останавливайте его. handoff должен читаться глазами за полторы минуты.

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

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

попробуйте простой ритуал: подключите скилл из репозитория https://github.com/harnessmachine/github-handoff или просто скопируйте базовый шаблон handoff в свой проект. завершайте каждую рабочую задачу фиксацией одной короткой сводки в GitHub Issue и без сожаления закрывайте окно.

если хотите обсудить свой опыт разделения контекста, шаблоны для агентов или поделиться находками в вайбкодинге, приходите в открытый чат вайбкодим (@vaybcodim).