Модели и capability

Anthropic: десятки Claude-агентов формализовали теорему Ферма в Lean

Что произошло. Anthropic опубликовала первый, по её утверждению, полный computer-checked proof Великой теоремы Ферма. Claude в основном автономно работал 11 дней, сгенерировал около 13 млн строк Lean и доказал 30 300 промежуточных теорем, из которых 29 500 вошли в итоговый proof. Финальный результат проверяется самим Lean, а полный код опубликован.

Самое интересное для нашей темы — не математика, а архитектура. Первые попытки нескольких агентов проваливались: они теряли состояние проекта и переставали эффективно координироваться. Успех пришёл после перехода на Prove2Me + Claude Code multi-agent harness: DAG зависимостей между теоремами, раздельное хранение statements и proofs, общий поиск и повторное использование результатов. Проект потребовал примерно 6 млрд output tokens.

Почему это важно. Это чрезвычайно чистый production-like пример тезиса: capability модели сама по себе оказалась недостаточной. Задача стала решаемой после появления правильного external state, decomposition и deterministic verifier.

Это почти тот же паттерн, который нужен в software engineering:

большая задача → dependency graph → независимые workers → общий state → deterministic verification.

Что показали данные. Это не benchmark и не сравнение моделей. Это большой vendor-run experiment на одной конкретной задаче. Сильная сторона evidence — финальный артефакт проверяется формальной системой, а не LLM-judge.

Что нужно уже понимать: formal verification, Lean, DAG, multi-agent orchestration, deterministic verifier.

Что это может изменить. Для сложных coding agents всё интереснее становятся не «длинные промпты», а явный dependency graph и проверяемые промежуточные artifacts. Если команда строит long-running agent workflow, это хороший повод посмотреть, можно ли разбить его на dependency-aware units вместо одного огромного контекста.

Дата: 4 сентября. Первоисточник: Anthropic — Formalizing Fermat's Last Theorem

Архитектура и эксплуатация агентных систем

Speculative execution пришёл в tool-using agents

Что произошло. Работа Speculative Macro Commit предлагает двухуровневую архитектуру: большая authoritative model принимает реальные решения, а маленькая быстрая модель параллельно предполагает несколько следующих действий и заранее исполняет их в изолированной копии environment. Если первое предсказанное действие совпадает с решением основной модели, система может сразу принять уже рассчитанную цепочку следующих шагов.

Что показали данные. С Qwen3.5-27B INT4 в роли actor и Qwen3.5-4B в роли drafter авторы получили на τ²-Bench Telecom ту же общую accuracy, но latency ниже на 18,59% относительно обычного последовательного выполнения и на 10,23% относительно simpler speculative-actions baseline. На AppWorld wall-clock time сократилось на 44,9% против sequential execution, хотя completion rate немного снизился. Код открыт.

Почему это важно. Latency агента — это не только скорость генерации токенов. В browser/code/tool agents огромная часть времени уходит на последовательность:

think → call → wait → observe → think → call.

Если следующий набор действий можно предсказывать и безопасно выполнять заранее, architecture начинает компенсировать latency самого environment.

Что нужно уже понимать: speculative execution, tool calling, actor/drafter, sandbox snapshot, wall-clock latency.

Что это может изменить. Пока это research-stage, но идея практически применима к агентам с повторяемыми workflow. Особенно интересна для browser automation, CI/CD и enterprise SaaS, где external actions медленнее model inference.

Дата submission: 3 сентября; работа попала в свежий arXiv listing 4 сентября. Первоисточник: arXiv — Speculative Macro Commit

«Свежая память» не гарантирует, что агент действует по свежему плану

Что произошло. Работа Fresh Memory, Stale Plans выделяет отдельный failure mode distributed agent systems: агент может получить обновлённый shared state, но продолжить выполнять действие, разрешённое старой версией плана.

Авторы предлагают PlanFence: каждый план явно указывает records, от которых он зависит, а непосредственно перед внешним действием executor проверяет только релевантные зависимости. Если они изменились — требуется replanning либо действие блокируется.

Что показали данные. В 30 controlled live workflows после изменения requirements простой freshness-only executor 30 из 30 раз исполнил устаревший план. PlanFence завершил все 30 workflow без invalid action. Авторы отдельно подчёркивают: это safety/systems-cost result, не общий прирост task accuracy.

Почему это важно. Это очень практический distributed-systems insight. У multi-agent системы два разных свойства:

state is fresh ≠ decision based on state is still valid.

Для агентов, которые создают PR, совершают покупки, меняют cloud infrastructure или обновляют CRM, такая разница критична.

Что нужно уже понимать: shared state, stale state, dependency tracking, optimistic validation, replanning.

Что это может изменить. Если несколько агентов работают с общим состоянием, стоит думать не только о memory synchronization. Важнее provenance: на основании какой версии данных было принято конкретное решение.

Дата: 3 сентября; в новом arXiv listing — 4 сентября. Первоисточник: arXiv — Fresh Memory, Stale Plans

Ограниченный deterministic workflow может оказаться надёжнее «умного» runtime-planning

Что произошло. В MasterControl Seventeen Every Time авторы сравнили два варианта enterprise analytics.

