Почему кодовый агент на ноутбуке не масштабируется и что нужно для облака: состояние, песочница, доступы, лимиты. Разбор для руководителя ИТ.
Latent Space разобрал, почему кодовые агенты так трудно вынести с ноутбука разработчика в облако (первоисточник). Главная мысль: пока обвязка агента живёт на одной машине, компания владеет личным инструментом сотрудника. Сервисом она начинает владеть, когда harness работает в облаке, а доступами, логами и бюджетом управляет команда эксплуатации.
У кодового агента простая архитектура: языковая модель в цикле вызывает инструменты и тащит за собой нужный контекст. Весь цикл вместе с инструментами, правами и памятью называется harness, то есть обвязка вокруг модели. Её проще всего написать локально, поэтому большинство агентов начиналось с терминала и потом переехало в десктопные приложения. Claude Code, по словам авторов разбора, тоже начинался как CLI-утилита.
У локального запуска есть понятный предел.
Агент работает над задачей час или два, разработчик закрывает крышку ноутбука, и работа останавливается.
Чтобы довести её до конца, разработчик возит ноутбук открытым, а сессию нельзя передать коллеге. С 2025 года OpenAI и Anthropic переносят свои harness в облако, и, по оценке авторов, результаты у них разные.
Среди трудностей, которые авторы перечисляют, есть сохранение состояния агента между сессиями.
- Состояние. Контекст, накопленный за часы работы, должен пережить перезапуск контейнера и сетевой сбой. - Изоляция. Агент исполняет код и команды. В облаке для этого нужна песочница, иначе один неудачный вызов заденет общую инфраструктуру. - Доступы. На ноутбуке агент пользуется ключами разработчика. В облаке ему нужна собственная идентичность с минимальными правами и срок жизни у каждого секрета. - Наблюдаемость.
Чтобы разобрать, почему агент удалил файл или потратил в десять раз больше токенов, нужен журнал каждого шага. - Стоимость. Цикл «модель, инструмент, модель»
расходует токены, пока кто-то не поставит лимит.
Без лимита счёт растёт до первого неприятного сюрприза в конце месяца.
За этим набором стоит тема, которую рынок называет безопасным доступом агентов к инструментам.
Здесь важен протокол MCP (Model Context Protocol), стандартный способ подключить к агенту внешние системы.
Протокол описывает формат вызова. Права, аудит и изоляцию серверов MCP должна обеспечить компания.
Если ваши разработчики уже работают с агентами, у вас скорее всего есть теневая инфраструктура.
Агенты запускаются на личных машинах, ходят в репозитории личными токенами, а расходы на модели проходят по корпоративным картам и не собираются в один бюджет.
Для директора по ИТ это три риска: утечка кода, невоспроизводимые результаты и неуправляемый бюджет. У той же ситуации есть выгодная сторона.
Облачный агент можно запустить по расписанию, по событию в трекере или по падению сборки.
Тогда он разбирает очередь задач ночью, пока команда спит.
Здесь измеряется TTU, время до результата: выигрывает тот, кто довёл агента до расписания и метрики. Тот, кто оставил демо на ноутбуке, получил презентацию.
Метрики для пилота давно известны: доля задач, которые агент довёл до слияния без правок человека, и время от постановки задачи до merge.
Цифр по облачным harness в источнике нет, и приводить чужие было бы выдумкой.
Эти две метрики стоит снять у себя на пилоте, прежде чем масштабировать.
1. Шлюз перед моделью. LLM & Security Gateway стоит между агентами и провайдерами: Anthropic Claude, OpenAI, а для закрытых контуров GigaChat, YandexGPT и локальные Qwen и Llama.
Шлюз ведёт лимиты токенов, маскирует персональные данные и коммерческую тайну, пишет аудит.
Смена провайдера не затрагивает агентов. 2. Инструменты через MCP.
Доступ к 1С, Битрикс, Pimcore или Odoo агент получает через отдельные MCP-серверы с узкими правами. Агенту, который готовит карточки товаров, доступ к бухгалтерии не нужен. 3. Оркестрация.
Запуски по событиям, повторы при сбоях и человеческое подтверждение на опасных шагах собираются в n8n или на Kafka, если нагрузка и надёжность требуют очереди. 4. Процесс разработки. В AI-native development агент встроен в цикл между «написал код» и «работает в проде»: тесты и проверки безопасности остаются обязательными, ревью делает человек.
В каждом пункте простой результат, то есть «агент сам закрыл задачу»
, оплачен сложной инженерной работой, которой не видно снаружи.
Авторы разбора сами отмечают, что у крупных вендоров облачные harness работают неровно. Гипотеза, которую стоит проверять: универсальной облачной платформы агентов не появится, и компании будут собирать контур из слоёв, где модель, песочницу и слой доступа можно заменять по отдельности. Для заказчика это аргумент не привязываться к одному вендору, пока рынок не определился.
Агент на ноутбуке остаётся личным инструментом. В компании он начинает приносить пользу, когда у него есть собственная идентичность, лимит бюджета, журнал действий и расписание. Самый дешёвый первый шаг на этом пути - шлюз с лимитами и аудитом: он закрывает риски утечки и перерасхода раньше, чем вы выберете, чей облачный harness покупать.
