Асинхронные ИИ-агенты: архитектура и память

Обновлено 4 августа 2026 года. Материал подготовлен редакцией AI рассвет на основе выступления команды Anthropic и первичных технических источников.

Асинхронный ИИ-агент — это система, которой можно делегировать задачу и вернуться за результатом позже: она сохраняет состояние между шагами, выполняет действия в изолированных средах, проверяет результат по измеримым критериям и знает, когда обратиться к человеку. Долгая автономность появляется не только благодаря более сильной модели. Её создают архитектура с внешней сессией, независимый verifier, управляемая память и строгие права доступа.

Главная ошибка — взять чат-агента, поместить его вместе с инструментами и секретами в один контейнер и просто разрешить работать дольше. Если контейнер упадёт, сессия пропадёт. Если агент ошибётся, он может подтвердить собственную ошибку. Если запишет ложный вывод в память, тот начнёт влиять на будущие запуски.

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

Содержание

Почему асинхронные агенты стали возможны
Из чего состоит долгоживущий агент
Принцип 1. Отделить «мозг» от «рук»
Сессия как внешний журнал событий
Принцип 2. Проверять в отдельном контексте
Как устроить цикл исполнитель — verifier
Принцип 3. Память должна учиться и исправляться
Почему не стоит заранее задавать жёсткую схему памяти
Принцип 4. Агент становится общим слоем организации
Риски долгой автономной работы
Минимальная производственная архитектура
Как запустить первого асинхронного агента
FAQ
Итог

Почему асинхронные агенты стали возможны

Продуктовый интерфейс всегда следует за возможностями модели. Когда модель могла выполнять лишь короткий фрагмент работы, ей подходили автодополнение и чат: человек постоянно находился рядом, уточнял запрос и исправлял курс. Когда агенты научились работать дольше, появились локальные coding agents. Следующий шаг — задачи, которые идут часами или днями без непрерывного наблюдения.

Эту динамику часто описывают через task-completion time horizon. METR определяет его как длительность задачи для человека-эксперта, при которой агент прогнозируемо достигает заданной вероятности успеха. Это не буквальное время непрерывной работы модели. Например, «горизонт 8 часов» не означает, что агент способен сделать любую восьмичасовую работу специалиста: измерение METR основано главным образом на хорошо заданных задачах программирования, машинного обучения и кибербезопасности. Сама организация предупреждает, что текущие оценки выше 16 часов ненадёжны из-за ограничений набора задач. Методология METR

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

Компонент	Что он даёт	Что случится без него
Постоянная сессия	восстановление хода работы	падение процесса уничтожит прогресс
Изолированное исполнение	контроль файлов, сети и секретов	ошибка получит слишком большой радиус воздействия
Verifier	независимый сигнал качества	агент подтвердит правдоподобный, но неверный результат
Память	перенос опыта между сессиями	повторение одних и тех же ошибок
Права и аудит	безопасная работа в организации	непонятно, кто поручил действие и к каким данным был доступ

Из чего состоит долгоживущий агент

Полезно перестать считать агента одной программой. В производственной системе есть как минимум пять частей.

Модель выбирает следующий шаг и интерпретирует результат.
Управляющий контур вызывает модель, маршрутизирует инструменты, следит за бюджетом и условиями остановки.
Сессия хранит последовательность запросов, ответов, вызовов инструментов и результатов.
Среды выполнения запускают код, работают с файлами и обращаются к разрешённым сервисам.
Хранилище секретов и политик выдаёт минимальные права на конкретное действие.

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

Принцип 1. Отделить «мозг» от «рук»

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

Anthropic описывает решение как разделение «мозга», «рук» и сессии. Управляющий процесс находится вне sandbox, среда выполнения вызывается как инструмент, а состояние хранится отдельно. Если контейнер перестал отвечать, управляющий слой получает ошибку вызова, создаёт новую среду и продолжает работу из журнала. Архитектура Claude Managed Agents