В первом небольшие LLM сами генерировали SQL и выбирали tools во время выполнения. Во втором Qwen3-8B только интерпретировал intent пользователя, после чего deterministic policy выбирала заранее разрешённую analytical program.

Что показали данные. Из 330 agentic runtime-planning runs ни один не выполнил полный answer-and-evidence contract на всех test datasets. Deterministic-policy architecture выполнила 110 из 110. Авторы специально предупреждают: это результат конкретной конфигурации, а не доказательство того, что runtime agents в принципе не работают.

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

Полезная архитектура:

LLM understands intent → deterministic software decides what is permitted → deterministic executor performs operation.

Это особенно релевантно finance, analytics, permissions, compliance и другим системам, где auditability важнее максимальной автономности.

Что нужно уже понимать: deterministic execution, SQL generation, policy engine, evidence contract, auditability.

Что это может изменить. Хороший вопрос к команде: какие решения действительно требуют agent reasoning, а какие после распознавания intent можно вернуть в обычный deterministic software.

Дата submission: 2 сентября; новый arXiv listing — 4 сентября. Первоисточник: arXiv — MasterControl Seventeen Every Time

Developer tooling и программирование

GPT‑6 Astra дошла до GitHub Copilot — но важнее то, как GitHub описывает её поведение

Сам релиз Astra уже был в предыдущем выпуске, поэтому здесь только новое существенное обновление.

Что произошло. 4 сентября GitHub открыл GPT‑6 Astra в Copilot для VS Code, Visual Studio, CLI, coding agent, JetBrains, Xcode, Eclipse, GitHub.com и mobile.

GitHub отдельно отмечает, что во внутренних тестах модель не просто генерировала лучший конечный результат: она планировала, самостоятельно валидировала промежуточную работу, объединяла diagnosis с verification и отдельно подтверждала результат перед завершением задачи. GitHub утверждает, что это дало более сильные long-horizon coding results с меньшим количеством шагов относительно предыдущих OpenAI models; абсолютные benchmark numbers здесь не опубликованы.

Почему это важно. Граница между «способностью модели» и «harness behavior» становится всё менее чёткой. Часть planner/verifier logic постепенно перемещается непосредственно в модель.

Это потенциально упрощает harness, но создаёт новый вопрос: что можно доверить встроенному self-verification модели, а что всё равно должно проверяться внешним deterministic layer.

Что нужно уже понимать: long-horizon coding, self-verification, agent loop, model policy, usage-based billing.

Что это может изменить. Не менять default model всей команды сразу. Стоит прогнать Astra на внутренних задачах и сравнить прежде всего human interventions, number of steps, cost per completed issue и post-review defects, а не только субъективное качество ответа.

Дата: 4 сентября. Первоисточник: GitHub Changelog — GPT‑6 Astra in Copilot

VS Code Agent Merge начинает закрывать весь цикл PR после написания кода

Что произошло. В VS Code 1.136 появился public preview Agent Merge: агент получает pull request и пытается самостоятельно разбирать review feedback, failed checks и merge conflicts, пока PR не станет merge-ready. Одновременно появились hierarchical chat sessions и experimental multi-root agent workspaces.

Почему это важно. Coding agents постепенно перемещаются дальше по SDLC:

write code → create PR → react to review → fix CI → resolve conflicts → merge-ready.

Именно последние этапы обычно съедают большой объём инженерного времени после первоначальной генерации кода.

Что показали данные. GitHub пока не публикует independent completion-rate или defect-rate для Agent Merge — это product preview, а не подтверждённое productivity improvement.

Что нужно уже понимать: pull request, CI, merge conflict, agent session, SDLC.

Что это может изменить. Если команда уже активно использует coding agents, имеет смысл измерять не «сколько кода написал AI», а time from issue to merge и human review minutes. Именно туда теперь движется tooling.

Дата: 4 сентября. Первоисточник: GitHub Copilot weekly releases

Production AI, SaaS и бизнес

Wonderful привлекла $550 млн при оценке $5 млрд на «AI OS для предприятия»

Что произошло. Амстердамская Wonderful закрыла Series C на $550 млн при $5 млрд valuation. Раунд возглавила Insight Partners, участвовали Salesforce, Index Ventures, IVP, Vine Ventures, 9Yards и Bessemer. Компания сообщает о работе более чем в 35 рынках и 650 сотрудниках.

Wonderful позиционируется уже не как набор готовых agents, а как общий AI operating layer: workflows, context, приложения, compliance и coordination нескольких agents внутри предприятия.

Почему это важно. SaaS-рынок начинает продавать не отдельного «AI sales agent» или «support agent», а control plane для всей организации агентов.

Это важная архитектурная эволюция:

single AI feature → isolated agent → fleet of agents → organization-wide agent platform.

Что показали данные. Финансирование и geographic expansion подтверждены компанией. Независимых показателей productivity/ROI клиентов в релизе нет.

Что нужно уже понимать: agent orchestration, enterprise context, AI control plane, workflow automation, governance.

Что это может изменить. Пока наблюдать. Но если внутри компании начинают появляться десятки автономных workflows, вопрос «какой агент использовать?» быстро превращается в «где хранится общий context, permissions, audit log и policy?».

Дата: 4 сентября. Первоисточник/официальное сообщение: Wonderful Series C announcement