Детерминированный контроль агентов: как остановить двойные платежи в автономных AI-системах

Проблема: когда ваш AI-агент платит дважды за одно и то же

В теории звучит идеально. Автономный агент на GPT-5 получает задачу, анализирует рынок, находит подрядчика на фриланс-бирже, переводит ему 50 USDT и получает результат. В реальности все выглядит иначе. Из-за сетевого таймаута после первого запроса агент не получил подтверждение. Он честно решил, что транзакция не прошла, и отправил идентичный платеж снова. Подрядчик счастлив – он получил 100 USDT за одну работу. Ваш баланс – нет.

Это не гипотетический сценарий. В 2025-2026 годах, с ростом сложности агентов на базе Claude 3.7 Sonnet, GPT-5 и их открытых аналогов, такие инциденты перестали быть редкостью. Агенты, о которых мы писали в разборе архитектурных рисков, управляют собственными финансами. Их ошибки теперь измеряются в реальных деньгах.

Почему фреймворки оркестрации не решают эту проблему

LangGraph, AutoGPT, CrewAI – все они раздражают одним фундаментальным упущением. Они прекрасно управляют потоком данных между LLM и инструментами, но полностью абстрагируются от внешнего состояния мира. Для фреймворка вызов API – это просто функция. Успешен ли платеж, создан ли заказ на маркетплейсе – это вопросы к внешним системам.

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

1 Концепт OxDeAI: авторизация на границе

Нужен механизм, который стоит на границе между агентом и внешним миром. Не внутри промпта, не как скрытый инструмент, а как обязательный шлюз для любого действия, меняющего состояние. Я называю это Детерминированной Авторизацией Действий (OxDeAI).

Принцип прост: прежде чем выполнить действие (платеж, создание заказа, отправка сообщения), агент должен получить для него уникальный одноразовый токен авторизации. Этот токен выдается централизованным контроллером, который имеет полную картину состояния системы и истории действий. Один токен – одно действие. Всегда.

2 Архитектура контроллера авторизации

Контроллер – это отдельный сервис с единственной ответственностью: выдавать и проверять токены действий. Его состояние (выданные токены, выполненные действия) должно храниться в надежном, согласованном хранилище. В 2026 году для этого идеально подходят Redis с модулем RedisJSON для скорости или распределенная база данных типа TiKV для максимальной отказоустойчивости.

Каждое действие агента должно иметь уникальный составной идентификатор: agent_id::session_id::action_fingerprint. Отпечаток действия (fingerprint) – это хеш от его параметров. Это гарантирует, что даже если агент захочет выполнить "похожие, но разные" действия, контроллер их различит.

import hashlib
import json
from typing import Dict, Any

class ActionAuthorizer:
    def __init__(self, storage_client):
        self.storage = storage_client

    def generate_action_fingerprint(self, action_type: str, params: Dict[str, Any]) -> str:
        """Создает уникальный отпечаток для действия."""
        param_string = json.dumps(params, sort_keys=True)  # Детерминированный JSON
        payload = f"{action_type}:{param_string}"
        return hashlib.sha256(payload.encode()).hexdigest()

    def request_token(self, agent_id: str, session_id: str, action_fingerprint: str) -> str:
        """Запрос токена на выполнение действия. Выдает токен только если действие еще не авторизовано."""
        action_key = f"{agent_id}:{session_id}:{action_fingerprint}"
        
        # Проверяем, не было ли это действие уже выполнено или авторизовано
        if self.storage.exists(f"completed:{action_key}"):
            raise Exception("Действие уже выполнено.")
        
        if self.storage.exists(f"authorized:{action_key}"):
            # Возвращаем существующий токен, если авторизация уже была (идемпотентность запроса на токен)
            return self.storage.get(f"authorized:{action_key}")
        
        # Генерируем новый уникальный токен
        import uuid
        token = str(uuid.uuid4())
        
        # Сохраняем факт авторизации с TTL (на случай, если действие не будет подтверждено)
        self.storage.setex(f"authorized:{action_key}", 300, token)  # TTL 5 минут
        return token

Пошаговый план внедрения

Внедрение требует изменений на трех уровнях: агент, инструменты и инфраструктура.

1 Модификация агента: обертывание инструментов

