Вопросы на собеседовании harness engineering: 22 вопроса с ответами для AI-инженера

Как готовиться

Вопросы на собеседовании harness engineering обычно идут от общего к частному: что такое харнес, из чего он состоит, как вы диагностируете проблему, как измеряете эффект. Интервьюер ищет инженерное мышление: умение отличить проблему модели от проблемы окружения и предложить проверяемое решение. Ниже — 22 вопроса с ответами, сгруппированные по темам.

Основы

1. Что такое харнес агента?

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

2. Чем харнес-инжиниринг отличается от промпт- и контекст-инжиниринга?

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

3. Назовите пять подсистем харнеса.

Инструкции (AGENTS.md, CLAUDE.md, skills, доки), инструменты (shell, тесты, линтер, браузер, MCP), среда (зависимости, рантайм, Docker, worktree), состояние (PROGRESS.md, список фич, решения) и обратная связь (make check, E2E, хуки, оценщик). Пропуск любой подсистемы даёт не «чуть хуже», а систематический класс провалов.

4. Почему замена модели на более сильную часто не помогает?

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

Диагностика

5. Агент нарушает правило, записанное в CLAUDE.md. Ваши действия?

Сначала проверить, найдёт ли агент это правило: длинный файл с десятками пунктов размывает важное. Сократить входной файл до оглавления, вынести детали в доки по условию. Если правило критичное, превратить его в исполняемую проверку — линтер, тест, grep-гвард или хук, — тогда нарушение будет видно машинно, а не зависеть от внимания модели.

6. Как по симптому понять, какая подсистема сломана?

Нарушаются известные конвенции — инструкции. Агент «хочет, но не может» — инструменты. Каждая сессия начинается с починки окружения — среда. Новая сессия не знает, где остановились, — состояние. «Готово» не совпадает с реальностью — обратная связь.

7. С какой подсистемы начать строить харнес и почему?

С обратной связи. Пока нет команды, которая машинно отвечает «работает или нет», невозможно измерить эффект любых других изменений. Дальше обычно идут инструкции, состояние, среда и инструменты, но порядок эмпирический и зависит от того, что сломано сильнее.

8. Как измерить вклад отдельного компонента харнеса?

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

Инструкции и контекст

9. Как устроить хороший AGENTS.md?

Как роутер, а не учебник: что за проект, как запустить, как проверить, Definition of Done и короткий список обязательных ограничений. Подробности — в отдельных документах со ссылками вида «читать, когда задача касается оплаты». Файл задаёт инварианты («данные валидируются на границе»), а не диктует реализацию и библиотеки построчно.

10. Зачем нужны сабагенты?

Для изоляции контекста. Побочная задача — поиск по кодовой базе, ревью, проверка — выполняется в отдельном контексте и возвращает только вывод. Основной поток не засоряется, а проверяющий сабагент не наследует рассуждения исполнителя, что важно для честной оценки.

11. Что такое харнес-долг?

Накопленное расхождение харнеса с реальностью: устаревшие правила, команды, которые больше не работают, документы о модулях, которых нет. Он ведёт себя как технический долг — копится незаметно и платится сбоями агента. Харнес нужно ревизовать регулярно, а не настроить один раз.

Состояние и сессии

12. Как бороться с амнезией агента между сессиями?

Хранить состояние в репозитории: PROGRESS.md (состояние, сделано, блокеры, следующие шаги), DECISIONS.md (решение, причина, отвергнутые варианты), список фич со статусами, частые коммиты. В инструкциях закрепить порядок старта: прочитать прогресс, запустить скрипт проверки окружения, взять активную фичу.

13. Зачем правило WIP=1?

Когда агент начинает несколько фич одновременно, состояние размазывается: ни одна не доведена, изменения перемешаны, откат затруднён. Одна активная фича даёт понятную точку проверки, чистые коммиты и простое восстановление после сбоя.

14. Что такое тест холодного старта?

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

Верификация

15. Почему зелёные юнит-тесты не доказывают, что фича работает?

Юнит-тест изолирует модуль и мокает зависимости, поэтому не видит стыков: несовпадение интерфейсов, распространение состояния (схема поменялась, кэш старый), утечки ресурсов, проблемы конфигурации и окружения. Дефекты, которые ловят юниты, — подмножество тех, что ловят интеграционные тесты, а те — подмножество ловимых E2E.

16. Что такое verification gap и как его считать?

Доля задач, которые агент объявил готовыми, но независимая проверка не подтвердила. Берут 10 задач подряд и по каждой отмечают оба факта. Метрика даёт базовую линию: после изменений харнеса её пересчитывают на похожем наборе задач.

17. Как записать Definition of Done для агента?

В AGENTS.md, списком проверяемых пунктов: команды проверки завершились с кодом 0, есть E2E на сценарий, миграции применяются, прогресс обновлён. Полезно явно перечислить, что готовностью не считается: «выглядит правильно», «юнит-тесты проходят», «у меня локально работает».

18. Почему агент не должен сам ставить статус «готово»?

Модель склонна завышать оценку собственной работы, а самооценка идёт в том же контексте, где принималось решение. Статус passing должен ставить скрипт верификации по результатам прогонов, фиксируя хеш коммита как доказательство.

19. Как устроить независимого оценщика?

Отдельный агент или сессия, который видит только требование, дифф и результаты прогонов, но не рассуждения исполнителя. Он оценивает по рубрике (корректность, архитектура, тесты, обработка ошибок), и каждая оценка ссылается на файл, строку или лог. Желательно использовать другую модель, чтобы не совпадали слепые пятна.

20. Как сделать архитектурное правило исполняемым?

Три уровня: grep-гвард (быстро, по шаблону), правило линтера с пониманием графа импортов (import-linter, dependency-cruiser) и архитектурный тест в CI. Все встраиваются в make check, падают с ненулевым кодом и печатают WHY и FIX, чтобы агент исправил нарушение сам. Триггер для новой проверки — второй одинаковый комментарий на ревью.

Автономная работа

21. Что нужно, чтобы отпустить агента работать часами?

Однозначная цель, монотонная метрика прогресса (например, число фич в passing), бюджет на фичу по времени и попыткам, автоматический откат при регрессии и список действий, требующих человека: миграции, инфраструктура, деньги. Плюс изоляция: песочница или отдельный git worktree, чтобы ошибка не задела рабочее окружение.

22. Когда одного агентного цикла мало и как устроить граф ролей?

Когда исполнитель начинает сам себя проверять и застревает. Тогда задачу разбивают на роли: реализация, ревью, тесты, мердж. Ревью получает чистый контекст и рубрику, мердж выполняет код при review == pass. При провале ревью фича возвращается на реализацию, а после нескольких неудач перезапускается с чистого контекста — значит, проблема в понимании задачи, а не в коде.

Итог

На вопросы на собеседовании harness engineering сильнее всего отвечает тот, кто говорит о проверяемом: какие файлы, какие команды, какая метрика. Держите в голове пять подсистем, verification gap и правило «готовность ставит скрипт». Все эти темы собираются в единый харнес на сквозном проекте в курсе по харнес-инжинирингу.