Pantry на Go: решение проблемы амнезии AI-агентов без Python и зависимостей

Амнезия AI-агентов: болезнь, которую никто не лечит

Вы работаете с AI-агентом над проектом два часа. Обсудили архитектуру, выбрали стек, настроили конфигурацию. Закрываете сессию. Открываете завтра. И ваш агент спрашивает: "Какую архитектуру мы выбрали для проекта?" Как будто вчерашних восьми тысяч токенов диалога не было.

Типичное решение? Пишете в чате "помни, что мы выбрали микросервисы на Go с PostgreSQL". Каждую сессию. Каждый день. Это раздражает. Это тратит токены. Это убивает продуктивность.

Pantry: не просто хранилище, а долгосрочная память

Pantry — это минималистичное хранилище ключ-значение, написанное на Go. Но не путайте его с очередным Redis-клоном. Его создали специально для AI-агентов. Для тех случаев, когда нужно сохранить контекст проекта между сессиями. Когда агент должен "помнить", что вы делали вчера.

Как это работает на практике

Допустим, вы работаете над веб-приложением. Ваш AI-агент помогает с кодом. В процессе он узнает:

• Вы используете React 19 с TypeScript 5.8
• Бэкенд на Go 1.24 с фреймворком Fiber
• База данных — PostgreSQL 17 с расширением pgvector
• Авторизация через JWT с 24-часовым сроком
• Деплой на Fly.io с контейнерами

Без Pantry эта информация "живет" только в контексте текущей сессии. Закрыли чат — забыли. С Pantry агент сохраняет эти детали в хранилище. В следующий раз, когда вы спросите "как добавить новую endpoint?", он уже знает контекст вашего стека.

Почему Go, а не Python? История одного разочарования

До Pantry был Echovault — аналогичное решение на Python. Работало. Но с оговорками.

Главная боль Echovault? Зависимости. Вы устанавливаете его на свежий сервер, а там конфликт версий Python. Или не хватает libssl. Или redis-py несовместим с вашей версией Redis. Знакомо? Pantry убивает эту проблему напрочь.

Скомпилированный бинарник — это свобода

Скачиваете бинарник для своей архитектуры (amd64, arm64, даже riscv). Даете права на выполнение. Запускаете. Всё. Никаких:

• "pip install -r requirements.txt"
• "python -m venv venv"
• "export PYTHONPATH=..."
• "uvicorn не найден"

Особенно ценно, когда вы настраиваете окружение для AI-агентов через ABC-Bench. Вместо танцев с бубном вокруг Python-зависимостей — один файл.

Установка и запуск: проще некуда

Для Linux/macOS:

# Скачиваем последнюю версию (актуально на 20.02.2026)
curl -L https://github.com/yourusername/pantry/releases/download/v2.1.0/pantry-linux-amd64 -o pantry
chmod +x pantry

# Запускаем на порту 8080
./pantry --port 8080 --data-dir ./pantry-data

Для Docker (если всё-таки любите контейнеры):

docker run -d -p 8080:8080 -v ./pantry-data:/data yourusername/pantry:2.1.0

Интеграция с AI-агентами: как заставить Claude помнить

Вот где начинается магия. Ваш AI-агент (Claude Code, Cursor, или кастомный агент на платформе с stateful memory) может сам решать, что сохранять.

Пример промпта для Claude:

Когда мы принимаем важные архитектурные решения (стек технологий, структура проекта, ключевые конфигурации), сохрани их в Pantry. Используй ключи в формате "project:{project_name}:{category}". Например, "project:myapp:backend_stack" или "project:myapp:deployment_config".

Агент учится сам определять, что "важно". Архитектура — важно. Имя временной переменной — не важно. Конфигурация базы данных — важно. Отступы в коде — не важно.

API настолько простой, что его поймёт даже AI

Pantry предоставляет REST API:

• POST /store/{key} — сохранить значение
• GET /get/{key} — получить значение
• DELETE /delete/{key} — удалить
• GET /keys?prefix=... — список ключей по префиксу

