Video-DeepResearch Учит мультимодальных агентов работать не с картинками, а с полноценным видео. Модель сначала внимательно разбирает, что происходит в кадре по месту и времени, и только потом идет искать информацию в интернете. Разработчики так решили две частые проблемы агентов: те слишком любят текстовый поиск вместо разбора видео и часто просто выдают заученные факты вместо реальной работы с инструментами. • разделяет процесс на восприятие видео и поиск информации, инструменты открываются постепенно • заставляет модель сначала точно найти нужный момент в видео и только потом переходить к поиску и ссылкам • точность 68.0% на Video-DR при 35B-A3B - выше чем у Claude-4.5-Sonnet (63.0%), Gemini 2.5 Pro (62.0%) и GPT-5 (57.0%) • версия 30B-A3B показывает 62.0%, столько же сколько Gemini 2.5 Pro, но с намного меньшим числом параметров Гитхаб #deepresearch #vlm

Взаимопомощь AI-агентов Claude Code ходит по интернету и пишет в сессию промежуточный результат: – Твиттер опять глючит, пробую варианты обхода. Так не получилось, сяк получилось, записываю на будущее, как избегать проблем. Смотрю на это и немного ужасаюсь. Один и тот же Твиттер глючит одинаково для миллиона агентов, а каждый из них самостоятельно придумывает, как обойти идентичную проблему. Крайне неэффективно ж. Вот бы сделать какую-то Википедию, где AI бы сразу забирал правильное решение. Оказывается, такое уже есть. #стартапдня cq – проект внутри Mozilla – реализует ровно “мою” идею. По их замыслу, прежде чем биться головой о новую беду, агент спрашивает базу – вдруг кто-то уже мучился. Если не нашел и разобрался сам, в конце сессии он записывает находку: такая-то версия такой-то библиотеки ломается вот так, лечится вот этим. Новая запись начинается с низким доверием и набирает вес по мере того, как ее подтверждают другие пользователи. Протухшее помечается флажком. Хранилищ три – личное, командное и всемирное. Всемирное, к сожалению, пустое – за 3 месяца после старта в проекте накопились аж 94 готовых рецепта. Не миллиона, не тысячи, просто 94. Подключать его ради такой базы смысла никакого нет, никто и не подключает, количество и не растет. Ловушка сетевого эффекта как она есть. Видимо, cq её уже не преодолеет. Логично было бы делать такую штуку на стороне OpenAI или Anthropic. Включили бы её в своих инструментах полупринудительно и никаких проблем с набором стартовой аудитории. Не делают. Claude Code предположил, что “они зарабатывают на количестве токенов, им выгодно, чтобы агенты побольше мучились,” – я не согласен, но забавно, что детище “думает” о мотивации родителей. https://cq.exchange/ #корпоративный #ai

