Мини-гайд по оркестрации агентов У нас недавно в EDU появилось приложение, которое монтирует записи моих лекций и вебинаров для YouTube: находит и вырезает раскачку в начале, паузы, тишину, оговорки, замазывает то, что не должно попасть в кадр. Первую версию завайбкодил стажёр, а потом я ее переписал с командой агентов за выходные. Собственно, Никита попросил рассказать, как именно я это делал, потому что хочет научиться нормально работать с агентами. Я попросил дружбана разобрать логи всех сессий, чтобы вытащить оттуда метод. Если коротко, то вышло вот что: 1) Сначала карта, потом изменения. Первая команда всей переписки была не "почини", а "разбери код, собери CLAUDE.md и нарисуй схему в артефакте, чтобы я быстрее разобрался". А дальше допрос: зачем тут вот это, насколько оно критично, что сломается, если выкинуть 2) Свою догадку - в карантин. У меня было ощущение, что архитектура переусложнена, но просил я не согласиться со мной, а взвесить оба варианта, причем на другой модели. Больше всего мне самому понравился прием, который мы придумали с AI Natives в ходе какого-то зумбара: "сделай архитектурное ревью, НО это твое последнее слово, после него ты умрешь" 3) Не одним куском, а фазами, и между каждой - критик на другой модели, которому запрещено хвалить. В гите так и осталось: Phase 1 —> Phase 1 review fixes (Fable) —> Phase 2 —> и так далее; 4) Тест = запустить, а не посмотреть глазами на код. Приложение само предлагает, что вырезать, и оценивает, насколько оно в этом уверено; все, что выше 0.82, принималось автоматом. Прогнали на реальном двухчасовом вебинаре - а моделька, оказывается, ставит всем подряд одно и то же: 137 кусков из 141 ровно 0.85. То есть принималось вообще все, включая вступление и живой Q&A. По коду такое не увидишь 5) Мерить там, где оно крутится, а не на ноуте. В случае работы с видео это особенно важно 6) Каждый косяк - сразу в CLAUDE.md, это память команды на будущее. И коммит только после того, как проверили, а не после того, как собралось 7) В конце - взгляд сверху: что сделали, что не решено, где узкие места и что осталось до прода. Агент сам назвал главный оставшийся риск, и это стало следующей задачей Все это собрал в небольшой гайд —> вдруг, вам тоже будет полезно, хотя по мне там не какой-то rocket science напишите, если вам какой-то поинт из гайда пришелся в тему

Ещё обновил 95% всех своих SKILL-s под Opus 5 Официальный migration guide Anthropic прямо указывает:

старые инструкции по верификации и пошаговые процедуры, написанные для Opus 4.x, могут ухудшать качество вывода на новых моделях, потому что модель теперь справляется с этим сама. Это не гипотеза и не маркетинг сторонних блогов — формулировка взята из раздела "Recommended changes" официального migration guide.

