Запоминание стенограмм сессий бесполезно

theahura в публикации на 12gramsofcarbon от 2 июля 2026 года делится отрицательным результатом из опыта собственной компании: за многие месяцы тестирования с этой функцией и без неё агенты, имевшие возможность искать по стенограммам своих прошлых сессий, справлялись с задачами программной инженерии ничуть не лучше тех, у кого её не было, при условии доступности других форм контекста. Если уж на то пошло, доступ к поиску даже слегка ухудшал результаты моделей. Он лицо заинтересованное: его компания построила продукт на предпосылке, что стенограммы сессий - это "новая нефть", более ценная, чем сам код, и в этой публикации он от этой идеи отказывается.

Архитектура, против которой он выступает, вполне стандартна. Все стенограммы внутри организации сохраняются в базу данных, поверх ставится векторный поиск, Elasticsearch или SQL (амбициозные команды берут все три, иногда вместе с графом), после чего доступ отдаётся агенту через MCP или CLI, обёрнутый в навык. Собственная память сессий Claude Code относится к этому же семейству.

Почему пользы нет

Объяснение упирается в то, куда полезная информация уже попала. Его команда почти не пишет код руками, поэтому вкладывается в сообщения коммитов, описания PR и документацию, а каждое изменение поставляется вместе с этими зафиксированными метаданными. Агенты получают инструкцию изучить документацию и прошлые PR перед началом работы над участком кода. Иными словами, агент уже дистиллировал долговременную часть каждой стенограммы и записал её туда, где её обязательно найдут.

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

Дрейф намерений (intent drift)

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

По его мнению, дело здесь не в составлении промптов. У агентов нет состояния, поэтому всё содержимое входного контекстного окна воспринимается как абсолютная истина, а каждый токен в нём читается как выражение намерения - включая код или память, возникшие из случайного решения в одной из прошлых сессий, которое ни один человек не проверял. Накапливающийся вариант этой проблемы он называет дрейфом намерений (intent drift): чем больше агент автономно наращивает собственную базу памяти, тем большая часть его контекста состоит из непроверенного машинного вывода, который следующий агент сочтёт намеренным решением.

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

Что он по-прежнему делает

Вывод не в том, что агенты не способны накапливать контекст со временем, а в том, что они не могут делать это без присмотра. В его команде работают внутренние боты: они анализируют PR за неделю, Slack и Drive, после чего предлагают правки в файлы навыков команды и тегают людей в Slack. Каждое предложение по умолчанию отклоняется. Чтобы принять его, нужно прочитать diff и убедиться, что он соответствует намерению. Принимается менее 20%, а значит, 80% этих изменений ухудшили бы систему, применись они автоматически. Для организации в несколько сотен человек, непрерывно сохраняющей обновления, это соотношение - исчерпывающий аргумент.

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

В чём это противоречит базе знаний

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

В базе описано несколько продуктов для памяти агентов, построенных ровно на том конвейере, который, по его словам, не окупается: agentmemory, hippo-memory, mempalace (сохраняющий диалоги дословно в векторном хранилище), stash и ctx. engrim хранит отобранные типизированные записи вместо стенограмм, что ближе к идее дистилляции при записи, но позволяет агентам писать их без этапа проверки человеком. agent-memory-components рассматривает связку "извлечение - хранение - поиск" как пространство проектирования с реальными компромиссами на каждом слое; тезис theahura заключается в том, что для кодирующих агентов с хорошей гигиеной артефактов весь этот конвейер даёт нулевой или отрицательный итог вне зависимости от выбранных компромиссов. Ни за одной из позиций нет достаточного объёма публичных измерений, чтобы поставить точку, а measuring-ai-coding-productivity напоминает, почему стоит скептически относиться к обеим: его результат - это внутренний A/B-тест одной команды на одном типе нагрузки, описанный без конкретных цифр.

Две существующие страницы скорее согласуются с ним, чем спорят. agent-memory-decay существует ровно потому, что неочищенная память превращается в шум, а это механический ответ на проблему "агенты никогда не удаляют контекст": затухание убирает то, от чего модель сама не откажется. А претензия со страницы agent-memory-anatomy о том, что подобные системы предлагают лишь автобиографическую семантическую память, заявляя при этом большее, - это то же самое наблюдение о том же объекте, просто под другим углом.

Паттерн, который он поддерживает, совпадает с принципом работы этой базы знаний. Дистиллировать устойчивые утверждения в понятный, удобный для поиска через grep артефакт в момент записи, держать его там, где читатель будет его искать, и ставить человека на этап подтверждения - это суть llm-wiki-as-agent-memory и human-in-the-loop, а не поиск по стенограммам. Связанный аргумент о рабочих процессах - понимание рождается из чтения diff'а - раскрывается в short-leash-ai-method. a-voice-from-nowhere объясняет, зачем вообще кому-то могли понадобиться стенограммы: промпт выступает артефактом, фиксирующим пройденный путь; данный же отрицательный результат служит ответом: к тому моменту, как вы начнёте искать, ценная часть уже дистиллирована в коммиты и документацию. Противоположную ставку на сохранение сырых данных делает log-is-the-agent: там тоже сохраняется всё, но в виде причинно-следственного журнала событий для воспроизведения и отслеживания происхождения, а не как текст для поиска.