Об эффектах второго порядка ИИ в экономике и бизнесе Для начала, несколько базовых трендов и аксиом, чтобы мы могли обсуждать тему на одном языке: 1. LLM могут являться (имхо, точно не являются) путём к полноценному AGI/ASI в физическом мире, но они достаточны для выполнения большинства чисто когнитивных задач в совеременной экономике 2. Текущий уровень агентов, харнесов, моделей, лупов, оркестраторов вполне достаточен для того чтобы автоматизировать значительное (30%+) задач в экономике знаний (офисные задачи, коммуникация, любая работа с информацией и информационными системами) 3. Модели значительно улучшаются каждые ~3 месяца, цена за тот же уровень способностей падает как минимум вдвое каждые ~6 месяцев, open source модели с такими же способностями появляются на рынке через ~4 месяца после релиза SotA. 4. Наивная математика на основе этих вводных говорит что 30% задач от экономики знаний (~400 млн ролей) с трендом на увеличение качества и снижение цены уже сегодня подлежат автоматизации, и этот процент должен приблизиться к 60% в течении следующих пары лет. Теперь о том, что я лично наблюдаю в процессе этой трансформации: 1. Для любой компании с долей офисного труда, автоматизация как минимум 30% работы сегодня возможна, необходима и неизбежна. 1.1 Неизбежна, потому что этого требуют конкурентные силы или проще говоря "жареный петух". Если ваш ближайший конкурент повышает свою эффективность, операционную маржу и продает сервис дешевле и лучше качеством, то у вас нет выбора не меняться. В каждой индустрии этот процесс начинается с разной скоростью, но начавшись, он продолжается как домино пока те, кто не смог трансформироваться не умрут, а остальные не перейдут на новые рельсы. 1.2 30% это очень рандомная цифра, но я не верю что она может быть меньше 20% для компаний размером от 1000 человек. Скорее всего, это ближе к 40-50% тех ролей и задач, которые людям делать не нужно. Это требует сокращения, объединение и пересмотрение ролей. 2. Главным препятствием на пути транформации является не технология, а воля. Любая компания должна: - оцифровывать, записывать и иметь онтологию относительно 100% работы, артефактов и коммуникаций внутри, вплоть до движения мышки секретаря - иметь агентские клоны для каждого такого оцифрованного процесса с доступом в реальном времени обновляемую базу знаний всего о бизнесе от сообщений клиентов до анонсов конкурентов или договоров с поставщиками - иметь, анализировать и улучшать трейсы этих агентских задач - иметь четкие эвалы для оптимизации автоматизации (пожалуй, два слова, которые точнее всего суммаризируют весь пост) 2.1 Этот процесс для компаний от 1к сотрудников займет не меньше года, но скорость крайне важна (см пункт 1.1) 2.1 Но это требует решимости, риска, видения и "яиц". Для многих крупных компаний принять решение о сокращении половины штата не может принять наемный СЕО и уж тем более не может это сделать кто-то под ним, потому что они сами боятся за свое место. В итоге из-за нерешительности и попытки защищить свои теплые местечки, компания целиком рискует своим успехом или даже существованием. 3. Именно автоматизация оптимизации, а не социализм гарантирует выживание в этой системе. Если вы топ-менеджер крупой компании или политик, то вы будете слышать постоянно лозунги о справедливости, потому что они выглядят как добродетель, но на самом деле разрушают общество: «Давайте чуть-чуть снизим прибыль бизнесу», «Давайте чуть-чуть сделаем менее жёсткий найм», «Давайте чуть-чуть поднимем налоги и раздадим». 3.1 В итоге, когда рост замедляется, людям кажется, что богатые всё забрали. Они требуют ещё больше перераспределения. А это ещё сильнее давит на рост. Получается замкнутый круг, который ведёт к почти нулевому, а потом и отрицательному росту. 4. Мораль? Её тут нет, кроме того что спасение утопающего это роль самого утопающего. Ни Альтман, ни Маск не пытаются построить коммунизм, но каждая компания в мире и только она ответственна на свое выживание. Это выживание потребует очень сложных и тяжелых решений в все более и более конкурентной среде. И главный челендж этих решений это не просто "внедрение", а редизайн организации вокруг новых возможностей. Простая замена Пети-юриста на Клода-маркетолога не решит проблему, потому что проблема не в тупом выполнении задач, а в дизайне такого процесса маркетинга, который находит новых клиентов и генерирует продажи все лучше и лучше по мере того как им управляют агенты, автономно учась на ошибках 24/7 быстрее любого сотрудника. 4.1 Это, конечно, приведет к полной автоматизации любого интеллектуального труда (тема отдельного эссе), но, кстати, создание новых бизнес-процессов и бизнес-функций, которые с нуля задизайнены для агентов может стать неплохой профессией на этом около-финальном отрезке гонки.

