Главный тезис прост: модель не «работает» сама по себе. Работает связка из модели, контекста, инструментов, политики доступа, тестов и наблюдаемости. Если убрать harness, остаётся чат. Если собрать его правильно, агент может править код, запускать сборку, читать ошибки, повторять итерацию, готовить pull request и оставлять воспроизводимый след для человека.
Почему одного LLM недостаточно
- Контекст не равен состоянию. Модель видит фрагменты задачи, но harness хранит текущую ветку Git, открытые файлы, результаты тестов, терминальные процессы и ограничения доступа.
- Ответ не равен артефакту. Пользователю нужен не красивый план, а изменённый файл, зелёный тест, собранный пакет, миграция или понятный diff.
- Автономность без контроля опасна. Shell, сеть, секреты и браузер требуют разрешений, журналов и точек остановки; иначе агент быстро превращается в непрозрачный скрипт.
Матрица: чат-бот, workflow и полноценный harness
| Критерий | Обычный чат | Agent harness |
|---|---|---|
| Файлы | Советы и сниппеты | Чтение, патчи, проверка diff |
| Команды | Просит пользователя запустить | Shell с политиками и логом |
| Ошибки | Объяснение по тексту | Итерация: тест → stdout → исправление |
| Память задачи | Только окно диалога | Файлы, Git, артефакты, todo, терминалы |
| Безопасность | Не формализована | Разрешения, sandbox, аудит, остановка |
Анатомия рабочего harness
Практический harness состоит из семи слоёв. Orchestrator разбивает цель на шаги и решает, когда спрашивать человека. Tool gateway выдаёт функции чтения файлов, патчей, shell, браузера и API. State store связывает текущий план с Git-статусом, логами и артефактами. Policy layer ограничивает разрушительные команды, сетевой доступ и секреты. Executor запускает команды на машине, где реально есть Xcode, Docker, браузер или эмулятор. Verifier требует тесты, линтеры, скриншоты или контрольные запросы. Audit log объясняет, что было сделано и почему это можно принять.
Именно executor часто недооценивают. Для задач с iOS, WebKit, браузерной автоматизацией, локальными LLM, CI-артефактами и долгими shell-процессами агенту нужна не абстрактная «облако-среда», а предсказуемый компьютер. Выделенный Mac mini M4 удобен тем, что даёт Apple Silicon, macOS, SSH/VNC, стабильный диск и возможность держать несколько агентных прогонов без шума соседних VM.
Типовой сбой возникает не в reasoning, а в интерфейсе между reasoning и машиной. Агент может правильно вывести причину ошибки, но потерять рабочую директорию, перезаписать файл без просмотра diff, запустить тест не в том окружении или скрыть stderr в слишком коротком summary. Поэтому зрелый harness фиксирует каждое действие как инженерное событие: входные файлы, команду, разрешение, длительность, код возврата, артефакт и следующий шаг. Такая дисциплина особенно важна для долгих задач, где один прогон длится десятки минут и затрагивает несколько подсистем.
Как внедрять: семь шагов
- 1. Опишите границы. Разрешённые каталоги, ветки, команды, сеть, секреты и критерии остановки должны быть явными до первого запуска.
- 2. Подключите файловый слой. Агент должен читать точные файлы, применять минимальные патчи и видеть полный diff перед финальным отчётом.
- 3. Дайте shell, но с предохранителями. Запретите разрушительные команды без подтверждения; логируйте cwd, exit code, stdout и stderr.
- 4. Сделайте тесты обязательными. Unit, lint, build, smoke или браузерный сценарий должны быть частью цикла, а не факультативным финалом.
- 5. Храните артефакты. Скриншоты, пакеты, coverage, логи CI и JSON-отчёты нужны для review и повторения.
- 6. Запускайте на подходящем железе. Для macOS, Xcode, WebKit и локального вывода выбирайте удалённый Mac, а не generic Linux runner.
- 7. Завершайте через человека. Harness должен подводить агент к review: что изменено, какие проверки прошли, где риск.
Цитируемые ориентиры для архитектуры
Для пилота достаточно одного репозитория, одной машины и одного жёсткого правила: агент не завершает задачу без проверки. Через неделю такой режим уже показывает, где нужна автоматизация, а где требуется ручной review.
Вывод: покупайте не «доступ к модели», а рабочую систему
Реальная ценность agent harness появляется там, где модель может безопасно трогать код, запускать команды, видеть результат и доводить итерацию до проверки. Если ваша команда строит таких агентов для iOS, Web, CI, браузерных smoke-тестов или локального AI, выделенный Mac mini M4 на vpshalo даёт понятную базу: SSH для автоматизации, VNC для GUI, стабильное железо и регионы рядом с командой.
Нужна среда, где агент действительно выполняет работу?
Выберите Mac mini M4 на vpshalo, подключите SSH/VNC и разместите harness рядом с репозиторием, тестами, браузером и артефактами сборки.