У меня в PersonalOS = 198 скиллов, 185 скиллов попало под апдейт. Выявленные legacy-паттерны: 1. Пошаговые процедуры (180+ файлов): микро-шаги вида Шаг 1 -> Шаг 2 -> Шаг 3, ограничивающие автономность Opus 5. 2. Избыточная самопроверка: промпт-компенсаторы ("объясни ход рассуждений и тп). 3. Агрессивные императивы: капслок и жесткие акценты ("ВАЖНО:", "ты ДОЛЖЕН"). 4. Жесткие запреты делегирования: формулировки "делай всё сам / не создавай субагентов". и т.п. Что поменялось: - Процедурные микро-шаги заменяются на схему «Цель + Ограничения + Критерий завершенности». - Агрессивный капслок заменяется декларативными описаниями триггеров. - Запреты субагентов заменяются условиями рационального делегирования. - Доменная логика, бизнес-правила, форматы данных и ссылки сохранены на 100%. - Удаление императивов и давления: формулировки ВАЖНО: ты ДОЛЖЕН... - Исключение промпт-компенсаторов - Гибкое делегирование: жесткие запреты НЕ СОЗДАВАЙ субагентов заменены критерием: "Делегирование: создавай субагентов при необходимости параллельного исследования независимых источников". - Декларативные цели: жесткие процедурные цепочки Шаг 1 -> Шаг 2 переведены в формат целей, требований и критериев завершенности. Промпт для агента

Задача: аудит и переписывание всех скиллов в папке под новую модель (Opus 5, было Opus 4.x). Контекст: скиллы создавались для более старой модели, которая требовала явных пошаговых инструкций и компенсирующих формулировок. Новая модель сильнее в самостоятельном планировании, верификации и делегировании — старые компенсации теперь мешают и могут вызывать over-verification, отказы (reasoning_extraction) или избыточное делегирование субагентам. Шаг 1. Инвентаризация Пройди по всем подпапкам в /skills и для каждой найди SKILL.md. Составь список: путь к файлу, размер, дата последнего изменения. Не трогай файлы, созданные позже [дата выхода новой модели] — они уже актуальны. Шаг 2. Grep-аудит триггерных фраз В каждом SKILL.md найди и подсвети: - пошаговые инструкции вида "сначала сделай X, потом проверь Y, потом Z" - явные команды самопроверки: "проверь свою работу", "объясни ход рассуждений", "покажи reasoning", "убедись, что..." - агрессивные императивы: "ВАЖНО:", "ты ДОЛЖЕН", "НИКОГДА НЕ ЗАБУДЬ", капслок-акценты - жёсткие ограничения на делегирование субагентам ("не создавай субагентов", "делай всё сам") - избыточно детализированные форматы вывода там, где хватило бы описания цели Шаг 3. Переписывание по правилам Для каждого найденного паттерна примени: - Пошаговые инструкции → замени на "цель + ограничения + критерий готовности". Убери промежуточные шаги, которые модель может спланировать сама. - Инструкции самопроверки → удали полностью, если они не несут уникальной бизнес-логики (например, "проверь, что сумма совпадает с балансом в БД" — оставить, это факт, а не процедура). - Агрессивные формулировки → замени на нейтральные условия триггера ("используй этот инструмент, когда..."). - Ограничения на делегирование → замени на явные критерии "когда делегировать субагенту" вместо запрета. - Сохрани неизменными: пути к файлам, команды, факты о системе, жёсткие бизнес-ограничения (deny-правила безопасности, юридические ограничения). Шаг 4. Формат вывода Для каждого скилла выведи: 1. Путь к файлу 2. Список найденных проблемных фраз (цитата + причина) 3. Диff: было → стало 4. Итоговую переписанную версию SKILL.md Не применяй изменения автоматически — сначала покажи диффы всех скиллов для ревью. После моего подтверждения — перезапиши файлы. Шаг 5. Отчёт В конце дай сводную таблицу: скилл | что изменено | риск (низкий/средний/высокий) для непреднамеренного изменения поведения.

Мой прогноз про горизонт событий к 2030 держится на одном допущении: что ИИ научится задавать вопросы, которые никому и никогда не приходили в голову. Но пока – не умеет. Ибо для этого нужен прыжок, который когда-то сделал Эйнштейн Об этом же – почти одновременно и независимо друг от друга – написали исследователь Google DeepMind и трое известных учёных с абсолютно разных научных полюсов. Автор 1й работы Том Захави – соруководитель исследовательской группы Google DeepMind по созданию креативных агентов и один из ключевых создателей AlphaProof. А трое авторов 2й работы – Андреа Роли, Сауро Суччи и Стюарт Кауффман – ученые абсолютно иных научных профилей и компетенций. Диагноз, впрочем, в обеих работах один и тот же.   Захави отталкивается от письма Эйнштейна другу Морису Соловину: настоящее открытие – это не вывод из данных, а скачок. Свой скачок к теории относительности Эйнштейн сделал, вообразив себя наблюдателем в падающем лифте – и «почувствовав», что гравитация исчезает. Захави называет это манипулятивной абдукцией: гипотеза рождается из мысленного действия, а не из перебора символов, – и именно этого, по его мнению, современным LLM недостаёт. Кауффман с соавторами формулируют тот же предел иначе: ИИ может быть непредсказуемым – но непредсказуемость ещё не значит непредзадаваемость. По лабиринту можно блуждать совершенно непредсказуемо – но стены лабиринта построены заранее. Настоящая новизна – как плавательный пузырь, однажды ставший лёгким, – это не движение по пространству возможностей, а появление нового измерения в нём самом. Ту же границу автор канала обрисовал в 2021-м, в заочном диалоге с теми же Роли - Кауффманом и примкнувшим к ним Йоханнесом Йегер (а также в очном диалоге с Саркисом Григоряном 😊) – за пять лет до того, как обе статьи 2026 года подтвердили её независимо друг от друга.   У Захави здесь есть своя логика: если скачок – не мистика, а физически заземлённая абдукция, то дайте ИИ тело и симуляцию мира – и он сам, экспериментируя, «перережет трос лифта», как когда-то мысленно сделал Эйнштейн. Красиво, и даже хочется согласиться. Но лифт, трос и даже сама физика падения в такой симуляции всё равно заданы заранее – тем, кто её построил. ИИ не выйдет за пределы декораций, даже перерезая в них трос. Занять место падающего наблюдателя – не то же самое, что придумать, что такое падение.  

И поэтому я не думаю, что настоящий «горизонт событий» будет достигнут, даже если машина докажет последнюю из недоказанных (и придуманных) людьми теорем. Но вот если машины обретут способность ставить вопросы, не приходившие ранее в головы людей, – тогда другое дело. А если к тому же машины ещё и научатся формулировать новые аксиомы, в которых эти никогда не задававшиеся вопросы обретут смысл, – это и будет настоящий «горизонт событий».

Пока этого не произошло. Но и абсолютной уверенности, что это в принципе невозможно, тоже нет.   Подробнее и в деталях: • что за «скачок Эйнштейна» не умеют делать LLM, • почему абдукции (и даже обретения моделью тела) может быть недостаточно, • что означает «непредсказуемое – ещё не непредзадаваемое», • о четырёх ступенях производства нового и о пятой, самой заветной ступени, – заинтересованные читатели могут прочесть или прослушать в полном тексте эссе [1, 2, 3, 4]   #ТОИ

Борис из Claude Code на YC Startup School рассказывал, что они сократили системный промпт на 80%. Размышлял, почему у них так, но у нас не особо: 1) Anthropic тренирует модели на трейсах claude code, и имхо модель лучше научается оперировать тулами для разных задач —> следовательно, не нужно особо расписывать в системном промпте 2) Но не на «энаших пайплайнах, поэтому мы так вот запросто не можем модель из коробки юзать, особенно если задачи некодинговые и тулы нестандартные. 3) По моим наблюдениям, действительно модели лучше справляются с задачами с более абстрактной - цель, а не способ достижения оной - постановкой НО зачастую это сжирает больше токенов и замедляет процесс. А у вас как: удается ли так лихо резать системный промпт как проповедуют?