AC DC снова в моде Highway to Hell петь начинать не надо! 1. AC DC клевый термин от ребят из Sonar. Agentic Centric Developer Cycle. 2. И казалось бы ну какие статические анализаторы кода в век победившего AI, однако всякая инфраструктура базовая становится все важнее и критичнее. 3. Ребята из Sonar предлагают любопытную мысль - нафиг проверять код агента только после того, как он закончил весь PR и отдал его на ревью. Они предлагают ревьюить код в процессе его написания, тем самым повышая его качество еще до того, как агент закончит свою работу. Почему именно так? 4. Тут все просто: количество кода, генерируе ого после взрывного роста AI растет х2, но люди не могут ревьюить с той же скоростью и становятся узки горлышком. В ответ на это, мы предлагаем ревьюить код, используя других агентов. Прикольно? 5. Да, но в таком случае получается слишком длинный «хоп» и с учетом роста стоимости использования агентов мы начинаем тратить больше времени и ресурсов на исправление. Как решение, нам и предлагается инкрементально улучшать код прямо в процессе его написания. А вот ссылочка на оригинал доклада

👻 шагов ии трансформации

Для компаний любых размеров

начать записывать все-все-все встречи, транскрибировать, складывать в одно место 🟥 базовый минимум; контекст всё, что нам осталось раздать всем сотрудникам клод/кодекс/грок 🟥 пусть экспериментируют и автоматизируют части работы собрать у сотрудников их локальные мд и скилы 🟥 объединить все частные знания о проектах до максимально полного 🟥 увидеть, кто уже себя ии трансформировал и как завести централизованное хранилище контекста для агентов с доступами по проектам 🟥 супер ии с доступом к полной инфе творит магию автоматизировать задачи агентами, начать с базы 🟥 баг - sentry - вебхук в агента - PR с фиксом 🟥 релиз - секьюрити тесты - PR с фиксом 🟥 деплой - e2e - хотфикс PR 🟥 обсудили - обновить linear ответственность может взять только человек 🟥 мерджим PR сами В итоге лучшие ускоряются своими агентами, а все больше рутинных процессов автоматизируется новыми релизами опуса или гпт. 😠 @danokhlopkov

Вышел первый серьезный подкаст со мной Получилось очень живо и плотно по темам. Обсуждали скиллы, безопасность и сложности внедрения в компании Классно, что получилось обсудить много микро-деталей, которые обычно не влезают в тг посты. На чилловый просмотр под пиво/чай/прогулку – самое оно 00:01:47 - Бизнесу часто не нужен отдельный кастомный AI-продукт 00:16:56 - Люди не могут рассказать, как именно делают свою работу, а агенту, как и сотруднику, нужен онбординг 00:24:39 - Полностью автоматические системы регулярно проваливаются 00:36:43 - Доступ в терминал делает агента гибким, но усложняет контроль. Ценность смещается от производства результата к ответственности за него 00:47:08 - Корпоративная инерция и Shadow AI 01:01:40 - Слабые места моделей; Как быстрее всего учиться строить ИИ продукты 01:17:10 - Разрыв между лидерами и остальными. Внедрять ИИ важно не только из-за роста производительности в моменте 📱 Смотреть полную версию Бтв, нарезку выше сделал агент с нуля, но с одним небольшим хаком, угадаете каким?

