Среда: песочницы, десктопы, репозиторий

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

Свой компьютер каждому агенту

Люк Марсден, CEO HelixML, доклад «Giving Every Agent Its Own Desktop». Тезис в одной фразе: «You wouldn't hire a team of software developers and ask them all to share one computer». Вывод — централизованный пул агентских машин на инфраструктуре компании вместо уникальных и невоспроизводимых конфигураций на ноутбуках.

Аргументы три:

• follow-the-sun — в Токио человек закончил, в Лондоне встал другой и продолжил работу того же агента;
• безопасность — агент не бегает по чьей-то персональной машине с личными учётными данными;
• воспроизводимость — среда одинаковая, и её чинят один раз для всех.

Возражение «централизация отдаёт данные вендору» он снимает сразу: пул можно поднять на собственной инфраструктуре компании, свой Kubernetes здесь работает.

СО СЦЕНЫ: Пять агентов в одной папке

• Кто и где: Люк Марсден, CEO, HelixML — «Giving Every Agent Its Own Desktop», AI Native DevCon 2026.
• Что показали: собственный инцидент автора при подготовке к встрече с клиентом. Пять параллельных агентов запущены в одном рабочем каталоге.
• Цифры: 5 агентов, 2 инцидента за 2 дня. В первый день один агент сделал git stash работы всех остальных. На следующий день другой сделал rm -rf в git-checkout.
• Что это меняет: это стартовая точка, с которой начинается вся тема изоляции. Параллелизм без изоляции превращается в способ терять работу.

Что оказалось нужно кроме изоляции

Марсден описывает путь собственной эксплуатации честно, включая то, что чуть его не остановило.

Нормальный десктоп. Чтобы фоновый агент ощущался фоновым, ему нужно больше, чем голая консоль: GPU-ускоренные десктопы (mutter в контейнере, технологии из облачного гейминга, аппаратное кодирование видео). Внутри — форкнутый Zed: быстрый, с малым memory footprint, поддерживает ACP, а значит работает и с Codex, и с Claude Code. Каждый агент поднимает свой Chrome через Chrome MCP и не мешает соседям. Его формулировка: «You need an IDE on the inside, but you also need the meta IDE — the control plane for all the agents».

Скорость старта. Точка боли, которая остановила внутреннее использование: стек собирался в Docker с нуля 40 минут. Решение — ZFS-клоны Docker-окружений, прогретые последним main-коммитом, чтобы каждый агент стартовал с полностью закэшированной среды. Docker-in-Docker технически выдерживает до 16 уровней, у них около трёх. Десктопы гасятся после часа простоя. Вывод дословно: нет смысла быстро поднимать песочницы, если агент 40 минут не может ничего сделать.

Интерфейс под реальный режим работы. Разработчик взаимодействует с агентом по несколько минут в час — значит, управление должно работать с телефона. Пригодятся и Figma-подобные множественные курсоры: несколько человек могут парно работать на десктопе одного агента.

Спецификация как обязательная фаза. У Марсдена один и тот же агент имеет явную фазу планирования и фазу реализации. Спецификация — это короткий человеческий промпт и то, что планировщик вычитал из кода. Спецификации на 3–4 задачи генерируются за 30–60 секунд. Ревью идёт в Google-Docs-подобном UI, потому что терминал — плохое место для комментирования документов. Сами спецификации лежат markdown-файлами в git на отдельной ветке, чтобы все агенты видели спецификации друг друга. Описание его рабочего дня: «Most of my day now… I find the two lines in the spec where the agent got it wrong».

Аргумент про железо. Отдельный совет Марсдена: взять трёхмесячный бюджет на токены и вместо него купить железо (условные восемь карт RTX 6000 Pro), гонять рутину на открытых весах и выходить в топовую модель только на трудные задачи. По его оценке, открытые модели уровня GLM 5.1 покрывают около 80% нужной работы. Заодно это защита от привязки к одному вендору — при условии, что у вас есть слой переключения агентов и моделей.

Песочница как полный стек

Роб Уиллоуби (Tessl, «Inside the Dark Factory») описывает требование к песочнице иначе, чем «изолируй, чтобы не сломал». У них агенты крутятся в Daytona-песочницах на намеренно «жирной» машине — чтобы поднять весь монорепозиторный тестовый стек: интеграционные тесты, поднятый репозиторий, клики по UI.

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

Патрик Дебуа и Марсден отмечают ту же тенденцию с другой стороны: IDE возвращается, но уже как поверхность верификации — скриншоты, записи кликов агента, «follow»-режим, где ты пассивно впитываешь знание о кодовой базе. Формулировка Дебуа: «It's the job of the agent to convince you that it did the right thing».

