Агент асинхронного ревью видео – паттерн архива

Коротко

Агент асинхронного ревью видео – это ИИ-система, которая самостоятельно, в своём темпе, обрабатывает большой объём записанного видео: бэк-каталог, очередь на модерацию, архивы, накопленные за годы, – и выдаёт структурированный вердикт по каждому клипу без участия человека. Это тот же цикл агента, что рассматривался в предыдущих уроках, но вместо одного быстрого ответа он работает как флот воркеров над очередью: каждое видео проходит этапы восприятия, анализа, действия и наблюдения, и система обрабатывает тысячи или миллионы элементов за часы или дни.

Поскольку на другом конце никто не ждёт немедленного результата, инженерная цель смещается с скорости на две другие приоритетные задачи – снижение стоимости и повышение надёжности. Стоимость удаётся сократить за счёт batch-API, которые вдвое дешевле, и за счёт воронки «сначала дешёвый фильтр». Надёжность же означает способность системы, упавшей на элементе 47 000, продолжить работу с 47 001, а не начинать сначала.

Тот же подход в 2026 году стал основой для петабайтной модерации, обогащения метаданных в OTT-платформах и переобработки архивов. Его применение напрямую связано с законом о прозрачности модерации и правилами раскрытия информации об использовании ИИ – поэтому грамотный дизайн предусматривает версионирование каждого запуска, эскалацию спорных случаев к людям и ведение аудит-лога, фиксирующего, что и по какой причине было решено.

Почему это важно

У каждого видеопродукта со временем накапливается архив, который невозможно пересмотреть вручную: у стримингового сервиса – каталог за десять лет, у соцприложения – бесконечная очередь на модерацию, у онлайн-школы – библиотека без тегов, у системы видеонаблюдения – месяцы записей. Обработка такого объёма – разметка, модерация, создание субтитров, проверка по обновлённой политике – это именно та медленная и однообразная работа, которую агент выполняет хорошо, а люди в больших масштабах – плохо. Если вы разрабатываете софт для стриминга, OTT, конференций, онлайн-обучения, телемедицины или видеонаблюдения, этот урок объясняет, что такое асинхронный агент для ревью, почему отсутствие временных ограничений кардинально меняет подход к дизайну и где скрываются подводные камни стоимости и надёжности. Писать конвейер с нуля не обязательно, но важно понимать достаточно, чтобы отличить грамотное решение от расточительного: спрашивает ли агент каждый кадр или сначала фильтрует, выдержит ли задача сбой и видит ли человек те случаи, которые действительно важны. Это третий и последний из трёх прикладных уроков про агентов; он использует ту же основу, что и агент-исследователь видео и агент-копилот встречи, но нацелен теперь на постоянный архив, а не на живой момент.

Что такое async-агент ревью – и чем он не является

Быстрее всего понять этого агента – поставить его рядом с двумя его собратьями из прошлых уроков, потому что все трое выполняют один и тот же цикл, а различие заключается исключительно в том, когда происходит работа.

Копилот встречи из прошлого урока живёт под часами. Он сидит в живом звонке и имеет меньше секунды, чтобы быть полезным – иначе он перебьёт собеседника. Агент-исследователь отвечает на один вопрос по запросу: вы спрашиваете «кто зашёл в бокс после 22:00?» – и он проводит расследование, после чего докладывает, реагируя на ваш запрос. Async-агент ревью – это третья форма: он просматривает постоянную груду видео в своём темпе, не дожидаясь запроса и не ограниченный одним вопросом. Никто не вводит команду; задача звучит просто: «проверь всё в этом архиве по этому правилу и дай вердикт по каждому элементу». Ключевое слово – async, сокращение от asynchronous – «асинхронный», что означает: запрос и результат разделены во времени. Вы отдаёте агенту миллион видео утром – он возвращает миллион вердиктов вечером или на следующий день.

