Когда простой промпт превращается в монстра

Вы помните 2023 год? Открыли ChatGPT, написали три строчки промпта, получили ответ. Не понравилось - переписали промпт. Все просто.

Сейчас, в 2026 году, все иначе. Ваш "агент" - это не промпт. Это система из десятков компонентов: планировщики, исполнители, проверщики, суб-агенты, долгосрочная память, инструменты API. Он делает 50 запросов к разным моделям, вызывает 15 внешних сервисов, пишет промежуточные результаты в базу, и где-то на шаге 47 тихо сходит с ума.

А вы сидите и думаете: "Почему он не отвечает?"

Глубокий агент - это не просто LLM с промптом. Это распределенная система со всеми вытекающими: race conditions, deadlocks, state corruption, и любимой ошибкой всех времен - "silent failure".

Пять уровней сложности, которые ломают мозг

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

Простое LLM-приложение	Глубокий агент
Один запрос → один ответ	Многошаговая цепочка с ветвлениями
Детерминированная логика (в основном)	Недетерминированные решения на каждом шаге
Проблема: плохой ответ	Проблема: агент застрял в бесконечном цикле, съел все токены и умер
Отладка: смотрим промпт и выход	Отладка: анализируем граф из 200 узлов с временными метками

1 Проблема: агент молчит три часа

Классика. Запускаете исследовательского агента на сложный запрос. Проходит час. Два. Три. Ни ответа, ни ошибки.

В простом приложении вы бы проверили: "А API ключ работает?" В глубоком агенте нужно понять: на каком из 47 шагов он завис? Может, он в рекурсивном цикле "подумать → проверить → подумать еще"? Или deadlock между суб-агентами? Или просто ждет ответа от медленного API?

💡

Инструменты вроде Langfuse стали обязательными. Без детальной трассировки каждого шага вы просто слепой в темной комнате.

2 Проблема: контекстный дрейф и потеря цели

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

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

Новые инструменты для новых проблем

Старые методы не работают. Print-дебаггинг? Вы будете печатать мегабайты JSON. Логи? Они покажут только, что агент "работает".

Polly: когда нужно понять "почему"

Polly (актуальная версия на 2026 - 3.2) - это не просто трекер. Это система объяснений решений. Она отвечает на вопросы:

Почему агент выбрал именно этот инструмент на шаге 24?
Какие альтернативы он рассматривал и отверг?
Как вес доказательств менялся в процессе?

Вместо "агент вызвал Google Search" вы видите: "Агент выбрал Google Search (уверенность 87%), отвергнув Wikipedia API (45%) и внутреннюю базу (23%), потому что в контексте было ключевое слово 'новейшие', а Google лучше для свежих данных".

Fetch: трассировка как граф

Fetch 2.1 (релиз январь 2026) визуализирует выполнение агента как интерактивный граф. Каждый узел - шаг. Ребра - зависимости. Цвета - статусы (успех, ошибка, ожидание).

Вы видите не линейный лог, а топологию выполнения. Вот где агент разветвился на параллельные задачи. Вот где две ветки ждут друг друга (deadlock!). Вот где цикл из 5 узлов повторяется 8 раз (бесконечная рекурсия?).

Совет: настройте алерты на "циклы длиннее 5 итераций" и "узлы в состоянии waiting > 5 минут". Это ловит 80% проблем с зависаниями.

Три типа ошибок, которых нет в простых приложениях

1. Эпистемическая асимметрия

Агент знает что-то, но не говорит. Вы знаете что-то, но агент не спросил. Молчаливый ученый - классическая проблема.

Пример: агент нашел в исследовании критическую ошибку, но не сообщил, потому что его не спросили "есть ли проблемы?". Он просто продолжил работу. Выход выглядит нормально, но фундамент сгнил.

2. Координационные сбои между суб-агентами

Вы создали архитектуру с суб-агентами. Исследователь находит данные, аналитик их обрабатывает, редактор пишет отчет.

А потом: аналитик ждет данные от исследователя. Исследователь ждет уточнения от аналитика. Оба молчат. Координационный слой (тот самый System 2) не сработал.

3. Утечка контекста между сессиями

Агент А закончил работу с контекстом X. Агент Б начал работу, но получил остатки контекста X в своей долгосрочной памяти. Теперь он думает, что знает что-то, чего на самом деле не знает.

Особенно больно с H-MEM и InfiniRetri - мощные системы памяти, которые иногда "помнят" слишком много.

Практический план: как отлаживать глубокого агента

1 Сначала включите максимальное логирование

Не экономьте на токенах для логов. Каждый шаг должен оставлять след:

Входные данные (что агент решил сделать)
Рассмотренные варианты (почему выбрал этот)
Выполнение (что именно сделал)
Результат (что получил)
Следующий шаг (куда пошел)

Используйте структурированные логи (JSON), а не текстовые. Потом будете анализировать програмmatically.

2 Настройте трассировку с временными метками

Каждый компонент должен записывать:

{
  "component": "research_agent",
  "step": 15,
  "timestamp": "2026-02-01T14:30:25.123Z",
  "action": "call_google_search",
  "input": {"query": "latest AI benchmarks 2026"},
  "duration_ms": 1245,
  "token_usage": {"input": 45, "output": 0}
}

Без точных временных меток вы не отличите "медленный API" от "агент думает 10 минут".

3 Создайте детекторы аномалий

Автоматизируйте поиск проблем:

Циклы длиннее N итераций
Шаги, занимающие > X времени
Резкий рост использования токенов
Повторяющиеся одинаковые действия
Суб-агенты, которые никогда не завершаются

Напишите скрипты, которые анализируют логи и кричат, когда что-то идет не так.

4 Тестируйте сценарии, а не юниты

Забудьте про unit-тесты для отдельных функций. Тестируйте полные сценарии:

"Агент исследует тему X и пишет отчет"
"Агент отвечает на сложный вопрос с проверкой фактов"
"Агент работает с противоречивыми источниками"

Смотрите не только на конечный результат, но и на процесс. Правильный ответ, полученный через 100 ошибочных шагов, - это все равно ошибка.

Чего ждать в 2026-2027?

Тренды, которые уже видны:

Автоматическая отладка

Системы, которые сами анализируют трассы, находят паттерны ошибок и предлагают fixes. Не "агент упал", а "агент упал, вот вероятная причина, вот патч, применять?".

Программные контракты для агентов

Как в обычном программировании: pre-conditions, post-conditions, invariants. "Агент-исследователь гарантирует: если найдет противоречивые данные, сообщит". Система проверяет соблюдение контрактов в runtime.

Стандартизация трассировок

Сейчас каждый фреймворк (AgentHub, RLM, другие) имеет свой формат логов. Будет OpenTelemetry для AI-агентов - единый стандарт трассировок.

Главный совет: начните с инструментов observability ДО того, как агент станет сложным. Добавить трассировку в работающую распределенную систему - это боль. Добавить с самого начала - пара дней работы.

Финальная мысль

Отладка глубоких агентов - это не "исправить промпт". Это системная инженерия. Это понимание распределенных систем, асинхронных взаимодействий, координационных проблем.

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

Инструменты есть. Методологии появляются. Осталось перестроить мышление: от "промпт-инжиниринга" к "системной отладке".

И да, держите под рукой сильные кофе и терпение. Много терпения.

Отладка глубоких агентов: почему это не просто починить промпт