ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Написать postmortem для неудачного делегирования

1. Цель задачи

Научиться системно анализировать инциденты, связанные с отказом цепочки делегирования между AI-агентами или между человеком и агентом. Написать структурированный postmortem (посмертный анализ) по реальному или смоделированному сценарию, где агент А не справился с задачей, затем агент Б, принявший делегирование, также не смог выполнить её, и система не смогла восстановиться.

Ключевой результат Документ, который позволяет команде разработчиков агентов и инженерам pipeline за <15 минут понять корень проблемы и внедрить меры, исключающие повторение такого сценария.

2. Исходные данные

Перед началом необходимо иметь:

Если нет реального инцидента (рекомендуется симуляция):

1. Создайте минимальную multi-agent систему на LangGraph или CrewAI с двумя агентами:
   • Агент А — выполняет задачу, но имеет лимит ретраев (например, 2 попытки).
   • Агент Б — принимает задачу, если А не справился, но имеет ограничение по времени или контексту (например, слишком длинный промпт от А).
2. Задайте сценарий, где А не может найти нужный инструмент (например, отключён API), а Б получает от А неполный контекст и тоже ошибается.
3. Соберите логи и метрики за 10-20 запусков: часть успешных (baseline) и часть ошибочных.
4. Зафиксируйте метрики «до» и «после» внесения преднамеренной ошибки (например, отключение инструмента search_weather).

3. Технологический стек

4. Этапы выполнения

Этап 1: Обнаружение и первичная диагностика (15-30 минут)

Действия

1. Зафиксировать инцидент делегирования

   • Время начала: 2025-XX-XX XX:XX:XX
   • Какие агенты участвовали? (А и Б)
   • Сколько задач не выполнилось из-за двойного отказа? (X% от общего числа)

2. Собрать первичные данные

   • Логи промптов и ответов А и Б за 5-10 неудачных запусков.
   • Сравнить с baseline (успешные запуски до внесения ошибки).

3. Проверить очевидные причины

   • Были ли изменения в промптах А или Б за последние 24 часа?
   • Отключался ли какой-либо инструмент (API, функция)?
   • Менялась ли конфигурация ролей (лимиты ретраев, таймауты)?

Ожидаемый результат этапа Заполненный раздел «Обнаружение» в postmortem, первая гипотеза: «А не смог выполнить из-за недоступного инструмента, Б не справился из-за неполного контекста».

Этап 2: Глубокий анализ корневых причин (1-2 часа)

Действия

Проанализируйте причины отказа для каждого агента. Используйте таблицу:

Дополнительно

• Постройте граф вызовов (networkx) для неудачных цепочек. Подсветите, где происходит разрыв.
• Вычислите метрику delegation failure cascade: доля отказов, где оба агента ошиблись последовательно, по сравнению с отказами только первого агента.

Ожидаемый результат этапа Root cause с точным описанием: «Агент А не смог выполнить задачу, потому что инструмент get_inventory был отключен на staging, а агент Б не смог принять корректное решение, потому что в контексте от А отсутствовал обязательный параметр warehouse_id».

Этап 3: Устранение и верификация (30-60 минут)

Действия

1. Разработать fix

   • Для А: добавить fallback-инструмент или улучшить обработку ошибок.
   • Для Б: добавить валидацию контекста перед обработкой; если контекст неполный — запросить уточнение у А (цикл feedback).

2. Реализовать fix в симуляции (или staging).

3. Повторить те же сценарии (не менее 10 запусков с преднамеренной ошибкой).

4. Проверить метрики после фикса:

   • success rate для цепочки А→Б: baseline 100% (или хотя бы >90%).
   • Среднее количество шагов не увеличилось больше чем на 20%.

Ожидаемый результат этапа Инцидент не воспроизводится; метрики вернулись к baseline.

Этап 4: Написание postmortem (1-2 часа)

Структура postmortem (обязательные разделы):

# POSTMORTEM: Сбой делегирования между агентом A и B

## Информация об инциденте
- ID инцидента PM-DELEG-YYYY-MM-DD-001
- Дата и время YYYY-MM-DD HH:MM UTC
- Длительность X часов Y минут до обнаружения / до фикса
- [[Вики/severity|Severity]] P1 (критический — остановка цепочки задач)
- Автор [Имя]

## Что случилось (Executive Summary)
[2-3 предложения: "Агент А не смог вызвать API склада, после чего передал задачу агенту Б с неполным контекстом. Агент Б выдал некорректный ответ, инициировав ошибочный заказ."]

## Влияние на пользователей
- Доля неудачных цепочек: 65% → 5% после фикса.
- Какие бизнес-процессы затронуты: обработка заказов.
- Были ли жалобы? Отдел поддержки зафиксировал 3 инцидента с неправильными заказами.

