Что такое Claude Dynamic Workflow простыми словами
Claude Code выкатили Dynamic Workflows, и все кинулись объяснять это так, что чёрт ногу сломит: Claude пишет JavaScript-скрипт, который оркестрирует субагентов в масштабе, рантайм исполняет его в фоне, а промежуточные результаты живут в переменных скрипта, а не в контексте модели.
По мне сильно проще. Допустим, полгода назад вы выпилили password grant из auth-сервиса. Надо пройтись по 20 микросервисам и найти, кто ещё ходит в токен-эндпоинт с grant_type=password, чтобы перевести их на client_credentials.
Делается это так: на каждый сервис запускаешь отдельного подагента - он лезет в свой репозиторий и ищет эти вызовы. Сервисов 20, значит и подагентов 20.
Раньше этих двадцать подагентов запускал основной агент-оркестратор, а он сам LLM. Чтобы стартовать подагента на billing, он своими токенами пишет ему задание: «открой billing, найди grant_type=password, верни места». Потом ровно то же самое для notifications, для search - и так двадцать раз подряд. Один и тот же текст модель перепечатывает под каждый сервис, а ответы всех двадцати валятся ей обратно в контекст. К середине списка окно забито однотипными заданиями и их выводами.
В воркфлоу это задание пишется один раз - шаблоном в коде, а имя сервиса подставляется в строку. Двадцать подагентов стартуют из обычного map, модель их не перепечатывает, а ответы оседают в переменных скрипта:
Всё что трогает мир - поиск, заведение Jira, фиксы - делают агенты; у самого скрипта доступа к сети и файлам нет (к сожалению, кажется, что это откроет огромный пласт возможностей для автоматизации менеджмента агентов. Думаю, они это сделали из-за секьюрности)
И главное: этот JavaScript ты не пишешь сам. Говоришь Opus словами что нужно - он сам пишет весь скрипты для менеджмента агентов
Claude Code выкатили Dynamic Workflows, и все кинулись объяснять это так, что чёрт ногу сломит: Claude пишет JavaScript-скрипт, который оркестрирует субагентов в масштабе, рантайм исполняет его в фоне, а промежуточные результаты живут в переменных скрипта, а не в контексте модели.
По мне сильно проще. Допустим, полгода назад вы выпилили password grant из auth-сервиса. Надо пройтись по 20 микросервисам и найти, кто ещё ходит в токен-эндпоинт с grant_type=password, чтобы перевести их на client_credentials.
Делается это так: на каждый сервис запускаешь отдельного подагента - он лезет в свой репозиторий и ищет эти вызовы. Сервисов 20, значит и подагентов 20.
Раньше этих двадцать подагентов запускал основной агент-оркестратор, а он сам LLM. Чтобы стартовать подагента на billing, он своими токенами пишет ему задание: «открой billing, найди grant_type=password, верни места». Потом ровно то же самое для notifications, для search - и так двадцать раз подряд. Один и тот же текст модель перепечатывает под каждый сервис, а ответы всех двадцати валятся ей обратно в контекст. К середине списка окно забито однотипными заданиями и их выводами.
В воркфлоу это задание пишется один раз - шаблоном в коде, а имя сервиса подставляется в строку. Двадцать подагентов стартуют из обычного map, модель их не перепечатывает, а ответы оседают в переменных скрипта:
Всё что трогает мир - поиск, заведение Jira, фиксы - делают агенты; у самого скрипта доступа к сети и файлам нет (к сожалению, кажется, что это откроет огромный пласт возможностей для автоматизации менеджмента агентов. Думаю, они это сделали из-за секьюрности)
И главное: этот JavaScript ты не пишешь сам. Говоришь Opus словами что нужно - он сам пишет весь скрипты для менеджмента агентов
❤14🌚3🥰1🤮1💩1🤡1
Алексей Маметьев
Что такое Claude Dynamic Workflow простыми словами Claude Code выкатили Dynamic Workflows, и все кинулись объяснять это так, что чёрт ногу сломит: Claude пишет JavaScript-скрипт, который оркестрирует субагентов в масштабе, рантайм исполняет его в фоне, а…
Кстати используя этот Dynamic Workflows, смогли очень быстро переписать BUN.js с ZIG на Rust (и это вызвало бурю обсуждений). Этот подход позволил очень эффективно распараллелить работу между модулями.
Я смог без всяких динамик воркфлоус переписать тот же самый bun.js на Excel
Джеррету пришлось самому закрывать мой пул реквест, потому что остальные контрибутеры захотели это мерджить
https://github.com/oven-sh/bun/pull/31085
Я смог без всяких динамик воркфлоус переписать тот же самый bun.js на Excel
Джеррету пришлось самому закрывать мой пул реквест, потому что остальные контрибутеры захотели это мерджить
https://github.com/oven-sh/bun/pull/31085
👍12🥰6❤1🤯1
Офер Прес из SWE-bench жалуется, что стало сложнее собирать датасеты для coding agents: платишь разметчикам за “человеческие” задачи, а они сами генерят их через LLM. Формально это human-written data, по факту - synthetic data laundering.
И это хуже обычного синта: обычный синт хотя бы подписан как синт. А тут модельные данные проходят через человека-прокси и возвращаются в пайплайн как “реальные” задачи, хотя там уже нет настоящего пользователя, настоящего бага и настоящего продакшен-контекста.
Это значит что результаты почти всех не синтетических бенчмарков (типо терминал бенч), которые мы сейчас видим, вероятно, завышены. Так как какая-то часть заданий сделана через агентов, а Llm biased на простые задачи, которые сама понимает как решать.
https://x.com/OfirPress/status/2060921480473465081
И это хуже обычного синта: обычный синт хотя бы подписан как синт. А тут модельные данные проходят через человека-прокси и возвращаются в пайплайн как “реальные” задачи, хотя там уже нет настоящего пользователя, настоящего бага и настоящего продакшен-контекста.
Это значит что результаты почти всех не синтетических бенчмарков (типо терминал бенч), которые мы сейчас видим, вероятно, завышены. Так как какая-то часть заданий сделана через агентов, а Llm biased на простые задачи, которые сама понимает как решать.
https://x.com/OfirPress/status/2060921480473465081
X (formerly Twitter)
Ofir Press (@OfirPress) on X
There's 2 approaches to train+eval data acquisition:
A. Finding it in the real world
B. Paying someone to produce it
In the coding domain, you can see SWE-bench as the first category and TerminalBench as the second.
In coding, it might soon be impossible…
A. Finding it in the real world
B. Paying someone to produce it
In the coding domain, you can see SWE-bench as the first category and TerminalBench as the second.
In coding, it might soon be impossible…
😁23🤣4❤3🥰1💩1
Если компания хайрит - то это сигнал того что они плохо настроили агентов - и смысл туда идти?
Если компания не хайрит то она не хайрит
Основная причина кризиса найма 2026 - остальное только производные
Переубедите меня?
Если компания не хайрит то она не хайрит
Основная причина кризиса найма 2026 - остальное только производные
Переубедите меня?
😁25🔥6👍3
Не знаю почему про это никто ещё не написал
https://www.anthropic.com/news/confidential-draft-s1-sec?utm_source=chatgpt.com
Только что антропик подала заявку на IPO. Раньше openai
Upd: оказывается Openai тоже подали такую заявку, причем раньше Antropico
https://www.anthropic.com/news/confidential-draft-s1-sec?utm_source=chatgpt.com
Только что антропик подала заявку на IPO. Раньше openai
В S-1 лежит описание бизнеса: продукты, рынок, клиенты, стратегия.
Финансы: выручка, убытки/прибыль, расходы, долги, cash burn.
Риски: конкуренция, регулирование, суды, зависимость от облаков/compute.
Параметры IPO: сколько акций, цена, оценка, инвесторы, банки, lock-up.
Upd: оказывается Openai тоже подали такую заявку, причем раньше Antropico
Anthropic
Anthropic confidentially submits draft S-1 to the SEC
Anthropic has confidentially submitted a draft S-1 registration statement to the Securities and Exchange Commission
❤7💩1
Я очень жду NVIDIA Rubin.
Это следующее поколение GPU после Blackwell, и там главный апгрейд для LLM - не сколько compute, а скорость памяти.
Сейчас decode-инференс часто упирается в HBM bandwidth: на каждый новый токен надо снова читать веса модели из памяти. У Rubin заявлено около 22 TB/s на GPU против 3.35 TB/s у H100 и ~8 TB/s у B200.
То есть для memory-bound inference это может быть около 7× к H100.
Для обучения тоже большой скачок: NVIDIA обещает до 4× меньше GPU для MoE training vs Blackwell.
Плюс CMX - по сути SSD прямо на видеокарте с быстрым доступом для KV-cache/long context. Если это нормально заработает, LLM смогут стать быстрее, больше или дешевле в инференсе (или всё вместе) уже в этом году
Это следующее поколение GPU после Blackwell, и там главный апгрейд для LLM - не сколько compute, а скорость памяти.
Сейчас decode-инференс часто упирается в HBM bandwidth: на каждый новый токен надо снова читать веса модели из памяти. У Rubin заявлено около 22 TB/s на GPU против 3.35 TB/s у H100 и ~8 TB/s у B200.
То есть для memory-bound inference это может быть около 7× к H100.
Для обучения тоже большой скачок: NVIDIA обещает до 4× меньше GPU для MoE training vs Blackwell.
Плюс CMX - по сути SSD прямо на видеокарте с быстрым доступом для KV-cache/long context. Если это нормально заработает, LLM смогут стать быстрее, больше или дешевле в инференсе (или всё вместе) уже в этом году
🔥16❤6👍2
Новый агент Google, который решал открытые задачи по математике
Часто говорят: harness не важен, главное, насколько умная модель. Но если просто попросить Gemini “реши открытые задачи Эрдёша”, она не начнёт стабильно выдавать проверяемые доказательства. В работе Google интересен именно harness: как вокруг Gemini собрали систему, которая хранит частичные Lean-доказательства, продолжает удачные ветки и не теряет полезные ошибки прошлых запусков.
Обычный coding agent работает линейно: получил задачу, написал код, запустил проверку, исправил ошибки, снова проверил. Для Lean-доказательств это тоже работает: модель видит theorem statement, пишет доказательство, Lean возвращает ошибки, модель правит файл.
Но у такой схемы есть проблема: если запустить её много раз, большинство полезных промежуточных находок пропадает. Один запуск нашёл хорошую лемму, другой, правильное разбиение цели, третий, что подцель ложная, четвёртый почти закрыл технический кусок.
Одна попытка в агенте Google называется episode. Внутри episode Gemini 3.1 Pro правит Lean-файл. После правки запускается Lean. Все ошибки в доказательстве попадают в модель обратно.
Если остаётся конкретная незакрытая Lean-цель, Gemini может вызвать AlphaProof. Это работает как маленькая модель-субагент: он пытается закрыть одну подцель.
После episode результат не выбрасывается, если у модели было хоть какое-то продвижение. Из него делают sketch.
Sketch, это текущая версия Lean-доказательства. Не просто текстовая идея, а Lean-файл: часть доказательства уже написана, часть целей ещё открыта. Рядом лежит план, summary, список целей и вызовы AlphaProof.
Новая попытка обычно стартует не с пустого файла. Агент выбирает из базы один root sketch и два inspiration sketches.
Root sketch, это основной черновик. Его Lean-код Gemini реально продолжает редактировать. Если root уже содержит полезную лемму или частично закрытое доказательство, новая попытка наследует этот прогресс.
Inspiration sketches, это дополнительные черновики в prompt. Их код не становится стартовым файлом. Они нужны как подсказки: в другой ветке пробовали такую лемму, там была такая ошибка, там AlphaProof закрыл такую подцель, там план выглядел перспективно.
Все попытки доказательств оцениваются отдельной моделью Gemini Flash, чтобы получить score для каждого sketch. Root sketch не обязательно выбирается как самый лучший по score. Sketches семплируются: сильные черновики получают больше шансов, но менее исследованные ветки тоже иногда выбираются. Так модель не циклится на одном подходе и получает больше exploration.
Иногда агент специально меняет режим prompt-а: разбей незакрытые цели, попробуй новый подход, скомбинируй идеи прошлых попыток. Поэтому новая попытка может продолжать сильную ветку, а может уйти в сторону ради exploration.
Подагенты напрямую не общаются. Один prover-subagent не пишет другому. Обмен идёт через базу sketches и global goal cache.
Результат: 9 из 353 формализованных задач Эрдёша и 44 из 492 OEIS-гипотез.
P.s. lean это язык формальной верификации математики. На ней можно написать любое утверждение или доказательство любой теоремы и компилятор сможет верифицировать, правильное ли оно.
Часто говорят: harness не важен, главное, насколько умная модель. Но если просто попросить Gemini “реши открытые задачи Эрдёша”, она не начнёт стабильно выдавать проверяемые доказательства. В работе Google интересен именно harness: как вокруг Gemini собрали систему, которая хранит частичные Lean-доказательства, продолжает удачные ветки и не теряет полезные ошибки прошлых запусков.
Обычный coding agent работает линейно: получил задачу, написал код, запустил проверку, исправил ошибки, снова проверил. Для Lean-доказательств это тоже работает: модель видит theorem statement, пишет доказательство, Lean возвращает ошибки, модель правит файл.
Но у такой схемы есть проблема: если запустить её много раз, большинство полезных промежуточных находок пропадает. Один запуск нашёл хорошую лемму, другой, правильное разбиение цели, третий, что подцель ложная, четвёртый почти закрыл технический кусок.
Одна попытка в агенте Google называется episode. Внутри episode Gemini 3.1 Pro правит Lean-файл. После правки запускается Lean. Все ошибки в доказательстве попадают в модель обратно.
Если остаётся конкретная незакрытая Lean-цель, Gemini может вызвать AlphaProof. Это работает как маленькая модель-субагент: он пытается закрыть одну подцель.
После episode результат не выбрасывается, если у модели было хоть какое-то продвижение. Из него делают sketch.
Sketch, это текущая версия Lean-доказательства. Не просто текстовая идея, а Lean-файл: часть доказательства уже написана, часть целей ещё открыта. Рядом лежит план, summary, список целей и вызовы AlphaProof.
Новая попытка обычно стартует не с пустого файла. Агент выбирает из базы один root sketch и два inspiration sketches.
Root sketch, это основной черновик. Его Lean-код Gemini реально продолжает редактировать. Если root уже содержит полезную лемму или частично закрытое доказательство, новая попытка наследует этот прогресс.
Inspiration sketches, это дополнительные черновики в prompt. Их код не становится стартовым файлом. Они нужны как подсказки: в другой ветке пробовали такую лемму, там была такая ошибка, там AlphaProof закрыл такую подцель, там план выглядел перспективно.
Все попытки доказательств оцениваются отдельной моделью Gemini Flash, чтобы получить score для каждого sketch. Root sketch не обязательно выбирается как самый лучший по score. Sketches семплируются: сильные черновики получают больше шансов, но менее исследованные ветки тоже иногда выбираются. Так модель не циклится на одном подходе и получает больше exploration.
Иногда агент специально меняет режим prompt-а: разбей незакрытые цели, попробуй новый подход, скомбинируй идеи прошлых попыток. Поэтому новая попытка может продолжать сильную ветку, а может уйти в сторону ради exploration.
Подагенты напрямую не общаются. Один prover-subagent не пишет другому. Обмен идёт через базу sketches и global goal cache.
Результат: 9 из 353 формализованных задач Эрдёша и 44 из 492 OEIS-гипотез.
P.s. lean это язык формальной верификации математики. На ней можно написать любое утверждение или доказательство любой теоремы и компилятор сможет верифицировать, правильное ли оно.
❤21🔥6🥰2👎1👀1
2_5260573882280089928.pdf
71.3 KB
Обязательно прочитайте предыдущий длин-пост
Если кому-то интересно, сами задачи, что он смог решить, сделал хороший файл с ними
Если кому-то интересно, сами задачи, что он смог решить, сделал хороший файл с ними
❤9🔥3🥰1
Как вам кажется, развитие ИИ больше угрожает женскому рынку труда или мужскому?
Anonymous Poll
35%
Женскому
65%
Мужскому
🤷♀21😁6❤2
Новый самый сложный бенчмарк для агентов
FrontierCode - benchmark для coding agents, где агенту дают сделать pull request в реальном репозитории, а дальше мейнтейнер репозитория решает, можно ли это мержить в main. В SWE-Bench итоговая оценка завязана на прохождение тестов. Тут критерий жёстче: принял бы такой PR мейнтейнер.
Сначала запускались юнит-тесты и стандартные проверки репозитория: build, lint, typecheck, style-checks и другие команды. Так устроены почти все coding-бенчмарки, и агенты уже неплохо научились это проходить. Отдельно проверяли тесты, которые написал сам агент: их запускали на старом коде, и они должны были падать. Если тест проходит до фикса, он не доказывает, что агент поймал исходную проблему.
Для каждой задачи мейнтейнеры заранее задавали конкретные ограничения проверки: какие файлы здесь допустимо менять, какие трогать нельзя, какой размер diff будет подозрительным, какие требования к стилю, архитектуре и поддерживаемости важны именно в этом месте кода. Эти пункты проверялись автоматически. Часть можно проверить обычным кодом: список файлов, размер diff, число изменённых строк. Часть проверял LLM-ревьюер: ему давали diff и текстовое требование, а он смотрел, соблюдён ли критерий. Например, в одной задаче агент вместо переиспользования общей функции LOG_WARNING() для логирования писал напрямую в stderr. Формально это работает и может проходить тесты, но PR всё равно плохой: код обходит общую логику проекта.
Лучше всех с большим отрывом показал себя Opus 4.8, но даже он пока далёк от стабильного end-to-end качества.
FrontierCode - benchmark для coding agents, где агенту дают сделать pull request в реальном репозитории, а дальше мейнтейнер репозитория решает, можно ли это мержить в main. В SWE-Bench итоговая оценка завязана на прохождение тестов. Тут критерий жёстче: принял бы такой PR мейнтейнер.
Сначала запускались юнит-тесты и стандартные проверки репозитория: build, lint, typecheck, style-checks и другие команды. Так устроены почти все coding-бенчмарки, и агенты уже неплохо научились это проходить. Отдельно проверяли тесты, которые написал сам агент: их запускали на старом коде, и они должны были падать. Если тест проходит до фикса, он не доказывает, что агент поймал исходную проблему.
Для каждой задачи мейнтейнеры заранее задавали конкретные ограничения проверки: какие файлы здесь допустимо менять, какие трогать нельзя, какой размер diff будет подозрительным, какие требования к стилю, архитектуре и поддерживаемости важны именно в этом месте кода. Эти пункты проверялись автоматически. Часть можно проверить обычным кодом: список файлов, размер diff, число изменённых строк. Часть проверял LLM-ревьюер: ему давали diff и текстовое требование, а он смотрел, соблюдён ли критерий. Например, в одной задаче агент вместо переиспользования общей функции LOG_WARNING() для логирования писал напрямую в stderr. Формально это работает и может проходить тесты, но PR всё равно плохой: код обходит общую логику проекта.
Лучше всех с большим отрывом показал себя Opus 4.8, но даже он пока далёк от стабильного end-to-end качества.
❤7
Не могу понять, почему все так начали обсуждать 30-дневный data retention mythos? У антропиков в Claude Code и так по умолчанию для всех пользователей подписок data retention 30 дней. Дополнительно, если вы делаете оценку чата или ставите лайк/дизлайк на какие-то сообщения, то Антропик будет хранить ваш чат 5 лет. Для всех моделей кроме mythos есть программа Zero Data Retention, но она доступна только корпоративным клиентам и только по ручному согласованию. Этим пользуются меньше чем 0.1% трафика.
если вы пользуетесь подпиской, то и для mythos, и для остальных моделей период составляет 30 дней. Он был таким с самого появления cc. Смысл фразы в релизе Mythos, что они будут просматривать и сохранять все чаты, означает лишь то, что эта программа Zero Data Retention для корпоративных клиентов не распространяется на новую модель.
если вы пользуетесь подпиской, то и для mythos, и для остальных моделей период составляет 30 дней. Он был таким с самого появления cc. Смысл фразы в релизе Mythos, что они будут просматривать и сохранять все чаты, означает лишь то, что эта программа Zero Data Retention для корпоративных клиентов не распространяется на новую модель.
❤7🐳1
Во время reasoninga mythos изобрел собственный язык.
При обучения модели не дают (или почти не дают) референс-резонинга так как это делают самими ответами, например, обучая на question-answering датасетах. А через RL учат модель самостоятельно придумывать такой резонинг, приводящий к правильному ответу
Google полгода назад показали, что во время решения математики их модель иногда думает о еде. Так что в целом идея о том, что рассуждения модели не должны совпадать с человеческими паттернами мыслей, не нова.
И еще до выхода ChatGPT, самой первой большой текстовой reasoning модели в мире, были идеи использовать в целом не человеческий язык во время ризенинга, а просто набор векторов эмбэйдингов. Почему-то от такой идеи отказались и все перешли на человекочитаемый reasoning.
Но Mythos решила иначе, что ей лучше размышлять вот так.
При обучения модели не дают (или почти не дают) референс-резонинга так как это делают самими ответами, например, обучая на question-answering датасетах. А через RL учат модель самостоятельно придумывать такой резонинг, приводящий к правильному ответу
Google полгода назад показали, что во время решения математики их модель иногда думает о еде. Так что в целом идея о том, что рассуждения модели не должны совпадать с человеческими паттернами мыслей, не нова.
И еще до выхода ChatGPT, самой первой большой текстовой reasoning модели в мире, были идеи использовать в целом не человеческий язык во время ризенинга, а просто набор векторов эмбэйдингов. Почему-то от такой идеи отказались и все перешли на человекочитаемый reasoning.
Но Mythos решила иначе, что ей лучше размышлять вот так.
🔥12😁4🗿3🤷♂1❤1😨1
Anthropic сделала все по технике
1) релизнула сота модель, которая значимо лучше всего остального
2) предлагает остановить всем лабораториям исследования в области фронтирного ИИ на неопределенный срок до тех пор, пока не разрабатываем механизмы безопасности
3) profit
Reuters
1) релизнула сота модель, которая значимо лучше всего остального
2) предлагает остановить всем лабораториям исследования в области фронтирного ИИ на неопределенный срок до тех пор, пока не разрабатываем механизмы безопасности
3) profit
Reuters
😁24👍4🐳2
Несколько недель назад сенатор Берни Сандерс предлагал «национализировать половину Anthropic» — ну, формально заставить OpenAI, Anthropic и xAI заплатить разовый налог в 50% акций в публичный фонд.
Тогда это звучало как максимально левый популизм, и я даже не стал про это писать.
А теперь США уже заставили Anthropic отключить Fable 5 и Mythos 5 по директиве экспортного контроля.
Чем чёрт не шутит.
https://x.com/BernieSanders/status/2061631422188626083
Тогда это звучало как максимально левый популизм, и я даже не стал про это писать.
А теперь США уже заставили Anthropic отключить Fable 5 и Mythos 5 по директиве экспортного контроля.
Чем чёрт не шутит.
https://x.com/BernieSanders/status/2061631422188626083
X (formerly Twitter)
Bernie Sanders (@BernieSanders) on X
I will soon be introducing a bill to give the public a 50% ownership stake in the largest AI companies in America.
This would guarantee that the trillions created by AI are used to improve the lives of all of us — and block oligarch decisions that harm the…
This would guarantee that the trillions created by AI are used to improve the lives of all of us — and block oligarch decisions that harm the…
❤9😁2👍1
OpenRouter выпустил Fusion, свою модель “Mythos дома”: в API это
У меня от этого лёгкое дежавю: пару лет назад были популярны пайплайны вокруг моделей с ранкерами, реранкерами и судьями, потом все поверили в одну большую модель, а теперь идея возвращается. Самое сложное место тут, модель-судья: LLM сильно biased, и честно сравнивать ответы ей тяжело. Если OpenRouter это нормально решит, получится очень сильная инженерная обвязка.
openrouter/fusion, а внутри один запрос параллельно уходит в несколько LLM. Потом модель-судья сравнивает ответы: где модели сошлись, где противоречат друг другу, какие куски каждая пропустила. Финальный ответ собирается уже из этого разбора.У меня от этого лёгкое дежавю: пару лет назад были популярны пайплайны вокруг моделей с ранкерами, реранкерами и судьями, потом все поверили в одну большую модель, а теперь идея возвращается. Самое сложное место тут, модель-судья: LLM сильно biased, и честно сравнивать ответы ей тяжело. Если OpenRouter это нормально решит, получится очень сильная инженерная обвязка.
👍12❤3🐳2🤝2