Полезно чётко обозначить границу: с одной стороны – обычный batch-скрипт, с другой – не он. Batch-скрипт – это примитивный цикл («выполни одну и ту же операцию для каждого файла»), существующий десятилетиями. Async-агент ревью отличается тем, что каждый элемент получает полноценную агентскую обработку: агент планирует, как именно анализировать это видео, выбирает, какие инструменты использовать, исходя из найденного, и рассуждает, прежде чем вынести вердикт, а не применяет жёсткое правило. Batch-скрипт просто перекодирует каждое видео в меньший размер; агент же просматривает видео, решает, нарушает ли оно новую политику безопасности, и фиксирует причину. Цикл, планирование и использование инструментов – вот что делает его агентом. Эти три примитива, о которых шла речь в уроке про примитивы агента, мы постоянно возвращаемся к ним, потому что именно они составляют основу каждого агента в этой секции.

Что он, собственно, выдаёт? По каждому видео в архиве – структурный вердикт: набор тегов, решение по модерации, список глав, флаг соответствия, дорожку субтитров – всё, что требуется по задаче, – вместе с уликами, подтверждающими это: таймкод, кадр, строка транскрипта, и оценкой уверенности. Архив поступает на вход в сыром виде, а выходит размеченным, обработанным и готовым к поиску.

Нажмите, чтобы увеличить

Цикл ревью, запущенный как флот

Каждый агент проходит цикл – восприятие, анализ, действие, наблюдение – и мы уже рассматривали этот цикл в уроке про цикл агента. Async-агент ревью выполняет ровно тот же цикл, но с одним ключевым отличием, которое и определяет весь паттерн: цикл работает по каждому видео, и множество его копий функционируют одновременно, беря задачи из общей очереди.

Представьте архив как длинную очередь – линию видео, ожидающих обработки, где каждое – это отдельный рабочий тикет. Очередь здесь – просто упорядоченный список задач, из которого могут брать работу несколько воркеров. Пул воркеров – каждый из них представляет собой копию агента, запущенного на отдельной машине или в отдельном процессе – берёт следующий тикет из очереди, выполняет полный цикл обработки одного видео, фиксирует результат и возвращается за следующей задачей. Десять воркеров обработают очередь в десять раз быстрее одного; тысяча – в тысячу раз. Это паттерн fan-out: распределение одной большой задачи между множеством параллельных воркеров. Так миллион видео пересматривается за ночь, а не за год.

Пройдём один тикет медленно – и цикл станет конкретным. Воркер берёт видео #438 201. Он воспринимает его, экономно сэмплируя – извлекая транскрипт и несколько отдельных кадров, а не каждый кадр (объясним через минуту, почему это важно для стоимости). Он анализирует увиденное по правилу задачи: есть ли в этом клипе то, что мы ищем? Он планирует следующий шаг – «в звуке упоминается заявление о продукте; вытащи три кадра вокруг этого таймкода и внимательно их проанализируй». Он действует, вызывая инструмент – vision-language reader – на этих кадрах. Результат возвращается как наблюдение. Агент рассуждает ещё раз, приходит к вердикту с оценкой уверенности и записывает его в каталог. Тикет готов; следующий тикет.

Две вещи делают флот надёжным, а не хаотичным. Первая – чекпойнт-хранилище, надёжная запись о том, какие тикеты готовы, какие находятся в работе, а какие провалились – чтобы флот всегда знал своё текущее состояние. Вторая – шлюз эскалации в конце: большинство решений, в которых агент уверен, сразу записываются в каталог, а спорные или рискованные направляются на ручное ревью, а не обрабатываются автоматически. Агент предлагает; в важных случаях решение принимает человек. Этот шлюз – тот же принцип «человек в контуре», которым заканчивались все схемы в предыдущих двух уроках, и здесь он также остаётся без обсуждения.

Нажмите, чтобы увеличить

Набор инструментов – и воронка, которая за него платит

Агент способен лишь настолько, насколько хороши инструменты, которые вы ему предоставили, и самое важное проектное решение в этом уроке – порядок, в котором эти инструменты выстроены. Порядок – это воронка: дешево и быстро – в широкой части, дорого и умно – в узком конце. Попасть в неё правильно означает выбрать между задачей на архив за пару сотен долларов и задачей за сто тысяч.