Безопасность автоматизации

Дон Сайм, GitHub Next (создатель F#), доклад «The Agentic Repository Automation Revolution», говорит прямо: «Do not run coding agents directly in GitHub Actions… without a security architecture of some kind».

Его архитектура для агентного шага:

• работает read-only;
• без прямого доступа к секретам;
• в контейнере;
• с очень узким выходным каналом — например, «разрешено создать один issue»;
• выход обрабатывается вторым, не-агентным этапом по схеме plan и apply;
• между этапами стоит threat detection;
• shared package caches выключены, исходящая сеть за фаерволом.

И его же наблюдение, которое переворачивает привычную логику: в индивидуальной продуктивности безопасность конфликтует со скоростью, и разработчик просто отключает подтверждения. В автоматизации связь обратная: чем лучше рельсы, тем быстрее может ехать поезд, тем больше вы готовы автоматизировать. «It's like a rail track. The better the quality of the rails, the faster your train can go». Отсюда его тест на докладчика: если кто-то рассказывает про автоматизацию и не говорит про безопасность — задавайте вопросы.

Отдельный сюжет — что делать, когда данные агенту показывать можно, а людям нельзя. Ори Шошан (Cyera) описывает схему «Малдер и Скалли»: агент внутри контролируемого периметра видит всё, но наружу выдаёт только structured validated output из фиксированного словаря, про который доказуемо, что он не течёт. Второй агент снаружи собирает из этого объяснение для людей. Реализовано за 2 дня. Escape hatch остаётся — свободный текст, но только узкой approved-группе, после чего словарь расширяют.

Джеймс Уикетт (Dryrun Security) и Адам Дайч (Commerce) в докладе «Securing AI-native Commerce Without Breaking the Cart» добавляют третий класс риска — периметр агента, который ходит наружу. Prompt injection в agentic-коммерции приходит через метаданные каталога: описания товаров, отзывы, заметки мерчанта. Источник такого риска — третьи стороны. Ваш код здесь ни при чём. Второй риск — excessive agency: слишком широкие права на внешние ресурсы. Их наблюдение: классические уязвимости (XSS, SQLi) падают, контекстные (авторизация, бизнес-логика) растут, при том что объём написанного кода за 2,5 года примерно удвоился. Рантайм-контроль сводится к scopes, MFA, human-in-the-middle на любое чувствительное действие и rate limiting.

Репозиторий как объект автоматизации

Дон Сайм предлагает добавить к CI и CD третью букву — CAI, continuous AI. Его диагноз: индустрия перекосилась в сторону индивидуальной продуктивности в духе copilot и недоинвестировала в автоматизацию и непрерывность. Признаки continuous AI: автоматизированность, повторяемость, коллаборативность, интегрированность, auditable. Его личное описание эффекта: «I wake up to code improvements, start my day with code that's better».

Единица автоматизации — agentic workflow: один файл (front matter и markdown), который «затвердевает» (hardening) в GitHub Action. В файле лежат триггеры, safe output specification, набор tools и намеренно неоднозначный текстовый промпт. Всё коммитится в репозиторий.

Отсюда его главный образ: репозиторий превращается в фабрику. CI и CD автоматизировали сборку и деплой, теперь на конвейер issues и pull requests ставятся «станки». Можно делать sub-factories — вырезать часть работы по меткам или заголовкам issue. «The repository is a site where humans and agents come together to work collaboratively to get forward velocity». Почему это распространится: приняв GitHub Actions, компания уже дала каждому разработчику право самостоятельно забирать compute, сеть и хранилище без похода к «облачным людям». Теперь к этому добавляются агенты.

Практический пример — его собственный. Workflow repo assist раз в сутки читает свою память и выбирает несколько задач из настраиваемого набора: триаж, предложения улучшений, обновления, метки. Сайм включил его на dormant-репозитории FSharp.Data с большим забытым бэклогом: 3 мажорных релиза, пройден весь бэклог issue — некоторые задачи лежали аж с 2018 года.

Внутри GitHub Next есть спор о форме. Коллега Сайма Pelli завёл сотни отдельных agentic workflows на любой случай — «agent factory». Сам Сайм предпочитает один workflow, делающий много вещей. Оба подхода задокументированы в серии «Meet the Workflow». Из цифр по конкретному workflow семантического рефакторинга функций: 112 смёрдженных PR из 142.

Что ещё относится к репозиторию как к среде:

• Никаких локальных конфигов. Дру Нокс: в Tessl объявили вне закона локальную конфигурацию агентов — всё коммитится, чтобы улучшение одного становилось улучшением для всех. Ограничение: часть остаётся специфичной для репозитория, а style guide, дизайн-система и политики безопасности общие.
• Control plane: тикет, за ним агент, за ним PR и комментарии. Нокс называет это первым и самым дешёвым шагом: все точки взаимодействия человека с агентом становятся legible, и по ним можно натравить другого агента. Цифра, на которую он ссылается: OpenAI в white paper — пятикратный рост производительности за 2–3 месяца при переходе от интерактивных сессий к тикетам и PR.
• «Agent it». Самый нудный слой: найти все места, где нужен человек, залогиненный куда-то руками — база, логи, фиче-флаги, административная панель. Каждое такое место — целый класс задач, недоступный агенту. Сюда же доступ к собственному продукту через CLI и API. Предупреждение Нокса: «I promise, it's worse than you think».

Данные: почему нужен data harness

Уилл Мартин, data & AI evangelist в Dremio, доклад «Why AI Agents Need a Data Harness, Not Just a Lakehouse». Тезис: хранилище само по себе ещё не оснастка. Агенту нужны три свойства данных.

• Accessible — весь массив данных через федерацию, без физического переезда данных.
• Understandable — semantic layer с определениями метрик и колонок. Без него модель «угадает с уверенностью»: определения Q2, revenue и customer различаются даже внутри одной компании.
• Performant — субсекундный ответ.

Последнее выглядит придиркой, но ломается первым. Аналитика «на скорости email» — когда отчёт готовится к утру — на агентах не работает: пайплайны отваливаются по таймауту, а агент в это время жжёт токены. Цифра по их кэшу C3 (данные рядом с compute): снижение стоимости до 90% у части клиентов.

Смежный сюжет — «мозг компании». Нокс (ответ на вопрос из зала) даёт свой рейтинг источников: транскрипты встреч (Granola) дают лучшую отдачу на вложенное, Slack тоже неплох, доки в Notion полезны, но быстро устаревают. И приём: в тикете точечно указывают источник — «возьми этот транскрипт и сделай по нему», — вместо того чтобы вываливать его целиком. Ограничение он признаёт открытым: решения проблемы устаревшей информации нет, и с агентами она станет хуже.

Ори Шошан добавляет граф знаний и инструмент «найди связанное»: по строке лога поднять PR, который внёс исключение, сами логи и оценку влияния. Агенты хорошо исследуют, но не всегда исследуют всё нужное — они зависят от того, попадётся ли им подсказка. Построение графа оказалось разовой дорогой операцией, зато эксплуатация дешёвая — именно из-за структурности. Его формула: «I try to set up my development environment so that the compiler yells at me when I do something wrong. I do that for my friend the bot too».

Что воспроизводимо малой командой, а что требует платформы

Элемент среды	Малой командой	Требует платформы
Изоляция каждого агента (отдельный воркспейс или контейнер)	да, это первый шаг	—
Переход на цепочку «тикет, агент, PR»	да, дешевле всего остального	—
Локальные конфиги вне закона, всё в репозиторий	да	—
Agentic workflow одним файлом в репозитории	да, если вы на GitHub Actions	—
repo assist-подобный ночной workflow	да	—
Полный тестовый стек в песочнице (интеграционные тесты, UI-клики)	частично, зависит от монорепы	скорее да
GPU-десктопы, ZFS-клоны прогретых окружений	нет	да
Своё железо под открытые модели	нет	да
Threat detection между этапами, фаервол на исходящую сеть	частично	да
Semantic layer и федерация данных	нет	да
Agent observability по всей организации, MCP gateway, identity	нет	да

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

Коротко

• Параллельные агенты в одной папке ломают работу друг друга: 5 агентов, 2 инцидента за 2 дня — git stash чужой работы и rm -rf в checkout (Марсден, HelixML). Изоляция при этом бесполезна без скорости старта: 40-минутная сборка обесценивает быстрые песочницы.
• Песочница должна поднимать полный тестовый стек: тогда агент прикладывает к PR видео и скриншоты, и проверка идёт глазами (Уиллоуби, Tessl).
• В автоматизации безопасность и скорость связаны прямо: чем лучше рельсы, тем быстрее поезд (Сайм, GitHub Next). Read-only, без секретов, узкий safe output, второй не-агентный этап.
• Репозиторий — единица автоматизации: agentic workflow одним файлом, sub-factories по меткам, ночной repo assist (3 мажорных релиза на dormant-репозитории FSharp.Data).
• Данным нужна своя оснастка: федерация, semantic layer против «уверенной догадки» и субсекундная скорость — иначе агент жжёт токены в таймаутах (Мартин, Dremio).