Как сделать агента самовосстанавливающимся (self-healing)?

Краткий тезис

Самовосстанавливающийся (self‑healing) агент — это система, способная автономно обнаруживать сбои, диагностировать их причину и восстанавливать свою работоспособность без вмешательства человека. Это достигается комбинацией health checks (проверки здоровья), recovery actions (действий по восстановлению), self-diagnosis (самодиагностики с помощью LLM) и таких паттернов, как checkpointing, breaker|circuit breaker и canary deployments. Self‑healing критически важен для production‑агентов, работающих с внешними инструментами, памятью и длинными сессиями, где отказы неизбежны.

1. Термин: Self-healing agent (самовосстанавливающийся агент)

Self-healing agent — это агентная система, которая в ответ на сбой (ошибка инструмента, повреждение памяти, падение LLM‑эндпоинта) выполняет заранее определённый набор действий для минимизации downtime и потери данных. В отличие от простого повторного запроса (retry), self‑healing включает:

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

Отличие от традиционных микросервисов агенты недетерминированы (LLM даёт разные ответы), сбои часто семантические (неверный выбор инструмента), а состояние распределено между памятью, вызовами API и контекстным окном. Поэтому self‑healing для агентов сложнее, чем стандартный health check в Kubernetes.

2. Почему агенту нужно самовосстановление?

Self‑healing позволяет:

• повысить availability (доступность) системы;
• уменьшить MTTR (mean time to recovery);
• снизить нагрузку на инженеров по он-call.

3. Health checks: постоянный мониторинг компонентов

Health check — это процедура, которая периодически опрашивает каждый компонент агента и возвращает статус (healthy / degraded / unhealthy). Компоненты для мониторинга:

• Memory store (Redis, Postgres): проверка коннективности, целостности данных (например, контрольная сумма ключевых записей).
• Инструменты (tools): проверка каждого внешнего API (ping, test‑запрос с известным ожидаемым ответом).
• LLM‑эндпоинт: простой запрос (например, «Hello») и проверка, что ответ не пустой и не содержит ошибок.
• Внутренняя очередь (если агент асинхронный): глубина и задержка.

# Пример health check для инструмента
async def check_tool_health(tool_name: str, tool_callable) -> HealthStatus:
    try:
        result = await tool_callable.health_check()  # встроенный метод
        if result.status == "ok":
            return HealthStatus.HEALTHY
        else:
            return HealthStatus.DEGRADED
    except Exception as e:
        log.error(f"Tool {tool_name} health check failed: {e}")
        return HealthStatus.UNHEALTHY

Частота: раз в 5–60 секунд в зависимости от критичности. Для LLM достаточно раз в минуту. Для инструментов — чаще.

4. Recovery actions: что делать при обнаружении проблемы

После health check агент запускает одно из следующих recovery actions:

Circuit breaker — паттерн, при котором после K последовательных ошибок вызов инструмента блокируется на заданное время (разомкнутое состояние), а затем постепенно разрешается (полуоткрытое). Реализация:

class CircuitBreaker:
    def __init__(self, threshold=3, timeout_seconds=30):
        self.failures = 0
        self.threshold = threshold
        self.state = "closed"  # closed, open, half_open
        self.last_failure_time = None

    async def call(self, tool_func, *args):
        if self.state == "open":
            raise CircuitBreakerOpenError("Tool temporarily unavailable")
        try:
            result = await tool_func(*args)
            self.failures = 0  # success → reset
            self.state = "closed"
            return result
        except Exception:
            self.failures += 1
            self.last_failure_time = time.time()
            if self.failures >= self.threshold:
                self.state = "open"
            raise

Checkpointing — сохранение полного состояния агента (память, стек вызовов, контекст) в определённые моменты (после каждого шага или при достижении ключевой точки). Позволяет откатиться до последнего корректного checkpoint.

5. Self-diagnosis: LLM как диагностический движок

Self-diagnosis — использование LLM для анализа возникшей ошибки и предложения фикса. Это возможно, если ошибка семантическая (например, неверный формат ответа от инструмента).

Пример цикла агент получает exception при вызове API погоды. Вместо того чтобы просто retry, он отправляет в LLM:

• последний запрос пользователя;
• ответ инструмента (который вызвал ошибку);
• сообщение об ошибке;
• предыдущий шаг (какой инструмент был выбран).

LLM возвращает диагностику:

«Ошибка: инструмент вернул JSON без поля 'temperature'. Возможная причина — изменилась структура ответа. Предлагаемое действие: переключиться на запасной инструмент weather_v2 и повторить запрос».

async def self_diagnose(error_context: dict) -> RecoveryPlan:
    prompt = f"""
    Analyze the following agent error:
    - User query: {error_context['query']}
    - Tool called: {error_context['tool_name']}
    - Tool response: {error_context['tool_response']}
    - Error message: {error_context['error']}
    
    Suggest a recovery action (choose one):
    1. Retry with same tool after {delay} seconds
    2. Switch to fallback tool {fallback_name}
    3. Query user for clarification
    4. Restore from checkpoint
    5. Other (specify)
    
    Output format: action: <action> | parameters: <json>
    """
    llm_response = await llm_complete(prompt)
    return parse_recovery_plan(llm_response)

