Какие есть типичные failure modes в harness-engineering (over-decomposition, over-pruning)?

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

Harness-engineering — это проектирование упряжи (harness), то есть набора правил, ограничений и оркестрации, в рамках которой действует AI-агент. Неправильная настройка harness приводит к трём типичным failure modes: over-decomposition (чрезмерное дробление задачи), over-pruning (pruning|отсечение безопасных, но полезных путей) и hallucinated execution (следование инструкции вопреки фактам окружения). Понимание этих сценариев помогает строить отказоустойчивых агентов, способных адаптивно перестраивать своё поведение.

1. Термин: Harness-engineering

Harness в контексте AI-агентов — это программная обвязка, которая контролирует жизненный цикл агента]]: какие действия ему разрешены, как он принимает решения, как обрабатывает ошибки и как взаимодействует с внешней средой. Harness-engineering — это процесс проектирования и реализации этой обвязки.

Аналогия: если агент — это машина, то harness — это система рулевого управления, тормозов и датчиков, которая не даёт машине съехать с дороги, но при этом не мешает ей ехать к цели.

Основные компоненты harness:

• Декомпозиция задачи — разбиение высокоуровневой цели на подзадачи (subtasks).
• Ограничения (constraints) — правила, которые агент не должен нарушать (например, «не удалять файлы», «не вызывать API|внешние API без подтверждения»).
• Механизмы принуждения — логика, которая перехватывает управление, если агент пытается совершить запрещённое действие.
• Логирование и мониторинг — сбор трасс действий агента для последующего анализа.

Failure modes возникают, когда эти компоненты настроены слишком жёстко или слишком мягко, либо когда агент начинает игнорировать реальные данные.

2. Failure mode: Over-decomposition (чрезмерное дробление)

Определение — ситуация, когда задача разбивается на слишком мелкие подзадачи, из-за чего агент теряет общий контекст и не может эффективно планировать.

Причины

• Разработчик стремится к максимальной модульности и детализирует каждый шаг.
• Harness принудительно требует разбивать любую задачу на фиксированное число шагов (например, «не более 3 шагов» или «каждый шаг не длиннее одного предложения»).
• Использование жестких шаблонов (templates) без учёта сложности задачи.

Последствия

• Агент «застревает» в микроменеджменте: тратит время на переходы между подзадачами, а не на решение.
• Увеличивается latency (каждый шаг требует вызова LLM).
• Возникают логические разрывы: агент не видит, что первые 10 шагов были частью одного большого действия.
• Потеря связности: результат одной подзадачи забывается к моменту выполнения следующей.

Пример:

Задача: «Напиши краткое резюме документа, затем отправь его по email».

Нормальная декомпозиция:
1. Прочитать документ → 2. Составить резюме → 3. Написать email → 4. Отправить.

Over-decomposition (жесткий harness с разбивкой на 6 шагов):
1. Открыть документ → 2. Извлечь 1 абзац → 3. Извлечь 2 абзац → 4. Сформулировать резюме → 5. Открыть почтовый клиент → 6. Вставить резюме и отправить.

При over-decomposition агент может забыть, зачем он извлекал абзацы, и вместо целостного резюме склеить их дословно.

Как обнаружить

• Анализ логов: среднее число шагов на задачу значительно превышает ожидаемое.
• Снижение метрики Task Success Rate при росте числа шагов.
• В трассировке видны повторяющиеся действия (например, агент трижды открывает один и тот же файл).

3. Failure mode: Over-pruning (избыточное отсечение)

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

Причины

• Перестраховка разработчика: список запрещённых действий составлен так широко, что под него попадают и безопасные операции.
• Использование статических чёрных списков (blacklist) без учёта контекста.
• Жёсткие границы по количеству попыток (retry limit) или шагов (step limit) без возможности их динамического расширения.

Последствия

• Агент отказывается выполнять действия, которые могли бы решить задачу (например, не вызывает API из-за страха, что это «опасно»).
• Падение качества ответов: агент выбирает безопасное, но неоптимальное решение.
• User experience страдает: пользователь видит сообщения вроде «Извините, я не могу это сделать» на совершенно безобидные запросы.