## Таймлайн инцидента
| Время (UTC) | Событие |
|-------------|---------|
| 09:00 | Baseline — success rate 98% |
| 09:15 | Отключён API `inventory` на staging (плановые работы, но не оповещена команда агентов) |
| 09:17 | Агент А получает задачу на заказ; вызывает инструмент — ошибка 503 |
| 09:18 | Агент А выполняет 2 ретрая — всё равно ошибка; переходит к делегированию |
| 09:19 | Агент Б получает от А сообщение без `warehouse_id` (поле отсутствовало в контексте) |
| 09:20 | Агент Б формирует заказ с warehouse_id=null → падение downstream системы |
| 09:25 | Мониторинг регистрирует всплеск ошибок; инцидент создан |
| 09:30 | Откат к предыдущей стабильной версии агентов (v1.2) |
| 09:45 | Success rate восстановлен до 98% |

## Root Cause Analysis
- Причина отказа А Инструмент `get_inventory` был недоступен, ретраи исчерпаны.
- Причина отказа Б Контекст от А не содержал обязательный параметр `warehouse_id`, и Б не имел проверки обязательных полей.
- Системная причина Отсутствие автоматического уведомления команд об изменении статуса инструментов; отсутствие валидации контракта между агентами.

## Действия по предотвращению

| Действие | Ответственный | Срок |
|----------|---------------|------|
| Добавить fallback инструмент для get_inventory (кэш + mock) | Команда DevOps | 2 дня |
| Ввести схему передачи данных между агентами (JSON Schema) и валидацию на стороне Б | Команда ML | 4 дня |
| Настроить оповещение при падении success rate делегирования ниже 95% за 5 мин | Команда мониторинга | 1 день |
| Провести ретроспективу процедуры уведомлений о плановых работах | Tech Lead | 1 неделя |

## Что сработало хорошо
- Мониторинг вовремя зафиксировал всплеск ошибок (PagerDuty).
- Быстрый откат (15 минут) без потери данных.

## Уроки и выводы
- Необходим формальный контракт (схема) для передачи данных между агентами.
- Делегирование без fallback и валидации — источник каскадных отказов.

Ожидаемый результат этапа Полный postmortem в Markdown, готовый к обсуждению на ретроспективе.

Этап 5: Презентация и внедрение улучшений (30-60 минут)

Действия

1. Представить postmortem команде (реальное или ролевое обсуждение).
2. Добавить задачи из раздела «Действия по предотвращению» в трекер (Jira / Linear).
3. Обновить runbook для делегирования (шаблон контракта между агентами).

Ожидаемый результат этапа Все мероприятия по предотвращению заведены, postmortem принят командой.

5. Критерии приемки (Definition of Done)

• Postmortem содержит все обязательные разделы: информация, executive summary, влияние, таймлайн, RCA, действия.
• Указаны root causes для обоих агентов (А и Б).
• Предложены конкретные инженерные меры (код/конфигурация, не только процессные).
• Postmortem написан в Markdown, пригоден для публикации в вики.
• Таймлайн имеет точные временные метки (допускается симулированное время).
• Указаны метрики до/после инцидента (success rate, latency).
• Проведена симуляция (или есть ссылка на реальный инцидент), и инцидент не воспроизводится после фикса.
• Документ прочитан и одобрен хотя бы одним коллегой (peer review).
• Добавлена ссылка на инцидент в трекере (если применимо).

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

Основной артефакт Файл postmortem_delegation_failure.md, содержащий полный postmortem по описанному выше шаблону.

Содержание файла (минимально): Разделы из Этапа 4 (включая таблицы, код вставок, если нужно).
Дополнительно (опционально):

• Граф вызовов агентов (PNG/SVG).
• Python-скрипт анализа логов (analyze_delegation.py).
• Обновлённый конфиг агентов (YAML), реализующий предложенные меры.

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание При первом выполнении рекомендуется заложить 5 ч, включая симуляцию инцидента. Опытный инженер может выполнить за 2-3 ч.

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я написал postmortem, который можно прочитать за 10-15 минут.
• Я указал конкретные root causes для каждого агента, включая технические детали (какой инструмент, какие параметры контекста).
• В разделе «Действия по предотвращению» есть хотя бы одно изменение кода/конфигурации, а не только процессные шаги.
• Я приложил скрипт или логи, подтверждающие, что инцидент не повторяется после fix.
• Я проверил, что все временные метки и метрики согласованы и логичны.
• Postmortem прошел peer review коллеги (хотя бы устное согласование).