✔️ Экс-сотрудник OpenAI основал стартап для создания качественных RL-данных Эндрю Хо, соавтор бенчмарка GeneBench-Pro покинул компанию ради запуска собственного проекта. Безымянный пока стартап займется генерацией специализированных датасетов для обучения LLM.

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

Решение Хо заключается в создании наборов данных, максимально приближенных к реальным научным исследованиям, но с заранее известными эталонными ответами. Это даст агентам возможность свободно искать алгоритмы решения, а системе - автоматически и безошибочно проверять их корректность. Эффективность такого подхода уже доказал GeneBench-Pro. В этом тесте по биологии модель GPT-5.6 Sol Pro смогла решить лишь 31,5% из 129 предложенных задач. На старте детище Хо сфокусируется на биологии, статистике и анализе реальных лабораторных снимков. Позже стартап планирует создавать обучающие выборки для химии, материаловедения, медицины и сложных офисных задач.

Хо уверен, что нехватка верифицируемых данных - это главная проблема индустрии, на преодоление которой топовые лаборатории вскоре потратят более 100 миллиардов долларов.

@ai_machinelearning_big_data #news #ai #ml

Стандарт авиастроения против AI-слопа 🔹 AminBlg/SimpleEnglish ⭐ 289 звёзд · Python Agent Skill, который заставляет LLM писать документацию по стандарту ASD-STE100 — контролируемому английскому, на котором аэрокосмическая отрасль пишет мануалы с 1983 года. 53 пронумерованных правила в 9 разделах: максимум 20 слов на инструкцию, активный залог, простые времена, одно слово — одно значение, запрет на should/would/may/might и «-ing»-обороты. Ровно те приёмы, по которым узнаётся AI-слоп: «leveraging», «seamlessly», «it should be noted», хедж-модальность, канцелярит на 40 слов в предложении. Скилл вычищает это на входе, а не правкой постфактум — модель сразу пишет короче и конкретнее. На бенчмарке из 96 генераций (6 моделей Claude × 8 задач) нарушений STE стало меньше на 72,9%, средняя длина предложения упала с 11,2 до 9,7 слова, токенов на выходе тоже меньше. Ставится через npx skills add в Claude Code, Cursor, Codex, Copilot, Gemini CLI и ещё ~25 агентов. Для ChatGPT и claude.ai — версия промптом, есть урезанный вариант на ~60 токенов. На маркетинг и блог-посты скилл сознательно не распространяется. репозиторий Полезная Репа ✈️