Разделение решает три задачи.

Отказоустойчивость

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

Безопасность

Секреты не нужно помещать в среду, где агент исполняет сгенерированный код. Лучше использовать посредника: агент формирует намерение вызвать сервис, политика проверяет действие, а шлюз подставляет учётные данные только на время разрешённого запроса. Официальное описание Managed Agents отдельно подчёркивает хранение credentials вне sandbox. Обзор производственной архитектуры

Масштабирование

Один управляющий процесс может обращаться к нескольким «рукам»: отдельным контейнерам, браузеру, эмулятору, среде анализа данных или сервису внутри VPC. Это не обязательно мультиагентная система. Одна модель может координировать несколько изолированных исполнителей.

Важно не копировать название продукта, а сохранить контракт:

execute(tool_name, input) → structured_result

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

Сессия как внешний журнал событий

Обычная история чата — временный контекст для следующего ответа. Сессия долгоживущего агента — append-only log, то есть журнал, в который события добавляются без уничтожения предыдущих записей.

В него входят:

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

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

Эта идея совпадает с направлением Recursive Language Models: длинный вход рассматривается как внешний объект, который модель программно исследует и разбивает на части, вместо того чтобы целиком помещать в один prompt. Авторы RLM показали работу с входами до двух порядков больше контекстного окна на исследованных задачах, хотя перенос результата на конкретную производственную систему требует собственных тестов. Статья Recursive Language Models

Практический вывод: compaction должен менять рабочее представление, а не оригинальную историю. Резюме можно пересобрать, а исходные события должны оставаться доступными для расследования, восстановления и новой стратегии извлечения.

Принцип 2. Проверять в отдельном контексте

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

Независимый verifier получает другой набор данных:

исходную цель;
измеримый критерий готовности;
проверяемый артефакт;
доступ к тестам или первичным источникам;
минимум истории исполнителя.

Он не обязан быть более крупной моделью. Для кода лучшим verifier часто становится тест runner, компилятор или статический анализатор. Для публикации — проверка HTTP 200, видимого H1 и совпадения фактов с источниками. Для финансов — сверка с учётной системой. LLM нужна там, где критерий включает смысловое суждение, но даже тогда её вывод стоит связывать с доказательством.

Anthropic описывала generator-evaluator схему для многочасовой разработки приложений: отдельные планировщик, исполнитель и оценщик работали по критериям, а результат возвращался на доработку. Разбор архитектуры долгой разработки

Как устроить цикл исполнитель — verifier

Минимальный цикл выглядит так:

BUILD → VERIFY → PASS или REPAIR → BUILD

Но фраза «повторять до успеха» опасна без ограничений. У цикла должны быть:

Поле	Пример
Outcome	все тесты проходят, файл создан, источник открыт
Rubric	корректность 50%, полнота 30%, формат 20%
Evidence	exit code, URL, checksum, запись из системы-источника
Budget	максимум 6 итераций или 20 долларов
Timeout	не более 90 минут
Escalation	после двух одинаковых ошибок — человеку
Stop condition	verifier вернул PASS и приложил доказательство

В расшифровке этот подход показан на Parameter Golf — открытом соревновании OpenAI по обучению компактной модели. Участникам нужно было минимизировать held-out loss на фиксированном FineWeb, уложившись в артефакт 16 МБ и десять минут обучения на восьми H100. Это удачный тип задачи для автономного цикла: метрика числовая, бюджет жёсткий, а запуск воспроизводим. OpenAI сообщает, что соревнование получило более 2 000 работ от более 1 000 участников и что coding agents широко использовались для экспериментов. Итоги Parameter Golf

Смысл примера не в конкретном результате одной модели. Важно, что сигнал управления вынесен в среду: агент меняет гипотезу после реального запуска, а не после субъективной просьбы «подумай ещё».

Принцип 3. Память должна учиться и исправляться

