Борис Черный, создатель Claude Code, отдал 12 агентам 64 научные статьи и одну задачу: превратить их в браузерную лабораторию, где читатель запускает симуляции и повторяет эксперименты из этих работ. Пользователь открывает страницу, выбирает опыт, меняет условия и следит за результатом.
Показательный пример из описания кейса - симуляция жидкости (разбор кейса). Меняешь условия задачи, запускаешь расчёт, наблюдаешь, как меняется поведение системы. Рядом с анимацией выводят уравнения и код, на которых всё построено: читатель видит и картинку, и математику за ней.
Практическая ценность здесь в автоматизации рутины, которая обычно съедает недели: вычитать десятки статей, вытащить уравнения, собрать численную схему, написать код и убедиться, что он не врёт. Каждый из этих шагов отдан отдельной группе агентов.
Главную проблему в кейсе называют прямо: симуляция может выглядеть правдоподобно и при этом выдавать неверный результат. Красивая анимация сама по себе ничего не доказывает. Поэтому перед одобрением эксперимента идёт проверка сохранения массы, стабильности системы и совпадения с измерениями из оригинальной статьи. Дальше - разбор ролей, проверок и сухих цифр: 11 методов, 28 эталонных сцен, 7 совпадений с допустимой погрешностью и 4 сцены, оставшиеся под вопросом.
Архитектура мультиагентного пайплайна: кто за что отвечает
12 агентов делятся на четыре функциональные группы: readers, builders, reviewers и interface agents. Роли не закреплены жёстко, границы между ними пересекаются по мере движения статьи по конвейеру. Логика такая: текст разбирают на данные, данные превращают в код, код проверяют, поверх всего строят интерфейс.
Readers: извлечение уравнений и условий из статей
Readers работают с исходными 64 статьями и вытаскивают из текста уравнения, граничные условия и параметры экспериментов. Это не механический парсинг: агенту нужно понять, какие переменные существенны, в каких единицах они заданы и какие допущения авторы принимали по умолчанию. Для симуляции жидкости речь про уравнения движения, вязкость, плотность и начальные условия.
Ошибки интерпретации на этом этапе не бросаются в глаза, но всплывают в расчётах. Если reader решит, что вязкость дана в других единицах, симуляция соберётся, запустится и покажет неверный результат.
Builders: превращение методов в рабочий код
Builders берут извлечённые данные и пишут код симуляции, который исполняется прямо в браузере. Код должен считать корректно и оставаться воспроизводимым: параметры опыта выносят в интерфейс, чтобы читатель мог их менять и получать сопоставимый результат.
Здесь же закладывают базу для последующих проверок. Если численная схема неустойчива или шаг по времени выбран неудачно, reviewers поймают это на валидации, а не пользователь в браузере.
Reviewers: проверка сохранения массы, стабильности и совпадения с эталоном
Reviewers - звено, от которого зависит доверие ко всей лаборатории. Перед одобрением эксперимента они проверяют три условия: сохраняется ли масса, остаётся ли система стабильной, совпадают ли результаты с измерениями из оригинальной статьи. Анимация, которая нарушает сохранение массы, не проходит как валидный результат.
Сверка идёт по эталонным сценам, всего их 28. Семь совпали с допустимой погрешностью, четыре остались под вопросом. Для каждого опыта фиксируют исходное утверждение, условия, отклонение от эталона и параметры, которые ещё нужно проверить.
Interface agents: интерфейс и элементы управления
Interface agents собирают пользовательскую часть: выбор симуляции, ползунки для изменения условий, кнопки запуска, графики и визуализацию данных. Отдельная задача - вывести рядом с анимацией уравнения и код, чтобы читатель сопоставлял поведение системы с математикой за ним.
Интерфейс решает, получится ли у читателя повторить эксперимент без инструкции. Если параметры спрятаны, а результат не с чем сравнить, лаборатория теряет смысл, потому что воспроизвести опыт становится нельзя.
Конвейер из четырёх ролей позволяет прокачать 64 статьи, которые вручную обрабатывали бы месяцами. Цена этой скорости - координация: чем больше агентов работает параллельно, тем выше риск, что один перепишет допущения другого. Про типичные сбои таких схем мы разбирали отдельно: рой из десятков агентов не становится умнее.
Как работает лаборатория на примере симуляции жидкости
Сквозной сценарий выглядит так. Читатель открывает лабораторию, выбирает симуляцию жидкости, меняет условия: например, вязкость или начальные параметры потока. Запускает расчёт и наблюдает, как система реагирует на правку. Рядом на экране - уравнения и код, которые описывают этот расчёт.
Уравнения рядом с анимацией меняют характер работы. Это не чёрный ящик, куда подставляют числа и получают картинку: формулу можно сверить с поведением жидкости на экране и заметить расхождение. Для обучения такой формат полезнее статичного графика из PDF, потому что читатель сам двигает параметры и видит последствия.
Тот же подход работает для проверки гипотез и повторения чужих экспериментов без написания кода с нуля. Условия уже заданы, код открыт, остаётся менять входные данные и сравнивать результат с исходной статьёй.
Проверка достоверности: почему правдоподобная симуляция может быть неверной
LLM-агенты ошибаются в уравнениях, единицах измерения и численных методах. Ошибка не всегда ломает визуализацию: картинка остаётся гладкой и убедительной, а числа за ней уже неверны. Отсюда требование проверять каждый эксперимент перед публикацией.
Сохранение массы и стабильность системы
Сохранение массы для жидкости - фундаментальный закон. Если численная схема его нарушает, результаты недостоверны, как бы красиво они ни выглядели. Стабильность системы означает, что решение не расходится со временем. При слишком большом шаге по времени симуляция может буквально «взорваться», и это не всегда заметно на ранних кадрах анимации.
Проверки сохранения массы и устойчивости дают быстрый фильтр: расчёт либо проходит их, либо сразу идёт на доработку. Такой слой самопроверки - общий инженерный паттерн для агентных систем, его разбирали на примере призовых проектов хакатона Anthropic Built with Claude: Life Sciences (архитектура LLM-агентов с верификацией).
Сравнение с измерениями из оригинальной статьи
Дальше результаты сверяют с эталоном из статьи: графиками, таблицами, значениями. Для каждого эксперимента фиксируют отклонение от эталона. Так видно, какие методы держат точность, а какие требуют доработки.
Методику расчёта допустимой погрешности и её конкретные значения источник не раскрывает. Известно только итоговое распределение: 7 сцен из 28 попали в допуск, 4 остались под вопросом.
Результаты: 7 из 28 сцен совпали, 4 под вопросом
Сухие цифры кейса: 11 методов, 28 эталонных сцен. Семь совпали с допустимой погрешностью, четыре остались под вопросом. По остальным сценам данных в источнике нет: не сказано, провалили они проверку или до них не дошла очередь.
Четыре сцены под вопросом - честный результат первого прохода, а не провал. Для каждого эксперимента описан исходный тезис статьи, условия, отклонение от эталона и параметры, которым нужна дополнительная проверка. Это и есть рабочий список задач для следующей итерации.
Источник не уточняет, какие именно четыре сцены остались спорными и в чём состояли отклонения. Пока не раскрыты и детали пайплайна: используемые модели, инфраструктура и то, как reviewers сверяли числа с измерениями. Дальнейшая судьба лаборатории, её доступность и открытость кода тоже не описаны (публикация с разбором кейса).
Границы доверия: что можно и чего нельзя ждать от таких агентов
Агенты ошибаются на всех этапах: в извлечении уравнений, в выборе численного метода, в трактовке условий. Ошибка на входе проходит через весь конвейер и превращается в уверенно выглядящую, но неверную симуляцию. Поэтому проверка результатов остаётся обязательным этапом, а не опцией.
Слепо доверять агенту, который сам себя проверяет, опасно: у него нет внешней точки опоры, кроме тех же данных. Здесь работает тот же принцип, что и в runtime-контроле продакшен-систем, где между агентом и изменением данных ставят детерминированный шлюз (разбор контроля на границе исполнения). Для научных симуляций роль такого шлюза играют проверки сохранения массы, стабильности и сверка с измерениями: физика не даёт агенту договориться с самим собой.
Методика определения допустимой погрешности в источнике не раскрыта. Для практики это значит: критерии проверки придётся задавать самому, под конкретную задачу и требуемую точность.
Практические выводы: кому и как использовать такой подход
Подход стоит разбирать тем, кто строит агентные пайплайны и упирается в один и тот же барьер: код агенты пишут быстро, а проверять его некому. Схема из четырёх ролей - readers, builders, reviewers, interface agents - даёт разделение труда, где валидация выделена в отдельную функцию, а не висит на человеке.
Что перенять в свои проекты:
- Разделять извлечение данных, генерацию кода и проверку между разными агентами. Тот же агент не должен оценивать собственную работу.
- Определять проверяемые метрики заранее. Для жидкостей это сохранение массы и устойчивость, для других задач - свои инварианты, которые можно посчитать, а не оценить на глаз.
- Фиксировать для каждого эксперимента исходное утверждение, условия и отклонение от эталона. Без такой таблицы непонятно, какие результаты подтверждены, а какие висят в воздухе.
- Начинать с малого набора сцен. 28 эталонных случаев и 7 подтверждённых совпадений полезнее сотни непроверенных симуляций.
Ограничения тоже конкретны. Не каждый метод из статьи поддаётся автоматическому переносу в код, а часть расчётов требует экспертной валидации. Код в таких пайплайнах дешевеет, и ценность смещается к проверке, постановке критериев и данным (что это значит для ценности кода в эпоху AI-агентов).
Практический старт: возьмите одну статью с понятными уравнениями и эталонными графиками, соберите минимальный конвейер из читателя, разработчика и проверяющего, задайте измеримый критерий совпадения. Если симуляция проходит проверку по физике и цифрам, конвейер можно масштабировать на остальные статьи.