Память Codex: что стоит сохранять между задачами, а что лучше не доверять агенту
Память кажется идеальным решением: один раз объяснил проект, и агент больше не забывает. Но в рабочем контуре память опасна ровно настолько, насколько она удобна. Если в ней закрепилась ошибка, устаревшее решение или личная догадка, агент начнет приносить это в новые задачи как будто это факт.
Официальная документация OpenAI описывает этот слой как Memories в Codex. Для ONFF важен практический перевод: память — это вспомогательный контекст, а не замена явным файлам, package state и gates.
Какая рабочая боль здесь решается
В каждом проекте есть повторяемый контекст: стиль, ограничения, рабочие привычки, любимые проверки, запрещенные действия. Если каждый раз проговаривать это заново, работа замедляется. Но если все спрятать в память, человек перестает видеть, откуда агент взял решение.
Нужен баланс. Память должна снижать повторяемое объяснение, но не должна становиться невидимым источником правды.
Что устанавливает официальный источник
Документация показывает, что memories можно включать, использовать в новых threads, хранить, контролировать per thread, настраивать через параметры и просматривать. Среди настроек есть генерация памяти, использование памяти, отключение при external context, лимиты и модели для извлечения/консолидации.
Для владельца процесса это означает: память управляется. Ее можно включать, ограничивать, просматривать и отключать. Значит, ее нужно проектировать так же аккуратно, как rules или skills.
Что дать Codex на вход
| Что можно помнить | Что лучше держать в файлах | Почему |
|---|---|---|
| стабильные предпочтения | текущий текст статьи | статья меняется чаще |
| стиль коммуникации | публикационный статус | статус должен быть в package |
| постоянные запреты | секреты и токены | память не место для секретов |
| типовые проверки | конкретный результат gate | gate должен быть артефактом |
| любимые форматы | спорные решения | спорное требует human review |
Codex можно попросить подготовить политику памяти:
Проект: ONFF journal
Раздели контекст на три группы:
1. Можно сохранить в memories.
2. Должно жить в файлах проекта.
3. Нельзя сохранять, нужно спрашивать человека.
Для каждого пункта объясни:
- почему это память или файл;
- как человек проверяет актуальность;
- когда память нужно удалить или обновить.Такой вход не просит Codex “запомнить все”. Он просит Codex сделать карту ответственности.
Какой артефакт должен вернуть Codex
Хороший результат — memory policy card:
- что можно сохранять;
- что нельзя сохранять;
- что должно жить в
AGENTS.md, skill, package или policy file; - как часто это проверять;
- кто принимает спорные изменения;
- когда память отключается для thread.
В ONFF это особенно важно после сжатий контекста. Архитектура должна жить в файлах, а память может помогать ориентироваться. Но память не должна становиться единственным местом, где “агент вроде бы помнит”.
Как проверить без программирования
Проверка простая: открыть список memories и спросить, помогает ли каждая запись будущей работе.
Минимальный чек:
- Память не содержит секретов.
- Память не заменяет publication state.
- Память не закрепляет спорное решение как факт.
- Понятно, когда ее обновлять.
- Память можно отключить или не использовать в конкретном thread.
Если запись невозможно проверить, ее лучше не хранить.
Где это место в контент-заводе
В ONFF память может хранить устойчивые предпочтения: русские заголовки, запрет прямой отправки Telegram/VK, ArticleFactory как distribution-only, visual production через Codex skills. Но конкретная статья должна жить в iteration package. Конкретная публикация — в PUBLISH_LOG.yaml. Конкретный gate — в review YAML.
Память помогает не начинать с нуля. Но завод работает на артефактах.
Что нельзя отдавать только в память
Память удобна для предпочтений, устойчивых правил и повторяемого контекста, но она не должна становиться единственным местом правды. Если решение влияет на деньги, публикацию, доступ, юридическую позицию, production-среду или редакционную политику, оно должно жить в файле проекта, в policy, в задаче или в журнале изменений. Memory может напомнить о правиле, но не должна быть его единственным доказательством.
Практическая проверка простая: если завтра другой агент откроет проект без этой памяти, сможет ли он понять правило по файлам? Если нет, значит память используется неправильно. Codex можно попросить разделить сведения на три группы: можно сохранить как memory, нужно записать в project file, нельзя сохранять без отдельного решения человека.
Так память становится не тайным мозгом агента, а удобным индексом. Она ускоряет старт, но не подменяет документацию, gates и человеческую приемку.
Что остается человеческим
Человек решает, какие сведения можно сохранять между задачами, а какие должны жить только в package, policy или документе.
Codex может предложить memory policy и найти устаревшие записи. Но он не должен превращать память в скрытую конституцию проекта. Хорошая память — это фонарь. Плохая память — это невидимый начальник.