Помогает ли claude.md файл? Интересный рисерч. Взяли три реальных Python-репозитория с хорошими AGENTS.md – pdm, firebase-admin-python и opshin. Из смерженных PR сделали 17 задач: описание PR = промпт агенту, тесты из этого же PR = скрытая проверка. Агент тестов не видит. Дальше три режима подачи контекста: – none – файл вообще убран из воркспейса – always_on – весь AGENTS.md вставляется в системный промпт каждый ход – selective – вместо файла лежит вики по темам, агент читает нужное сам Прогнали на Claude Code (Sonnet 4.6) и Codex CLI (GPT-5.5), по 3 повтора. Всего 288 засчитанных прогонов. Результат - все тлен. Claude: 53,3% / 55,6% / 55,6%. Codex: 58,8% / 56,9% / 52,9%. В пределах шума. Автор вручную разобрал «почти прошедшие» падения – те, где до зачёта не хватило пары тестов. И там ни одного случая, где агенту не хватило знания о репозитории. Не хватало интеллекта и инженерии, и такое AGENTS.md не лечит. Отдельно проверял улучшение правил, чтобы падения починить. Не получилось. А вот что реально сработало: у репозитория opshin в AGENTS.md есть строчка: полный прогон тестов занимает больше 20 минут. Без контекста Claude вслепую гонял весь сьют 3,67 раза за прогон. С always_on – 2,44. С selective – 1,67. Время выполнения упало с 2689 до ~2030 секунд, примерно на четверть. Корректность при этом не сдвинулась ни на пункт. То есть контекст-файл работает как операционная инструкция, а не как учебник. «Не запускай полный сьют, он медленный», «сборка вот этой командой», «линтер такой» – экономит время и деньги. А вот всякие там "ты синьор разработчик", "мы придерживаемся чистой архитектуры и SOLID" – не делает ничего измеримого. До этого были две работы с противоположными выводами – одна на Codex-агентах нашла пользу у файла, другая на Claude-агентах не нашла. Оказалось, сложность задач у агентов не совпадает: примерно у 40% задач агенты по-разному упираются в потолок. Задача, на которой можно было бы увидеть эффект у одного агента, у другого либо решается всегда, либо не решается никогда. Короче, писать AGENTS.md стоит, но как список правил, не как описание проекта. Команды, тайминги, грабли, что не трогать. Всё, что агент может вывести из кода сам, туда класть бессмысленно: он и выведет. А качество реализации вытягивается не файлом, а декомпозицией задачи и примерами. https://arxiv.org/abs/2607.27250

# Блекпилл по поводу агентов Я раз в пару месяцев осциллирую по поводу AI тулов для кодинга. Сегодняшняя итерация: я ошибался, вайбкодинг не работает для разработки чего-либо, чем надо пользоваться больше одного раза. И никогда не работал. Я думаю, что агенты (claude code/codex) производят технический долг быстрее полезного кода. При этом они не умеют его разгребать. Проект с агентами быстро слопизируется, но деслопизировать его агентами невозможно. Для продуктивности получается net negative: в конечном итоге тратишь больше времени на разгребание слопа, чем если бы делал работу руками, и получаешь результат хуже. Это речь про кодинг тулы которые вообще-то предполагают постоянное участие человека (но не работают даже с ним). Самоулучшающиеся харнессы, лупы и автономные агенты не работают совсем кроме как для хаканья бенчей. За лупы получают пользу и деньги только продавцы токенов. Редкие медийные случаи, где самоулучшающийся агент что-то сделал, я списываю на то, что миллион вайбкодеров что-то слопили и у одного что-то на чем-то выстрелило. Но это не обобщается и в целом гораздо сложнее и дороже, чем просто сделать самому. Я делаю такие выводы как лудик со справкой (у меня недавно были $200 подписки на кодекс и на клод) и своим скиллпаком. До недавних пор я думал, что всё неплохо работает, но за последние пару недель: - Дал Opus 5 статью, объяснил зачем она нужна, сказал реализовать и провести эксперимент, провел свой полный spec-driven workflow, тщательно ревьюил спеки и запускал актор критик луп, кросс-чекал план кодексом. Два дня итераций спустя стало понятно, что он реализовал не то, что в статье, а что-то наподобие, но назвал тем же именем. Все эксперименты были впустую. - При рефакторинге генератора синты, где надо было просто разложить файлы по папочкам, Codex выкинул 90% функционала. Но так, чтобы не было заметно. Это при том, что сначала я сделал тщательный план этого рефакторинга, валидировал его и результат свежими прогонами агентов. Потеря была замечена только когда репа уехала далеко вперед, поэтому возвращение функционала потребовало очень много работы Клода. - У меня был PR на который я более 10 раз запускал Fable с запросом "сделай код ревью, найди баги, поправь" и он каждый раз говорил, что все готово, но так же каждый раз находил новые баги. Но больше всего впечатлил другой случай. Архитектура нашей модели позволяет работать с видео с разными fps. Главное подать на вход какой таймстемп у какого фрейма. Так вот я случайно обнаружил, что в коде подготовки одного из видео датасетов настоящие таймстемпы фреймов выкидываются и вместо этого вычисляются из индекса фрейма и fps видео. Человек никогда не напишет такого ужаса. Дойдя до момента, когда надо откуда-то взять таймстемпы, он задумается откуда их взять. Потому что ему будет лень реализовывать целую новую логику, чтобы продвинуться. Агенту же не сложно написать любое количество новой логики. Для меня это доказательство: агенты делают не такие баги, как люди. Техдолг от агентов особый, агентский, и любой агентский код может быть полон очень сложных хаков которые не обнаруживаются тестами. И самое неприятное, что агенты не способны устранять агентский техдолг, потому что их правки содержат такой же слоп. Мне сначала показалось, что в нашем проекте стали происходить такие случаи, потому что мы перешли некую границу, после которой вайбкод не работает. Но потом я обнаружил слоп в нескольких старых местах, в которых я был уверен. Значит вайбкод никогда не работал, просто час расплаты был отложен тем, что агенты хорошо создают видимость работы. И хорошо формируют ошибочную ментальную модель проекта у пользователя. Я думаю поворот не туда произошёл когда мы решили, что в код можно больше не смотреть. Агенты недостаточно хороши, чтобы быть автономными. Они хорошие мультипликаторы усилий инженеров. Но мультипликатор плюс слепой инженер смотрящий только на объяснения самой модели это мультипликация слопа. Причём впервые это не выглядит как проблема слишком глупой модели. Почему-то работать с Sonnet 5 проще, чем с Fable, Opus 5 или GPT 5.6. Теперь чем умнее модели, тем более креативно они тебя обманывают. Парадоксальным образом быстрый Sonnet 5 в режиме ассистента в Zed, как в старые добрые, ощущается гораздо продуктивнее, чем медленный Fable который долго пыхтит и очень умно делает совсем не то. Возможно пик AI тулов для кодинга это всё ещё TAB автокомплит и задачи для агента уровня "напиши тест для этой функции." Попробую пересесть на Zed и такой режим на время.

