Как устроена память в Codex CLI

Подробный разбор архитектуры памяти в Codex CLI от OpenAI: как воспоминания записываются, загружаются и консолидируются, какие у системы ограничения и как Mem0 решает эти проблемы через MCP-интеграцию.

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Как устроена память в Codex CLI

How Memory Works in Codex CLI Автор: mem0 Оригинальный текст:

Codex CLI поставляется со встроенным хранилищем памяти на основе асинхронной суммаризации, расположенным в ~/.codex/memories/.

Это штатная функция:

• задокументирована на developers.openai.com/codex
• полностью открыта в репозитории github.com/openai/codex

В этой статье из серии In Context мы разбираем, как устроена память в Codex CLI.

Codex — это агент для написания кода от OpenAI, который существует в трёх вариантах: CLI, расширение для IDE и облачное рабочее пространство внутри ChatGPT.

CLI — наиболее подробно задокументированная поверхность, и внутренности его памяти открыты, поэтому именно его мы и рассмотрим. Большая часть описанного ниже по транзитивности применима и к расширению для IDE, которое использует ту же конфигурацию ~/.codex/ и ту же структуру памяти.

Архитектура Memories

Память Codex живёт в одной директории: ~/.codex/memories/. В ней хранится фиксированный набор markdown-файлов. Никаких SQLite, индексов embeddings (эмбеддингов, векторных представлений) или непрозрачных бинарных объектов.

Важные файлы:

• memory_summary.md — консолидированное представление, которое следующая сессия читает первым
• MEMORY.md — полный объединённый файл памяти, по которому выполняется grep по запросу
• raw_memories.md — результат извлечения до консолидации
• skills/<name>/SKILL.md — воспоминания, привязанные к конкретным навыкам
• rollout_summaries/<slug>.md — резюме по сессиям, которые подаются на вход процессу консолидации

Это и есть весь слой памяти. Всё остальное — это pipeline (пайплайн, конвейер обработки), который его наполняет, и путь чтения, который из него извлекает.

Как записываются воспоминания

Путь записи разделён на две фазы.

Фаза 1 — пороллаутная. Когда сессия простаивает достаточно долго (по умолчанию шесть часов), Codex берёт задачу при запуске, сэмплирует разговор по промпту со строгой схемой извлечения, прогоняет каждый результат через редактор секретов и сохраняет его в локальной базе данных состояний. В директорию памяти пока ничего не попадает.

Фаза 2 — глобальная. Она захватывает глобальную блокировку (хранящуюся в базе состояний), чтобы два прохода консолидации никогда не выполнялись параллельно. Загружает недавние результаты Фазы 1, синхронизирует их на диск, проверяет, действительно ли получившееся рабочее пространство отличается от текущего, и только тогда запускает отдельный подагент консолидации. Подагент читает кандидатов, решает, что объединить, что обновить, что отбросить, и записывает diff обратно в ~/.codex/memories/.

Обе фазы используют настраиваемые модели (extractmodel для Фазы 1, consolidationmodel для Фазы 2), а процесс консолидации выполняется как отдельный подагент, а не встроенно в чат пользователя.

Как загружаются воспоминания

При старте сессии Codex читает memory_summary.md целиком, обрезает его до фиксированного бюджета в 5 000 tokens (токенов) (константа, определённая в крейте пути чтения, а не в публичной документации) и инжектирует результат в инструкции разработчика. Это обрезанное резюме — всё, что агент получает предзагруженным.

Для всего, что не вошло в резюме, агент инструктирован выполнять grep по MEMORY.md напрямую. Шаблон пути чтения говорит агенту: извлеки ключевые слова из резюме, ищи по MEMORY.md, открой соответствующие файлы резюме роллаутов, если на них есть ссылка, останови поиск, если ничего не найдено. Весь бюджет поиска укладывается в небольшое число шагов.

Здесь нет хранилища embeddings, нет поиска по семантическому сходству, нет этапа переранжирования. Это простой текст и поиск подстрок — намеренно. Компромисс — предсказуемость и нулевая стоимость поиска в обмен на невозможность найти факты, чья формулировка в запросе и в хранилище не совпадает по ключевым словам.

Механики, которые всем управляют

Несколько конфигурационных параметров контролируют всё описанное выше. Стоит знать, прежде чем полагаться на систему.

• Выключено по умолчанию. Мастер-флаг features.memories должен быть включён. После включения два подпереключателя управляют рантаймом: generatememories (запись) и usememories (чтение). Оба по умолчанию true после активации фичи.
• Порог простоя. minrolloutidle_hours (по умолчанию 6) задаёт минимальное время простоя, прежде чем сессия станет кандидатом для Фазы 1. Активные сессии его никогда не триггерят.
• Лимиты консолидации. maxrawmemoriesforconsolidation (по умолчанию 256, максимум 4 096) ограничивает количество недавних роллаутов, которые проход консолидации рассматривает за один запуск.
• Старение. maxrolloutagedays (по умолчанию 30) перестаёт рассматривать треды старше этого срока для генерации памяти. maxunused_days (по умолчанию 30) делает воспоминания, не вызывавшиеся в течение этого окна, непригодными для следующего прохода консолидации.
• Учёт лимитов API. minratelimitremainingpercent (по умолчанию 25) замедляет консолидацию при низкой квоте API пользователя, чтобы фоновая работа никогда не голодила основные запросы.
• Редакция секретов. Встроенная очистка учётных данных перед записью любого воспоминания на диск.
• Географическое ограничение. На момент запуска Memories недоступна в ЕЭЗ, Великобритании и Швейцарии. Пользователи из этих регионов не имеют доступа вообще.

