Экосистема AI Vibe
RAG против памяти агента: два слоя вместо ложного «или-или»
Соло-сборщик агента в IDE упирается не в размер контекстного окна, а в границу между read-only выборкой из репозитория и тем, что агент должен помнить между сессиями. В свежем разборе @plur9 жёстко разводит RAG и agent memory — для схемы без отдельного слоя памяти это архитектура, а не модная метка.
Почему спор «RAG vs agent memory» зацепил сборщиков агентов
Формат «против» здесь не ради холивара: в ленте opensource всплыл explainer на семь минут чтения, где явно разведены read-only retrieval и read-write learning. RAG на query time тянет пассажи из фиксированного корпуса документов, а agent memory копит то, чему агент научился во взаимодействиях, и обновляет это со временем. Многим агентам нужны оба механизма — не замена одного другим, а связка слоёв.
Для тех, кто собирает coding agent или MCP-обвязку вокруг LLM, это бьёт в практику: индекс по коду закрывает «где определена функция», но не закрывает «какой стиль кода предпочитает этот разработчик».
Два слоя: знания из корпуса и опыт из диалога
Архитектура раскладывается на knowledge layer (RAG) и experience layer (agent memory). Первый слой — документы, код, справочники: поиск и цитирование на момент запроса. Второй — предпочтения, исправления, решения, накопленный опыт с пользователем.
Наглядный пример coding agent: RAG находит определение функции в репозитории, а agent memory помнит, что пользователь предпочитает функциональный стиль вместо OOP. Когнитивная аналогия в тексте — semantic memory (RAG) против episodic/procedural memory (agent memory); метафора «библиотека» против «блокнота, в который агент пишет».
Память агента — не «RAG с лишними шагами», а отдельный контур с операциями Capture → Store → Retrieve with context → Update and forget, которых у read-only retrieval нет как у единого пайплайна.
Четыре ограничения RAG, которые не лечит ещё один векторный индекс
Разбор перечисляет структурные дыры RAG для агентов — и каждая бьёт по соло-схеме с IDE-агентом:
- Нет обучения на коррекциях. Фраза «мы используем Vitest, не Jest» не попадает в retrieval pipeline; в следующей сессии та же ошибка возможна.
- Нет персистенции предпочтений. Tabs vs spaces, выбор PostgreSQL, deprecated API — это не документы в корпусе.
- Нет forgetting/decay. Старая и новая документация (Jest → Vitest) в индексе retrievable с равным весом; agent memory может моделировать забывание (в тексте — ACT-R-inspired time-based decay).
- Нет feedback loops. RAG — one-shot retrieve; память агента может замыкать петлю positive/negative/neutral сигналов для качества recall.
Практический риск read-write слоя тоже назван: без decay память копит устаревшее. Забывание здесь — design feature, а не баг.
Ландшафт инструментов: от LangChain до MCP и YAML-памяти
Исполняемого кода в материале нет — только сравнительные таблицы. Роли проектов сводятся так: LangChain и LlamaIndex — RAG в core, memory-модули частично; Mem0, Letta (бывш. MemGPT), Zep/Graphiti, Cognee и PLUR смещены в сторону agent memory с разными форматами хранения — vector store, agent state blocks, temporal knowledge graph, собственная data model, human-readable YAML.
Отдельный акцент — MCP (Model Context Protocol): в тексте ссылка на спецификацию 2025-11-25 как открытый транспортный слой. PLUR (open-source Apache-2.0, репозиторий github.com/plur-ai/plur) позиционируется как engram engine с YAML-памятью, которую можно открыть, diff-нуть и version-control — в противовес opaque vector/state blocks у части конкурентов. Автор — @plur9, сравнительную таблицу стоит читать с учётом его позиции.
Академические якоря: Lewis et al., 2020 (RAG, NeurIPS 2020, arXiv:2005.11401); обзор RAG Gao et al., 2023 (arXiv:2312.10997); обзор memory-механизмов Zhang et al., 2024 (arXiv:2404.13501); MemGPT Packer et al., 2023 (arXiv:2310.08560) — через идею core memory в окне и archival memory по запросу.
Когда что включать: матрица для агента в IDE
Прямая матрица выбора:
| Потребность | Что брать |
|---|---|
| Поиск и цитирование фиксированного корпуса, Q&A по codebase/docs/wiki | RAG |
| Предпочтения пользователя между сессиями, не повторять исправленные ошибки | Agent memory |
| Отслеживать изменение фактов во времени | Agent memory (в тексте — Zep как temporal, PLUR как decay-based) |
| Inspect/edit того, что «знает» агент | Agent memory с открытым форматом (в материале — PLUR) |
| Оба сценария одновременно | RAG и agent memory |
По latency оба механизма делают retrieval на query time; write, decay и feedback у agent memory — фоновые операции, не обязательно на inference path. Заявление Zep о sub-200ms retrieval для temporal KG — пересказ без независимого бенчмарка в материале.
Вывод для соло-разработчика с агентом в IDE: RAG заменяет agent memory только если агент никогда не должен помнить предпочтения и коррекции между сессиями. Во всех остальных случаях вопрос не «что выбрать», а куда класть факт — в индекс документов или в персистентную память с возможностью обновления и забывания.
Источники
- @plur9 — What's the Difference Between RAG and Agent Memory? — Dev.to, опубликовано 2026-07-12; дата доступа: 2026-07-12 (UTC).
- PLUR: github.com/plur-ai/plur — упомянут в первоисточнике; дата доступа: 2026-07-12 (UTC).