01Почему модель сама по себе не является продуктом
Большинство провалов агентных систем связано не с «слабым интеллектом», а с отсутствием исполнительного контура. Модель теряет контекст после перезапуска, не видит полную историю файловых правок, путает свой diff с генерацией build-скрипта и часто не знает, можно ли выполнять рискованную команду. Для задач разработки добавляется физическая среда: Xcode, Safari, Homebrew, сертификаты, SSH-ключи, симуляторы, браузерные профили и долгие процессы, которые не живут внутри чата.
Практический pain делится на три группы. Контроль инструментов определяет, какие shell-команды, сетевые запросы, файловые правки и approvals допустимы. Контроль состояния хранит transcript, checkpoints, diff, terminal output и решения, принятые по ходу работы. Контроль исполнения даёт агенту стабильный host, где тесты, кэши и GUI ведут себя одинаково от запуска к запуску.
02Матрица выбора: чат, скрипт или agent harness
| Тип работы | Обычная модель | Скрипт | Agent harness |
|---|---|---|---|
| Разовое объяснение | Подходит лучше всего | Избыточен | Обычно не нужен |
| Массовая миграция | Нет устойчивого состояния | Хорош при жёстких правилах | Сильнее при исключениях |
| Ремонт репозитория с тестами | Недостаточно проверки | Ломается на новом сбое | Планирует, правит, запускает, восстанавливается |
| Release или QA workflow | Нет durable host | Полезен для узкого шага | Лучший выбор для evidence loop |
03Шесть слоёв практического harness
Первый слой — рамка задачи: цель, область репозитория, ожидаемый артефакт, критерии готовности и правила остановки. Второй — посредник инструментов: поиск, shell, редактор файлов, web, браузер, package manager и cloud API проходят через явные разрешения. Третий — память и журналирование: prompt, diff, логи, переменные среды, вывод терминала и причины решений доступны после resume.
Четвёртый слой — изоляция. Каждая задача получает branch, workspace, sandbox или отдельный remote Mac, который можно удалить без риска для пользовательских изменений. Пятый — верификация: тесты, линтеры, скриншоты, benchmark, `git diff` и командный вывод становятся обязательным доказательством. Шестой — handoff: итоговый отчёт показывает изменённые файлы, команды, остаточные риски и места, где нужен человеческий judgement.
04Runbook из семи шагов для реальной работы
- Зафиксируйте границы. Укажите репозиторий, ветку, владельца, допустимые инструменты, запреты и формат финального результата.
- Поднимите стабильный host. Для Xcode, Safari, WebGPU-проверок, Homebrew и Apple Silicon parity используйте выделенный Mac mini M4.
- Загрузите контекст дозированно. Читайте нужные файлы, последние diff, тестовые команды и runbook деплоя, а не весь проект подряд.
- Ограничьте риск. Требуйте approval для destructive-команд, доступа к секретам, публикации, billing-изменений и production deploy.
- Фиксируйте каждую правку. Diff, terminal output и stderr должны быть доступны ревьюеру без пересказа модели.
- Запускайте циклы проверки. Тесты, formatters, браузерные smoke checks и сборки возвращают сигнал в следующий шаг агента.
- Восстанавливайтесь без драмы. Используйте checkpoints, изолированные worktree и возможность бросить плохой прогон без очистки всего окружения.
05Цитируемые пороги перед масштабированием агентов
Перед тем как отдавать агентам больше задач, задайте измеримые пороги. Поиск и чтение файлов должны укладываться примерно в 200 мс на частых операциях, иначе модель начинает строить догадки. Журналы команд стоит хранить минимум один цикл ревью. Pull request не должен уходить без чистого diff и хотя бы одной успешной проверки. Для Mac-нагрузок 16 ГБ хватает одиночному maintenance-агенту, а 24 ГБ разумнее для браузера, Xcode, симуляторов и параллельных тестов. Диск 1-2 ТБ нужен, если harness хранит кэши, артефакты, screenshots и несколько репозиториев.
Remote Mac упрощает и техническую, и организационную часть. Инженер подключается по SSH для скриптов, по VNC для GUI-проверок, через браузер для скриншотов, а агент работает на том же bare-metal host. На neokvm один Mac mini M4 может держать репозиторий, package cache, simulator state и audit trail. Поэтому harness не пересобирает мир на каждом шаге и быстрее показывает реальную ценность.
Отдельно стоит считать лимиты безопасности. Harness должен разделять роли наблюдателя, редактора и оператора релиза; иначе модель получает слишком широкий blast radius. Практичная схема выглядит так: чтение репозитория разрешено по умолчанию, запись идёт через diff, shell-команды с удалением требуют подтверждения, секреты не выводятся в transcript, а доступ к Apple Developer, App Store Connect или production API включается только на короткое окно. Для команд с несколькими агентами полезно держать один базовый образ Mac, но разные рабочие каталоги, ключи и порты. Тогда сбой одного runner не портит соседний прогон, а аудит показывает, кто именно изменил файл, запустил сборку и подготовил релизный артефакт.
Дайте агенту стабильный Mac mini M4 workspace
Арендуйте выделенный neokvm Mac для coding agents, браузерных проверок, Xcode-задач и долгих verification loops. Начните с одного узла, измерьте пользу harness и масштабируйте парк по факту.