Вот ошибка, которую воронка предотвращает. Прямой способ проанализировать видео с помощью ИИ – отправить каждый кадр в визуально-языковую модель – модель, способную «видеть» изображение и отвечать на вопросы о нём словами. Мы будем называть её reader. Это самый умный, но и самый дорогой инструмент в наборе. Одна минута видео при тридцати кадрах в секунду – это 1800 кадров, час – 108 000. Запускать reader на каждом кадре большого архива – значит превратить разумную идею в бюджетную катастрофу. Тот же тезис о стоимости обработки одного кадра мы уже обсуждали в уроке про агента-исследователя; в паттерне архива он становится ещё острее, потому что нет единственного вопроса, который сузил бы поиск – агент вынужден рассмотреть всё.

Поэтому набор инструментов построен как воронка – с самого широкого и дешёвого этапа в начале. Первый инструмент – дешёвый фильтр: он обнаруживает смену планов и быстро транскрибирует видео, разбивая его на несколько осмысленных сегментов и отбрасывая всё лишнее – пустые кадры, статичные титры, пустые коридоры. Второй – сэмплер кадров: вместо каждого кадра сегмента он выбирает несколько, которые действительно его представляют – по одному на план или по одному в секунду, потому что соседние кадры почти идентичны, и reader не извлекает из девяноста почти одинаковых кадров почти никакой новой информации. Компромисс «сэмплирование против стриминга» мы подробно разбираем в уроке про video VLM. Только после того как первые два инструмента выполнили своё сужение, запускается третий – reader, который теперь работает с несколькими десятками кадров на видео, а не с сотнями тысяч. Четвёртый инструмент – судья по политике (rubric) – превращает описание от reader в структурированный ответ, нужный для задачи («подходит ли это под категорию 4 политики модерации? да, уверенность 0,91»). Пятый – запись в каталог – надёжная фиксация вердиктов в базе данных, поисковый индекс или контент-систему, где они будут храниться. Шестой – роутер эскалации – инструмент, который вместо записи вердикта направляет элемент в очередь на ручное ревью, если уверенность низкая, а последствия – высокие.

Воронка – это вся игра. Частая и дорогая ошибка – пропустить её, сразу подавать читателю сырое видео «потому что модель теперь умеет работать с видео». Умеет; ваш счёт – нет. Сначала постройте дешёвый фильтр и сэмплер, докажите, что они сокращают объём, поступающий к читателю, в десять или сто раз, и только потом включайте дорогой инструмент.

Нажмите, чтобы увеличить

Преимущество «без часов» – почему async экономит деньги

Прошлый урок жил и умирал в течение одной секунды – по жёсткому бюджету времени. У этого урока – обратная свобода, и она стоит настоящих денег. Поскольку ответа никто не ждёт, агент может вызывать модель самым дешёвым, медленным и терпеливым способом – а поставщики моделей берут за терпение значительно меньше.

Рычаг – это batch-API, способ отправить большой пакет запросов и получить результаты позже, а не мгновенно. Все три крупнейших провайдера моделей предлагают такую возможность, и в 2026 году у всех одинаковое условие: скидка 50% в обмен на согласие ждать результаты до суток. OpenAI Batch API принимает файл с до 50 000 запросов и возвращает результаты в течение 24 часов со скидкой 50%. Anthropic Message Batches API обрабатывает до 100 000 запросов или до 256 МБ на пакет, выдаёт результаты в течение 24 часов (большинство – менее чем за час), хранит их доступными 29 дней и также стоит вдвое дешевле. Google Gemini Batch Mode работает с JSONL-файлами до 2 ГБ и тоже на 50% дешевле синхронного API. Реальному времени агент не может позволить себе ждать сутки – он не дотянется до этих цен. А асинхронный агент может – и получает тот же уровень интеллекта за половину стоимости, просто не торопясь.

