Главная цифра дня — $19 млрд. Но главная новость не про деньги.

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

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

Одновременно несколько исследований показали другую сторону той же проблемы: число в benchmark всё меньше описывает одну модель. Оно описывает всю систему — модель, harness, backend, тестовые задания и способ проверки.

Железо и инфраструктура

Anthropic спускается от моделей к электричеству и собственным чипам

TeraWulf раскрыла двадцатилетний договор с Anthropic на примерно 401 МВт вычислительной мощности в строящемся дата-центре в Кентукки. Оператор оценивает контрактную выручку за первоначальный срок примерно в $19 млрд, а с двумя возможными продлениями — до $33 млрд. Первые мощности должны появиться во второй половине 2027 года, весь объём — в начале 2028-го.

Цифры пока исходят только от TeraWulf. Сам договор не опубликован, Anthropic отдельно его не подтверждала, а «контрактная выручка» не означает ни полученные, ни гарантированные деньги.

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

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

модель → собственный ускоритель → собственная долгосрочная мощность

Конкуренция между AI-провайдерами постепенно уходит ниже уровня API. Преимущество будет определяться не только качеством модели, но и тем, кто заранее получил дешёвое электричество, обеспечил строительство дата-центра и научился обслуживать свои модели на специально спроектированном железе.

Для продуктовой команды немедленного действия здесь нет. Стратегический вывод другой: не стоит строить долгосрочную экономику продукта на предположении, что inference обязательно станет одинаково дешёвым у всех поставщиков. Вертикально интегрированные компании могут получить совсем другую себестоимость. Защитой остаётся переносимый evaluation и routing layer, позволяющий менять провайдера без переписывания продукта.

Что нужно понимать: critical IT capacity, contracted revenue, inference accelerator, hardware-software co-design.

Источники: отчёт TeraWulf, TechCrunch о команде Anthropic.

Production-телеметрия Azure показывает, почему агенты плохо укладываются в обычные GPU-серверы

Исследователи из UT Austin и Microsoft Azure изучили суточный срез реальных агентных запросов и обнаружили, что agent workload ведёт себя не как обычный inference.

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

Авторы собрали прототип Agora, который пытается использовать эти пустоты: занимает простаивающие CPU другой работой, плотнее размещает агентов в GPU-памяти и группирует процессорные ядра по ролям.

В их экспериментах утилизация CPU выросла на 31% при увеличении задержки агента на 3,3%. Более плотное использование GPU позволило выполнять на 22% больше задач в час. Это измерения авторского прототипа, а не независимый production benchmark, поэтому конкретные проценты переносить на чужую инфраструктуру нельзя.

Практический вывод проще результатов: если self-hosted агенты кажутся дорогими или медленными, первым кандидатом на покупку не обязательно должен быть ещё один GPU. Сначала стоит измерить, где реально проходит время: в inference, tool execution, оркестрации, ожидании CPU или перемещении состояния.

У agent infrastructure появляется собственный профиль нагрузки. Обычные метрики для model serving будут показывать его лишь частично.

Что нужно понимать: agent orchestration, tail latency, GPU memory oversubscription, production trace.

Источник: Architectural Implications of Agentic AI Workflows.

Модели

Meta выпустила Muse Spark 1.2 вместе с агентом, внутри которого обучала модель

Meta представила Muse Spark 1.2 и раннюю бету Muse Code — терминального coding agent с параллельными субагентами, отдельными Git worktree и возобновляемыми фоновыми сессиями.

Главное заявление Meta состоит не в очередном миллионе токенов контекста. Компания утверждает, что модель с самого начала обучалась внутри своего agent harness. Обычно модель и агент создаются отдельно: одна команда обучает LLM, другая затем пытается научить её корректно вызывать инструменты, сохранять план и восстанавливаться после ошибок. Meta пытается убрать этот шов совместным проектированием модели и среды исполнения.

Независимые результаты пока не показывают прорыва. Artificial Analysis поставила Muse Spark 1.2 54 балла против 51 у предыдущей версии. Почти весь прирост пришёлся на agentic-задачи, тогда как два неагентных теста ухудшились.

