Агенты, Codex и MCP-инфраструктура: почему AI переходит из чата в рабочий слой

AI-агенты переходят из чата в рабочую инфраструктуру: Codex, MCP, Computer Use и Autodata показывают, какие слои теперь нужны.

Инфраструктура AI-агентов: LucidLink MCP Server читает файлы и собирает список задач

Факты проверены 26 июня 2026 года. Инфраструктура AI-агентов - это слой файлов, памяти, инструментов, политик доступа и eval-контуров, который позволяет агентам не просто отвечать в чате, а выполнять длинные рабочие задачи в командах и продуктах.

На этой неделе сразу несколько новостей сложились в одну картину. OpenAI показала, как Codex расползается по внутренним отделам, LucidLink выпустила MCP-сервер с общим файловым слоем для агентов, Google добавила Computer Use в Gemini 3.5 Flash, а Meta описала Autodata - агентный цикл для создания и оценки данных. Это уже не история про "умный чат". Это история про рабочую инфраструктуру.

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

Что изменилось

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

Поэтому важен не отдельный релиз Codex, MCP или Gemini. Важна связка. Если агент пишет код, готовит финансовую модель, собирает исследовательскую справку или прогоняет тесты, ему нужен не только LLM, но и среда: где лежат данные, кто может их менять, что считается успешным завершением и как потом проверить результат.

Сигнал Инфраструктурный слой Почему это важно
OpenAI Codex Рабочий слой для задач Codex выходит за пределы разработки и используется отделами с разными процессами.
LucidLink MCP Общий слой файлов и состояния Агенты получают место, где можно читать, писать и передавать состояние между сессиями.
Gemini 3.5 Flash Computer Use Действия в интерфейсах Модель работает не только с текстом, но и с браузером, мобильной и настольной средой.
Meta Autodata Данные и eval-контуры Агент создаёт, анализирует и улучшает данные для обучения и оценки.
Ornith-1.0 Агентные coding benchmarks Разработчики моделей уже оптимизируют не только ответы, но и каркас вокруг решения.

Codex становится рабочим слоем, а не просто помощником для кода

OpenAI 26 июня опубликовала исследовательский материал о том, как агенты меняют работу. Самые заметные числа там про внутренний Codex: к июню 2026 года медианное использование Codex среди активных внутренних пользователей выросло с ноября 2025 года в 56 раз в Research, в 32 раза в Customer Support, в 27 раз в Engineering и в 13 раз в Legal.

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

Для читателя Toolarium здесь важна не сама цифра, а смена роли. Если юрист, рекрутер или сотрудник поддержки генерирует большую часть output tokens через Codex, значит агентная среда становится местом, где выполняется рабочий процесс. Не окно "спросить модель", а слой, куда уходят задачи.

Мы уже разбирали, как OpenAI Codex становится рабочей средой для агентного программирования. Новый сигнал шире: тот же принцип уходит в knowledge work. Отсюда и требование к инфраструктуре. Агенту нужен доступ к данным, задачам, документам, результатам и правам.

MCP даёт протокол, но агенту нужно ещё и состояние

MCP часто описывают как способ подключить модель к инструментам. В базовом смысле так и есть: подробнее об этом у нас есть отдельный материал про стандарт MCP и интеграцию ИИ с инструментами. Но новая волна вокруг LucidLink показывает другой слой проблемы.

На официальной странице LucidLink MCP Server компания формулирует тезис прямо: агентам и командам нужен общий постоянный слой данных, где можно читать, писать и работать с корпоративными файлами без предварительного перемещения данных. В своём объяснении LucidLink отдельно подчёркивает: MCP - это уровень протокола, но не слой хранения состояния. Протокол помогает агенту добраться до ресурса; он сам по себе не гарантирует долговечное и согласованное состояние между сессиями.

Это звучит приземлённо, но именно здесь начинается настоящая агентная инфраструктура. Агент может сгенерировать план, но где он его оставит? Может обработать документы, но как другой агент или человек увидит результат? Может начать задачу утром, но что будет с состоянием вечером, после перезапуска, передачи другому исполнителю или параллельного запуска второго агента?

Для enterprise-сценариев ответ "в чате" слабый. Нужны файлы, версии, права, аудит, совместная запись и понятный контекст. LucidLink продаёт именно эту часть истории: не "ещё один агент", а место, где агентам есть с чем работать.