Каждый инструмент, способный изменить внешний мир (платежный модуль, API создания задач), должен быть обернут в декоратор, который первым делом запрашивает токен у контроллера авторизации. Без токена – вызов инструмента блокируется.

def with_authorization(action_type):
    def decorator(original_func):
        def wrapper(agent_id, session_id, *args, **kwargs):
            # 1. Генерация отпечатка из аргументов функции
            authorizer = ActionAuthorizer(storage_client)
            fingerprint = authorizer.generate_action_fingerprint(action_type, kwargs)
            
            # 2. Запрос токена
            try:
                token = authorizer.request_token(agent_id, session_id, fingerprint)
            except Exception as e:
                return {"status": "error", "message": f"Авторизация отклонена: {e}"}
            
            # 3. Добавляем токен к аргументам вызова исходного инструмента
            kwargs['_authorization_token'] = token
            
            # 4. Выполняем действие
            result = original_func(*args, **kwargs)
            
            # 5. При успехе – фиксируем выполнение в контроллере
            if result.get("success"):
                authorizer.storage.setex(f"completed:{agent_id}:{session_id}:{fingerprint}", 86400, "done")
                authorizer.storage.delete(f"authorized:{agent_id}:{session_id}:{fingerprint}")
            return result
        return wrapper
    return decorator

# Использование
@with_authorization("crypto_transfer")
def transfer_usdt(to_address: str, amount: float, _authorization_token: str = None):
    # _authorization_token автоматически передается декоратором
    # Ваш код вызова блокчейн-API
    pass

2 Настройка контроллера и хранилища

Разверните сервис авторизации. Для старта хватит одного инстанса с Redis. Для промышленного использования, особенно в сценариях с микроплатежами для AI-агентов, нужна кластеризация. Настройте репликацию и периодическое сохранение снапшотов состояний в объектное хранилище.

3 Интеграция с оркестратором

Внедрите промежуточное ПО (middleware) в ваш фреймворк оркестрации (LangGraph, LangChain). Middleware должно перехватывать все вызовы инструментов и применять логику авторизации централизованно, чтобы не модифицировать каждый инструмент вручную.

Нюансы, которые заставят вас вырвать волосы

Звучит просто? Вот где начинается боль.

Сессии и их идентификаторы. Что такое session_id? Время жизни контекста LLM? Весь "разговор"? Запуск графа? Если определить сессию слишком узко, агент не сможет продолжить прерванную работу. Слишком широко – риск повторения действий после перезагрузки системы. Мой совет: используйте идентификатор конкретного экземпляра рабочего процесса (workflow run ID), который сохраняется при перезапусках.

Таймауты и откаты. Выдали токен, агент начал действие, но завис. Токен истекает через 5 минут (TTL). Что если платеж в блокчейне все-таки пройдет через 6 минут? Контроллер уже забыл про этот токен и разрешит повтор. Решение: внешние системы (биржи, блокчейны) должны также принимать токен и проверять его уникальность на своей стороне. Или увеличивайте TTL соразмерно максимальному времени выполнения операций.

Частые ошибки и как их не совершить

• Хранение состояния в памяти. Контроллер авторизации должен быть stateless относительно данных. Все состояние – в внешнем хранилище. Иначе при падении инстанса вы потеряете учет токенов.
• Слабый fingerprint. Хеширование только части параметров. Агент может изменить незначительный параметр (например, метку времени), чтобы получить новый токен для того же действия. Хешируйте все существенные параметры.
• Игнорирование человеческого фактора. Что если человек вручную выполнит действие, которое уже в очереди у агента? Контроллер должен получать фидбэк о завершении действий из всех источников, включая ручные операции в админ-панели.

К 2026 году проблема детерминизма в AI-системах перешла из академической плоскости в сугубо практическую. Компании, которые запускают агентов для реальных финансовых операций, уже сталкиваются с исками и репутационными потерями. Внедрение слоя детерминированной авторизации – это не "оптимизация", а обязательный гигиенический минимум. Как показывает практика моделей ответственности, когда что-то ломается, винят не агента, а его создателя.

Следующий рубеж – сделать этот контроллер умным. Чтобы он не только запрещал дубли, но и оценивал риск действий на основе контекста, как это делают живые сотрудники в нормальных компаниях. Но это уже тема для другой статьи.

Подписаться на канал