Где система буксует

Кратчайшая формулировка: эта система памяти не является надёжной. Это markdown-файлы одного пользователя в рамках фиксированного бюджета токенов, и большинство режимов отказа следуют именно из этого.

• Жёсткий лимит токенов на загрузку. memory_summary.md обрезается до 5 000 токенов при каждом старте сессии. Всё, что за лимитом, молча отбрасывается. Никакого предупреждения, никакого лога. Агент просто этого не видит.
• Фолбэк только по ключевым словам. Всё, что не попало в резюме, должно быть находимым в MEMORY.md по буквальному совпадению подстрок. Перефразированные факты невидимы. Запрос «Какая у нас команда деплоя?» не найдёт «продакшен-деплои идут через make ship-prod», если ни одно из этих точных слов не сохранено.
• Стоимость grep растёт вместе с файлом. MEMORY.md ищется линейно. Для пользователя с месяцами накопленных воспоминаний каждый промах с последующим grep обходится дороже.
• Только сгенерированное состояние, не редактируемое. Документация описывает ~/.codex/memories/ как управляемое Codex. Ручное редактирование воспоминаний — не поддерживаемый путь. Всё, что пользователь действительно хочет, чтобы агент всегда знал, помещается в AGENTS.md.
• Хрупкость порога простоя. Сессии должны простоять шесть часов, прежде чем станут кандидатами на консолидацию. Разработчик, работающий в непрерывных спринтах кодирования, может никогда этого не дождаться.
• Только локальное состояние. ~/.codex/memories/ — это состояние файловой системы конкретного пользователя на конкретной машине. Никакой синхронизации между машинами, никакого командного обмена, никакого удалённого хранилища.
• Географический шлагбаум. Memories заблокирована в ЕЭЗ, Великобритании и Швейцарии на момент запуска.

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

Как вписывается Mem0

Mem0 — это слой памяти, который располагается между агентом и персистентным хранилищем.

Конкретно для Codex существует MCP-интеграция, задокументированная на docs.mem0.ai/integrations/codex.

Codex CLI нативно поддерживает MCP-серверы. Они настраиваются в ~/.codex/config.toml в секции [mcp_servers.<name>] (config-reference). Минимальная настройка Mem0 — один блок:

[mcp_servers.mem0]
url = "https://mcp.mem0.ai/mcp"
bearer_token_env_var = "MEM0_API_KEY"

Этот единственный блок предоставляет Codex девять MCP-инструментов: addmemory, searchmemories, getmemories, getmemory, updatememory, deletememory, deleteallmemories, deleteentities, listentities.

Агент Codex подхватывает их так же, как любую другую поверхность MCP-инструментов.

Что меняется под капотом:

• Персистентная, кросс-машинная память. Потолок локальной ~/.codex/memories/ исчезает. Одно и то же хранилище Mem0 следует за пользователем между ноутбуками, серверами и CI-окружениями. Никакой регенерации с нуля на новой машине.
• Кросс-инструментальная память. Пользователь, работающий с Codex CLI в терминале и с Cursor в редакторе, может направить оба на один и тот же бэкенд Mem0. Факт, захваченный во время сессии Codex CLI («скрипт деплоя в staging молча проглатывает ошибки, для диагностики лучше использовать продакшен-стиль вывода»), всплывает в следующем запуске Cursor Agent на том же проекте. Пользователю не нужно ничего копировать между двумя инструментами.
• Семантический поиск. Mem0 ищет по смыслу через поиск на основе embeddings. Нативный поиск Codex читает memory_summary.md целиком и откатывается к grep по MEMORY.md: быстро и предсказуемо, но неспособно найти сохранённый факт, чья формулировка отличается от запроса. С Mem0 запрос «какая у нас команда деплоя?» находит «продакшен-деплои идут через make ship-prod», даже если слова не совпадают.
• Изоляция по пользователям. userId каждого пользователя определяет область видимости его памяти. Три коллеги с одним бэкендом Mem0 хранят раздельные базы.
• Нет лимита резюме в 5 000 токенов. Поиск — это ранжированный семантический поиск по реальному хранилищу, а не загрузка целого файла с одним резюме. Большие базы памяти остаются юзабельными, а не обрезаются до бюджета developer instructions.
• Обновления в реальном времени. Mem0 записывает воспоминания по ходу разговора, а не по шестичасовому порогу простоя. Следующая сессия видит то, чему научилась предыдущая.
• Доступно там, где Memories нет. Пользователи из ЕЭЗ, Великобритании и Швейцарии получают слой памяти, не зависящий от региональной раскатки Codex.

Слой памяти Codex CLI тщательно спроектирован для агентного пространства в сфере написания кода: двухфазная фоновая консолидация, редакция секретов, путь чтения на основе grep с предсказуемой стоимостью в токенах и полностью открытый pipeline.

Если вы используете Codex CLI сегодня и какие-то из этих пробелов выглядят знакомо, интеграция Mem0 занимает около минуты — docs.mem0.ai/integrations/codex.

In Context #9

Этот блог — часть In Context, серии блогов @mem0ai об агентной памяти и context engineering (управлении контекстом).

@mem0ai — это интеллектуальный слой памяти с открытым исходным кодом, разработанный для больших языковых моделей и AI-агентов для обеспечения долгосрочного, персонализированного и контекстно-зависимого взаимодействия между сессиями.

• Получите бесплатный API-ключ здесь: app.mem0.ai
• или разверните mem0 самостоятельно из открытого GitHub-репозитория.

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot