Агенты проигнорировали подсказку читать память в 7 сессиях из 7 — разбор 13 тысяч логов

Команда kaeru, которая делает долгосрочную память для ИИ-агентов вроде Claude Code, Codex и Cursor, опубликовала разбор собственных логов: больше 13 тысяч файлов рабочих сессий с июня по сентябрь. Главный результат: в 7 сессиях, где агент увидел подсказку «можешь прочитать сохранённые рассуждения», он не прочитал их ни разу, хотя другую подсказку, «свяжи запись с предыдущей», выполнил 751 раз. Авторы несколько месяцев проектировали продукт «по ощущениям», а потом проверили, как агенты пользуются памятью на самом деле. Многое оказалось не так, и большинство выводов касается не только kaeru, но и любого, кто пишет MCP-сервер, хуки или длинные инструкции для агентов.

Что такое kaeru и что проверяли

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

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

Долг выполняется, возможность пропускается

На входе в проект добавили подсказку «по проекту есть сохранённые рассуждения, можешь прочитать». За четыре дня модель увидела её в 7 сессиях и не прочитала ни разу, хотя за то же время агенты сохранили 17 новых рассуждений. Писать они готовы, перечитывать нет.

Другая подсказка, «свяжи эту запись с той, из которой она выросла», приходила сразу после записи и была выполнена 751 раз. Это самое частое действие во всём продукте. В версии 0.8 связь указывается прямо в вызове записи, отдельная подсказка не нужна. Разница в моменте: вторая продолжает то, что агент уже делает, первая просит бросить задачу и заняться посторонним.

Та же картина со сводкой. По строке «2 записи под вопросом, ждут решения» агенты 8 раз разбирали спорные записи, просроченные задачи закрываются исправно, а строка «можешь прочитать сохранённые рассуждения» не сработала ни разу. Теперь всё в сводке формулируется как долг.

Хуки, обрезанные инструкции и необязательные параметры

На логах одного пользователя 80% вопросов агента к человеку шли без единого обращения к памяти за предыдущие десять минут; медиана составила 74 минуты с последнего чтения. Для этого сделали хук — скрипт, который клиент запускает в заданный момент. Когда агент собирается передать ход человеку, хук ищет в памяти материалы по теме и один раз отправляет агента их прочитать. Первая версия определяла обращение к человеку по знаку «?». На 2 608 остановках агента из 1 164 обращений она увидела 201, то есть 17%. В 856 случаях это были просьбы в повелительной форме: «скажи», «пришли отчёт», «нужен твой ответ по поставщику». Агенты чаще просят, чем спрашивают.

Самая неприятная находка: клиент обрезал инструкцию MCP-сервера на 2 048 символах, и два месяца этого никто не замечал. Среди инструментов, упомянутых до обрыва, не использовались 9%. Среди упомянутых после обрыва — 31%, как и у тех, о которых в инструкции не сказано вообще. Для модели хвост инструкции просто не существовал. Сейчас вводный текст kaeru занимает 1 499 символов.

С параметрами то же самое. Вес связи был необязательным, со значением по умолчанию. За 6 003 вызова инструментов памяти агенты создали 1 262 связи и ни разу не указали вес. В 0.8 он стал обязательным. У напоминаний срок показа обязателен с самого начала: «сертификат истекает» и «перемерь цифру перед цитированием» требуют разных сроков, и знает их только автор записи.

Лучше всего сработала фоновая уборка, которая ничего не просит у агента: с первого прохода она сама разложила по слоям 33 накопившиеся записи.

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

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

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