Память агента полезно разделить на два процесса.

In-band запись происходит во время задачи. Агент фиксирует найденные команды, предпочтения пользователя, локальные ошибки, промежуточные гипотезы и следующий шаг. Это быстрая рабочая память.

Офлайн-консолидация запускается позже. Она читает несколько сессий и текущее хранилище, удаляет дубликаты, ищет противоречия, повышает уровень абстракции и помечает сомнительные выводы. В материалах Anthropic этот процесс называется Dreaming: запланированный проход анализирует сессии и память, извлекает повторяющиеся паттерны и обновляет сохранённые знания. Описание Memory и Dreaming

Почему одного процесса мало? Во время работы локально полезная заметка может быть неверной в общем случае. Например, агент однажды нашёл обходной путь для ошибки API и сохранил его как постоянное правило. После обновления API правило мешает каждому следующему запуску. Офлайн-процесс может сравнить несколько трасс, заметить, что решение устарело, и заменить частный факт более устойчивым принципом.

Память должна иметь происхождение и срок действия. Минимальная запись содержит:

сам вывод;
тип: факт, предпочтение, гипотеза или процедура;
источник или session ID;
дату создания и последней проверки;
область действия;
confidence;
историю исправлений.

Без этих полей ложная память выглядит так же убедительно, как подтверждённая.

Почему не стоит заранее задавать жёсткую схему памяти

Файловая система не является обязательным выбором. Подойдут база данных, объектное хранилище или их сочетание. Важнее, чтобы модель могла выполнять простые операции: создать запись, прочитать, найти, связать, пересмотреть и архивировать.

Слишком предписывающая схема заранее решает, какие типы опыта окажутся важны. Это часто ведёт к потере сигналов, которые разработчик не предусмотрел. Более сильные модели лучше выделяют переносимые абстракции: не только «команда X сработала», а «при ошибке этого класса сначала проверь версию схемы, затем повтори запрос с совместимым форматом».

Но свобода структуры не означает отсутствие контроля. Над хранилищем всё равно нужны:

лимиты размера и стоимости;
разделение памяти по пользователям и проектам;
запрет сохранять секреты;
проверка происхождения;
карантин для непроверенных выводов;
право человека удалить или исправить запись.

Принцип 4. Агент становится общим слоем организации

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

Claude Tag показывает один вариант такого интерфейса. Он работает в Slack, но суть не в чат-боте: один агент доступен нескольким людям, сохраняет контекст разрешённых каналов, может действовать асинхронно и при включённом ambient-режиме сам сообщать о важных незакрытых вопросах. Администраторы задают источники данных, инструменты, лимиты расходов и область памяти; действия связываются с человеком, который поставил задачу. Официальный анонс Claude Tag

Такой слой даёт компании три преимущества.

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

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

Риски долгой автономной работы

Чем дольше работает агент, тем больше действий он успевает выполнить до человеческой проверки. Поэтому длительность усиливает не только пользу, но и ошибку.

Prompt injection

Внешняя страница, тикет или README могут содержать инструкцию, которая пытается изменить цель агента. Данные инструментов нужно считать недоверенными, проверять сетевые направления и не позволять тексту из источника расширять права.

Отравление памяти

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

Коррелированная проверка

Исполнитель и verifier на одной модели могут ошибаться одинаково. Помогают разные контексты, разные инструменты и внешние критерии. Простое голосование нескольких агентов не является доказательством.

Неограниченный цикл

Агент может бесконечно улучшать метрику, повторять один сбой или тратить бюджет на слабую гипотезу. Нужны лимиты попыток, времени, токенов, денег и правило эскалации.

Необратимое действие

Публикация, платёж, удаление данных, выдача прав и изменение production требуют отдельного шлюза. Для значимых действий полезны preview, approval, idempotency key и возможность отката.

Минимальная производственная архитектура

Для первого запуска не требуется сложная платформа. Достаточно восьми блоков.