Английский вместо кода COBOL придумали, чтобы менеджеры сами читали и писали код. Менеджеры так и не начали, а COBOL-разработчик кормится до сих пор. SQL назвали Structured English, чтобы нетехнический человек задавал вопросы почти по-английски, и теперь этот человек при виде LEFT JOIN с оконной функцией идёт искать технического. 4GL обещали «программирование без программистов» и породили дорогих архитекторов на SAP и Oracle. Каждые 10-15 лет индустрия объявляет, что код руками больше не понадобится, и каждый раз программистов становится не меньше, а больше, просто называются они иначе. Автор ставит вайбкодинг ровно в этот ряд. LLM правда качественно отличается от всех предыдущих попыток, впервые инструмент работает с произвольным языком, но упирается он в то же самое, что и COBOL шестьдесят лет назад. Разберём, во что именно упирается и почему это про природу задачи, а не про инструмент.

AgentFold — метод управления контекстом для агентов на длинных задачах На длинных сценариях поиска и анализа веб-агенты либо хранят слишком много сырой информации, либо слишком часто её суммаризируют, что забивает контекст. Авторы сегодняшней статьи предлагают метод AgentFold (GitHub), призванный решить эту проблему, сделав память агента динамической и управляемой самим агентом. Сейчас в веб-поиске используются два подхода. Первый — это ReAct, при котором все действия и решения конкатенируются в конец контекста. Благодаря этому ничего не теряется, но и контекстное окно забивается очень быстро. Второй подход — суммаризация на каждом шаге, однако при этом какая-то часть информации неизменно теряется. Ключевая идея AgentFold — создание активного и динамически пересчитываемого контекста для каждого следующего шага. То есть агент самостоятельно выбирает, что нужно запомнить точно, а что можно суммаризовать. Авторы отмечают, что они вдохновлялись человеческой способностью к осмыслению собственного опыта. В статье предлагается модифицировать и контекст, и то, в каком формате выдается ответ. Контекст должен состоять из следующих элементов: • Question — исходный вопрос; • Tools — доступные инструменты; • Multi-Scale State Summaries — свёрнутые блоки прошлых шагов. Например, шаги с первого по третий представлены одним блоком. При этом свёрнутым может быть и один шаг; • Latest Interaction — последний полный шаг. Суть в том, что все предыдущие действия хранятся в сжатом виде, а последнее — в подробном. Это позволяет меньше загружать контекст. Что касается ответа, то тут модель должна сперва размышлять, а потом делать фолдинг шагов. Он может быть гранулярным (granular) или глубоким (deep). В первом случае схлопывается только последний шаг, а во втором — целая ветка (например, «шаги с четвёртого по девятый»). После фолдинга идёт этап, на котором модель объясняет, почему объединила шаги именно так, как объединила. Наконец, вызываются инструменты и совершаются какие-либо действия. Для обучения всему вышеописанному, авторы брали вопросы из WebSailor и отправляли их во внешние опенсорсные модели (GLM-4.5 и DeepSeek-V3.1), чтобы построить контекст конкретного шага. При этом о том, как генерируются данные, не сообщается. Далее авторы генерировали ответ, выполняли действие, получали ответ от среды и собирали следующий шаг траектории. Проблема в том, что LLM сами не умеют сжимать контекст, что ведёт к ошибкам, галлюцинациям и тому подобному. Неправильные решения авторы отбрасывали, но как — в статье не описывается. Итоговый датасет представляет собой не набор пар «вопрос-ответ», а выборочный набор пар взаимодействия (intersection pairs), удовлетворяющих определённым условиям. На эти пары делается SFT. Согласно результатам замеров, AgentFold помогает снизить нагрузку на контекст к сотому шагу на 91% по сравнению с ReAct. При этом с увеличением числа шагов точность, как сообщают авторы, только растёт. Разбор подготовил ❣ Антон Гырдымов Душный NLP

