Цифры я считаю отдельно кодом, там все детерминированно и модели просто нечего додумывать.
А вот с текстовыми выводами проблема ровно та, о которой ты пишешь. Git дает воспроизводимость, можно посмотреть, что было в исходниках на момент генерации. Но не дает отследить, по готовой сводке не всегда понятно, из каких именно записей появился конкретный вывод.
Поэтому идею с цитатами и счетчиком «обработано N заметок из M» забираю. У меня все дневники лежат по предсказуемым путям daily/YYYY/MM/YYYY-MM-DD.md (e.g. daily/2025/08/2025-08-16.md), так что напрашивается ссылка на источник для каждого тезиса. Тогда и пропущенный день, и странный вывод будут сразу видны, а не потеряются в гладком пересказе.
Так что числовую часть я уже более-менее закрыл, а текстовую ещё предстоит допилить.
Да, мне кажется я пока сознательно остановился на Markdown, чтобы не превратить дневник в отдельный проект :)
Но мысль про отдельный слой фактов мне нравится. Для дат, расходов, лекарств, встреч и прочих вещей, где важна точность, БД выглядит вполне логичным развитием.
Мне понравилась именно идея вынести текущее состояние в отдельный наблюдаемый слой, а не прятать все внутри истории диалога. В каком-то смысле это решает ту же проблему, на которую я наткнулся с дневником: важно не только хранить память, но и понимать, на основании чего агент делает вывод прямо сейчас.
У меня получилось через Markdown-архив и отчеты, у вас через отдельную панель состояния, но мысль очень похожая если память нельзя проверить глазами, ей сложно доверять.
Согласен, формулировка спорная. Скорее имел в виду не полноту как идеальность записи, а полноту временного ряда. Тридцать коротких записей за месяц для меня действительно оказались полезнее семи подробных.
Насчет "велосипеда" тоже согласен :) Когда начинал, был уверен, что сейчас найду готовое решение. В итоге как-то прям идеальное решение так и не нашел, но для себя решил сначала собрать минимальную систему из того, что уже использую каждый день.
Пока собирал дневник, тоже пришел к мысли, что проблема не столько в объеме памяти, сколько в ее структуре и в дисциплине чтения источника перед выводами.
По сути, ваш CHECKPOINT.md решает ту же задачу, что у меня ежедневные Markdown-записи, создает внешний источник истины, который переживает контекстное окно, перезапуски и смену моделей.
Да, похоже, у нас одинаковый диагноз :)
Цифры я считаю отдельно кодом, там все детерминированно и модели просто нечего додумывать.
А вот с текстовыми выводами проблема ровно та, о которой ты пишешь. Git дает воспроизводимость, можно посмотреть, что было в исходниках на момент генерации. Но не дает отследить, по готовой сводке не всегда понятно, из каких именно записей появился конкретный вывод.
Поэтому идею с цитатами и счетчиком «обработано N заметок из M» забираю. У меня все дневники лежат по предсказуемым путям daily/YYYY/MM/YYYY-MM-DD.md (e.g. daily/2025/08/2025-08-16.md), так что напрашивается ссылка на источник для каждого тезиса. Тогда и пропущенный день, и странный вывод будут сразу видны, а не потеряются в гладком пересказе.
Так что числовую часть я уже более-менее закрыл, а текстовую ещё предстоит допилить.
Да, мне кажется я пока сознательно остановился на Markdown, чтобы не превратить дневник в отдельный проект :)
Но мысль про отдельный слой фактов мне нравится. Для дат, расходов, лекарств, встреч и прочих вещей, где важна точность, БД выглядит вполне логичным развитием.
Почитал статью, теперь понял о чем речь.
Мне понравилась именно идея вынести текущее состояние в отдельный наблюдаемый слой, а не прятать все внутри истории диалога. В каком-то смысле это решает ту же проблему, на которую я наткнулся с дневником: важно не только хранить память, но и понимать, на основании чего агент делает вывод прямо сейчас.
У меня получилось через Markdown-архив и отчеты, у вас через отдельную панель состояния, но мысль очень похожая если память нельзя проверить глазами, ей сложно доверять.
Согласен, формулировка спорная. Скорее имел в виду не полноту как идеальность записи, а полноту временного ряда. Тридцать коротких записей за месяц для меня действительно оказались полезнее семи подробных.
Насчет "велосипеда" тоже согласен :) Когда начинал, был уверен, что сейчас найду готовое решение. В итоге как-то прям идеальное решение так и не нашел, но для себя решил сначала собрать минимальную систему из того, что уже использую каждый день.
Очень похожее наблюдение, да.
Пока собирал дневник, тоже пришел к мысли, что проблема не столько в объеме памяти, сколько в ее структуре и в дисциплине чтения источника перед выводами.
По сути, ваш CHECKPOINT.md решает ту же задачу, что у меня ежедневные Markdown-записи, создает внешний источник истины, который переживает контекстное окно, перезапуски и смену моделей.
Ух ты, это отличная идея, я что-то думал что для меня это будет оверинженеринг, но вероятно что в итоге упрус в потолок из-за мд файловой системы….
А что значит отдельную панель? Отдельный аккаунт? Это вы про чат гпт ?