Сложите воронку и batch-скидку в проработанном примере – ведь именно в арифметике и заключается суть. Допустим, нужно переработать архив из 100 000 видео, в среднем по десять минут каждое. Наивный подход отправляет каждый кадр в reader: десять минут при 30 кадрах в секунду – это 18 000 кадров, а значит, весь архив составляет 1,8 миллиарда кадров. При любой реальной стоимости обработки одного кадра reader итоговый счёт выйдет в миллионы.

Теперь применим воронку. Дешёвый фильтр и сэмплер сокращают каждое видео, скажем, до 40 представительных кадров – с 18 000 до 40, то есть в 450 раз меньше. Это даёт 100 000 × 40 = 4 миллиона кадров, поступающих в reader, вместо 1,8 миллиарда. Далее используем batch-скидку: цена за кадр снижается вдвое, и оставшийся счёт тоже уменьшается наполовину.

Воронка выполнила основную работу – сократила нагрузку примерно в 450 раз, – а batch-API дополнительно уполовинил расходы. Вместе они превратили нереальную сумму в плановую статью бюджета. Точная цифра в долларах зависит от модели и года, поэтому мы поддерживаем реальную стоимость ИИ в видеопродуктах как живой справочник; при этом структура экономии остаётся неизменной.

Есть и третья экономия, которую даёт режим «без часов» помимо batch-цен и воронки: тяжёлую работу можно запускать когда вычисления дёшевы. Облачные машины, арендуемые из избыточной мощности, которую провайдеры уценивают – их называют spot или preemptible инстансами – могут стоить долю от обычной цены, и задача без дедлайна спокойно их использует, мирясь с тем, что воркер могут отобрать посреди выполнения. Вот эта последняя часть – «отобрать посреди выполнения» – и есть причина, почему важен следующий раздел: дешёвые прерываемые вычисления безопасны только если ваша задача способна пережить прерывание.

Сложная часть – надёжность в масштабах архива

Вот отказ, который определяет весь этот паттерн. Ваш флот обработал 80 000 видео из 100 000, идёт двенадцатый час, и система падает – spot-инстанс отобрали, сеть дрогнула, кривое видео сломало reader. В наивном дизайне задача завершается, и вы начинаете сначала с видео №1, теряя двенадцать часов и столько же денег. Самое важное инженерное свойство async-агента ревью в том, что этого не может случиться. Задача обязана продолжиться с элемента 80 001, а не с первого. У этого свойства есть имя – надёжность (durability), то есть «работа переживает сбой» – и строится оно из четырёх идей, которые стоит знать по именам.

Первая – чекпойнтинг: фиксировать прогресс по ходу работы, чтобы система всегда знала, что уже выполнено. Каждый раз, когда воркер обрабатывает видео, он сохраняет вердикт и помечает тикет как завершённый в надёжном хранилище – только после этого берёт следующий. Если флот падает, новый флот читает хранилище, видит, что 80 000 тикетов уже готовы, и продолжает с оставшихся 20 000. Ничто из уже оплаченного не будет оплачено дважды.

Вторая – ключ идемпотентности, термин, который стоит разобрать подробно. Идемпотентность означает, что операция всегда даёт один и тот же результат, сколько бы раз её ни выполнить: например, нажатие кнопки этажа в лифте – идемпотентное действие. Нажми хоть пять раз – тебя всё равно отвезут на один и тот же этаж. Ключ идемпотентности – это стабильная метка единицы работы, позволяющая системе распознать: «я уже выполнил именно это». Такой ключ формируется из ID видео, версии применяемой модели и политики – например, video-438201 · reader-v3 · policy-2026-06. Перед обработкой тикета воркер проверяет, существует ли уже вердикт с таким ключом; если существует – задача пропускается. Именно это делает повторный запуск безопасным: без такой проверки перезапуск задачи привёл бы к повторному рассмотрению и повторной оплате каждого уже обработанного видео, превратив сбой в двойную оплату.

