TL;DR
Агенты могут "выполнить задачу", но при этом нарушить политики, пропустить критические проверки или использовать неправильную последовательность действий. Исследователи из IIIT-Hyderabad и MontyCloud столкнулись с этим в продакшене: CloudOps-агенты закрывали тикеты, но при проверке выяснялось, что они не консультировались с политиками безопасности или пропускали обязательные диагностические шаги. Классические метрики ("задача выполнена / не выполнена") такие проблемы не ловят.
Авторы выделили 4 источника ошибок в агентных системах: LLM (следует ли инструкциям и политикам), Memory (правильно ли сохраняет и находит информацию), Tools (выбирает ли правильный инструмент с правильными параметрами в правильном порядке), Environment (соблюдает ли ограничения и разрешения). Проблема: LLM-модели недетерминированы — при одном и том же промпте могут выбрать разные пути выполнения. Эта вариативность проходит через всю систему: модель то вспоминает нужный контекст, то нет; то вызывает инструменты в правильном порядке, то пропускает шаги.
Фреймворк оценивает агентов по трём слоям: статический анализ (проверка логов и траекторий против эталонов), динамическое выполнение (мониторинг в рантайме — какие инструменты вызваны, какие запросы к памяти сделаны, какие политики проверены), и judge-оценка (качественная проверка рассуждений и безопасности через LLM-as-Judge). Эксперименты на CloudOps-сценариях показали: 100% задач формально выполнены, но детальная проверка выявила массу поведенческих ошибок — неправильный порядок действий, отсутствие диагностики перед исправлением, игнорирование политик.
Применимые принципы для работы в чате
Это исследование про инфраструктуру оценки агентных систем с кодом и метриками. Читатель не может взять фреймворк и применить напрямую. НО можно извлечь принципы, которые сделают работу с LLM надёжнее — особенно если используешь Projects в ChatGPT/Claude, Custom Instructions, или ведёшь долгие диалоги с контекстом.
1. Проверяй процесс, а не только результат
Проблема: Модель может дать правильный ответ, но "неправильным путём" — без обращения к нужному контексту, с пропущенными проверками, с нарушением последовательности.
Принцип: Требуй от модели показывать шаги рассуждений и какие части контекста она использовала.
Пример промпта:
Проанализируй {задачу}.
Перед ответом покажи:
1. Какие части контекста/документов ты проверил
2. Какие шаги рассуждений сделал
3. Какие альтернативы рассмотрел
Затем дай финальный ответ.
Зачем: Ты увидишь, если модель проигнорировала важный документ или политику, которые ты загрузил в контекст. Это особенно критично в Projects, где модель имеет доступ к большому объёму информации.
2. Структурируй инструкции явно
Проблема: При абстрактных инструкциях ("оптимизируй облачную инфраструктуру") модель может пропустить обязательные шаги — диагностику перед действием, проверку разрешений, валидацию результата.
Принцип: Вместо "сделай X" → задавай workflow пошагово с явными условиями и проверками.
Пример промпта:
Задача: {оптимизировать расходы на рекламу в Яндекс.Директе}
Workflow:
1. Сначала проанализируй текущую статистику (CTR, CPC, конверсии)
2. Найди кампании с аномалиями (низкий CTR при высоком бюджете)
3. ОБЯЗАТЕЛЬНО: Проверь в документе "Политика рекламы" — есть ли ограничения на изменение ставок
4. Предложи оптимизацию с обоснованием
5. Покажи прогноз экономии в рублях
Не пропускай шаг 3 — без него не действуй.
Зачем: Явная последовательность снижает вариативность поведения. Модель следует чёткому плану, а не "придумывает путь на лету".
3. Требуй консультации с контекстом
Проблема: Модель может ответить из общих знаний, игнорируя загруженный контекст (документы, политики, примеры).
Принцип: Явно требуй проверки контекста перед действием.
Пример промпта:
Ты консультант по карьере. В контексте проекта есть документ "Моя карьерная стратегия 2025".
Правило: Перед любым советом ОБЯЗАТЕЛЬНО процитируй релевантные части из "Моя карьерная стратегия 2025". Если совет противоречит стратегии — укажи явно и объясни почему предлагаешь отклонение.
Задача: {стоит ли переходить в стартап или остаться в корпорации?}
Зачем: Ты увидишь, обратилась ли модель к твоим документам или отвечает "из головы". Это критично для Projects и Custom Instructions с большим контекстом.
4. Валидируй "память" через саммари
Проблема: В длинных диалогах модель может "забыть" ранние договорённости, детали, ограничения. Memory retrieval ненадёжна — модель не всегда вспоминает нужное в нужный момент.
Принцип: Периодически проси модель подытожить, что она помнит. Проверяй, не потерялись ли критические детали.
Пример промпта:
Мы обсуждаем {разработку MVP для сервиса аренды}.
Перед тем как продолжить, подытожь:
1. Какие ограничения по бюджету мы установили?
2. Какие фичи решили НЕ включать в MVP?
3. Какие технические требования обсудили?
Если что-то забыл — скажи, я напомню.
Зачем: Ты выявишь пробелы в "памяти" модели до того, как она предложит решение, противоречащее ранним договорённостям. Это аналог проверки Memory Retrieval из фреймворка — только вручную.
5. Проверяй "инструменты" и параметры
Проблема: Если даёшь модели доступ к функциям/API/кастомным GPT, она может выбрать неправильный инструмент или передать некорректные параметры.
Принцип: Требуй от модели объяснять выбор инструмента и показывать параметры перед вызовом.
Пример промпта (для Custom GPT с actions):
У тебя есть доступ к API: get_weather, book_ticket, send_email.
Правило: Перед вызовом API покажи мне:
1. Какой API ты выбрал
2. Какие параметры передашь
3. Почему этот API подходит для задачи
Жди моего подтверждения, затем вызывай.
Задача: {узнай погоду в Москве на выходные и забронируй билет в музей, если будет солнечно}
Зачем: Ты поймаешь ошибки до выполнения — неправильный API, неправильные параметры, неправильная последовательность. Это аналог Tool Selection и Parameter Mapping из фреймворка.
Почему это работает
LLM-модели недетерминированы: при одинаковых промптах могут выбрать разные пути выполнения. Модель генерирует текст вероятностно — иногда она "вспоминает" нужный контекст, иногда нет; иногда следует инструкциям строго, иногда отклоняется. Эта вариативность — не баг, а свойство архитектуры.
Сильная сторона LLM: модель отлично следует явным структурированным инструкциям и генерирует текст по заданному паттерну. Если промпт содержит чёткий workflow ("сначала сделай А, потом Б, не пропускай В") — модель выполняет его надёжнее, чем абстрактное "сделай задачу".
Как принципы снижают вариативность: - Явный workflow сужает пространство возможных путей выполнения — модель не "придумывает" последовательность, а следует заданной. - Требование показывать шаги делает процесс прозрачным — ты видишь, если модель отклонилась от ожиданий. - Консультация с контекстом снижает риск "ответа из общих знаний" — модель явно обращается к загруженным документам. - Саммари "памяти" выявляет пробелы в retrieval — модель явно формулирует что помнит, ты проверяешь полноту.
Рычаги управления: - Строгость workflow: "ОБЯЗАТЕЛЬНО сделай шаг 3" vs "желательно сделай шаг 3" — первое снижает вероятность пропуска. - Требование подтверждения: "Покажи план, жди подтверждения, затем действуй" vs "Сразу действуй" — первое даёт контроль до выполнения. - Частота саммари: Проверяй "память" каждые 5 сообщений в критичных диалогах, каждые 15 — в обычных.
Ограничения
⚠️ Ручная работа: Эти принципы требуют активного участия — ты должен проверять выводы модели, валидировать шаги, запрашивать саммари. Это не автоматическая система оценки, а набор практик для более надёжной работы.
⚠️ Не гарантия детерминизма: Даже с явными инструкциями модель остаётся вероятностной. Принципы снижают вариативность, но не устраняют полностью — модель всё ещё может отклониться, особенно при сложных задачах.
⚠️ Overhead для простых задач: Если задача тривиальна ("напиши email с благодарностью"), требование показывать шаги рассуждений избыточно. Эти принципы для критичных сценариев — долгие диалоги, сложный контекст, важные решения.
⚠️ Применимость к сложным агентным системам: Исследование показало проблемы в multi-agent системах с кодом и инфраструктурой. Описанные принципы — упрощённая адаптация для одиночного диалога в чате. Для настоящих агентных систем нужен полноценный фреймворк оценки с метриками и мониторингом.
Ресурсы
Beyond Task Completion: An Assessment Framework for Evaluating Agentic AI Systems Авторы: Sreemaee Akshathala, Bassam Adnan, Mahisha Ramesh (SERC, IIIT-Hyderabad), Karthik Vaidhyanathan, Basil Muhammed, Kannan Parthasarathy (MontyCloud Inc)
GitHub с экспериментами: https://github.com/sa4s-serc/asf
MOYA framework: упоминается как основа для экспериментов [19]
Mem0: инструмент для memory механизмов [5]
Arize Guards: open-source решение для мониторинга guardrails
Strands Agents: observability для агентов