Блок	Минимальная реализация
Intake	очередь задач с owner и приоритетом
Goal	измеримый результат и запрещённые действия
Session store	append-only события и ссылки на артефакты
Orchestrator	шаг модели, маршрутизация инструментов, budgets
Sandbox	отдельный контейнер с ограниченной сетью
Credential proxy	выдача минимального разрешения на запрос
Verifier	тест или отдельный контекст с rubric
Human gate	подтверждение рискованного финального действия

Поток можно записать так:

TASK → SESSION → PLAN → SANDBOX ACTION → ARTIFACT → VERIFY → MEMORY → DONE

Если проверка не пройдена, результат возвращается в PLAN, но только пока не исчерпаны лимиты. Если повторяется одна ошибка, задача переходит человеку.

Для широких процессов этот цикл можно включать в граф из нескольких параллельных ветвей. Подробно такой подход разобран в материале Graph Engineering: как строить графы ИИ-агентов.

Как запустить первого асинхронного агента

Шаг 1. Выберите проверяемую задачу

Подойдёт работа, где есть цифровой вход, ограниченные инструменты и явный результат: подготовить отчёт по данным, исправить набор тестов, классифицировать обращения или обновить документацию. Не начинайте с цели «улучшать бизнес».

Шаг 2. Опишите outcome

Сформулируйте состояние, которое можно проверить без самооценки модели. Например: «создан CSV с 12 обязательными колонками, все строки прошли валидацию, сумма совпадает с источником».

Шаг 3. Вынесите сессию из процесса

Записывайте события до и после каждого вызова инструмента. Храните артефакты отдельно, а в журнале — ссылки и контрольные суммы.

Шаг 4. Ограничьте среду

Запретите лишнюю сеть, подключите read-only данные, задайте CPU, память, время и объём диска. Секреты передавайте через прокси конкретным запросам.

Шаг 5. Добавьте verifier

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

Шаг 6. Введите память-кандидат

Разрешите агенту предлагать записи, но не превращайте любую заметку в постоянное правило. Запускайте консолидацию по расписанию и храните историю изменений.

Шаг 7. Проведите теневой запуск

Пусть агент готовит результат, но не совершает финальное действие. Сравните его выводы с человеком минимум на 20–30 задачах. Это рекомендуемый диапазон, Estimated, а не универсальный стандарт.

Шаг 8. Постепенно расширяйте автономию

Сначала разрешите безопасные read-only действия, затем обратимые изменения, после — ограниченные операции с подтверждением. Полностью автоматическими оставляйте только действия с проверяемым результатом и малым радиусом ошибки.

FAQ

Что такое асинхронный ИИ-агент?

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

Чем асинхронный агент отличается от чат-бота?

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

Зачем отделять управляющий контур от среды выполнения?

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

Почему агент не должен сам оценивать свою работу?

Исполнитель склонен сохранять собственные допущения. Независимый verifier получает критерий и артефакт в отдельном контексте и подтверждает результат тестом, первичным источником или записью из системы-источника.

Что лучше для памяти: файлы или база данных?

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

Что означает Dreaming у ИИ-агентов?

Это не обучение весов модели и не человеческий сон. Так Anthropic называет запланированную офлайн-консолидацию: процесс читает прошлые сессии и память, выделяет повторяющиеся паттерны, исправляет или объединяет записи.

Можно ли оставить такого агента работать на ночь?

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

Итог

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

Память добавляет накопление опыта, но требует отдельного процесса исправления. Организационный контекст делает агента общим участником работы, но требует собственной идентичности, границ данных и полного аудита.

Практическая последовательность проста: выберите проверяемую задачу, вынесите сессию наружу, ограничьте среду, добавьте verifier, введите память-кандидат и расширяйте автономию только после теневых запусков. Сильная модель повышает потолок возможностей. Надёжность создаёт вся система вокруг неё.