Создание PM-агента с Claude API и устойчивой памятью

Май 2026 · чтение 11 мин · Fran Olivares, основатель OlivaresAI

Агент управления проектами на Claude API и устойчивой памяти Alma отслеживает стейкхолдеров, решения, SLAs и заметки standup'ов между днями и неделями, не теряя контекста. Архитектура состоит из четырёх частей: цикл разговора Claude, хранилище памяти, ключ-сущность проекта, экстрактор, который вытягивает структурированные записи из каждого чата, и context-assembler, который вставляет правильный срез в каждый промпт. Устойчивая память превращает Claude из умного инструмента для черновиков в агента, который помнит, что команда решила в прошлый вторник.

Управление проектами — это в основном работа с памятью. Кто владеет этим потоком? О чём мы договорились о окне миграции? Почему мы убрали rate limiter из объёма? Когда юридическое ревью блокирует релиз? Агент, которому приходится повторно задавать эти вопросы каждое утро — это не агент, это просто чуть более быстрый стажёр. Способ изменить это — дать модели слой устойчивой памяти, который она может читать и записывать между ходами, заполняемый автоматически из разговора. Это руководство проходит через эталонную архитектуру и код интеграции, используя Anthropic Claude API как LLM и REST API Alma как слой памяти.

Почему PM-агенту специально нужна устойчивая память?

Три структурные причины. Первая, сущности, которые отслеживает PM (люди, решения, deliverables, SLAs, риски), сами по себе долговечны — они переживают любой отдельный разговор по определению. Вторая, разговорный стиль высокочастотный и низкоусильный: короткие standup-сообщения, быстрые уточнения, вопросы «что мы говорили про X?». Загрузка правильного среза контекста дёшево имеет значение. Третья, цена забывания высока: пропущенное решение становится пропущенным релизом, забытая зависимость становится блокером.

Stateless-разговор с Claude хорошо справляется с одной сессией планирования. Как только пользователь хочет непрерывности («вчера мы договорились…», «что блокирует auth-команду на этой неделе?»), разговор должен либо повторять всю историю в окно контекста (дорого, в итоге невозможно), либо полагаться на слой памяти вне модели.

Как выглядит эталонная архитектура?

Четыре движущиеся части:

Как структурировать категории памяти для PM-агента?

Пять категорий покрывают большинство команд: stakeholder (люди с ролью + обязанностями), decision (что было согласовано, когда, кем, с обоснованием), sla (обязательства перед другими командами или клиентами), risk (открытые проблемы с владельцем + смягчением), milestone (целевая дата + объём + статус). Каждое memory несёт оценку важности, чтобы assembler мог приоритизировать высокоставочные элементы при извлечении.

Категория не просто для организации — это часть сигнала извлечения. Когда пользователь спрашивает «что мы решили?», assembler взвешивает memories категории decision выше. Когда они спрашивают «кто заблокирован?», memories категории risk поднимаются. Сборка контекста Alma открывает веса повышения для каждой категории именно для этого сценария.

Как выглядит цикл интеграции в реальном коде?

Три фазы на сообщение пользователя. Псевдокод ниже использует Node.js с Alma SDK и Anthropic SDK, но та же форма работает в Python или любом другом стеке:

Фаза 3 работает в фоне — пользователь видит стримящийся ответ немедленно, а извлечение происходит в следующие ~1 с без блокировки. Новые memories дедуплицируются, противоречия обнаруживаются против существующих записей, и хранилище остаётся чистым автоматически. Полная справка по SDK: @olivaresai/alma-sdk; HTTP-эквиваленты в документации REST API.

Как агент справляется с изоляцией мультипроекта?

Используйте environments Alma: один environment на проект. У каждого environment свои memories, episodes, procedures и Soul-блоки, полностью изолированные от других. Агент передаёт environmentId на каждый вызов памяти; API обеспечивает границу. Межпроектные запросы просто невозможны без явного переключения environment — это правильное значение по умолчанию для PM-инструмента, где утечка решений из проекта A в проект B — реальная проблема.