Пример:

Harness содержит правило: «Никогда не вызывать API с параметрами, содержащими слово "delete"».
Агент должен очистить временные файлы. Единственный доступный API — `cleanup(remove_temp=true)`.
Из-за присутствия "remove" (синоним "delete") срабатывает стоп-правило, и агент не выполняет команду.

Over-pruning также проявляется в излишнем запросе подтверждения у пользователя: 
агент спрашивает «Вы уверены?» на каждое действие, делая диалог мучительным.

Как обнаружить

• Сравнение числа действий, которые агент реально совершил, с числом действий, которые были разрешены (например, по логам видно, что 50% запросов заканчивались на стадии валидации).
• Обратная связь от пользователей: жалобы на излишнюю осторожность.
• Анализ rate of user confirmations — если агент слишком часто запрашивает подтверждение, это признак over-pruning.

4. Failure mode: Hallucinated execution (галлюцинаторное выполнение)

Определение — ситуация, когда агент выполняет предписанную инструкцию, игнорируя реальные данные из окружения (evidence). Проще говоря, агент «видит» то, что ожидает увидеть по инструкции, а не то, что есть на самом деле.

Отличие от обычной галлюцинации LLM

• Обычная галлюцинация: LLM генерирует факты, не соответствующие обучению.
• Hallucinated execution: агент действует на основе ложного предположения, хотя мог бы проверить окружение. Это failure mode именно harness, потому что harness должен был принудительно сверить действие с реальностью.

Причины

• Слишком жёсткая привязка к шаблону: агент считает, что «шаг 4 всегда должен быть "отправить отчет"» и отправляет пустой отчет, не проверив, сформирован ли он.
• Отсутствие механизма валидации результатов промежуточных шагов.
• Игнорирование обратной связи от среды (например, агент не читает error code API и продолжает вызывать метод, который выдает ошибку).
• Guidance overrides evidence — установка в системе промптов, где сказано «делай X, не отвлекайся на другие данные». Агент буквально выполняет X, даже если данные говорят об обратном.

Пример:

Harness настроен так:
1. Получить текущую погоду для города.
2. Если температура > 30°C, отправить уведомление «Жарко».
3. Иначе ничего не делать.

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

Это классический hallucinated execution: агент «галлюцинирует» отсутствие действия, слепо следуя ветвлению инструкции.

Как обнаружить

• Логи с расхождением: агент утверждает, что выполнил действие, но среда не содержит следов этого действия.
• Использование ground-truth трейсов (trace comparison): сравниваем действия агента с ожидаемыми по золотому стандарту.
• Метрика Evidence Override Rate — доля случаев, когда агент проигнорировал данные окружения.

5. Сравнительная таблица failure modes

6. Как обнаруживать failure modes на практике

Для выявления всех трёх режимов следует внедрить мониторинг действий агента (action monitoring) в harness.

Рекомендуемые инструменты

• Trajectory logging — запись каждого шага агента с полным контекстом (вход, выход, состояние среды).
• Alerting — пороговые значения метрик (например, если avg_steps > ожидаемых × 2 — alert on over-decomposition).
• A/B тестирование — сравнение двух версий harness (например, с разным уровнем декомпозиции) на золотом датасете.

Код-пример псевдо-монитора на Python

class HarnessMonitor:
    def __init__(self, expected_steps, max_rejection_rate=0.1):
        self.expected_steps = expected_steps
        self.max_rejection_rate = max_rejection_rate
        self.log = []

    def log_step(self, step_type, action, result, environment_state):
        self.log.append({
            "step_type": step_type,
            "action": action,
            "result": result,
            "env_snapshot": environment_state
        })

    def detect_over_decomposition(self):
        if len(self.log) > self.expected_steps * 1.5:
            return True
        # также можно проверять повторяющиеся типы шагов
        return False

    def detect_over_pruning(self, rejected_actions_count, total_actions):
        rejection_rate = rejected_actions_count / total_actions
        return rejection_rate > self.max_rejection_rate

    def detect_hallucinated_execution(self, ground_truth_trace):
        # сравниваем self.log с золотым стандартом
        mismatch = 0
        for my_step, gt_step in zip(self.log, ground_truth_trace):
            if my_step["action"] != gt_step["action"] or \
               my_step["result"] != gt_step["result"]:
                mismatch += 1
        return mismatch / max(len(ground_truth_trace), 1)

