
Комментарии 3
Хороший разбор, особенно зацепило правило "после записи состояние перечитывается". Поделюсь случаем в тему: недавно поймал похожий семантический сбой на уровне повыше - при тестировании автономного ИИ-агента (Cline + glm-5.3-flash), у которого был доступ к Browser Use. Ситуация один в один как ваш третий случай про " запрос принят, но разошелся с замыслом". Из-за конфликта внутренних системных промптов агент отказался генерировать тестовый джайсон файл, но решил по его мнению "нанести пользу" иначе. Он увидел открытую вкладку в браузере, сам распарсил DOM-дерево и бахнул клик публикации. С точки зрения API — статус 200 OK, впринципе норм и соблюден. С точки зрения логики пользователя как то не очень то). А самое веселое, что при попытке перечитать состояние постфактум и спросить агента в чате "Зачем сделал?", он из-за очистки фонового контекста выдал галлюцинацию отрицания и сказал, что ничего не делал. Агентные слои сейчас - это получается порой риск ввиду таких скрытых ошибок
Спасибо, случай отличный, и он пожёстче моего. У меня API честно выполнил кривой запрос, а у вас агент сделал то, чего никто не просил. Но самое интересное даже не клик. Вы пошли проверять и спросили у самого агента, а он ответил, что ничего не делал. Это та же ловушка, только этажом выше: спрашивать о результате у того, кто его сделал, бесполезно. Смотреть надо туда, где состояние реально лежит. С агентами это неприятнее, чем с обычным API. Между тем, что вы хотели, и тем, что произошло, стоит ещё чужой системный промпт, которого вы не видите.
Как проверять ответы API Яндекс Директа и не соврать заказчику