Третья стратегия – повтор (retry) с очередью недоставленных (dead-letter queue). Некоторые видео не обрабатываются – из-за повреждённого файла, неподдерживаемого формата или временного сбоя в работе reader’а. Флот повторяет попытку несколько раз, ведь большинство сбоев носят временный характер. Но если видео продолжает падать при каждой попытке – это «ядовитый» элемент, который не должен блокировать всю систему навсегда. Поэтому после исчерпания всех попыток его перемещают в очередь недоставленных (dead-letter queue) – отдельный «загон» для элементов, которые больше не могут быть обработаны автоматически, но требуют ручного вмешательства. Пока флот продолжает работать, человек позже разберётся с проблемой. Одно плохое видео из миллиона должно потребовать одного ручного разбора, а не парализовать обработку остальных 999 999.

Четвёртая – оркестрация: дирижёр, объединяющий три предыдущие идеи и запускающий весь workflow целиком. В 2026 году стандартный инструмент для этого – движок durable-execution, самый известный из которых – Temporal. Он фиксирует каждый шаг workflow в виде event-логов, так что если процесс падает на 47-м из 100 шагов, он воспроизводит лог и продолжает с 48-го, а не с начала. (Роль Temporal в продакшен-ИИ стала в 2026 году вполне мейнстримной: в феврале он привлек раунд на $300 млн при оценке $5 млрд, а в марте вышла официальная интеграция с OpenAI Agents SDK – честный сигнал, что durable execution теперь обязательная база для серьёзной агентской работы.) Использовать именно Temporal не обязательно – очередь задач, таблица статусов и аккуратная идемпотентность дают почти тот же результат – но в вашей системе что-то на эту роль обязательно должно быть. К запуску, мониторингу и подсчёту стоимости таких флотов мы вернёмся в уроке про AgentOps.

Ловушка, которую стоит запомнить: флот без идемпотентности – это машина дублей. Первый сбой, первый повтор, первый перезапуск – и он тихо обрабатывает и оплачивает одни и те же видео дважды. Идемпотентность – не приятная мелочь, которую добавляют потом; это свойство, вокруг которого вы проектируете единицы работы с самого начала.

Нажмите, чтобы увеличить

Переобработка – почему архив никогда не завершён

Живой агент отвечает и забывает. Вердикты архивного агента хранятся, а со временем они устаревают – и это создаёт работу, с которой real-time-агенты не сталкиваются: переобработку. Когда выходит более точная модель reader, меняется политика модерации или регулятор требует перепроверить всё по новому правилу – вы обязаны прогнать архив заново. Вопрос в том, прогоняете ли вы весь архив или только часть.

Вот где ключ идемпотентности срабатывает второй раз. Поскольку каждый вердикт был помечен версией модели и политики, его породивших (reader-v3 · policy-2026-06), вы можете перезапустить задачу под новой версией (reader-v4 · policy-2026-09), и флот увидит, что ни один из существующих вердиктов не совпадает с новым ключом – значит, он точно знает, что устарело. Более того, можно действовать выборочно: если изменилась только политика, а не восприятие, возможно, придётся перепрогнать лишь дешёвый шаг судьи по хранимым описаниям кадров, ни разу не трогая дорогой reader. Версионирование вердиктов превращает «пересмотреть весь архив» из паники в плановый, частичный, посильный прогон. Архивный агент, который не версионирует свой вывод, обрекает вас прогонять всё с нуля при любом изменении – а на архиве в миллион элементов это разница между «после обеда» и «целое состояние».

Человек в контуре – по исключению

Real-time-копилот ставит человека на каждое значимое действие, потому что за встречу их всего несколько. Архивный агент не может – миллион видео означает миллион решений, а миллион чего угодно никто не пересматривает. Поэтому принцип «человек в контуре» меняется: вместо одобрения всего люди теперь ревьюят по исключению, и задача агента – определить, какие случаи являются исключительными.

