• Память агента — это markdown в трёх слоях: дневники, проектные папки, инцидент-артефакты
  • Один дневник в день с пятью фиксированными секциями; тишина в чате становится сигналом
  • Файлы в git дают воспроизводимость, передачу и аудит без отдельного инструмента

Задача

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

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

Приём

Память агента живёт в markdown-файлах в папке, которой владеет агент и которую читает оператор. Три слоя.

flowchart TD
    M[Папка memory:<br/>владеет агент] --> D[Дневники:<br/>горизонт день]
    M --> P[Проектные папки:<br/>горизонт проект]
    M --> I[Инцидент-артефакты:<br/>горизонт инцидент]
    O([Оператор]) -. читает .-> M

Ежедневные дневники. Один файл в день, memory/YYYY-MM-DD.md, всегда с одной и той же схемой:

memory/2026-05-19.md
  1. План на сегодня (из вчера)
  2. Факт (по чатам)
  3. Статус (по проектам)
  4. Проблемы
  5. На завтра

Каждый запуск по крону дописывает в дневник дня. Утренний проход читает вчерашний файл и собирает план; вечерний пишет секцию «На завтра», которая становится завтрашним планом. Дневник — не пересказ сообщений, а структурированный дайджест: что произошло в каждом чате, где каждый проект, что заблокировано. Продюсер, подменяющий коллегу на день, читает вчерашний файл и в курсе.

flowchart LR
    Y[Вчерашний<br/>дневник] --> U[Утренний проход:<br/>план на сегодня]
    U --> C[Запуски по крону<br/>дописывают день]
    C --> V[Вечерний проход:<br/>секция На завтра]
    V -. завтрашний план .-> Y

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

Проектные папки. У каждого активного проекта memory/<project>/ с обзором (контекст, команда, правила коммуникации), файлом дедлайнов с визуальными маркерами (приближается, пропущен, ближайший) и трекерами под специфику: видео, утверждения, 3D-модели, работа сверх объёма. Каждый трекер — это markdown-таблица, которую агент перерисовывает при каждом проходе, а оператор иногда правит руками, когда срок сдвинулся.

Инцидент-артефакты. Длинные аналитические документы, собранные из дневников, когда ситуация того требует: хронология проблемного этапа, таблица блокеров (кто, что, с какой даты), список работы сверх договорённостей. Такой файл не проектируется заранее — он накапливается: агент логирует каждое событие в дневник с идентификатором исходного сообщения, а когда нужен сводный разбор, собирает его из дневников. Дневники — вход, разбор — артефакт. Гранулярность «дневник плюс ссылка на сообщение» пересобирается в любой документ под ситуацию без дополнительной нагрузки во время проекта.

flowchart LR
    S[Событие<br/>в чате] --> D[Запись в дневнике<br/>+ id сообщения]
    D --> A[Дневники<br/>за период]
    A -->|нужен разбор| R[Инцидент-артефакт:<br/>хронология, блокеры]
    classDef key stroke:#FF3600,stroke-width:2px
    class R key

Почему это актив, а не кэш.

  • Воспроизводимость. Файлы в git; любое прошлое состояние памяти восстанавливается чекаутом. Спор «что мы знали в среду» решается за минуту.
  • Передача. Схема одна для всех дней и проектов, поэтому новый человек читает файлы без инструмента и без объяснений. SQL требует клиента, markdown — нет.
  • Аудит. Каждая запись привязана к дате и источнику. Когда проект разваливается, команда восстанавливает, что случилось, из того же материала, который агент вёл для себя.
flowchart TD
    G[Markdown-файлы<br/>в git] --> R[Воспроизводимость:<br/>чекаут состояния]
    G --> T[Передача:<br/>одна схема для всех]
    G --> A[Аудит:<br/>дата и источник]

Поиск двумя путями: grep для точных строк, небольшая локальная embedding-модель для семантики, обе по тем же файлам. Схема держится соглашением, а не принуждением: новый трекер — это новый файл, миграций нет.

Обновление, сентябрь 2026. Летом появилась вторая схема: память агента как выжимка из общей базы знаний. Рабочие правила живут в wiki, а агент держит у себя указатель на них, шпаргалку и формат своего лога; для другого агента память собрали так же — семью файлами, которые грузятся в каждую сессию. Источником истины осталась wiki, память агента — только быстрый доступ к ней. Цена схемы — в синхронизации: копию у агента нужно догнать до актуального состояния до того, как он выходит в работу.

Где ломается

  • Нет ограничений целостности. Ничто не гарантирует, что таблица дедлайнов сегодня имеет те же колонки, что вчера. Компромисс намеренный: система для одного оператора, который часто читает файлы, а не база для многих писателей.
  • Память без аудитории. Агент щедро пишет, оператор не читает, актив превращается в архив. Лечится ритуалом: чтение дневников с известной частотой и статус-апдейты клиенту прямо из дневника, чтобы файл стал поставляемым результатом.
  • Транскрипт вместо схемы. Длинное контекстное окно без фиксированных секций даёт хороший recall один на один и ничего для команды. Схему нужно записать, а транскрипты считать сырьём, не памятью.
  • Одноразовые задачи. Резюмировать один документ и уйти — корпоративного регистра не требует; паттерн окупается на развёртываниях от нескольких недель.

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

Итог

  • Память агента должна иметь схему, иначе её читает только агент.
  • Три слоя покрывают три горизонта: день, проект, инцидент.
  • Файлы в git выигрывают у базы там, где второй читатель — человек.
  • У каждого файла памяти и каждого зеркала должен быть владелец, иначе файл тихо устаревает, а читают его по-прежнему как правду.
  • Соседний паттерн для личных знаний: Агентная wiki; цикл, который растит правила вокруг памяти: Конфигурация через инциденты.

© Александр Никулин. Цитирование — с указанием автора и ссылкой · Версия для LLM