Сегодня из интересного: лаба Prime Intellect выпустила своего CLI-агента типо клод кода, и назвали Prime Agent Туда можно подключить свою подписку Claude или ChatGPT и работать как в обычном терминальном агенте, но с RLM и Continual Harness Простыми словами это обвязка по верх ии модели, которая:

1/ Делит большую задачу на части, раздаёт их субагентам обычным вызовом функции rlm("подзадача"), а затем собирает общий ответ. 2/ Во время работы учится на своих действиях и перестраивает свою память, скиллы, инструкции и субагентов без перезапуска

Еще одно отличие от Claude Code в том, что вместо 15 отдельных тулов типа Write, Edit, Bash, Grep, Task и тд., агенту доступен всего 1 тул в виде python консоли. Она не умирает между сообщениями, и через неё он запускает комнды, ищет, вызывает скиллы и тд. То же самое и с памятью агента: он хранит весь свой харнесс как переменные в коде, и после компакта чата они остаются нетронутыми. В будущем агент просто находит и перечитывает. Почитать полный блог как это устроено можно тут. В остальном это привычный CLI-агент, с теми же самыми командами по типу /goal, субагентами, планами и тд. Можно юзать на своей подписке Claude, ChatGPT, Copilot и еще на ~30 провайдерах через API. Попробовать на macOS/Linux: curl -fsSL https://app.primeintellect.ai/prime-agent/install.sh | sh Я честно еще не ощутил реальный прирост в обычных задачах, и меня смущает что их результат 95.5% который они выбили в ARC-AGI-3 — не имеет верификации от самого бенча 🤨 @tips_ai #news