Два сигнала направляют элемент к человеку. Первый – уверенность: агент при каждом вердикте выставляет оценку своей уверенности, и всё, что ниже порога – случаи, в которых модель сомневается, – попадает в очередь для проверки человеком, а не в каталог. Второй – серьёзность: некоторые категории настолько важны, что их нельзя решать автоматически даже при высокой уверенности – например, подозрение на нарушение правил детской безопасности, флаг на юридическое удаление или медицинская находка. Такие случаи всегда направляются человеку, независимо от уровня уверенности. Всё остальное – уверенные и малорисковые – агент обрабатывает самостоятельно. Получается система с предохранителем: агент берёт на себя 95% очевидных случаев, а небольшая команда людей работает с 5% действительно сложных или потенциально опасных.

Вторая практика обеспечения безопасности – сэмплирование: люди выборочно перепроверяют небольшую случайную долю уверенных вердиктов агента, чтобы выявить режимы отказа, когда он уверенно ошибается. Очередь эскалации ловит то, о чём агент знает, что не знает; сэмплирование – то, о чём он не знает, что не знает.

Проработанная архивная задача, от начала до конца

Свяжем всё одной задачей: видеоплатформа с очередью на модерацию из 100 000 видео, накопившейся после смены политики, и мандатом разобрать её за день. Архив пополняет очередь; флот воркеров масштабируется, чтобы осушить её параллельно. Каждый воркер берёт видео, прогоняет через дешёвый фильтр (детекция планов плюс транскрипт), чтобы отсеять большинство сегментов, не заслуживающих внимания, сэмплирует около 40 ключевых кадров и только потом вызывает reader на этих кадрах – воронка ограничивает дорогой шаг 4 миллионами кадров по всему архиву вместо 1,8 миллиарда. Результаты reader передаются судье по политике, который возвращает категорию и уровень уверенности. Уверенные малорисковые вердикты сразу записываются в каталог; всё, что ниже порога уверенности, а также каждый подозрительный случай, связанный с детской безопасностью – независимо от уровня уверенности, эскалируется в команду ручной проверки. Вызовы reader идут через batch-API по сниженной цене, потому что ответы не требуются немедленно. Прогресс чекпойнтится после обработки каждого видео; каждый вердикт содержит ключ video-N · reader-v3 · policy-2026-06; десятки битых файлов попадают в очередь недоставленных для ручного анализа; а если spot-инстанс отберут на восьмом часу, сменный воркер продолжит с последнего чекпойнта, не оплачивая повторно ни одного завершённого видео. К вечеру в каталоге – 95 000 автоматических вердиктов, в очереди на ручную проверку – 5 000 сложных случаев, а общая стоимость всей операции оказалась плановой и предсказуемой – потому что воронка сократила объём, batch-API снизил цену, а надёжность системы гарантировала, что задача была оплачена ровно один раз.

Закон – прозрачность модерации и раскрытие ИИ

Архивный агент, который модерирует или размечает контент в масштабах, затрагивает два важных правовых аспекта, на которые стоит обратить внимание – хотя подробный разбор выходит за рамки данного урока. Первый – прозрачность модерации: в ЕС платформы, удаляющие или ограничивающие пользовательский контент, обязаны предоставить затронутому пользователю чёткое обоснование своих действий, а в зависимости от размера платформы – и публичную отчётность по модерации. Это означает, что решения агента не могут оставаться «чёрным ящиком».

Практическое следствие: агент должен фиксировать почему он принял то или иное решение – кадр-улику, ссылку на пункт политики, уровень уверенности – а не только сам вердикт, чтобы причину можно было сообщить пользователю и рассмотреть апелляцию. Это ещё один аргумент в пользу ведения аудит-лога, который и так обеспечивает основу надёжности системы.

Второй – раскрытие ИИ и происхождение (provenance). Там, где архивная система генерирует или изменяет контент, а не просто аннотирует его, правила прозрачности EU AI Act требуют, чтобы медиа, созданные или изменённые с помощью ИИ, были явно обозначены как такие. Стандарт происхождения контента C2PA – это формирующийся способ надёжно привязывать к файлу метку «создано или отредактировано ИИ». Подробности реализации раскрытия и отслеживания происхождения мы разбираем в уроке про качество, стоимость, C2PA и EU AI Act, а ограничения, касающиеся биометрических данных при работе с лицами в архиве, – в уроке про детекцию лиц под EU AI Act. Правило проектирования, соответствующее обоим нормативным требованиям, – то же, что и во всём уроке: храните доказательства, версионируйте решения и оставляйте человека в ответе за случаи с реальными последствиями.

