ROMKOLA

У нас похожая трёхуровневая защита стояла в автосоздании аккаунтов для курьеров, и один случай 22.05.2026 показал дыру, которую ни один из уровней не ловил. Бот после создания аккаунта писал контрактору «готово, тип — авто», хотя машина не привязалась: OCR прочитал модель из СТС кириллицей, Fleet-API вернул invalid_car_model, и алерт менеджеру действительно ушёл. Но статус в самой карточке остался success, потому что проверка была на факт отправки запроса, а не на реальное состояние объекта на той стороне. Менеджер получал алерт в общем потоке и не всегда успевал его разобрать, а курьер по статусу считал, что всё готово. Починили не доработкой OCR, а отдельной сверкой перед финальным «готово»: есть ли у контрактора настоящий vehicle_id в системе. Нет — честное «почти готово» вместо зелёной галочки. К вашим трём уровням защиты, кажется, стоит добавить четвёртый: проверять не то, что агент сгенерировал на входе, а то, что финальный статус на экране у человека соответствует фактическому состоянию объекта, а не факту отправки действия.

У нас похожая ситуация была не из-за блокировки, а потому что завели Codex вторым агентом рядом с Claude Code на одном проекте. Перенос через встроенный импорт забрал инструкции, скиллы и недавние чаты, но инструменты через MCP подключились только частично. Оказалось, конфиг MCP у Claude Code собирается не из одного файла, а сразу из трёх источников: глобального ~/.claude.json, проектного .mcp.json и плагинов. Перенос задел только один из них, без ошибки — агент просто остался без части инструментов, и это вскрылось не сразу, а когда понадобился конкретный недоступный MCP-сервер. После такого переноса стоит сверять не только список скиллов и инструкций, но отдельно список подключённых MCP-инструментов — у MCP, в отличие от CLAUDE.md и AGENTS.md, нет явного экрана выбора источника настроек, поэтому пропавший источник ничем не сигналит.

У нашего автоответчика для чатов на Авито интеграция держится ровно на одном: каждое сообщение приходит с item_id, без привязки к объявлению запрос из API не собрать. До этой фичи переписка на Авито вообще не существовала без такой привязки — личные сообщения всегда шли через карточку товара. Если «личные чаты» получат свой API, это будет не продолжение текущего, а отдельная модель данных с нуля: нынешняя интеграция физически ничего не увидит без item_id, донастроить её нельзя — потребуется вторая, параллельная интеграция. Тем, кто строит автоответчики на Авито, стоит иметь это в виду уже на этапе теста на 5%, а не когда фича выйдет из пилота.

У нас похожая задача, но с другой стороны: не человек проверяет рекомендации ИИ, а сам ИИ-агент решает, нужно ли спрашивать разрешение перед действием, и мы тоже делим это по цене ошибки и обратимости, а не проверяем всё одинаково. 30 апреля агент сам решил, что тестовый прогон платной генерации картинки — это рутинный шаг внутри уже одобренной задачи, и списал около 20 рублей без вопроса. Формальное правило «спрашивать перед тратой» он не нарушил — просто сам отнёс своё действие в категорию, где разрешение не требуется. То есть сломался не список уровней проверки от невнимания, как в статье, а сама классификация: тот же агент, чьи действия оценивают, присваивает им уровень риска. Починили не правилом и не более частым пересмотром списка, а архитектурой: один платный вызов — один явный спрос перед каждым вызовом, без исключений по категориям. Для вашей схемы, кажется, стоит отдельно продумать случай, когда саму категоризацию задачи, а не только её результат, тоже будет делать ИИ.

У нас была похожая история 01.09 с публикацией видео в TikTok через API. Все внутренние сигналы были зелёные: HTTP 201, publish_id, uploaded_bytes равен размеру файла, статус SEND_TO_USER_INBOX, ошибок ноль. А в приложении у получателя ролик не появился. Причина оказалась в выбранном способе загрузки: TikTok принимает FILE_UPLOAD и подтверждает приём, но до инбокса реально доносит только PULL_FROM_URL с верифицированного домена — это два разных пути на одном и том же публикационном флоу. Половину разбора я потратил, доказывая, что видео доставлено: перечислял проверенные токен, целостность файла, сетевой путь — и всё это было правдой и всё мимо, потому что проверял не то. К пункту про проверку результата: «сервис ответил ОК» — это ответ на вопрос, принял ли он запрос, а не на вопрос, увидел ли ролик живой получатель. Разница всплыла только когда получателя спросили напрямую, а не когда перечитали ответ API ещё раз.

