Готовый AI-ассистент отвечает на отдельный вопрос и проваливается на другом измерении: непрерывности. Каждый разговор начинается с нуля, а груз повторного объяснения контекста ложится на пользователя. Публикация AWS от 6 октября 2026 года Building a context-aware AI assistant on AgentCore and OpenClaw показывает рабочую сборку, где этот разрыв закрывается: open source агентная система OpenClaw запускается на AgentCore runtime (возможность Amazon Bedrock AgentCore), а управляемая память AgentCore memory превращает одноразовые чаты в долговременные знания.
Короткий ответ, как это собрать: развернуть OpenClaw на AgentCore runtime, подключить AgentCore memory, направить в InvokeAgentRuntime два входных потока (Telegram и расписание) и описать весь стек одним шаблоном AWS CloudFormation. Внутри runtime тонкий процесс server.py связывает OpenClaw gateway, память и Amazon Bedrock Converse API. Записи памяти тегируются структурированными метаданными, чтобы под каждый вопрос подтягивались нужные фрагменты, а не весь архив переписки.
Что это даёт на практике:
- ассистент помнит устойчивые предпочтения и не просит вводить их заново в каждом диалоге;
- запланированные задачи опираются на тот же контекст, что и ответы в чате;
- история превращается в структурированные записи, по которым можно фильтровать выборку.
Почему обычные ассистенты забывают всё между разговорами
Ответы на отдельные вопросы у массовых ассистентов выстроены неплохо, а вот непрерывность хромает: новое окно чата стартует с пустого состояния. Пользователь заново рассказывает, какие у него задачи, привычки и ограничения, и повторяет это каждый раз.
Долговременная память меняет модель работы: ассистент накапливает факты и предпочтения и подставляет их в следующие ответы. В разобранной AWS-сборке за это отвечают две части: open source агентная система OpenClaw на AgentCore runtime и AgentCore memory, которая превращает отдельные чаты в долговременные знания.
Эффект удобно смотреть на сквозном примере публикации, садоводческом ассистенте Sprout. Пользователь спрашивает про сад сегодня, а система помнит, что три недели назад речь шла о приподнятых грядках с быстрым дренажом, что используется только органическое удобрение и что петунии страдали от жары. Без долговременной памяти каждый из этих фактов пришлось бы вводить заново, причём в правильном порядке.
Отдельная ставка сделана на простоту запуска: весь стек живёт в одном шаблоне AWS CloudFormation, разворачивается одной командой и работает по модели оплаты за потребление.
Два слоя памяти: краткосрочные события и долгосрочные факты
Непрерывность требует двух разных вещей: удержать нить текущего диалога и сохранить выводы для будущих. Отсюда два слоя памяти агента.
Краткосрочная память держит события сессии: реплики, вызовы инструментов, их результаты. Долгосрочная хранит факты и предпочтения, которые извлекаются из этих событий асинхронно и живут уже отдельно от конкретного разговора.
Пример: пользователь пишет «поливаю помидоры по утрам». В краткосрочном слое это событие внутри сессии, в долгосрочном - запись «предпочитает утренний полив», которая всплывёт через месяц в другом разговоре, например при настройке напоминаний.
| Слой памяти | Что хранит | Жизненный цикл | Типичный запрос к слою |
|---|---|---|---|
| Краткосрочная | реплики, вызовы инструментов, результаты | в пределах сессии | что обсуждали только что |
| Долгосрочная | факты, предпочтения, выводы | между сессиями | что этот человек предпочитает |
Таблица описывает рабочую модель, а не дословную цитату: в доступном фрагменте публикации AWS детали разделения слоёв не раскрыты. Подтверждено, что AgentCore memory превращает отдельные чаты в долговременные знания и что записи можно тегировать структурированными метаданными. Конкретную схему слоёв, параметры извлечения и правила объединения записей стоит сверять с документацией AgentCore перед сборкой.
Зачем нужны namespace для изоляции пользователей
Namespace делит записи памяти по владельцам: отдельный пользователь, отдельный чат, отдельная рабочая область. Без такого разделения факты двух людей конкурируют за одно место в выборке, и ассистент может приписать одному человеку предпочтения другого.
В мультипользовательском боте рабочая схема выглядит так: каждый Telegram-чат получает собственный namespace, и поиск при сборке контекста идёт только внутри него. Пользователь A не увидит ни данных, ни формулировок пользователя B, даже если оба спрашивают про полив и используют одинаковые слова.
Отдельный namespace имеет смысл держать для запланированных задач, чтобы служебные записи не подмешивались в личную историю и не всплывали в ответах на бытовые вопросы.
Оговорка: в опубликованном фрагменте AWS namespace прямо не упомянуты, поэтому это требование к мультитенантной сборке, а не подтверждённая деталь конкретной реализации.
Индексируемые метаданные для точной фильтрации
Публикация описывает тегирование записей структурированными метаданными, чтобы извлекать те, что важны для текущего вопроса. Без тегов поиск опирается только на семантическую близость, и в контекст попадает лишнее.
Что обычно кладут в метаданные: тип записи (факт, предпочтение, задача), тему (садоводство, полив, удобрения), дату и namespace. Дальше фильтр работает до семантического поиска: вопрос про график полива сужает выборку до темы «садоводство» и типа «предпочтение», а рассуждения о ландшафтном дизайне и история покупок в контекст не попадают.
Эффект двойной: ответ точнее, промпт короче, стоимость запроса ниже.
Архитектура: как OpenClaw работает на AgentCore runtime
Система строится вокруг одного агента, в который сходятся два входных потока: интерактивный из Telegram и плановый по расписанию. Оба вызывают API InvokeAgentRuntime на AgentCore runtime, где управление получает OpenClaw.
Роль server.py: координация OpenClaw, памяти и Converse API
Внутри runtime работает тонкий процесс server.py. Тонкий он потому, что агентной логики в нём нет: она живёт в OpenClaw. Задача server.py - принять вызов, собрать контекст, развести данные по местам и вызвать Amazon Bedrock Converse API для генерации ответа. Схема, которая укладывается в это описание:
- Приём вызова InvokeAgentRuntime и определение namespace и сессии.
- Выборка релевантных записей из AgentCore memory с фильтром по метаданным.
- Передача запроса в OpenClaw gateway, который решает, какие инструменты вызывать.
- Генерация ответа через Amazon Bedrock Converse API.
- Запись новых событий в краткосрочную память, откуда они асинхронно становятся долгосрочными записями.
Пункты про определение namespace, фильтр по метаданным и запись событий - рабочая реконструкция вокруг роли server.py; пошаговый код и порядок шагов в доступном фрагменте публикации не приведены.
Два входных потока: Telegram и расписание
Интерактивный поток: сообщение пользователя принимает Amazon API Gateway и передаёт в webhook AWS Lambda, а та вызывает InvokeAgentRuntime.
Плановый поток: Amazon EventBridge Scheduler по расписанию запускает cronjob Lambda, которая вызывает тот же InvokeAgentRuntime. Пример из публикации - утреннее напоминание о поливе. Оба потока приходят в одного и того же агента, поэтому память и персона у них общие.
| Сервис | Роль в системе |
|---|---|
| Amazon API Gateway и webhook AWS Lambda | приём и обработка сообщений Telegram |
| Amazon EventBridge Scheduler и cronjob Lambda | запуск задач по расписанию |
| Amazon S3 | хранение рабочего пространства |
| AWS KMS | шифрование |
| AWS Secrets Manager | хранение токена бота |
| Amazon CloudWatch | логи и метрики |
Перечисленные потоки и вспомогательные сервисы описаны в публикации AWS. Тот же принцип разделения слоёв встречается и в других проектах на AgentCore, где runtime и память берут на себя исполнение и состояние, а логика остаётся в агентах: например, в разборе аналитики AvioBook на Amazon Bedrock AgentCore.
Практические решения: маршрутизация моделей, кэширование и отказоустойчивость
Маршрутизация текста и vision между Haiku и Sonnet
Публикация называет две модели для маршрутизации: Claude Haiku 4.5 под текстовые запросы и Claude Sonnet 4.5 под vision-задачи. Логика простая: большинство обращений к персональному ассистенту это текст, и гонять их через дорогую модель незачем.
Пример: пользователь присылает фото листа с пятнами, запрос уходит на Sonnet, потому что нужно разобрать изображение. Текстовый вопрос «когда поливать помидоры» обрабатывает Haiku.
Оговорка из публикации: модели указаны как планируемые для маршрутизации, и в своём аккаунте их можно заменить на доступные эквиваленты. Сам принцип маршрутизации по типу входа переносится на любые доступные модели, меняются только идентификаторы.
Кэширование промптов: меньше токенов, ниже задержка
Идея: неизменяемая часть промпта (персона, манифест навыков, инструкции) одинакова от запроса к запросу. Если провайдер кэширует такой префикс, он не пересчитывается каждый раз, и вы платите за меньшее число токенов, а ответ приходит быстрее. Динамическая часть, то есть реплика пользователя и выбранные записи памяти, добавляется в конец промпта.
Важное ограничение: в доступном фрагменте публикации AWS кэширование промптов не описано. Это общий приём оптимизации, который нужно проверять по актуальной документации Amazon Bedrock: поддержка кэширования зависит от модели и способа вызова, автоматически для любого запроса она не включается.
Правило при сборке: держите системную часть промпта стабильной и не подмешивайте в неё меняющиеся данные вроде текущей даты, иначе кэш будет промахиваться и экономия исчезнет.
Graceful degradation: что делать, если память недоступна
Принцип: сбой памяти не должен ломать ответ. Если AgentCore memory недоступна или вернула ошибку, server.py продолжает обработку без долговременного контекста, и пользователь получает ответ, просто менее персонализированный. Диалог не прерывается, а сам факт деградации виден в логах CloudWatch.
Пример: при таймауте выборки вопрос «когда поливать помидоры» получает общий ответ по культуре, без учёта приподнятых грядок с быстрым дренажом.
Здесь та же оговорка: поведение при сбое памяти в доступном фрагменте явно не расписано. Обработку ошибок вокруг вызовов памяти нужно закладывать самому, иначе падение одного сервиса утащит за собой весь ответ.
Что нужно для развёртывания и сколько это стоит
Требования к окружению и доступам
- доступ к Amazon Bedrock AgentCore, включая AgentCore runtime и AgentCore memory;
- выданный доступ к моделям, которые планируете использовать для маршрутизации: Claude Haiku 4.5 для текста и Claude Sonnet 4.5 для vision;
- Docker с поддержкой сборки linux/arm64;
- настроенный AWS Command Line Interface.
Список в публикации приведён как минимальный, и в доступном фрагменте он обрывается на требовании к Docker, поэтому полный перечень может быть шире. Права AWS CLI должны покрывать создание ресурсов стека: Lambda, API Gateway, EventBridge Scheduler, S3, KMS, Secrets Manager, CloudWatch, а также AgentCore runtime и memory. Сборка образа под linux/arm64 означает, что контейнер готовится под ARM, поэтому на машине нужен Docker с поддержкой buildx или Docker Desktop на Apple Silicon.
Развёртывание одной командой через CloudFormation
Весь стек, включая перечисленные выше сервисы, описан в одном шаблоне AWS CloudFormation и разворачивается одной командой. Модель оплаты за потребление: платите за вызовы и хранение, а не за простой. Токен Telegram-бота хранится в AWS Secrets Manager, а не в коде или переменных шаблона. Именно так это описано в публикации AWS: единый шаблон, одна команда развёртывания, оплата по факту использования.
Практический порядок: сначала развернуть шаблон, затем прописать токен бота в Secrets Manager, после чего проверить оба входных потока, сообщение в Telegram и тестовую cron-задачу.
Ориентиры по стоимости лёгкого персонального использования
Лёгкое персональное использование обходится в несколько долларов в месяц. Это ориентир, а не смета: точных сумм публикация не приводит, и при интенсивной работе счёт вырастет.
Из чего складываются расходы:
- вызовы моделей: Haiku заметно дешевле, Sonnet дороже, особенно на vision-задачах;
- запись и выборка в AgentCore memory, включая объём хранимых записей;
- Lambda и API Gateway на каждый входной запрос;
- S3 для рабочего пространства и CloudWatch за логи и метрики.
Сильнее всего счёт разгоняют длинные ответы vision-модели, большой объём памяти без фильтрации по метаданным (в контекст уезжает лишнее) и частые cron-задачи. Часть обновлений платформы касается как раз контроля расходов и лимитов, поэтому полезно держать под рукой обзор изменений Amazon Bedrock и AgentCore за август 2026 года, а точные цены сверять по прайс-листу AWS.
Как адаптировать решение под свой домен
Архитектура домен-агностична. Сквозной пример публикации, садоводческий ассистент Sprout, легко заменяется: поменяйте персону и манифест навыков, и тот же пайплайн начнёт обслуживать support-бота, фитнес-тренера или внутренний help desk.
Меняются два элемента: персона (кто ассистент и как он говорит) и манифест навыков (какие инструменты доступны и когда их вызывать). Инфраструктура, память, маршрутизация моделей и обработка сбоев остаются на месте. Персона «фитнес-тренер» плюс навыки «составить тренировку» и «разобрать дневник питания» дают новый продукт без переписывания стека.
Вместе с персоной придётся пересобрать схему метаданных. Для садоводства это темы «полив», «удобрения», «вредители», для фитнеса «тренировки», «питание», «восстановление». Фильтры выборки должны опираться на новый словарь, иначе метаданные быстро теряют смысл и память начинает отдавать нерелевантные записи.
Если хочется не адаптировать готовую сборку, а собрать агента с контролем над каждым слоем, есть отдельный разбор: архитектура самописного AI-агента на Python с оркестрацией вызовов, памятью, инструментами и метриками latency и cost.
Ограничения и на что обратить внимание
- Привязка к AWS. Runtime и память это управляемые сервисы AWS, open source здесь только OpenClaw. Перенести сборку в другое облако без переписывания слоя памяти не получится.
- Зависимость от доступа к моделям. Маршрутизация рассчитана на Claude Haiku 4.5 и Claude Sonnet 4.5; без доступа нужны эквиваленты с сопоставимым поведением, а это отдельная проверка качества.
- Отладка распределённой системы. Запрос проходит через API Gateway, Lambda, runtime, память и Converse API. Сбой на любом шаге выглядит для пользователя одинаково: «ассистент отвечает странно». Логи CloudWatch и метрики нужны с первого дня.
- Квоты и лимиты облака. Они влияют и на задержку, и на поведение под нагрузкой, особенно когда cron-задачи стартуют одновременно с активным диалогом.
- Неполнота публичных деталей. В доступном фрагменте не раскрыты механика двух слоёв памяти, namespace, кэширование промптов и обработка сбоев памяти: эти части придётся проектировать и проверять самому.
Кому подход подходит: тем, кто уже работает в AWS и хочет получить персонализированного ассистента без написания инфраструктуры вручную. Если облачную привязку держать не хочется, стоит смотреть self-hosted варианты вроде PersonalJarvis, но там хранение памяти, изоляцию пользователей и планировщик задач придётся закрывать самостоятельно.
Стартовая последовательность выглядит так: получить доступ к AgentCore runtime и memory, собрать образ под linux/arm64, развернуть шаблон CloudFormation, прописать токен бота в Secrets Manager и только после этого настраивать схему метаданных под свой домен. Первую версию памяти лучше делать узкой: две-три темы и один тип записи. Расширять словарь стоит по логам, когда видно, какие записи реально попадают в контекст и помогают отвечать.