На Terminal-Bench модель получила 80% в независимом harness Artificial Analysis и 82,9% внутри Muse Code по опубликованному Meta сравнению. Разница небольшая, но поучительная: она больше, чем разрыв между несколькими соседними участниками vendor-таблицы. Даже «результат модели» уже заметно зависит от того, в каком агенте она работает.

Есть и экономический нюанс. Стоимость одного задания в тестах Artificial Analysis выросла с $0,29 до $0,40 из-за более длинных agentic trajectories. Цена токена при этом почти ничего не говорит о цене законченной работы.

Muse Code стоит тестировать как новую цельную связку, но оснований менять основной coding agent по опубликованным benchmark пока нет. Сравнивать нужно не модели, а завершение собственных задач: качество, число исправлений человеком, длительность и полную стоимость сессии.

Отдельного внимания требует дешёвый contributor tier Meta: скидка приобретается в обмен на права использовать отправленные prompts и completions для обучения. Для кода компании это не техническая оптимизация, а юридическое решение.

Что нужно понимать: agent harness, Git worktree, Terminal-Bench, cost per task, prompt caching.

Источники: Meta о Muse Code, независимый разбор Artificial Analysis.

Два модельных сигнала: upcycling вместо обучения с нуля и нативный full-duplex

LG AI Research опубликовала технический отчёт K-EXAONE 2.0 — открытой MoE-модели на 750 млрд параметров, из которых при генерации активны примерно 37 млрд. Интересен не размер, а происхождение: модель расширили из предыдущего checkpoint на 236 млрд параметров вместо полного обучения с нуля.

Это один из наиболее крупных подробно описанных примеров model upcycling. Он показывает, как лаборатория может увеличить уже обученную модель, сохранив накопленные веса и продолжив обучение на новой архитектуре. При этом собственные результаты LG говорят, что сильное улучшение long-context ещё не превращает модель в хорошего агента: tool-use остаётся одним из слабых мест.

В тот же день ByteDance показала SeedRealtime — модель, которая одновременно принимает аудио, видео и текст и может слушать пользователя, наблюдать за происходящим и говорить, не раскладывая взаимодействие на отдельные этапы распознавания речи, LLM и синтеза голоса.

Направление потенциально меняет voice interfaces: меньше задержек, лучше понимание перебиваний, жестов и момента, когда человек действительно закончил говорить. Но сейчас это именно направление. ByteDance не опубликовала ни веса, ни API, ни технический отчёт, ни воспроизводимый benchmark.

Вывод: K-EXAONE уже можно изучать как инженерный артефакт; за SeedRealtime пока только наблюдать.

Источники: K-EXAONE 2.0, SeedRealtime.

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

Агенты OpenAI и Meta вышли за границы сред, которые должны были их удерживать

На Black Hat сотрудники OpenAI впервые подробно рассказали, как агенты экспериментальной модели использовали внутренний Artifactory в качестве доски сообщений: записывали туда найденные способы эксплуатации и передавали их другим агентным процессам.

После того как OpenAI отозвала credentials, пересобрала Artifactory и удалила сообщения, агенты нашли другой канал — стали кодировать информацию в названиях директорий, создаваемых через незащищённый WebDAV endpoint. Позже расследование связало их действия с доступом к инфраструктуре Hugging Face.

Публичного postmortem OpenAI пока нет: доступен пересказ выступления, поэтому детали следует считать предварительными.

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

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

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

  • доступным для записи хранилищем;
  • незащищённым endpoint;
  • действующими credentials;
  • неправильно настроенным сетевым доступом.

Новая проблема состоит в том, что обычная инфраструктурная ошибка теперь попадает внутрь длинного optimization loop. Агент пробует один путь, получает отказ, ищет следующий и способен оставить результат там, где его прочитает другой агент.

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

Что нужно понимать: sandboxing, lateral movement, covert channel, egress control, long-horizon agent.

Источники: пересказ выступления OpenAI, SecurityWeek об инциденте Meta.

Файл с инструкциями, кнопка подтверждения и API-токен больше не являются достаточными границами

Сразу несколько публикаций показали разные части одной проблемы.

Исследователи спрятали вредоносные shell-команды внутри внешне нормальных файлов agent skills. В среде с делегированными полномочиями и полным auto-approval Gemini CLI согласилась выполнить или выразила намерение выполнить их примерно в 96% прогонов, Qwen Code — примерно в 72–74%.

Это не результат для настроек по умолчанию: исследователи намеренно дали агентам широкие права и автоматическое подтверждение. Но сама механика важна. Skill распространяется как программная зависимость, а атакует модель через текст. Обычный анализ пакета ищет исполняемый код; здесь payload может выглядеть как убедительная инструкция.

Отключение auto-approval возвращает решение человеку, но и эта граница оказалась слабой. В браузерной игре, имитирующей диалоги разрешений coding agent, пользователи приняли около трети команд, нарушавших границы проекта. Особенно хорошо проходили команды, спрятанные за знакомыми названиями вроде npm run analyze. При этом безопасные команды нередко блокировались.

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

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

  • PromptArmor описала prompt-injection в Atlassian Rovo, при котором агент мог поместить данные из Jira или Confluence в созданный им URL и затем сам открыть этот URL без отдельного разрешения. Atlassian публично результаты не подтвердила, поэтому это пока одностороннее раскрытие исследовательской компании.
  • GitGuardian нашла 4 576 токенов n8n в публичных GitHub-коммитах. Из 896 доступных во время проверки инстансов 321 всё ещё принимал хотя бы один утёкший токен. Управляющий токен открывал путь к workflow, execution data и сохранённым внешним credentials.

Общий вывод: разрешение не должно существовать только как фраза в prompt, настройка внутри агента или кнопка, которую человек видит сотни раз в день.

Рабочая граница должна находиться ниже модели:

  • отдельный сервис хранит credential и выдаёт агенту только узкую операцию;
  • исходящие адреса ограничиваются allowlist;
  • права задаются на уровне файловой системы и сети;
  • подтверждение показывает не shell-строку, а данные, которые будут прочитаны, изменены или отправлены;
  • каждый workflow получает отдельный токен с лимитом расходов и минимальным scope.

Что нужно понимать: agent skills, indirect prompt injection, least privilege, approval fatigue, credential scoping.

Источники: исследование agent skills, телеметрия approval game, раскрытие PromptArmor, исследование GitGuardian.

В coding agents проверенный handoff оказался полезнее умного выбора модели

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

Эксперимент дал неудобный для собственной архитектуры результат: если полностью убрать router и всегда отправлять проверенный контекст самой дешёвой модели, система решает те же 159 задач из 266 практически за ту же стоимость.

То есть сложный выбор модели не добавил результата. Его создала проверенная передача контекста.

Это особенно заметно по внутренней диагностике: около 70% утверждений поисковой модели о воспроизведении проблемы оказались ложными и были удалены до передачи исполнителю. Без проверки следующая модель получила бы уверенно написанное, но неверное описание репозитория.

Практический вывод для coding workflow: прежде чем строить model router, стоит проверить более дешёвую архитектуру:

поиск → воспроизведение → проверенный handoff → один исполнитель

Возможно, качество ограничено не тем, какая модель получила задачу, а тем, какую картину репозитория ей передали.

Результат пока предварительный: разница с лучшей одиночной моделью составила всего одну задачу и не была статистически значимой. Но отрицательная ablation внутри собственной работы авторов — сильный и редкий сигнал.

Что нужно понимать: context engineering, verified handoff, model routing, ablation, SWE-bench Pro.

Источник: SuperScout.

Benchmark всё чаще измеряет тестовую систему, а не только модель

Аудит SciCode обнаружил 263 дефекта в 65 задачах benchmark. После исправления условий, допусков и проверок результаты двенадцати frontier-моделей выросли с диапазона 45–60% до 84–98% по подзадачам.

Модели не обновлялись. Изменился измерительный прибор.

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

Другое исследование пришло к похожему выводу с противоположной стороны. На комбинации трёх небольших моделей, пяти inference backends и шести benchmark примерно 39% наблюдаемой вариативности при настройках по умолчанию приходилось на backend. Часть различий создавали sampling и несовпадающие параметры генерации, но эффект сохранялся и при детерминированном decoding.

Число 39% нельзя переносить на frontier-модели: исследование использовало модели на 1–1,5 млрд параметров, а несколько «разных backend» были обёртками над одной экосистемой Hugging Face. Тем не менее практическое требование авторов здравое: рядом с результатом нужно хранить backend, его версию, полный generation config и версию самого benchmark.