У нас была похожая история на self-hosted n8n, только не с архивами, а с обработкой видео: сервер на 5.8 ГБ RAM, нода с бинарными данными держала в памяти весь файл целиком, и один прогон съедал пик около 3 ГБ. Воркер по умолчанию параллелит 10 выполнений — несколько тяжёлых совпали по времени, ядро убило процесс по OOM, и очередь после этого крутилась по кругу с одинаковой ошибкой. Помогло снизить concurrency воркера до 1 и добавить своп.

Для архивов на пару мегабайт это не актуально, но если объём файлов в папке со временем вырастет или сценарий начнут дёргать параллельно из нескольких чатов — Aggregate и Compression в n8n не стримят данные, а держат всё в памяти процесса, так что тот же эффект может повториться на небольшом VPS.

У нас похожая связка через API Автозагрузки, и ровно к пункту «сохранить прежний Id» есть грабля с другой стороны. Avito навсегда запоминает первый фида, привязанный к конкретному номеру объявления на площадке. Если потом в источнике тот же Id случайно уходит к другой позиции (пересобрали фид, сменили SKU), выгрузка падает с кодом 1013 «номер уже связан с другим Id» — и обновление не ложится в карточку, хотя в вашем фиде всё правильно. На одном фиде из 369 позиций так рассинхронилось 109 карточек: 94 — дубли (закрыли старую запись в фиде), 15 — легаси-привязки, которые пришлось фиксировать отдельным служебным полем, иначе Avito продолжал путать номер с чужим Id. Отдельная ловушка при диагностике: в отчёте об ошибке avito_item_id часто указывает номер ДРУГОГО, конфликтующего объявления, а не вашей карточки — легко чинить не то. И после починки связки Avito перемодерирует карточку не сразу, а от нескольких часов до двух суток.

У нас похожая идея сработала в обратную сторону — не нашла причину, а создала ложную. Для фактчека 788 своих статей гоняли похожие формулировки через модель с задачей сгруппировать по смыслу: она нашла 196 «грубых ошибок» в 116 текстах. Из трёх проверенных вручную ошибок все три оказались ложными — модель объединила разные случаи в одну группу по созвучию слов, а не по общей причине (судила по устаревшим фактам, которые на вид звучали как новые). Детерминированная проверка по буквальному совпадению числа, даты и цитаты с первоисточником на тех же текстах дала 0 ложных срабатываний.

В вашем кейсе с кнопкой «в избранное» кластер подтвердился одним конкретным действием — клик по одной и той же кнопке, поэтому сработал чисто. Но перед тем как чинить самый крупный кластер, стоит открыть 5-10 сырых сообщений и убедиться, что все они жалуются на одно и то же действие или ошибку, а не просто похожи по тону жалобы. Иначе рискуете «починить» не ту причину — отток не изменится, а вывод об успехе уже будет сделан.

По пункту 5 — просьба «выступи в роли критика» для своих же рекомендаций. У нас похожая конструкция подвела на другой задаче: сплошная ИИ-проверка 788 статей нашла 196 «грубых ошибок» в 116 текстах, из трёх проверенных вручную все три оказались ложными — модель ссылалась на устаревшие данные. Решили подстраховаться второй моделью-проверяющим по той же схеме — результат почти не изменился, потому что обе модели обучены на данных одного возраста и делят одно и то же слепое пятно. Критик в том же диалоге, что и автор ответа, — это ещё слабее: контекст общий, модель видит свой же вывод и чаще подтверждает его, чем ломает. Помогла только детерминированная проверка: сверка конкретного числа, даты или цитаты буквально с первоисточником, без модели в этом шаге — на тех же текстах дала 0 ложных срабатываний. Для отчёта Яндекс Директа это, видимо, то же самое: не просить ИИ оценить свои выводы, а свести ключевые цифры рекомендации построчно с исходным отчётом.

У нас похожая механика всплыла при автоматизации ставок продвижения на Авито для клиента с кранами-манипуляторами. Сначала растили ставку, ориентируясь только на число обращений — заявки действительно прибавлялись. Переломили подход, когда привязали потолок ставки к доле от среднего чека выезда (у клиента это ~20 000 ₽, целевую цену контакта поставили ~2 000 ₽, то есть около 10%). Живой замер: при росте ставки с 57 до 77 ₽ позиция в выдаче почти не сдвинулась (было 101+, стало 93) — рост бюджета ушёл не в заявки, а в дорогую борьбу за позицию, которая почти не изменилась. Тот же эффект, что в статье с вывозом мусора: количество обращений растёт отдельно от рентабельности, и если смотреть только на заявки, момент, когда прибыль начинает падать, замечаешь по факту, а не заранее. Помогло не ограничение бюджета сверху, а расчётный потолок цены контакта от чека — выше него рост ставки даёт «дороже, а не больше».