10 тысяч ИИ-агентов и задача тысячелетия: что показал эксперимент OpenAI

Новость о тысячах ИИ-агентов, работающих над задачей тысячелетия, легко прочитать как обещание: теперь нейросети могут всё. Но руководителю, инженеру или владельцу компании полезнее разобраться, как устроена такая работа и что считается её результатом. Между убедительным ответом, проверяемым материалом и признанным открытием есть несколько важных переходов.

Эксперимент OpenAI с задачей Навье — Стокса даёт повод обсудить именно их. Научный статус новости требует аккуратности, а вопросы организации работы уже понятны: кто ставит задачу, какие инструменты доступны, сколько попыток допустимо и чем проверяется итог.

По сообщению OpenAI от 8 сентября 2026 года, в работе участвовали около 10 тысяч агентов на внутренней модели. Поиск занял 88 часов; формализация и проверка в Lean — ещё 17 часов. Генерация составила около 130 млрд выходных токенов. Исследователи направляли группы и перераспределяли ресурсы. OpenAI · On the Navier–Stokes Millennium Prize Problem ↗

На момент проверки 9 сентября 2026 года сайт Института Клэя продолжает обозначать задачу как нерешённую. Поэтому здесь мы говорим о предложенном доказательстве и опубликованных материалах, а не об окончательно признанном решении задачи тысячелетия. Текущий статус института сам по себе также не является опровержением работы. Clay Mathematics Institute · Navier-Stokes Equation: current status ↗

Для рассмотрения премии правила Клэя предусматривают публикацию в подходящем издании, не менее двух лет после неё и общее признание математическим сообществом. Это отдельная процедура, которую нельзя заменить громким анонсом или наличием файла с доказательством. Clay Mathematics Institute · Rules for the Millennium Prize Problems ↗

Уравнения описывают движение жидкости и газа в математической модели. В официальной задаче рассматривается трёхмерная несжимаемая жидкость: сохраняются ли гладкие решения при заданных условиях или можно построить пример их разрушения. Варианты постановки включают определённые требования к начальным данным, внешней силе и энергии. Charles L. Fefferman · Official Navier–Stokes problem description ↗

В опубликованной работе авторы заявляют, что при гладкой внешней силе можно получить неограниченный рост скорости за конечное время, сохраняя ограниченную кинетическую энергию. Они связывают конструкцию с вариантами C и D задачи Клэя. Это конкретное утверждение о свойствах математических решений. OpenAI · Finite time blowup for Navier–Stokes: proposed proof ↗

Отсюда не следует, что появился универсальный расчёт любой вентиляции, трубопровода или самолёта. Между теоремой и инженерным инструментом остаются модель объекта, граничные условия, численные методы, исходные данные и проверка применимости. Для проектировщика это разные уровни работы, каждый со своими критериями качества.

Вместе с работой опубликован репозиторий формализаций на Lean и инструкции для проверки. Это позволяет изучать не только изложение аргумента, но и его машинно проверяемое представление. Наша редакция не воспроизводила сборку этого доказательства и не проводила математическую экспертизу. OpenAI · NavierStokesAndEuler formalizations ↗

Lean — инструмент формализации и проверки доказательств. Его небольшое проверяющее ядро проверяет формальные доказательные термы. Важен и перевод исходного вопроса в формальную запись: проверка относится к записанному утверждению и его предпосылкам. Она не устанавливает автоматически, что формализация охватывает именно то, что читатель понял из заголовка. Lean · The Lean Language Reference ↗

Для читателя без математической подготовки полезно разделить три вопроса. Что именно утверждают авторы? Можно ли проверить представленные основания? Признан ли результат специалистами в заявленном смысле? Ответ на один вопрос не должен незаметно становиться ответом на остальные.

Чем сложнее задачу мы поручаем ИИ, тем важнее заранее определить, как будет проверяться результат.

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

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

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

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

Для корпоративной задачи полезна последовательность: задать требования, выполнить ограниченные поисковые или подготовительные шаги, собрать основания, провести отдельные проверки и передать результат ответственному человеку. Это предлагаемая прикладная схема; она не воспроизводит устройство исследовательской системы OpenAI.