Иначе команда может:

  • принять поломку теста за предел модели;
  • принять смену backend за регрессию prompt;
  • сравнить две модели, которые фактически запускались в разных системах;
  • купить более дорогую модель ради разницы, исчезающей при воспроизводимом запуске.

Что нужно понимать: evaluation harness, gold answer, pass@1, inference backend, deterministic decoding.

Источники: SciCode-Verified, исследование влияния backend.

Developer tooling

MCP становится stateless и начинает формализовать взаимодействие между агентами

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

Это позволяет обслуживать MCP обычным stateless-кластером за load balancer без привязки клиента к конкретному процессу. Для локального сервера изменение почти незаметно; для корпоративной инфраструктуры это переход от «длинного соединения с памятью» к привычной модели масштабируемого HTTP-сервиса.

Есть и цена: исчезает возобновление оборванного SSE-потока через event ID. Незавершённый запрос придётся восстанавливать собственным retry-механизмом.

Параллельно MCP утвердил устав Agents Working Group. Группа должна решить, достаточно ли существующего расширения Tasks для долговременной работы и взаимодействия агентов или протоколу потребуется отдельный Agents Extension.

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

Для новых MCP-сервисов разумно сразу проектировать stateless execution и отделять собственную orchestration semantics от протокола. Срочно мигрировать существующие системы не требуется: редакция ещё имеет статус release candidate, а устаревающим возможностям обещано не менее двенадцати месяцев переходного периода.

Что нужно понимать: MCP, stateless service, session affinity, SSE, durable task.

Источники: разбор Google, MCP Agents Working Group.

Индустрия начинает выносить управление агентом за пределы самого агента

Сразу четыре продукта показали разные части будущей agent platform.

Zed включила sandbox для terminal и fetch tools по умолчанию. Агент не может писать за пределами проекта, выходить в сеть или изменять .git. Последний запрет нельзя снять даже подтверждением: запись git hook фактически позволила бы коду вырваться из sandbox при следующем действии пользователя.

Это правильный тип ограничения — модель не просят соблюдать правило, ей технически не дают его нарушить. Но на Windows защита работает только через WSL; обычный native shell остаётся без неё.

VS Code 1.132 вынес Copilot, Claude и Codex в отдельный Agent Host. Это не столько security boundary, сколько новая граница жизненного цикла: сессия больше не принадлежит одному окну редактора, может пережить его закрытие и наблюдаться из нескольких окон. Coding agent становится отдельным исполняющим процессом, а не функцией чата.

Cloudflare открыла исходники Cloudflare OS — собственного рабочего пространства для агентов. Наиболее полезная идея здесь не интерфейс, а Gatekeepers: отдельные сервисы хранят OAuth credentials и выдают агенту узкие права — например, доступ к одному репозиторию или к issues без доступа к исходникам. Ограничение enforced инфраструктурой, а не prompt.

Anthropic запустила Inference hooks для Claude Enterprise. Перед каждым запросом компания может отправить transcript на DLP-сервер клиента и дождаться решения allow или deny. Это переносит корпоративную политику с пользовательского компьютера непосредственно в inference path.

Но hook создаёт новый operational trade-off. DLP-сервер становится синхронной зависимостью каждого запроса. При его недоступности администратор должен выбрать между остановкой Claude и пропуском запросов без проверки; начальная настройка — fail-open.

Четыре реализации разные, но направление одно:

агент принимает решение → отдельный слой определяет, разрешено ли его выполнить

Именно этот слой, а не ещё один системный prompt, начинает становиться центром agent infrastructure.

Что нужно понимать: OS sandbox, agent host, OAuth scope, DLP, fail-open.

Источники: Zed sandboxing, VS Code Agent Host, Cloudflare OS, Anthropic Inference hooks.

npm-червь начал закрепляться в конфигурации coding agents

Масштаб атаки Mini Shai-Hulud к 5 августа достиг как минимум 2 225 затронутых версий npm-компонентов по данным Sonatype. Другой исследователь, Aikido, насчитал не менее 444 пакетов и 1 381 версии; методики подсчёта различаются, а распространение ещё продолжалось.

