Память проекта
Память проекта — это место, где Mockarty хранит то, что проект знает:
требования, которые написали люди, решения, которые они приняли, коммиты, которые
их реализовали, тесты, которые их проверили, развёртывания, которые их выкатили, и
то, что по дороге не сработало.
Она наполняется сама. По мере работы миссий, автономного кодера и по мере того, как
люди договариваются в комнатах и сообщениях, факты записываются автоматически.
Заметку можно добавить и вручную.
Читают её двое, и читают ровно одно и то же:
- Вы — на странице Память проекта в боковом меню.
- Агенты — через инструменты
project_memory_*, перед тем как действовать.
Память проекта входит в лицензируемую возможность A2A и автономных агентов.
Страница, REST API и MCP-инструменты доступны на Cloud- или on-prem-узле,
которому принадлежит пространство. Упакованный Desktop не показывает и не
поднимает вторую локальную Память проекта: историю агентов просматривают и
редактируют через веб-интерфейс лицензированного пространства.
Зачем это нужно
Автономный прогон настолько хорош, насколько хорошо то, что он знал на старте. Без
общей памяти каждый прогон заново открывает тот же адрес, заново выводит то же
решение и повторяет ту же ошибку — а когда что-то идёт не так, никто не может
сказать, на что агент смотрел, когда решал.
Из чего состоит факт
У каждого факта есть:
| Часть | Что это |
|---|---|
| Утверждение | Одно предложение, которое читают и человек, и агент |
| Субъект | О чём он — задача, миссия, коммит, артефакт, окружение |
| Доверие | Откуда берётся его авторитет |
| Состояние | Где он в жизненном цикле |
| Источник | Указатель туда, откуда он взялся, чтобы можно было проверить |
| Автор | Кто его записал |
Доверие: откуда берётся авторитет
Факты не равны между собой, и страница говорит об этом в каждой строке.
| Доверие | Значение |
|---|---|
product_db |
Прочитано из собственных записей Mockarty |
aqc_verdict |
Подписанный вердикт приёмки |
human_decision |
Решил конкретный человек |
repository |
Сверено с объектом репозитория |
test_result |
Получено прогоном тестов |
external_system |
Сообщила аутентифицированная внешняя система |
agent_observation |
Собственное наблюдение агента по ходу работы |
model_inference |
Вывод модели |
Последние два — заявления, а не факты. Они полезны, они показываются и они
помечены, но агенту они никогда не достаются как установленная истина.
Состояние: что можно исполнять
candidate → corroborated → reviewed → published, а disputed,
superseded, retracted и expired — способы, которыми факт перестаёт быть
актуальным.
Авторитет — только у published. disputed означает, что два опубликованных
факта расходятся, и обе стороны всегда показываются вместе, никогда одна.
Метки на странице
| Метка | Как читать |
|---|---|
| Установлено | Проверенный факт, по которому можно действовать |
| Решение человека | Указание человека; перекрывать его нельзя |
| Непроверенное заявление | Чьё-то наблюдение, пока не подтверждённое |
| Не сработало | Записанная неудача с условиями, при которых она случилась |
| Спорно | Два факта расходятся, и вопрос не улажен |
Работа со страницей
Откройте Память проекта в боковом меню.
- Ищите и фильтруйте по виду, по минимальному доверию или по идентификатору
субъекта. - Нажмите на факт, чтобы увидеть его целиком: все ревизии, связи вокруг него
и любые противоречия. - Показать контекст агента покажет ровно то, что получил бы агент, работающий
здесь: тот же текст, те же метки, те же цитаты, в том же ограничении по размеру.
Это самый быстрый способ понять, почему агент поступил так, как поступил. - Добавить заметку записывает то, что проект должен запомнить.
Ревью
Владелец пространства имён может:
- Опубликовать факт — сделать его авторитетом. Спрашивается причина, и она
сохраняется. - Отозвать факт, оказавшийся неверным. Он немедленно уходит из выдачи; история
остаётся. - Наложить юридическую заморозку на доказательство, которое обязано
сохраниться. Замороженный факт нельзя удалить ничем, включая удаление
пространства имён.
Ничто никогда не правится на месте. Исправление — это новая ревизия, поэтому
то, по чему агент действовал на прошлой неделе, по-прежнему читается ровно в том
виде, в каком было.
Очередь проверки
Факты, ожидающие проверяющего, отдаёт
GET /api/v1/project-memory/review-queue — кандидаты и подтверждённые факты,
старые первыми. Проверяющий берёт заявку на факт
(POST /api/v1/project-memory/facts/{id}/review/claim), продлевает её
…/review/heartbeat, возвращает …/review/release или завершает
…/review/finalize с явным решением — publish или reject — и причиной.
На завершении действуют три правила:
- generation заявки должен быть живым — проверяющий, чью просроченную
заявку перехватили, не опубликует поверх нового владельца; - автор факта не может утвердить свой же факт — решает независимый
проверяющий; - решение относится к точной проверенной ревизии — если факт успел
измениться, вызов конфликтует, и текущую голову нужно проверить заново.
Профили хранения
Память, растущая без потолка, перестаёт быть полезной и становится счётом. У
каждого проекта есть профиль:
| Профиль | Для чего |
|---|---|
lean |
Небольшие команды и тесные установки. Хранит решения и уроки; рутинная история исполнения стареет быстро. |
balanced |
По умолчанию. Достаточно истории, чтобы объяснить прогон, и достаточно бюджета, чтобы её сжать. |
deep |
Долгоживущие проекты, где качество выдачи стоит места на диске. |
Полоса расхода вверху страницы показывает, какая часть потолка занята. Когда
проект подходит к нему, непроверенные наблюдения отвергаются с объяснением;
решения, вердикты и записи о развёртываниях не отвергаются никогда. Полоса также
показывает, сколько потратили два юнит-тарифицированных фоновых процесса этого
проекта: summaryUnitsUsed (суммаризатор) и embeddingUnitsUsed (авторитет
эмбеддингов) — в тех же единицах, что ведёт журнал расходов.
Есть и линия раннего предупреждения — 95% потолка. Запись, допущенная за неё,
всё равно сохраняется, и ответ говорит об этом: заголовок ответа
X-Project-Memory-Budget: degraded и поле admission ({"degraded": true, "reason": "soft_limit"}) в теле результата записи — включая MCP-инструмент
project_memory_record. Клиент, увидевший сигнал, должен писать меньше:
короче формулировки, меньше фактов — а не повторять запись.
Кое-что не уплотняется ни при каком давлении: решения людей, вердикты приёмки,
записи о развёртываниях, инциденты, неразрешённые противоречия и всё под
юридической заморозкой.
Верно и обратное: эфемерный рабочий контекст — следы вызовов инструментов,
наблюдения за ходом задачи, шаги идущей миссии — хранится, только пока работа
свежа, и через 14 дней исчезает из выдачи.
Сжатие истории: стадия суммаризации
Память обслуживается проходами — от самого дешёвого шага к самому дорогому.
Последний шаг единственный вправе пользоваться языковой моделью: он берёт группу
старых холодных фактов об одном предмете, которую более дешёвые шаги сложить не
смогли, и просит модель сжать её в одно короткое утверждение. Члены группы не
исчезают — они помечаются как сжатые и остаются прослеживаемыми по связям, а
поиск сначала находит суммаризацию.
Стадия нарочно осторожная:
- Она работает только если на установке настроен профиль модели по умолчанию.
Изолированная (air-gapped) установка без модели продолжает жить полностью
работоспособной и полностью детерминированной памятью — все остальные шаги не
требуют ничего, кроме базы данных. - Суммаризация сохраняется как вывод модели — в самом слабом классе доверия и
без публикации. Пока человек её не проверил, она не несёт авторитета фактов,
которые заменила. - Модель вправе ответить, что сохранять нечего. Это нормальный исход: никакая
суммаризация не записывается, группа остаётся как была.
Бюджет суммаризации
Сжатие стоит денег, поэтому у каждого пространства есть отдельный лимит
суммаризации в юнитах (примерно юнит на несколько токенов материала). Полоса
расхода показывает обе его стороны:
maxSummaryUnits— лимит, который выдаёт профиль (уleanон нулевой:
на модели она не тратится);usedSummaryUnits— сколько пространство реально потратило.
Каждый вызов модели списывается с лимита до его выполнения. Если следующая
группа не помещается, проход просто перестаёт суммаризировать до следующего
раза — факты не тронуты, работа продолжится позже. Счётчик только растёт:
потраченный юнит не возвращается, потому что оплаченный вызов модели отменить
нельзя.
Оплата устойчива к сбоям. Каждая группа оплачивается не более одного раза: если
процесс погиб между оплатой группы и получением ответа, следующий проход узнает
уже оплаченную группу и пропустит её вместо второй оплаты. Группа, пополнившаяся
или поредевшая фактами, — это новая группа, и она суммаризируется сама по себе.
Для агентов
Четыре инструмента, по одному на момент прогона:
| Инструмент | Когда |
|---|---|
project_memory_context |
Перед действием — ограниченный контекст по тому, над чем вы работаете |
project_memory_search |
По ходу — конкретный вопрос к фактам проекта |
project_memory_record |
После — урок, грабли, наблюдение |
project_memory_timeline |
При разборе — объяснимая история одного прогона |
Для project_memory_context, project_memory_search и
project_memory_timeline токену нужно действие read, а для
project_memory_record — write. Контекст передаётся через POST только потому,
что запрос структурирован и ограничен по размеру; память проекта он не изменяет.
То, что записывает агент, входит кандидатом-наблюдением с его авторством.
Авторитетом проекта оно не становится, пока человек не проверит его или пока
независимый источник не скажет то же самое.
Изоляция и безопасность
- Факт принадлежит ровно одному пространству имён. Одинаковая формулировка в двух
пространствах — это два разных факта, и ни один не виден из другого. - Учётные данные отвергаются. Утверждение, атрибут или ссылка, похожие на токен,
не сохраняются, а отклоняются. - Сырые логи, переписки целиком и файлы целиком не хранятся. Факт держит короткую
цитату и указатель туда, где лежат подробности. - Текст, сохранённый в факте, не может стать указанием, когда его прочитает агент.