MCP memory — это сервер по протоколу MCP, что хранит факты между сессиями работы с ИИ-агентом: договорённости с клиентом, контекст проекта, историю решений, — и агент читает эту память в начале нового диалога вместо повторного объяснения с нуля. Ниже — как устроен такой сервер, какие варианты хранения бывают, какие риски несёт память агента и как подключить это к Claude или Cursor.
Зачем агенту память
Без памяти между сессиями агент забывает контекст диалога сразу после его закрытия — и каждый новый разговор начинается с объяснения одних и тех же фактов о проекте или клиенте заново; MCP memory решает эту задачу отдельным сервером, к которому агент обращается по протоколу MCP.
Контекст клиента — что он уже обсуждал, какие решения приняты, на чём остановились в прошлый раз. Факты о проекте — структура, договорённости, ограничения, что держатся неизменными от сессии к сессии. Без такой памяти агент каждый раз стартует с чистого листа, и человек заново пересказывает то же самое — минут пять-десять на разговор по нашему опыту внедрений, что накапливается за месяц в заметный объём времени команды.
Условный пример: консультант ведёт диалог с клиентом несколько недель подряд с перерывами в несколько дней между сессиями — без памяти агент каждый раз уточняет одни и те же вводные вроде бюджета, сроков и уже опробованных вариантов, и клиент замечает повтор быстрее, чем кажется.
Как устроен сервер
Сервер памяти по протоколу MCP — это хранилище фактов и набор инструментов для записи и чтения, к которым агент обращается во время диалога. Агент присылает запрос — сохранить факт, найти похожий по смыслу, обновить устаревшую запись, — сервер отвечает результатом, и это происходит прозрачно для человека внутри обычного диалога с моделью.
Инструменты сервера обычно делятся на запись (сохранить факт, обновить запись) и чтение (найти факт по запросу, получить список фактов по теме) — агент вызывает их автоматически внутри диалога, человек в этот момент продолжает обычный разговор без переключения в отдельный интерфейс.
Термин и общее устройство протокола — в глоссарии MCP, а конкретно про память агента — в глоссарии памяти агента. Подключение сервера к Claude разобрано пошагово в статье как подключить MCP к Claude.
Варианты хранения
| Вариант | Что подходит | Ограничение |
|---|---|---|
| Граф знаний | факты со связями между собой — клиент, проект, договорённость | сложнее настроить с нуля, чем простое хранилище |
| Векторная база | поиск по смыслу вместо точного совпадения слов | требует отдельного сервиса и регулярного обновления индекса |
| Простые заметки | короткие факты без сложных связей, быстрый старт | плохо масштабируется на большой объём и долгую историю |
Выбор варианта зависит от объёма фактов и от того, ищет агент точное совпадение или смысловую близость. Для отдела с десятком клиентов и коротким списком договорённостей простых заметок обычно хватает; для агента, что держит историю сотен диалогов, — граф знаний или векторная база.
Условный пример: отдел поддержки на пять человек с полусотней активных клиентов обходится простыми заметками — фактов немного, и связи между ними редкие. Агентство с полутысячей диалогов в истории и вопросом вроде «что похожего обсуждали с клиентом из смежной отрасли» уже упирается в поиск по смыслу, а значит — в векторную базу.
Риски и границы
- Персональные данные в памяти агента — имена, контакты, детали клиента хранятся дольше одного диалога, и это требует отдельного внимания к доступу и хранению.
- Устаревшие факты — договорённость поменялась, а память держит старую версию; без правила на обновление агент выдаёт противоречивый ответ.
- Конфликт версий — два источника факта расходятся между собой, и агент выбирает один из них без явного правила приоритета.
- Разросшаяся память без структуры — чем больше фактов накоплено без категорий, тем труднее агенту найти релевантный среди лишних.
Практика, что снимает часть риска, — хранить в памяти агента факты о проекте и решениях, а персональные данные клиента держать в отдельной системе с ограниченным доступом и ссылаться на запись по идентификатору вместо копирования имени и контактов в каждую заметку.
Какие факты о клиентах теряет ваша команда между разговорами?
Подключение к агенту
- Выбрать вариант хранения под объём фактов — заметки, граф знаний или векторную базу.
- Настроить сервер памяти и подключить его к Claude или Cursor по протоколу MCP.
- Задать правило на обновление устаревших фактов — вручную или по расписанию.
- Ограничить доступ к серверу памяти списком людей, что работают с чувствительными данными клиента.
- Проверить на тестовом диалоге — агент вспоминает факт из прошлой сессии без повторного объяснения.
- Настроить резервное копирование памяти, чтобы история фактов переживала потерю сервера и последней сессии.
Условный пример на проверку риска устаревших фактов: клиент сменил тариф месяц назад, а память агента до сих пор хранит старую договорённость — при следующем разговоре агент цитирует условия, что перестали действовать, и человек ловит расхождение только на этапе выставления счёта. Регулярная сверка ключевых фактов с источником снимает этот риск.
На тестовом диалоге проверяют факт правильного ответа и скорость поиска вместе — если сервер памяти ищет по большому объёму записей дольше пары секунд, агент ощутимо задерживает ответ до переноса памяти на всю команду.
Похожие сопутствующие запросы — «mcp search» (поиск по внешним источникам через протокол), «mcp коннектор» (подключение агента к конкретному сервису) и «локальный mcp» (сервер на своей инфраструктуре без облака вендора) — решают соседние задачи вокруг той же памяти агента. На практике эти три сервера часто ставят рядом с памятью в одной связке: search приносит свежие данные снаружи, коннектор подключает к внутреннему сервису, память хранит результат между сессиями.
Внедрение памяти агента для отдела — часть общей настройки ИИ-агента под процесс, разбор подхода и что влияет на объём работ — на странице ИИ-агентов.
На объём работ по настройке влияют три фактора: сколько фактов агент держит одновременно, сколько людей в команде обращаются к общей памяти и насколько часто договорённости меняются. Команда с небольшим числом клиентов и редкими изменениями укладывается в скромную настройку, отдел с сотнями диалогов и частыми обновлениями требует более внимательной структуры хранения с самого начала — здесь разницу между графом знаний и простыми заметками из раздела выше чувствуют быстрее всего.