Lockstep предлагает проверять MCP-память двумя агентами

Память агента не подтверждает актуальность решения

Lockstep в материале о MCP-серверах памяти для команд, работающих с AI-агентами для программирования, предлагает смотреть на память шире, чем на функцию сохранения и поиска текста. Сервер может исправно записывать заметки и возвращать их по запросу, но команда всё равно рискует получить неверный ответ о принятом техническом решении.

Пример из материала: один агент помнит, что сервис использует ключи идемпотентности, а другой находит старую заметку о том, что повторные попытки небезопасны. Оба фрагмента могут быть доступны в памяти, но сами по себе они не объясняют, какая позиция действует сейчас. Для работы над кодом этого недостаточно: агенту важно отличить действующее решение от отменённого, ограниченное правило — от общего и личную заметку — от командной договорённости.

Польза такого подхода для команды в том, что проверка смещается с вопроса «умеет ли инструмент искать?» к более прикладному: «вернёт ли новый сеанс агента утверждённый ответ после изменения решения?» Именно эту проверку Lockstep предлагает провести до развёртывания выбранного сервера.

Инструменты разделены по типу задачи

В обзоре официальный эталонный сервер MCP Memory описан как небольшой локальный граф знаний. Его предлагают рассматривать для прозрачных экспериментов, где важна понятная работа с данными на своей машине.

Basic Memory ориентирован на заметки в Markdown, ссылки и поиск. В материале он представлен как вариант для локального или общего облачного рабочего пространства, в котором люди и агенты редактируют одни и те же записи. Такой формат делает знания читаемыми для команды, но не снимает вопроса о противоречащих заметках.

Mem0 MCP в источнике отнесён к размещённому семантическому поиску между разными клиентами. Среди перечисленных клиентов — Claude Code, Cursor, Codex, Windsurf и VS Code. Graphiti MCP, в свою очередь, предназначен для фактов и связей, меняющихся со временем, через временной граф знаний.

Отдельно Lockstep противопоставляет этим вариантам слой решений. В такой записи, по версии компании, должны быть указаны владелец, статус, обоснование, отвергнутые альтернативы и область влияния решения. Это важно не как ещё один формат хранения, а как способ показать, что именно было принято и при каких границах оно работает.

Что проверить на реальной передаче задачи

Материал рекомендует не выбирать сервер только по описанию возможностей. Вместо этого нужно провести тест на настоящей передаче контекста между двумя агентами. Первый критерий — может ли агент записать контекст без специальной связки или дополнительной кастомной логики.

Затем следует открыть новый сеанс и проверить, находит ли он нужную память. Отдельно нужно убедиться, что персональный контекст не смешивается с командным. Для совместной разработки это принципиально: личные рабочие заметки и решения, на которые опирается вся команда, имеют разный статус.

Ещё два пункта касаются изменений. Команда должна проверить, можно ли исправить или удалить устаревший факт, а также способен ли человек понять, какая запись действует и одобрена. В источнике подчёркивается: семантическая близость записи к запросу не говорит ни об утверждении, ни об области применения, ни о том, что более новая запись заменила старую.

Практический сценарий перед запуском

Lockstep предлагает простой двухагентный прогон. Сначала один клиент сохраняет настоящее архитектурное решение. Затем второй клиент в свежем сеансе должен его найти. После этого решение меняют по обычному для команды пути согласования и повторяют запрос с обеих сторон.

Критерий успеха здесь не сводится к тому, что обе версии решения остаются доступными. Оба агента должны возвращать новый ответ, а не представлять старую и новую заметки как одинаково применимые. Такой тест позволяет увидеть разрыв между хорошим поиском по истории и управлением текущей договорённостью.

Выбор инструмента в этой логике зависит от конкретной потребности: локального блокнота, общей базы знаний, размещённого поиска, графа изменений во времени или журнала решений. Материал не сводит эти сценарии к одному универсальному серверу.

Ограничения материала

Это сравнительный материал, опубликованный Lockstep и содержащий позиционирование собственного продукта как слоя для фиксации решений. Исходник описывает критерии и сценарий проверки, но не приводит результаты независимого теста перечисленных серверов, не сопоставляет их по единой таблице и не показывает, как они ведут себя в конкретной команде.

Дата публикации в исходнике указана как 24 сентября 2026 года. В предоставленном материале нет дополнительных подтверждений даты и заявлений о продуктах. Поэтому рекомендации стоит воспринимать как редакционный пересказ подхода автора: перед внедрением необходима собственная проверка на рабочих решениях, передаче контекста и процедуре их обновления.