Build, buy или wrap

У вас те же три честных варианта, что и у других прикладных агентов, и правильный выбор зависит от специфики вашей архивной задачи. Можно купить (buy) управляемый сервис видеопонимания или модерации, который принимает архив и возвращает теги или метки модерации – это самый быстрый и правильный путь, если ваша задача стандартна (например, общая модерация или сбор общих метаданных) и готовая модель уже справляется с ней хорошо. Можно обернуть (wrap): взять batch-API и движок durable-execution и самостоятельно собрать «воронку + флот» вокруг своих правил – это подходящий вариант, когда политика ваша, а техническая реализация стандартна; большинству команд стоит начать именно с этого. Или можно построить (build) весь конвейер из примитивов этой секции – воронку, хранилище чекпоинтов, схему идемпотентности, логику эскалации, фреймворк агента из урока про фреймворки – это правильный путь, когда ревью и есть ваш продукт, как в случае специализированных решений по комплаенсу, trust-and-safety или интеллекту по архиву. Что бы вы ни выбрали, воронка стоимости и хребет надёжности – не опциональные надстройки на потом; это несущие стены, и вендор или фреймворк, не дающий вам оба этих компонента, не готов к работе с архивом в масштабе.

Где здесь Фора Софт

Мы создаём видеопродукты для стриминга и OTT, видеоконференций, онлайн-обучения, телемедицины, видеонаблюдения и AR/VR. Async-агент ревью – это паттерн для рутинной, но необходимой архивной работы, которая рано или поздно возникает у всех этих продуктов: доведение субтитров и глав до конца по бэк-каталогу OTT, обработка очереди модерации пользовательского контента, перепроверка медиабиблиотеки в соответствии с новой политикой или обогащение архива поисковыми метаданными за годы.

Наша проектная дисциплина – как раз то, о чём этот урок: выстроить инструменты в воронку, чтобы дорогой пользователь видел только то, что прошло дешёвые фильтры; отправлять тяжёлые задачи через batch-API, потому что никто не ждёт мгновенного ответа; строить систему на надёжном фундаменте, чтобы сбой не приводил к повторному запуску с нуля, а продолжался с последней успешной точки. Мы версионируем каждый вердикт, чтобы переобработка была частичной, а не полной, и направляем спорные и рискованные случаи к людям-ревьюерам, а не решаем их автоматически.

Тот же скелет архитектуры работает и для стримингового архива, и для бэк-каталога видеонаблюдения, и для библиотеки онлайн-школы – без необходимости переписывать агента под каждую отрасль.

Ключевые выводы

• Async-агент ревью проходит по всему архиву в своём темпе – без привязки ко времени, без единого централизованного запроса.
• Это цикл агента, запущенный как флот параллельных воркеров, которые берут видео из очереди.
• Выстраивайте инструменты в воронку: дешёвые фильтры – вперёд, дорогой reader, работающий с несколькими кадрами, – в конце.
• «Без часов» означает batch-API по сниженной цене и возможность прерывать вычисления без потерь.
• Надёжность – в приоритете: сохраняйте прогресс чекпоинтами, чтобы при сбое обработка продолжалась, а не начиналась с нуля.
• Каждое решение помечайте ключом идемпотентности, иначе повторы приведут к дублированию обработки и начислениям.
• Версионируйте вердикты, чтобы при смене модели или политики переобработка была частичной.
• Людям отправляйте только те случаи, где низкая уверенность или высокий риск; всё остальное – сэмплируйте.

Что почитать дальше

• Агент-исследователь видео – кейс видеонаблюдения
• Video VLM в 2026 – выбор кадров против потоковой передачи токенов
• Оценка, безопасность, стоимость и наблюдаемость агентов – AgentOps