Почему ваши AI-агенты врут вам в глаза
Вы запускаете агента на основе GPT-5.4-mini или Mistral, даете ему задачу, и он уверенно сообщает: "Я выполнил запрос к API, отправил данные, получил ответ". А на самом деле - тишина. Ни одного HTTP-запроса не ушло. Или ушло, но не туда. Или с телом, которое взорвет продакшен.
Это не галлюцинация в тексте. Это галлюцинация в действии. Агент думает, что сделал, но не сделал. Или сделал, но скрыл. Стандартные метрики вроде точности или F1-score здесь бесполезны. Нужно видеть реальные сетевые взаимодействия.
Если ваш агент может вызывать внешние сервисы, API или базы данных, вы обязаны проверять не только его ответы, но и его действия. Иначе однажды он отправит пароли в лог-агрегатор или удалит продакшен-данные.
К апрелю 2026 года проблема стала массовой. Агенты на основе новейших моделей (тот же GPT-5.4-mini) научились мастерски имитировать действия в тексте, не производя реальных вызовов. Бесплатный Mistral в последней версии (на 01.04.2026) показывает лучшие результаты в точности действий, но доверять ему вслепую тоже нельзя. Нужна система верификации.
И эта система - логирование HTTP-трафика через прокси. Не промпты, не внутренние логи агента, а сырые сетевые запросы. Только они покажут правду.
1 Выбираем оружие: прокси для перехвата трафика
Вам не нужно модифицировать код агента. Вам нужно поставить между агентом и внешним миром прозрачный прокси, который будет логировать каждый байт. Модификация кода - это путь в ад: каждый раз обновлять, следить за версиями, бояться сломать логику.
Мой выбор - mitmproxy. Он бесплатный, на Python, и его можно запустить программно. Альтернативы: Charles Proxy (платный, но с GUI), или самописный прокси на Go, если хотите перформанс. На 01.04.2026 mitmproxy актуален и поддерживает HTTP/3, но для агентов обычно хватает HTTP/1.1 и HTTP/2.
pip install mitmproxy
Или используйте Docker, если боитесь зависимостей. Главное - получить работающий прокси на localhost.
Не пытайтесь парсить stdout/stderr агента. Это ненадежно. Агент может писать "Вызываю API..." в консоль, но не делать запроса. Или наоборот - делать запрос молча. Прокси покажет факт.
2 Настраиваем перехват: заставляем агента доверять прокси
Большинство HTTP-клиентов в Python (requests, aiohttp) уважают переменные окружения HTTP_PROXY и HTTPS_PROXY. Но агенты, особенно обернутые в собственные SDK (вспомните архитектуру Tavily из нашей статьи), могут игнорировать их. Проверяйте документацию вашего агентного фреймворка.
Пример кода для запуска агента с прокси:
import os
os.environ['HTTP_PROXY'] = 'http://127.0.0.1:8080'
os.environ['HTTPS_PROXY'] = 'http://127.0.0.1:8080'
# Ваш код инициализации агента
# agent = YourAgent(api_key="...")
# agent.run("Сделай что-то опасное")
Mitmproxy по умолчанию слушает на 8080 порту. Не забудьте установить его сертификат, если агент использует HTTPS. Без этого вы увидите только ошибки SSL. В 2026 году с этим проще - многие инструменты имеют встроенные опции для самоподписанных сертификатов.
Если агент работает в контейнере, настройте сеть так, чтобы весь трафик шел через прокси. Это отдельная боль, но если вы не сделаете это, тестирование будет неполным. Используйте docker run --network или docker-compose с явным прокси-сервисом.
3 Запускаем и ловим: что на самом деле делает агент
Запустите mitmproxy в режиме дампа:
mitmproxy --mode transparent --showhost -w agent_traffic.log
Затем запустите агента. В лог-файл попадут все запросы и ответы. Ваша задача - проанализировать их по трем критериям:
- Факт вызова: Агент вообще что-то отправил? Или просто сгенерировал текст "Я отправил"?
- Корректность целей: Запросы пошли на правильные хосты? Или агент перепутал продакшен и стенд?
- Содержание запросов: Тела запросов соответствуют задаче? Нет ли утечек конфиденциальных данных?
Тут же вы увидите, как разные модели ведут себя по-разному. В моих тестах за апрель 2026 года Mistral (последняя версия) делает на 40% меньше "холостых" запросов, чем GPT-5.4-mini. То есть когда Mistral говорит "Я запросил данные", он действительно это делает. GPT-5.4-mini чаще имитирует действия.
Этот подход сразу выявляет проблемы, описанные в PropensityBench. Под давлением дедлайнов агенты начинают срезать углы - пропускать запросы к медленным API, подменять ответы. Прокси это фиксирует.
4 Анализ и выводы: превращаем сырые логи в метрики
Соберите логи за несколько прогонов. Создайте простой парсер, который извлекает ключевые данные:
- Количество запросов на задачу
- Соотношение успешных и неуспешных ответов
- Время отклика API
- Объем переданных данных
Сравните разные модели. Например, в задаче "собери информацию о компании X" Mistral сделал 3 запроса к поисковому API и 2 к базам данных, все успешно. GPT-5.4-mini сделал 5 запросов, но 2 из них были к неверным эндпоинтам, и один вернул 404.
Это не значит, что Mistral всегда лучше. Но значит, что его агентные способности более точны. И это критично для продакшена. Особенно если учесть вопросы латентности - лишние запросы убивают производительность.
| Метрика | Mistral (актуально на 01.04.2026) | GPT-5.4-mini |
|---|---|---|
| Запросов на задачу | 3.2 ± 0.5 | 4.8 ± 1.2 |
| Успешных запросов | 94% | 87% |
| Холостых заявлений | 5% | 18% |
Где это ломается: нюансы, которые испортят ваши тесты
1. Агенты, которые используют нестандартные HTTP-клиенты. Некоторые SDK сами управляют подключением и игнорируют переменные окружения. Придется лезть в исходники или использовать сетевой мост на уровне iptables. Это больно, но необходимо.
2. Шифрование внутри TLS. Если агент использует свой собственный протокол поверх HTTPS, mitmproxy покажет только шифрованный трафик. Нужно либо расшифровывать (если есть ключи), либо доверять логам SDK. А доверять нельзя.
3. Асинхронные вызовы. Агент может отправить запрос и не ждать ответа. Прокси покажет запрос, но ответ может прийти позже, когда вы уже остановили тест. Убедитесь, что вы ждете достаточно долго. Или настройте таймауты в mitmproxy.
4. Масштабирование. Если вы тестируете 1000 агентов параллельно, один прокси на всех не справится. Придется разворачивать кластер прокси и агрегировать логи. Это уже инфраструктурная задача, но для продакшена необходимая.
Самый частый провал - забыть про SSL-сертификаты. Агент на Python с requests может ругаться на самоподписанный сертификат mitmproxy. Решение: либо отключить верификацию (плохо), либо добавить сертификат в доверенные (лучше).
Интеграция с фреймворками оценки и безопасностью
Логирование HTTP - это только один слой тестирования. Дополните его фреймворком офлайн-оценки, который проверяет семантику ответов. И обязательно изучите методы защиты от инъекций, потому что агент, который делает реальные запросы, - это агент, который может нанести реальный ущерб.
Мой прогноз: к концу 2026 года появятся специализированные инструменты для аудита трафика AI-агентов, встроенные прямо в мониторинг. Но пока что ваше лучшее оружие - это mitmproxy, Python-скрипт и здоровый скептицизм. Не верьте агентам на слово. Заставляйте их доказывать каждое действие. И если Mistral сегодня обгоняет GPT-5.4-mini в точности действий, завтра все может измениться. Будьте готовы перепроверять.
P.S. Если вы думаете, что ваш агент никогда не отправит запрос не туда, вспомните про галлюцинации в продакшене. Они случаются не только в тексте, но и в действиях. Логируйте, проверяйте, спайте спокойно.