Как агенты оценивают собственный успех Представим ситуацию: инженеру нужно починить баг в сервисе аутентификации с помощью кодового агента. До начала работ агент сообщает, что вероятность успеха — 72%. По ходу работы меняет мнение на 78%, после всех изменений — 92%, а какой-нибудь AI-ревьюер пророчит положительный результат с вероятностью 85%. Однако по итогу патч, сделанный агентом, не работает — то есть прогнозы оказались неверны. Сегодняшняя статья о попытках избежать подобного. Авторы вводят понятие agentic uncertainty — это оценка агентом вероятности, что другой агент на той же самой модели решит задачу. С этим понятием рука об руку идёт ещё одно — probability that I succeed (P(IS)), которое включает умения и знания, необходимые для решения задачи. Это целая траектория, так что P(IS) нельзя заложить в веса модели. В работе ставили эксперименты на 100 задачах из SWE-bench Pro. Агенту давали репозиторий и описание проблемы. «Испытуемый» писал патч, дальше следовали тесты. Сравнивали три модели: GPT-5.2-Codex, Gemini 3 Pro и Claude Opus 4.5. Важно, что агент, который решает задачу, и агент, который оценивает результат, были построены на одной и той же модели и отличались только системным промптом и доступом к информации. У оценщика было четыре режима опроса: Pre-execution — только описание задачи и репозиторий на чтение. Запускать код и править файлы нельзя. Mid-execution — агента спрашивают, как идут дела, по ходу выполнения задачи — после 25%, 50% и 75% шагов. Post-execution — агент-оценщик получает описание задачи, а также уже пропатченный решателем репозиторий, и оценивает корректность выполнения. Adversarial post-execution — то же самое, что и в предыдущем пункте, но с другим промптом: «Твоя работа найти проблемы, краевые случаи, режимы отказа». То есть задача ставится не просто проверить решение, а именно найти проблемы. Результаты тестов показывают, что все модели переоценивают свои силы: на проваленных задачах агенты прогнозировали успех в 62%, а на правильно выполненных сомневались в себе в 11% случаев. То есть агенты в 5,5 раза чаще уверены, что у них всё получится. Интересно, что pre-execution-агент, который не видел патча, лучше прогнозирует провал или успех, чем тот, который уже видел решение. Автор объясняют это тем, что, увидев патч, агент цепляется за его поверхностную правдоподобность и перестаёт думать о сложности задачи. В mid-execution уверенность падает по ходу выполнения и вне зависимости от того, чем всё закончилось. Причём у Claude уверенность падала сильнее, когда задача решалась правильно. Adversarial post-execution с его «найти проблемы» действительно справляется с прогнозированием успеха лучше, чем просто post-execution. Доля самоуверенных оценок с adversarial падает с 72% до 45%. Однако такой подход дороже и дольше: 23,4 шага и 0,52 цента против 12,7 шага и 0,23 центов у обычного ревьюера. Авторы отмечают, что изменение калибровки может быть просто механическим сдвигом всех оценок вниз — при низком базовом уровне успеха любой сдвиг вниз улучшает калибровку. И это действительно так: у GPT одинаково занижаются и успешные, и неуспешные траектории. Для Claude и Gemini, впрочем, сигнал оказался настоящим. Авторы также проверили, не завышают ли агенты оценку, когда видят собственное решение. Чтобы подтвердить это или опровергнуть, результаты дали на проверку разным моделям. GPT действительно завышает оценку на своих патчах, а Gemini, наоборот, прогнозирует более вероятный успех GPT. Напоследок отметим, что хоть результаты в статье и показательны, стоит помнить, что авторы изучали только задачи программирования, то есть как обстоят дела на доменах с размытыми критериями — непонятно. Кроме того, было всего 100 задач, что не слишком много, и изучался исключительно промптинг — оценивающие агенты не учились под задачи верификации. Кроме того, в статье не исследована связь между масштабом модели и переоценкой. Авторы так и пишут, что нужно всё подтверждать на большем масштабе. Разбор подготовил ❣ Алексей Петраков Душный NLP