Computer Use переносит агента в интерфейсы

Второй кусок инфраструктуры - действие в интерфейсе. Google 24 июня 2026 года добавила публичный preview инструмента Computer Use в Gemini 3.5 Flash. В release notes указаны упрощённые действия с намерениями, поддержка браузерной, мобильной и настольной среды, настраиваемые политики безопасности и продвинутое обнаружение prompt injection.

Это важнее, чем кажется. Когда агент работает только через API, его среда относительно чистая. Когда он видит страницу, форму, таблицу, CRM или админку, появляется другой класс рисков: ложные инструкции на экране, скрытые подсказки, пользовательские права, необратимые действия. Поэтому Computer Use без политики безопасности - плохая идея.

В статье про ИИ-агентов в браузере, Computer Use и Operator мы уже разбирали, почему browser-agent не равен обычному чат-боту. Gemini 3.5 Flash добавляет к этой линии важный штрих: computer use становится не отдельной витринной демонстрацией, а инструментом внутри модели и платформы.

Autodata показывает, зачем агентам собственные eval-контуры

Третий слой - данные и оценка. Meta Research / RAM описывает Autodata как фреймворк, где автономный агент играет роль специалиста по данным: создаёт синтетические данные, проводит качественную инспекцию, считает метрики, формулирует выводы и обновляет рецепт генерации. Сам агент при этом может улучшаться по тем же критериям, которые используются внутри цикла.

Схема Meta Autodata: LLM-агент создаёт синтетические данные, анализирует результат и повторяет цикл
Autodata показывает агентный цикл создания, анализа и улучшения данных. Источник: Meta Research / RAM.

Это не означает, что дата-сайентисты завтра исчезнут. Корректнее сказать иначе: агентная система начинает захватывать часть работы вокруг данных и оценки. Она не просто отвечает на запрос. Она строит контур: создать данные, проверить, понять, почему результат плохой, поменять рецепт и повторить.

Здесь же появляется связка с бенчмарками. DeepReinforce представила Ornith-1.0 как семейство моделей для агентного программирования, где модель учится генерировать не только варианты решения, но и каркасы под конкретную задачу. Для Ornith-1.0-397B разработчики заявляют 77.5 на Terminal-Bench 2.1 и 82.4 на SWE-Bench Verified. Это числа от вендора, а не независимое доказательство превосходства. Но направление важно: оптимизируется уже не только ответ модели, а обвязка, которая помогает ей решать задачу.

Схема Ornith-1.0: каркас задачи, несколько вариантов решения, награда и RL-обновление
Ornith-1.0 иллюстрирует подход с самогенерируемым каркасом: модель улучшает и решение, и обвязку вокруг него. Источник: DeepReinforce.

Где границы этого сдвига

Главная ошибка - объявить, что "агенты уже заменяют рабочие процессы". Нет. Пока мы видим ранний слой инфраструктуры: продукты, протоколы, демонстрации, заявленные вендорами бенчмарки и внутренние данные компаний. Между этим и надёжной автономной работой в критичных процессах лежит много скучной инженерии.

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

Поэтому инфраструктура AI-агентов - это не модное название для набора API. Это практический вопрос: кто хранит состояние, кто отвечает за доступ, кто проверяет результат, кто видит след действий и кто откатывает ошибку.

Коротко: что такое инфраструктура AI-агентов?

Инфраструктура AI-агентов - это рабочая среда вокруг модели: файлы, память, инструменты, доступы, интерфейсы, политики безопасности, логи, оценки и циклы работы с данными. Без неё агент остаётся умным ответчиком. С ней он может выполнять длинную задачу, передавать результат человеку или другому агенту и оставлять след, который можно проверить.

Почему MCP важен для AI-агентов?

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

Чем рабочий агент отличается от чат-бота?

Чат-бот в основном отвечает. Рабочий агент выполняет: читает документы, запускает инструменты, меняет файлы, действует в интерфейсе, ждёт результата, продолжает задачу после паузы и оставляет проверяемый output. Именно этот переход и делает инфраструктуру центральной темой.

Что смотреть дальше

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

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

Источники и дата проверки

Факты проверены 26 июня 2026 года. Данные о моделях, бенчмарках и возможностях продуктов быстро меняются; точные характеристики и сравнения нельзя переносить в таблицы без повторной проверки первоисточников.

Читайте также

Telegram-канал @toolarium