7. Как предотвращать и смягчать failure modes

Over-decomposition

• Использовать адаптивную декомпозицию: позволить агенту самому определять уровень детализации, а не навязывать жёсткую схему.
• Ввести контекстное окно (context window) в harness: агент должен держать в памяти общую цель и регулярно пересматривать её.
• Установить максимальное число шагов не как жёсткий лимит, а как «мягкий предел» с возможностью превышения при обосновании.

Over-pruning

• Заменить чёрные списки на белые списки (whitelist) с возможностью динамического расширения.
• Внедрить контекстную валидацию: действие блокируется только если в текущем контексте оно действительно опасно (например, «удалить файл, который не является временным»).
• Добавить механизм апелляции: если агент считает, что действие безопасно, он может предоставить обоснование (reasoning) и выполнить его без подтверждения пользователя.

Hallucinated execution

• Обязательно ввести проверку реального результата (result validation) после каждого действия — агент должен подтвердить, что среда изменилась ожидаемым образом.
• Добавить в harness re-reading policy: перед выполнением действия, которое зависит от предыдущего, агент обязан перечитать актуальное состояние среды (re-fetch).
• Использовать self-consistency check — попросить агента сформулировать, почему он выбрал именно это действие, опираясь на данные (evidence).

8. Связь с архитектурой Agentic RAG

В контексте Agentic RAG (вопрос 739) harness определяет, как агент использует результаты retrieval. Например:

• Over-decomposition может привести к тому, что агент делает отдельный retrieval на каждый микро-шаг, теряя общую картину.
• Over-pruning может запретить агенту обращаться к внешнему поиску (search) из-за гипотетических рисков.
• Hallucinated execution в RAG проявляется, когда агент игнорирует ретривированные документы и отвечает по шаблону (guidance overrides evidence).

В статье arXiv (источник черновика) эти failure modes описаны именно как проблемы harness-engineering — неправильной настройки системы управления агентом, а не самой модели.

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

Задача Разработать симуляцию AI-агента с простым harness, намеренно внести поочерёдно три failure mode, затем добавить мониторинг и механизмы их коррекции.

Инструменты

• Python + фреймворк LangGraph (или CrewAI) для оркестрации агента.
• SQLite для логирования шагов.
• Простая среда: эмуляция файловой системы (создание, удаление, чтение файлов).

Шаги:

1. Реализуйте базового агента, который получает задачу «отредактировать файл и отправить его по почте» (почта — тоже эмуляция).
2. В первом варианте harness задайте жёсткую декомпозицию на 10 фиксированных шагов. Запустите на 10 разных тестовых сценариях. Соберите метрику avg_steps.
3. Во втором варианте введите 5 правил-запретов в чёрный список (например, «нельзя вызывать функцию delete», «нельзя отправлять файлы больше 1KB»). Запустите сценарии, где требуется удалить временный файл. Замерьте rejection rate.
4. В третьем варианте уберите проверку результата после каждого шага. Агент должен выполнить последовательность без чтения состояния файла. Убедитесь, что он «галлюцинирует» завершение шага. Сравните логи с ground truth.
5. Добавьте мониторинг (класс из раздела 6) и по каждому failure mode реализуйте коррекцию: адаптивная декомпозиция, белый список, проверка результата. Повторите эксперименты и покажите улучшение метрик.

Ожидаемый результат

• До коррекции: avg_steps = 10+ (over-decomposition), rejection_rate = 0.4 (over-pruning), mismatch rate = 0.7 (hallucinated execution).
• После коррекции: avg_steps ~4 (норма), rejection_rate <0.1, mismatch rate <0.1.
• Набор графиков (или таблиц) с улучшением.

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

Навигация

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