Ограничения self‑diagnosis требует дополнительного LLM‑вызова (деньги, latency); не всегда даёт корректный план (галлюцинации). Поэтому используется как вторая линия защиты после быстрых алгоритмических recovery.

6. Canary deployments и rolling updates

Canary deployment — параллельный запуск новой версии агента рядом с текущей стабильной. Если у новой версии ухудшаются метрики (например, процент успешных сессий падает ниже порога), происходит автоматический откат (rollback) к предыдущей версии.

Применимость в self‑healing когда агент самообновляется (например, загружает новую конфигурацию инструментов), можно сначала запустить канареечный экземпляр и оценить его работу. При деградации — откат.

Шаги:

1. Выкатка новой версии (новый образ, новый prompt, новый набор инструментов).
2. Направление 5% трафика на canary.
3. Мониторинг метрик: average response time, error rate, user satisfaction (explicit feedback).
4. Если метрики ухудшились — автоматический rollback.
5. Если метрики улучшились — постепенное увеличение доли до 100%.

Rolling update — последовательная замена старых экземпляров агента новыми. Если новый экземпляр не проходит health check, он удаляется, старый остаётся.

7. Graceful degradation (плавная деградация)

Graceful degradation — способность агента продолжать работу в ограниченном режиме при отказе части компонентов.

Реализация: агент хранит список fallback‑модулей и при health check с результатом UNHEALTHY отключает соответствующий компонент в конфигурации.

8. Пример: восстановление corrupted memory

Допустим, агент хранит историю диалога в Redis. Ресдис временно упал и повреждены 20 последних записей. Self‑healing цикл:

1. Detect: health check Redis возвращает "checksum mismatch" или timeout.
2. Diagnose: LLM‑анализ (или простое правило — если Redis unhealthy, использовать PostgreSQL как резерв).
3. Recover:
   • Поднять последний checkpoint из S3 (serialized memory до момента, когда Redis был здоров).
   • Загрузить checkpoint в новый экземпляр Redis.
   • Переключить агента на новый эндпоинт.
   • Продолжить сессию с восстановленной историей (потеряно не более 5 минут).
4. Verify: сделать тестовый запрос и проверить, что ответ соответствует контексту (например, «я хочу продолжить прошлый диалог»).

async def self_heal_memory():
    health = await check_redis_health()
    if health != HealthStatus.HEALTHY:
        last_checkpoint = await download_checkpoint("memory_20250315_093000.json")
        new_redis = await create_new_redis_instance(last_checkpoint)
        await switch_agent_to_new_redis(new_redis.endpoint)
        log.info("Memory healed from checkpoint")
        return True
    return False

9. Инструменты и фреймворки для self‑healing агентов

Для self‑diagnosis часто используют отдельную supervisor agent, который получает алерты от health check и запускает восстановительные процедуры.

10. Архитектурный паттерн: Supervisor + Worker

Supervisor agent — выделенный агент, который не выполняет задачи пользователя, а следит за группой worker‑агентов. Его обязанности:

• Периодически запускать health checks на worker‑ах.
• При обнаружении сбоя — запускать recovery actions.
• Логировать инциденты и уведомлять инженеров при невозможности автоматического восстановления.

Worker agent — обычный агент, который выполняет запросы и периодически отправляет heartbeat supervisor‑у.

Supervisor может быть реализован как stateless‑сервис (просто запускает скрипты) или как LLM‑агент с планом восстановления.

Пет-проект для закрепления

Задача Реализовать самовосстанавливающегося агента с памятью на LangGraph. При повреждении Redis – восстановить состояние из локального checkpoint.

Инструменты Python, LangGraph, Redis, PostgreSQL (для хранения checkpoint), ASGI-сервер (FastAPI) для эндпоинта health check.

Шаги:

1. Создайте простой агент для ответа на вопросы с памятью (хранит последние N запросов в Redis).
2. Добавьте health check: раз в 10 секунд проверка коннективности Redis и целостности (контрольная сумма JSON-записи).
3. Реализуйте checkpointing: после каждого успешного ответа сериализуйте состояние в PostgreSQL.
4. Напишите supervisor, который при health check = UNHEALTHY извлекает последний checkpoint из PG, очищает Redis и загружает данные.
5. Протестируйте: симулируйте падение Redis (удалите данные вручную). Убедитесь, что после следующего health check агент восстанавливает память и может корректно ответить на вопрос с учётом истории.

Ожидаемый результат Агент, который даже после потери данных в Redis продолжает корректно отвечать на вопросы в той же сессии (с потерей не более одного-двух оборотов). Вы получите практическое понимание циклов detect-diagnose-recover и работы с checkpoint.

Связь с другими вопросами

Навигация

• Предыдущий: 895
• Следующий: 897
• Индекс: 00. Индекс разборов