AI-агент может использовать это через простые HTTP-запросы. Никаких сложных клиентов. Никаких схем. Просто JSON туда и обратно.

Сравнение с другими решениями: когда Pantry выигрывает, а когда проигрывает

Pantry — не серебряная пуля. У него есть своя ниша.

Когда Pantry идеален:

• Локальная разработка с AI-агентами (Claude Code, Cursor)
• Небольшие проекты, где не нужен полноценный Redis
• Сценарии, где важна простота развёртывания
• Контейнерные среды без Python (чистые Alpine-образы)
• Образовательные проекты, где студенты не должны настраивать сложное окружение

Когда лучше выбрать что-то другое:

• Высоконагруженные продакшн-системы (берите Redis 8.0 или KeyDB)
• Сложные структуры данных (хеши, списки, множества)
• Кластеризация и репликация (у Pantry пока нет)
• Транзакции и атомарные операции

Реальные примеры: от забывчивого к внимательному агенту

1 Разработка микросервиса

День 1: Вы с агентом проектируете микросервис для обработки платежей. Выбираете Go, PostgreSQL, RabbitMQ для очередей, JWT для авторизации. Агент сохраняет это в Pantry под ключом project:payments:architecture.

День 2: Вы спрашиваете "как добавить retry логику для RabbitMQ?" Агент сначала читает из Pantry, узнаёт, что у вас RabbitMQ, и предлагает решение с dead letter exchange. Без Pantry он мог бы предложить решение для Redis Streams или Kafka.

2 Миграция проекта

Вы переносите проект с Express.js на Fastify. Агент сохраняет в Pantry: project:api:migration_target=fastify. На следующий день, когда вы спрашиваете про middleware, агент уже знает, что нужно предлагать решения для Fastify, а не для Express.

3 Командная работа

В команде три разработчика работают с одним агентом. Каждый добавляет в Pantry свои контексты: user:alex:prefers_tests=true, user:maria:prefers_docs=true. Агент адаптирует ответы под предпочтения каждого.

Под капотом: почему это работает быстро

Pantry написан на чистом Go без внешних зависимостей. Использует:

• sync.Map для конкурентного доступа (вместо мьютексов)
• JSON для сериализации (стандартная библиотека)
• Встроенный HTTP-сервер из net/http
• Дисковое хранилище через boltDB-совместимый формат

Это тот случай, когда простота — это фича, а не баг. Нет сложных конфигураций. Нет orchestration-логики. Просто хранилище, которое "просто работает".

Кому подойдёт Pantry (а кому — нет)

Берите Pantry, если:

• Устали каждый раз объяснять агенту контекст проекта
• Работаете с Claude Code или Cursor ежедневно
• Ненавидите настраивать Python-окружение на новых машинах
• Нужна "долгосрочная память" для небольших проектов
• Цените минимализм и простоту

Не берите Pantry, если:

• Вам нужны сложные запросы и агрегации
• Проект масштабируется на десятки нод
• Уже есть инфраструктура с Redis или PostgreSQL
• Нужны гарантии сохранности данных (Pantry пока не имеет репликации)
• Работаете с локальными агентными AI, которые требуют сложной state-логики

Что дальше? Будущее памяти AI-агентов

Pantry решает конкретную проблему здесь и сейчас. Но будущее — за семантической памятью. Когда агент не просто хранит ключ-значение, а понимает связи между концепциями.

Представьте: агент сохраняет не только "мы используем PostgreSQL", но и "мы выбрали PostgreSQL потому что нужны джойны, которые неудобны в MongoDB". И когда через месяц вы спросите "а что если перейти на MongoDB?", он вспомнит причину первоначального выбора.

Следующий шаг после Pantry — векторные базы данных для семантического поиска по памяти агента. Но это уже другая история. А пока — просто запустите ./pantry и перестаньте объяснять агенту одно и то же каждый день.

Иронично, но самый простой инструмент часто оказывается самым полезным. Pantry не пытается быть умным. Он просто помнит. А иногда этого достаточно.