Почему 90% AI-агентов в проде падают: как MCP Ouroboros решает проблему двусмысленности и контроля бюджета

Я — Денис Шохирев, архитектор agentic AI-систем из Фрайбурга, работаю со стеком Claude, Supabase, n8n, Doppler и self-hosted Postgres. Если вы хоть раз запускали AI-агентов в проде, то знаете: 90% из них либо расходуют бюджет за пару часов, либо намертво залипают на двусмысленных задачах. У меня есть публичная система на live.gerdennisai.com — и ни один день не проходит без ручных перезапусков или ловли runaway-процессов.

Почему агенты массово падают в проде — не только RAG и не только LLM

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

• Агент получает слишком общую задачу ("оптимизируй цепочку поставок") — и бесконечно уточняет входные параметры, не делая реальной работы.
• В цепочке агентов один вызывает другого с невалидным JSON — и оба начинают спорить, увеличивая токеновый бюджет.
• Логика бюджетирования не синхронизирована между агентами — один агент за ночь тратит весь лимит API-кредита.

Stanford AI Index 2024 отмечает, что 85% production-LLM-инцидентов связаны с неучтенными побочными запросами или runaway-процессами. Мои наблюдения это подтверждают: по меньшей мере 3 из 5 запусков требуют внедрения внешних ограничителей или "circuit breakers".

Паттерн MCP Ouroboros: минимальный контроллер процессов для agentic AI

Вместо попыток "залечить" каждый баг на уровне агентов, я применяю паттерн MCP Ouroboros — минимальный контроллер процессов, который:

1. Жестко лимитирует бюджет (по токенам/деньгам/времени) на уровне всей цепочки агентов.
2. Отслеживает прогресс по задаче через явные чек-пойнты и не дает агентам зациклиться на уточнениях.
3. Вытаскивает агента из "амбивалентных" состояний через внешние правила и валидацию JSON/структурированных данных.

Важный нюанс — MCP не вмешивается в генерацию текста, а управляет только процессом и бюджетами.

Архитектура: Claude + n8n + Supabase + custom MCP

Я реализую MCP как отдельный сервис (Python, FastAPI), который интегрирован с n8n и Supabase:

import time
import requests

class MCPOuroboros:
    def __init__(self, budget_tokens, budget_seconds):
        self.tokens_left = budget_tokens
        self.time_left = budget_seconds
        self.checkpoints = []
    def step(self, agent_input, agent_output, tokens_used):
        self.tokens_left -= tokens_used
        self.checkpoints.append((time.time(), agent_input, agent_output))
        if self.tokens_left < 0 or self.time_left < 0:
            raise Exception("Бюджет исчерпан")
        if self.detect_ambiguity(agent_input, agent_output):
            return self.external_validate(agent_output)
        return agent_output
    def detect_ambiguity(self, inp, out):
        # Простая эвристика: слишком частое уточнение одной и той же переменной
        return "уточнить" in out.lower()
    def external_validate(self, output):
        # Валидируем JSON через Supabase функцию
        resp = requests.post("https://your.supabase.io/validate", json={"out": output})
        return resp.json()

Вся коммуникация агентов идет через MCP, который агрегирует usage-статистику и ловит аномалии в самом начале.

Почему не хватает обычных rate limits и try/except

Если вы просто расставите rate limits на уровне API или добавите try/except в код, runaway-агенты все равно найдут лазейки — например, через рекурсивные вызовы или неявные форки задач. MCP подходит потому, что работает на уровне всей цепочки и ведет лог по каждому переходу состояния.

Контроль бюджета — не только про деньги

В DACH-рынке часто спрашивают: "А зачем такие сложности — не проще просто выставить лимиты на OpenAI/Claude аккаунтах?" На практике бюджет — это не только деньги, но и:

• Время ответа (SLA по договору с клиентом — 1 минута на задачу).
• Общее число обращений к базе (например, Supabase Billing по числу read/write).
• Ограничения на количество внешних вызовов (например, n8n webhooks).

Валидация структур — почему это must-have для агентных систем

На практике LLM-агенты часто возвращают невалидный JSON или теряются в длинных цепочках уточнений. Я использую semgrep и gitleaks для статического анализа кода, но в рантайме помогает только внешняя валидация через Supabase или отдельные Python-функции.

import jsonschema

schema = {
    "type": "object",
    "properties": {
        "action": {"type": "string"},
        "params": {"type": "object"}
    },
    "required": ["action", "params"]
}

def validate_json(data):
    try:
        jsonschema.validate(instance=data, schema=schema)
        return True
    except Exception as e:
        return False

Вся цепочка агентов не двигается дальше, пока каждый агент не вернет валидную структуру — это радикально снижает число runaway-запросов.

FAQ

Почему нельзя просто ограничиться стандартными timeout-ами?

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

Можно ли использовать n8n для построения подобных ограничителей?

Да, но только для простых сценариев. Для сложных цепочек с несколькими агентами нужен отдельный сервис-контроллер, интегрированный с n8n через API.

Как MCP отслеживает двусмысленность?

Явные правила на повторяющиеся уточнения параметров, внешний анализ output, валидация структур JSON.

Что делать если агент попал в двусмысленное состояние?

MCP может либо эскалировать задачу человеку, либо применить pre-defined fallback-логику.

Как часто нужно обновлять правила валидации?

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

В какой части вашей agentic-системы случается больше всего runaway-процессов — на этапе постановки задачи или в цепочке уточнений? Я реально хочу это знать. Я делаю бесплатный 30-минутный аудит стека для основателей DACH, которые строят AI в регулируемых рынках. Пишите в LinkedIn или @ger_dennis_ai.