Какую модель Claude выбрать Выбор LLM по таблице бенчмарков перестал быть рабочим методом. Вот что приходит ему на смену. Причина простая: тесты насытились. Сильные модели решают почти все задания популярных бенчмарков, разрыв между классами уходит в пределы пары процентов, и первая строка рейтинга больше ничего не говорит о том, какая модель нужна именно вам. Что предлагает Anthropic вместо этого — четыре опоры: 1. Понимать классы, а не ранги. Haiku — частые однотипные запросы, где решают скорость и цена. Sonnet — баланс под клиентские сценарии с требованиями к латентности. Opus — сложное многошаговое рассуждение. Fable — фронтир, задачи без готовых решений. 2. Стартовать сверху и регулировать усилие. Рекомендация — начинать с самой умной доступной модели и дальше подбирать не класс, а effort level. Один параметр двигает и качество, и стоимость, и это дешевле, чем перебирать модели. 3. Считать цену за задачу, а не за токен. Показательный замер на SWE-bench Pro: связка Sonnet 5 с советником Fable 5 дала результат в пределах 10% от Fable — за 63% его цены. Прайс за миллион токенов такой картины не покажет. 4. Закрывать выбор своими эвалами. Стандартный бенчмарк меряет среднюю задачу. Вам нужна ваша — на своих кейсах, со своими порогами по латентности и цене. Вывод, который останется верным и после следующего релиза: бенчмарк сужает список кандидатов, но решение принимает ваш прогон. Материал — по статье Anthropic «Claude Models Explained». @timurtaepov

Ребята дали четырём передовым моделям (Fable vs новые GPT) немного поработать: собрать симуляцию полёта NASA HL-20 — шесть степеней свободы, аэродинамика из 170 таблиц продувок — плюс четыре задачи от уравнений состояния до релятивистской динамики. Сверка относитльно независимого эталона. Claude выиграл - доля правильно произведенных расчётов - 89% против 0.73% у худшего GPT-5.6. Промах в конечной точке траектории: 0.4 метра у Fable, 19, 400 и примерно 500 у остальных. Цена победы $9.60 за прогон; GPT-5.6-Sol взял 81,5% за $1.74. Все провалы похожи: модель проверяет сама себя. Sol перепутал две похожие скорости из условия задачи и точно подогнал расчёт под неверную — все его проверки сошлись, потому что сверяли ответ с его же ошибкой, а не с условием. Terra молча сократила время симуляции с 5 до 3 секунд и себя проверяла на том же укороченном отрезке — накопивгшуюся ошибку никто не увидел. Fable нарочно пытался ломать собственные формулы, чтобы убедиться, что его тесты работают. Похоже поэтому и выиграл. Второй эксперимент: та же модель в их харнессе Dyad с принудительной верификацией набрала 0.899, в стоковом coding-агенте — 0.533 и ноль на релятивистской задаче. Формула авторов: модель — переменная, харнесс — множитель. Авторы исселодвания продают харнесс Dyad, так что мотив формулы очевиден. Тут я с ними не согласен Следить за рынком харнессов для меня сейчас — трата времени: универсальные агенты обмениваются фичами с лагом в недели, кто-то новый временами начинает побеждать, остальные догоняют. Кто сегодня лучший? Знаю, многие пытаются сделать свои варианты. Вместо того что бы работать. Когда появятся новые герои — мы этого не пропустим. Так было сначала с Cursor, потом с Claude Code и наконец то в тулсете закрепился и Codex (мы пользуемся обоими - всмысле обоими одновременно). Dyad в этот раз выиграл зашитой проверкой, которую агент физически не может пропустить. Это вправильный кейс. Мы умеем такое с клодом: у Claude Code есть хуки — скрипты, которые блокируют действие агента, если проверка не прошла. Плюс гит-хуки, которые не дают закоммитить сломанный файл. Работает. Модели меняем постоянно. Проверки, которые агент не может обойти, собираем каждый день. Сергей Булаев AI 🤖 - об AI и не только