Зачем это нужно

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

Цель — построить внешнюю, проверяемую и управляемую человеком долговременную память агента.

Основные потребности агента

1. Восстановление контекста при старте новой сессии

При начале новой сессии агенту нужен минимальный bootstrap-контекст:

• кто текущий пользователь;
• кто сам агент;
• активные проекты;
• открытые и недавно изменённые задачи;
• последние worklog'и;
• важные решения и ограничения;
• актуальные skills;
• свежая активность;
• при необходимости — текущие приоритеты пользователя или проекта.

Важно не загружать всё подряд. Bootstrap должен быть компактным, а более глубокие знания подтягиваться по мере необходимости.

2. Разделение разных типов памяти

Желательно явно различать несколько уровней памяти:

Краткосрочная память

Текущий диалог и контекст текущей сессии.

Операционная память

То, что нужно для текущей работы:

• проекты;
• задачи;
• статусы;
• worklog'и;
• последние события;
• текущие блокеры.

Долговременная фактическая память

Устойчивые знания, которые должны переживать отдельные задачи и сессии:

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

Память решений

Отдельно хранить решения, принятые человеком или командой:

• что решили;
• почему;
• какие альтернативы рассматривались;
• когда решение принято;
• кем принято;
• к каким проектам/задачам относится.

Процедурная память

Skills, runbooks и воспроизводимые способы работы:

• как расследовать проблему проекта;
• как проверять релиз;
• как оформлять багрепорт;
• как завершать задачу после проверки;
• как выполнять повторяющиеся операции безопасно.

Выводы агента

Гипотезы и интерпретации ИИ должны храниться отдельно от подтверждённых фактов и явно маркироваться как выводы агента.

3. Накопление знаний во время работы

Рабочий цикл не должен завершаться только ответом в чате.

При выполнении работы агент должен уметь фиксировать:

• новые факты;
• наблюдения;
• результаты проверок;
• причины ошибок;
• принятые решения;
• полезные ссылки;
• выводы;
• ограничения;
• уроки, которые стоит переиспользовать.

При этом не каждое сообщение и не каждый промежуточный вывод должны становиться долговременной памятью.

Нужен механизм отбора: что действительно стоит запомнить надолго.

4. Консолидация памяти

Сырые данные со временем нужно сворачивать в более компактные знания.

Пример:

10 worklog'ов расследования
→ итоговая причина
→ принятое решение
→ полезный lesson
→ при необходимости новый skill/runbook

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

Консолидация должна сохранять ссылки на первичные источники.

5. Retrieval по текущей цели

Новая сессия не должна перечитывать всю память.

Если пользователь спрашивает про конкретный проект, агент должен получить релевантный подграф знаний:

Project
→ текущие задачи
→ последние worklogs
→ связанные решения
→ релевантные facts
→ lessons
→ skills
→ свежая активность

То есть память должна поддерживать retrieval по:

• проекту;
• задаче;
• пользователю/агенту;
• сущности;
• теме;
• временному диапазону;
• типу знания;
• связям между сущностями.

6. Происхождение и доверие к знаниям

У существенного знания желательно хранить provenance:

• источник;
• автора;
• дату создания;
• дату последней проверки;
• связанный проект;
• связанные задачи/worklogs;
• уровень уверенности;
• статус актуальности;
• ссылки на первичные данные.

Агент не должен считать каждую сохранённую запись безусловной истиной.

Нужно различать как минимум:

• подтверждённый факт;
• решение человека;
• наблюдение;
• вывод агента;
• гипотезу;
• устаревшее знание;
• активную инструкцию/skill.

7. Обновление и устаревание знаний

Память должна уметь изменяться.

Нужно предусмотреть:

• supersede старого знания новым;
• пометку outdated / неактуально;
• переоценку гипотезы после новых данных;
• историю изменений;
• возможность человека исправить или удалить неверное знание.

Противоречащие друг другу факты нельзя молча «склеивать» в один.

8. Эволюция skills

Повторяющийся успешный рабочий процесс должен иметь возможность превращаться в skill.

Желаемый цикл:

наблюдение
→ действие
→ результат
→ фиксация
→ проверка
→ консолидация
→ переиспользование
→ превращение повторяемого опыта в skill

Таким образом агент развивается не только за счёт накопления фактов, но и за счёт накопления процедур.

9. Управляемость человеком

Долговременная память не должна быть скрытым состоянием модели.

Пользователь должен иметь возможность:

• посмотреть, что агент считает знанием;
• увидеть источник;
• исправить запись;
• пометить её неактуальной;
• удалить её;
• повысить или понизить доверие;
• явно закрепить решение как authoritative.

Это критично для совместной работы.

10. Возможные сущности

Нужно изучить, насколько текущая модель fi1osof.ru уже покрывает эти потребности.

Потенциально могут использоваться существующие или новые сущности уровня:

• Fact;
• Concept;
• Decision;
• Observation;
• Lesson;
• KnowledgeSpace;
• Skill;
• Task;
• TaskWorkLog;
• связи между ними.

Не обязательно создавать новые сущности, если нужная семантика уже корректно выражается существующей моделью.

Желаемый жизненный цикл агента

Старт сессии

1. Определить пользователя и агента.
2. Загрузить минимальный bootstrap-контекст.
3. Получить актуальные skills и ограничения.
4. Восстановить активную рабочую область.

Выполнение работы

1. Получить цель пользователя.
2. Подтянуть релевантные знания.
3. Проверить их актуальность там, где это важно.
4. Выполнить работу.
5. Зафиксировать результат в рабочих сущностях.

Завершение значимого этапа

1. Определить, появились ли новые долговременные знания.
2. Сохранить facts/decisions/observations/lessons.
3. Связать их с первичными источниками.
4. При необходимости обновить существующее знание вместо создания дубля.

Периодическая консолидация

1. Найти повторяющиеся или раздробленные знания.
2. Свернуть их в компактное представление.
3. Сохранить provenance.
4. Пометить устаревшие записи.
5. Выделить повторяемые процедуры в skills.

Следующая сессия

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

Что нужно изучить

На следующем этапе необходимо изучить текущие возможности fi1osof.ru и определить:

1. Какие существующие сущности уже подходят для долговременной памяти.
2. Как устроены facts, concepts, knowledge spaces и их связи.
3. Есть ли модели решений, участников, проекций, конфликтов и ограничений, которые можно использовать вместо новых сущностей.
4. Как работает поиск/retrieval по знаниям.
5. Как knowledge-сущности связываются с проектами, задачами, пользователями и агентами.
6. Как реализовать provenance и актуальность.
7. Как лучше организовать bootstrap новой сессии.
8. Какие skills уже существуют для работы со знаниями.
9. Чего не хватает в API или модели данных.

Критерий готовности архитектуры

Решение можно считать удачным, если после начала новой сессии агент способен по данным fi1osof.ru:

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

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