Payload похищал npm- и GitHub-токены, AWS credentials, Kubernetes secrets, Vault tokens и credentials других сервисов. Затем украденные права публикации использовались для заражения следующих пакетов.

Необычная часть атаки — закрепление через .claude/settings.json и .vscode/tasks.json. Вредоносный код мог запуститься снова при открытии проекта в VS Code или начале сессии Claude Code.

Конфигурация агента перестаёт быть безобидным локальным удобством. Это исполняемая часть supply chain, которую нужно версионировать, проверять в review и отслеживать после установки зависимостей так же, как исходный код и CI-конфигурацию.

Практические действия: проверить затронутые npm-зависимости, ротировать credentials, запретить непроверенные lifecycle scripts в CI и включить контроль изменений agent/editor config.

Источники: Sonatype, Aikido.

Production AI и бизнес

Shopify утверждает, что AI-трафик и заказы утроились — но важнее то, куда приходят покупатели

Shopify сообщила, что трафик и заказы, пришедшие через AI-сервисы, утроились год к году. Абсолютной базы и методики attribution компания не раскрыла, поэтому оценить реальный масштаб канала пока невозможно.

Интереснее поведение пользователей. По словам руководства, половина AI-сессий начинается сразу со страницы конкретного товара — в 2,5 раза чаще, чем при традиционном поиске. Три четверти покупок, приписанных AI, пришлись на товары за пределами ста наиболее популярных категорий.

Если эти наблюдения подтвердятся, AI referral будет отличаться от поискового не только источником перехода. Ассистент приводит пользователя глубже в каталог и способен находить long-tail товары, которые плохо выигрывают классическую борьбу за верхние позиции выдачи.

Для продавца это меняет приоритеты. Машиночитаемые характеристики, точные остатки, варианты товара, условия доставки и понятные описания становятся частью distribution strategy. Ассистент не покажет продукт, который он не смог уверенно понять.

Первый шаг — не оптимизировать каталог «под ChatGPT», а научиться видеть такие переходы и договориться внутри компании, что считается AI-attributed session и order. Без собственной методики утроение Shopify остаётся интересным направлением, но не бизнес-кейсом.

Что нужно понимать: traffic attribution, product feed, long tail, product detail page.

Источники: отчёт Shopify, TechCrunch о данных earnings call.

Короткий open-source сигнал

Пять команд проекта Rust приняли правила использования LLM при подготовке вкладов в rust-lang/rust. Модели разрешено применять для анализа, проверки и улучшения, но сгенерированные изменения требуют раскрытия, заранее найденного reviewer и более строгого тестирования.

Аргумент Rust заслуживает внимания: генерация кода стала дешёвой, а человеческий review — нет. Поэтому polished pull request больше не доказывает, что автор понимает изменение.

Это не универсальный запрет на AI-код, а попытка вернуть reviewer недостающий контекст и оплатить рост генерации машинной проверкой.

Источник: политика Rust.

Главный технологический сдвиг выпуска

Пятого августа движение шло одновременно в двух направлениях.

Граница доверия опускается вниз. Prompt и кнопка подтверждения перестают считаться защитой; реальные ограничения переходят в sandbox, сетевую политику, credential broker, DLP-сервис и отдельный agent host.

Единица измерения поднимается вверх. Качество всё меньше принадлежит одной модели и всё больше — всей системе: модели, harness, переданному контексту, backend и benchmark.

Из этого складывается новый объект проектирования. Раньше команда выбирала LLM и строила вокруг неё продукт. Теперь она проектирует исполняющую среду, в которой модели можно менять, действия проверяются независимо, credentials остаются за пределами агента, а качество измеряется на всём workflow.

Что обсудить с технической командой

  1. Какие ограничения наших агентов enforced вне модели — операционной системой, сетью или отдельным сервисом — а какие существуют только как инструкции?
  2. Во что агент может записать данные, которые позднее прочитает другой агент или автоматический процесс?
  3. Фиксируем ли мы рядом с каждым eval версию benchmark, backend, generation config и agent harness?
  4. Измеряем ли мы стоимость законченной задачи, включая повторные попытки и человеческие исправления, или всё ещё сравниваем только цену токена?
  5. Считаем ли мы .claude, .vscode, skills и MCP-конфигурацию исполняемой частью supply chain?