Для командных PM-агентов (несколько людей взаимодействуют с одним агентом) используйте ресурс Alma teams: у каждой команды есть общие memories, видимые всем участникам, плюс per-user memories для личных предпочтений. Доступ на основе ролей контролирует, кто что может писать.

Как выглядит ежедневный standup-ход от начала до конца?

Сообщение пользователя: «standup: backend-команда, Maria сегодня разблокирует миграцию, José на rate limiter; мы решили перенести GA-релиз на пятницу, потому что legal всё ещё проверяет DPA». Поток агента:

Распространённые workflows, о которых стоит помнить

Археология решений. «Почему мы убрали rate limiter из объёма?» — агент извлекает decision memory плюс окружающий episode и risk memory, на который оно ссылалось. Возвращает ответ со ссылками на записи, чтобы пользователь мог углубиться в разговор при необходимости.

Поиск стейкхолдера. «Кто владеет миграцией?» — прямой запрос памяти против категории stakeholder, возвращает запись. Если ответ устарел (роль изменилась на прошлой неделе), обнаружение противоречий ловит это на следующем разговоре, упоминающем нового владельца.

Генерация повторяющегося отчёта. «Сгенерируй статус-отчёт для auth-потока за эту неделю» — агент собирает окно контекста из episodes, decisions и risks, помеченных для этого потока, затем составляет отчёт из этого подобранного среза. Это значительно дешевле и точнее, чем просить Claude резюмировать сырую историю чата.

Как держать системный промпт маленьким, оставаясь обоснованным?

Бюджеты tokens по умолчанию в assembler: ~2 K tokens для memories, ~1 K для episodes, ~500 для procedures, ~500 для Soul-блоков. Итого ~4 K — значительно ниже любого бюджета контекста модели, и cache-попадания амортизируются между разговором. Если Ваш проект маленький (<100 активных memories), Вы можете снизить бюджет дальше. Если он большой (10 K+ memories), assembler остаётся на ~4 K, потому что извлечение ограничивает количество включаемых записей, даже когда хранилище большое.

Две вещи имеют значение операционно: Soul-блоки (идентичность агента) должны кэшироваться как стабильный префикс системного промпта, чтобы повторные вызовы не оплачивали повторно input tokens; и динамический контекст (memories + episodes) должен находиться после cache breakpoint, чтобы каждый вызов загружал заново только изменённую часть. Документация Anthropic по prompt-caching покрывает размещение breakpoint.

Сколько это стоит на практике?

На типичном потоке PM-команды (~20 сообщений/день на пользователя, в основном standup'ы + уточнения) маржинальная стоимость доминируется самими вызовами LLM. Слой памяти добавляет: один assemble-вызов (несколько KB чтения + извлечения, ~30 ms), один extract-вызов (Haiku, ~$0.001 за ход). Общие накладные расходы памяти за день на активного пользователя: значительно меньше цента. Сравните со стоимостью того, что PM-команда не теряет решений — и математика очевидна.

Как начать прототипирование?

Тариф Starter Alma ($14/month) — это начальный уровень и включает слой устойчивой памяти. Зарегистрируйтесь на alma.olivares.ai, сгенерируйте API-ключ в «Настройках» и склонируйте SDK-стартер со страницы для разработчиков. Подключите трёхфазный цикл в коде Вашего агента, направьте его на один тестовый проект и запустите на неделю. Хранилище заполнится естественно из разговоров; Вы увидите, как решения, стейкхолдеры и риски накапливаются без ручного ввода данных. Отсюда это просто крутить вверх категории и настраивать assembler.

Связанное чтение: Устойчивая память для AI: полное руководство 2026 · Как дать AI устойчивую память · Трёхуровневая архитектура памяти · Документация по сборке контекста · Environments.

See plans