Многие бенчмарки моделей начинаются с пустого контекстного окна — своего рода tabula rasa искусственного интеллекта. Отчасти это разумно: так бенчмарки остаются честными.
Но реальные агенты не должны начинать с пустого контекста. У них должно быть как можно больше релевантной информации с самого начала работы. AI-агентам нужна память.
Почему существующие системы памяти агентов не работают
Проблема в том, что многие системы памяти агентов работают довольно плохо. Можно выделить три популярных типа таких систем, и каждый не работает по-своему.
Первый тип — системы, которые намеренно привязывают пользователя к конкретной обвязке (harness), обычно написанной той же лабораторией, которая эту обвязку и предоставляет. Лаборатория стремится перейти из высококонкурентного «API-бизнеса» в куда более прибыльный «платформенный бизнес». Такие системы обычно добывают информацию из истории переписки, из-за чего большая часть памяти оказывается о пользователе, хотя информация о мире вокруг обычно куда полезнее.
Второй тип — до нелепости сложные системы. Известна одна заметная система, которой для решения, что стоит запомнить, нужны pgvector, графовая база Neo4j и собственная LLM. Такая сложность не только трудна в администрировании — по причинам, которые будут объяснены ниже, подобные громоздкие системы попросту сбивают модели с толку. К тому же они не масштабируются вместе с развитием фронтира моделей.
Третий тип — «высокомодернистские» системы, представляющие себе идеализированную, рационалистскую форму памяти. Неизбежно это выливается в граф, а иногда и в логические высказывания. Такой подход систематически вырывает информацию из контекста, оставляя её изолированной и бессмысленной как для агента, так и для человека. Насколько, в конце концов, полезен простой список «выжатых фактов»?
Общее у всех трёх подходов — то, что они рассматривают память как процесс. Но память, особенно для модели, гораздо лучше представлена как данные.
Память должна быть форматом данных, а не многоступенчатым пайплайном
Брукс писал:
Покажите мне свои блок-схемы и скройте таблицы — и я буду сбит с толку. Покажите мне таблицы, и мне обычно не понадобятся блок-схемы — они станут очевидны.
Вот формат портативного файла памяти под названием «memoryfield»:
my-memories.memoryfield.zip
├── carbon-fibre-woks.md
├── finnish-bureaucracy-tips.md
├── [... many more md files...]
├── wec-2026-season-notes.md
└── nomic-embed-text-v1.5.sqlite3
Memoryfield — это:
- Markdown-«страницы» с
- (опционально) YAML frontmatter и
- (опционально) SQLite-индексом векторов для семантического поиска
Агенты лучше всего работают с файлами. Дальше — почему.
Решение №1: прозаический текст, а не чанки или «факты»
Главная причина, по которой RAG-пайплайны получаются очень сложными, — попытка сделать массив существующих, написанных людьми документов доступным для чтения AI-агентом. Часто такие документы трудны для прямого чтения агентом — например, потому что это большие PDF.
Но память агента — не сложный легаси-документ. Память в момент формирования возникает непосредственно у AI-агента, который прекрасно способен писать прозу. Такой текст не нужно разбивать на чанки, обогащать, дважды суммаризировать или иначе механически обрабатывать: достаточно дать агенту написать память прямо в его любимом формате — Markdown.
Страница memoryfield выглядит так:
---
title: Carbon Fibre Woks
created: '2026-03-01T09:00:00Z'
updated: '2026-08-22T14:30:00Z'
uuid: 6aa615f0-486f-48a7-a210-ba4f5ff18c8b
summary: Thermal properties of carbon fibre cookware
---
Carbon fibre woks conduct heat evenly, but...
Единственное ограничение — страница должна быть достаточно короткой, чтобы поместиться в векторный эмбеддинг: мягкий лимит составляет около 8 Кб (~2000 токенов).
На практике это скорее полезное ограничение: 8000 символов — это примерно 1300 слов, длина среднего журнального материала. Такое ограничение имело бы смысл вводить и без технической необходимости. Если нужно больше деталей — просто добавляются новые страницы, агентам это не в тягость.
Решение №2: семантический прыжок, а не обход графа
Важным прототипом стали Karpathy wikis — вики на основе гиперссылок между Markdown-файлами по образцу Roam или Obsidian. Идея заключалась в том, что агент будет обходить «граф знаний» в поисках релевантных страниц.
Но на практике обход графа знаний AI-агентом получается медленным, ненадёжным и к тому же сбивает агента с толку.
Обход происходит медленно, потому что модели приходится часто останавливаться для последовательных вызовов инструментов, чтобы прочитать очередную страницу.
Примерный алгоритм обхода графа знаний агентом:
- Прочитать главную страницу вики [вызов инструмента]
- найти релевантные ссылки
- Прочитать связанную страницу(ы) [вызов инструмента]
- найти релевантные ссылки
- Решить, достаточно ли найдено релевантной информации
- если нет — вернуться к шагу 2
Если релевантная информация находится на глубине N шагов в графе знаний, для её получения требуется N+1 вызовов инструментов. Это медленно, поскольку миллиардной (а то и триллионной) по стоимости LLM-модели приходится приостанавливаться на каждом вызове — а каждый занимает 2-3 секунды. Это сильно штрафует глубоко вложенные графы знаний, что, откровенно говоря, противоречит самому смыслу их существования.
Графы знаний также ненадёжны. AI может судить о релевантности материала только по тексту ссылки или, может быть, заголовку страницы, если он вынесен наружу. Это создаёт большое давление на автора — приходится заниматься метаданными страниц в духе SEO 1990-х, чтобы текст ссылки, заголовок или подпись каждой страницы были броскими и точными. Это наказывает за отступления, за фиксацию побочных деталей и за тот неявный контекст, который обычно распространён и очень полезен в больших текстовых корпусах.
На практике в Karpathy wikis релевантная информация часто пропускается, потому что она не озаглавлена или не подписана достаточно привлекательно для ищущего агента.
Кроме того, графы знаний сбивают агента с толку, потому что при обходе графа он вынужден просматривать много нерелевантной информации. Непроизвольное чтение нерелевантной информации (часто главный виновник — главная страница) добавляет в контекстное окно модели шум, снижает качество вывода и заставляет модель выглядеть зациклившейся на странных деталях.
Всё это решается использованием семантического поиска, который позволяет прыгнуть прямо ко всем релевантным страницам (на основе реального содержимого, а не метаданных страницы) и дать агенту прочитать все релевантные страницы сразу, параллельно — большинство современных моделей уже способны на это. Таким образом, в memoryfield требуется не более двух вызовов инструментов: первый для поиска, второй — для параллельного чтения. Релевантная информация находится, а количество нерелевантных входных токенов минимизируется.
Решение №3: больше модели, меньше механики
Одна из проблем «высокомеханистичных» систем памяти — тех, что включают множество специально написанных API или баз данных — в том, что для их использования агенту нужно продираться через лабиринт интерфейсов ради своей цели. Если интерфейс большой — в контекст загружается увесистый openapi.json. Если маленький — он оказывается ограниченным. Даже если баланс верный, часто сам API оказывается неудачным: вспомните, как приходилось пользоваться чужим API, автор которого не предусмотрел ваших потребностей. Понравилось?
Memoryfields — система «низкой механики» (по сути, просто формат файла) — дают агентам гораздо больше свободы придумывать собственные паттерны доступа к данным. Хотя предоставляется и (надеюсь, полезный) инструментарий, агенты полностью вольны использовать любые удобные им способы работы. Например, применять perl для поиска и замены по всему корпусу или встраивать инлайн CSV-файлы внутрь памяти, а затем запрашивать их через SQLite (оба примера реально наблюдались на практике).
«Низкая механика» также означает, что memoryfields масштабируются вместе с фронтиром моделей. Чем лучше становятся модели, тем больше идей возникает у агентов. Один из недавних прорывов — модели неожиданно оказались очень хороши в bash. Они также хороши в Markdown. И в SQLite. Одна из причин, почему memoryfields хорошо работают внутри реальных агентов, — агенты фундаментально способны «понять», что происходит, на основе своих обучающих данных (это всё, что у них есть, пока они не начнут читать свою память) — в отличие от бестелесного вызова LLM внутри отдельного «пайплайна памяти».
По мере улучшения моделей они автоматически начинают писать память немного умнее. Системы памяти типа «прицепного вагона» редко на это способны — не так много способов творчески использовать фиксированный набор API-эндпоинтов. А memoryfields будут масштабироваться вместе с фронтиром моделей.
Решение №4: открытый формат, взаимозаменяемость, независимость от транспорта
Со временем коллекция памяти агента становится всё более ценной — накопленное сокровище извлечённых уроков и добытых фактов. Никому не хочется быть привязанным к конкретной обвязке, модели или агенту.
Написан RFC-подобный спецификационный документ формата файла — в основном чтобы убрать неоднозначности и не привязывать формат к конкретной функции эмбеддинга.
По одной только спецификации при желании можно накодить нужный инструментарий с помощью AI. Но также предоставляется skill и оптимизированная под агентов утилита командной строки.
Каноническим «архивным» форматом memoryfield является zip-файл — это максимально упрощает обмен данными. Но спецификация намеренно оставлена открытой для раздачи с локальных файлов, Amazon S3, GitHub или по HTTP. По сути, подходит всё, что работает с файлами. Лично используется смесь этих транспортов: Syncthing для личных memoryfields, S3 — для тех, что расшариваются с другими.
Как начать
Можно поручить агенту скачать SPEC.md и накодить реализацию самостоятельно, но, вероятно, проще начать с готового инструментария:
# Requires: ollama, uv and npx (comes with npm)
#
# 1. Pull the embedding model:
ollama pull nomic-embed-text
# 2. Install the CLI tool:
uv tool install git+https://github.com/calpaterson/memoryfield-tool
# 3. Install the skill:
npx skills add calpaterson/memoryfield-skill -g -y
Дальше агент сам поможет настроить всё необходимое.
Для тестового ознакомления можно взять демонстрационный memoryfield — soapstones.memoryfield.zip. Soapstones — более ранний проект по памяти агентов, и этот отобранный экспорт содержит немало ценных, компактных памятей о том, как агентам получать доступ к данным (например, как искать в Reddit в роли агента, как использовать Jina Reader, как эффективно читать вики через MediaWiki API).
«Разве это не просто RAG» — и другие частые вопросы
Разве это не просто RAG?
Термин «RAG» сейчас трактуется чрезвычайно широко — как только агент извлекает какие-то данные, считается, что «произошёл RAG». В этом смысле — да, это некоторая форма RAG.
Но почти все агенты извлекают данные — например, при поиске в интернете. При этом большинство техник, которые обычно ассоциируются с «RAG-системой», здесь отсутствуют: нет чанкинга, нет ре-ранкинга, нет гибридного поиска.
Другая сторона вопроса — memoryfields пишут сами агенты. RAG-системы обычно про чтение, а memoryfields — ещё и про запись.
Разве
nomic-embed-text-v1.5не старше двух лет? Разве нет более новых и лучших моделей?
Модели эмбеддинга не такие большие, как фронтирные модели, и не развиваются так же быстро. nomic-embed-text-v1.5 остаётся хорошим балансом между компактностью и мощностью. Она достаточно мала (270 МБ) и быстра, чтобы работать без GPU, и является широко популярной, часто рекомендуемой моделью эмбеддинга по умолчанию.
Впрочем, спецификация допускает использование и другой модели эмбеддинга.
Как понять, что стоит запоминать? Как не забить память мусором?
Это частый страх для систем памяти, но к memoryfields он почти не относится. Нерелевантный материал просто никогда не всплывает при семантическом поиске. Нерелевантные записи занимают место — да, возможно, стоит периодически проводить чистку, — но они никак не мешают работе агента.
Для лучшего результата: добавляйте память щедро. Единственный совет: память работает лучше всего, если включает ссылки на источники, в идеале в виде URL. Это помогает при будущих проходах усиливать записи и позволяет агентам проверять факты в устаревших или подозрительных материалах.
А как насчёт безопасности? А что насчёт «Забудь предыдущие инструкции!»?
Нельзя делиться своим контекстным окном, в том числе через память, со сторонами, которым вы не доверяете.
Одна из причин, по которой спецификация включает статичный zip-формат — возможность вручную проверять и фиксировать (через sha256sum) memoryfields, полученные от других.
При этом до сих пор не существует способа заставить агента отличить «хороший промпт» от «злого промпта».
Сначала данные
Теперь, когда блок-схема стала очевидной, можно сформулировать её явно:
- Написать память в виде Markdown
- Вычислить эмбеддинг и сохранить вектор в SQLite
- Искать семантически, чтобы находить память заново
Memoryfields необычны как система памяти в том, что они задают структуру данных, а не процесс. Здесь нет пайплайна извлечения, нет фоновых обрабатывающих сервисов, нет ничего подключаемого — вообще ничего. Есть векторный индекс, но это удаляемый кэш, а не сама система.
Память — это данные! Чем меньше фиксированной механики стоит между агентом и этими данными, тем лучше может работать агент.