В начале фиксируют входные документы и их версии. В конце — конкретный результат: проект предложения, таблицу соответствия, расчёт или перечень нерешённых вопросов. Формулировка «разберись и сделай хорошо» не позволяет понять ни границы полномочий, ни критерий завершения.

На каждом переходе полезно передавать вместе с выводом источник, допущения и обнаруженные ограничения. Если важного документа нет, этот факт должен пережить все последующие пересказы и остаться видимым в итоговом материале.

Представим задачу подготовки коммерческого предложения по спецификации объекта. В запросе перечислены позиции, количество и технические требования. Есть каталог, документы производителей и условия поставки. Сценарий иллюстративный: речь о проектируемом процессе, а не о выполненном заказе клиента.

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

Расчёт стоимости выполняется по утверждённым данным и правилам. Модель не должна придумывать цену, округление или налоговый режим по похожему примеру. Если варианты имеют разный состав поставки, их нельзя ранжировать только по нижней строке суммы.

Результатом становится проект КП с основаниями: откуда взята каждая позиция, чем подтверждена характеристика, какие условия ещё нужно уточнить. Менеджер проверяет спорные места, а профильный специалист подтверждает технические решения в пределах своей ответственности. Отправка заказчику остаётся отдельным действием с согласованными полномочиями.

Здесь может хватить одного агента с несколькими инструментами. Несколько агентов оправданы, если разделение задач даёт измеримую пользу. Количество участников выбирают после проверки процесса на реальных примерах.

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

Проверки поэтому имеют разную природу. Арифметику можно пересчитать программно. Наличие обязательного поля — проверить по схеме. Указанную характеристику — сверить с источником. Полноту комплекта и уместность технического решения нередко должен оценить специалист.

Важно показывать, что именно проверено. Метка «проверено ИИ» слишком неопределённа. Полезнее сообщить: суммы пересчитаны; позиции связаны с версией каталога; по двум характеристикам нет подтверждений; замена оборудования ожидает согласования.

Такой подход сохраняет ответственность и помогает человеку тратить внимание на существенные вопросы. Он не превращает деловой документ в математически доказанную истину, но делает процесс проверки понятнее и воспроизводимее.

Большой объём генерации показывает масштаб выполненной работы, но сам по себе не раскрывает её себестоимость. Для внутренней исследовательской модели нельзя без дополнительных данных переносить публичные тарифы другого продукта. Тем более нельзя обещать, что потенциальная премия окупает эксперимент.

В прикладном проекте считают полный путь: чтение документов, повторные обращения, проверку, ожидание и исправления человеком. Учитывают и обслуживание источников. Сценарий может отвечать быстро, но оказаться неудобным, если каждое его предложение приходится долго перепроверять.

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

Полезный показатель — стоимость принятой задачи с учётом проверки. Его сравнивают с исходным процессом на сопоставимом наборе примеров. Исследовательский рекорд не задаёт этот показатель для другой организации.

У новости есть спорная сторона. Тристан Бакмастер изложил претензии к обстоятельствам взаимодействия с OpenAI и описанию вклада участников. В заявлении он отдельно отмечает, что не знает, использовались ли их данные. Это позиция участника, а не установленный факт заимствования. Tristan Buckmaster · Public statement on concurrent work ↗

OpenAI отрицает доступ к конкретным пользовательским данным для решения задачи, но не исключает косвенного вклада обезличенных данных использования в улучшение моделей. Компания также указывает на различия работ. OpenAI · On the Navier–Stokes Millennium Prize Problem ↗

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

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

В программном прототипе AI Office есть отдельные элементы такого подхода: поиск по документам с проверкой прав, версии источников, связи КП со строками каталога и расчёты денежными десятичными значениями. Подготовленные документы можно экспортировать, а предусмотренные действия проходят согласование. Эти возможности относятся к конкретным реализованным сценариям.

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

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

Начать можно с одного повторяющегося задания: определить хороший результат, собрать проверочные примеры и заранее описать основания для принятия. Для AI Office это более содержательная отправная точка, чем обещание повторить научный эксперимент в масштабе обычного офиса.