Слово «харнес» за этот год попало во все разговоры про ИИ, а обьясняется это примерно так: «ну, это обвязка». Обвязка чего? Какая обвязка? Поделюсь своим мнением по поводу этого термина.
Если вы хоть раз запускали Claude Code, работали с Codex или Cursor, вы уже используюете харнес.
Проше говоря, харнес – это слой настроек, дополнительных файлов, инструментов для модели (LLM) или если хотите в своем роде *архитектурный паттерн в ИИ-агентах. Но в живой речи харнесами называют и программы целиком: «поставил себе харнес», «какой харнес выбрать», логика та же, по которой «мотор» иногда означает всю машину. Если нуэно различать то помогает вопрос «это можно скачать и запустить?»: если да, речь о программе. Дальше «харнес» у меня означает слой
Что такое «обвязка»
Раз слой вокруг модели решает так много, разберёмся, что в нём лежит. Список частей соберём не по вдохновению, а прямо из перечня того, чего модели не хватает в моем понимании.
Часть обвязки | Зачем она нужна |
|---|---|
цикл | Чтобы агент не замолчал после первого ответа, а вызывал LLM до достижения результата |
память | Тут все просто, чтоб в контекст модели попадали все ранее известные вводные: в коде, в проекте – да где угодно |
инструменты | Инструменты чтения, редактирования, поиска и вызов терминала |
инструкции и навыки | Чтобы не объяснять одно и то же в каждом новом разговоре. Вы уже с ними знакомы это skill и файлы типа: CLAUDE.md или AGENT.md |
проверки | Это скрипты, хуки. Короче: некий код, чтобы «готово» означало готово, а не «я перестал работать» |
ограничения | Чтобы агент не крутился всю ночь и не сделал непоправимого |
автоматический запуск | Чтобы работа шла без вас: ночью, по расписанию, по событию. |
работа с сохраненным контекстом | Чтобы агент не поглупел на середине длинной задачи |
изолированная среда и права досутпа | Чтобы агент не дотянулся туда, куда не должен. |
делегирование задач (субагенты) | Чтобы тяжёлая работа не забивала основной контекст |
наблюдаемость (логирование действий) | Чтобы понять, где именно агент свернул не туда |
Это не полный список одиннадцать пунктов я использую сам, какие то пункты могут по-другому называться но суть одна и та же.
Если вам не нужно строить своих харнес-агентов, то хорошая новость в том, что бо́льшую часть этого списка писать не придётся, так как цикл, инструменты, сжатие истории, механика субагентов и логирование действий уже есть в ваших любимых инструментах: Claude Code, Codex, Cursor и так далее. И тут хочу пояснить, что если вы задумали в каком-то из своих проектов, допустим вайбкодите приложение, и хотите в этом проекте настроить харнес, то вам остаётся только добавить правила, навыки, проверки и запреты.
Например: вы завайбкодили приложение и опубликовали его, поймали баг на проде или пользователи начали жаловаться. В таком случае вам придётся искать логи, смотреть, разбираться. Но если вы создадите скиллы, хуки и правила поиска багов, деплоя и фиксов, то в Claude Code будет достаточно просто скинуть жалобу пользователя, и он всё сделает сам. Ниже один из примеров того, какая будет обвязка.
Как создавать такие обвязки? Нужно ли уметь писать код, скрипты?
Если вы неразработчик, то ниже оставлю для вас промпт, в своем проекте где вайкодите, напишите этот промпт.
Собери обвязку для разбора жалоб пользователей. Про проект: стек — [ваш стек], прод — [адрес], сервисы — [список], логи лежат [где и чем смотрятся], деплой — [команда]. Что сделать: 1. CLAUDE.md — правила проекта. Раздел «как ходить на прод»: логи только через scripts/prod-logs.sh, прод-база только на чтение, миграции на проде не запускать никогда. Раздел «что считается сделанным»: прошёл check.sh и записан файл в docs/incidents/. 2. scripts/prod-logs.sh — единственная дверь на прод. Закрытый список сервисов, отдельный read-only ключ, потолок 500 строк, вырезать из вывода номера карт и токены до того, как они попадут в разговор. 3. .claude/skills/triage-bug/SKILL.md — порядок разбора: симптом → сервис, логи, поиск следа по id, сверка с docs/incidents/, гипотеза, показать место в коде. Дважды явно разреши остановиться и спросить меня, если данных не хватило. 4. .claude/agents/log-reader.md — субагент, который читает выгрузку логов у себя и возвращает не больше десяти строк. 5. .claude/hooks/guard-prod.sh — хук перед запуском команд. Блокирует прямой ssh мимо prod-logs.sh, запись в прод-базу, force-push и миграции на проде. 6. .claude/settings.json — три корзины: скрипты чтения в allow, git push и deploy в ask, .env и ключи в deny. Подключи оба хука. 7. scripts/check.sh — типы, линт, тесты. 8. docs/incidents/ — папка с шаблоном записи: симптом, причина, фикс, как воспроизвести. Сначала задай мне вопросы по тому, чего не хватает. Ничего не выдумывай про мой стек и мою инфраструктуру.
Коротко
Возвращаюсь к вопросу из начала. Обвязка чего? Обвязка вокруг вызова модели.
Модель получает текст и возвращает текст. Она не открывает файлы, не ходит в сеть, не запускает тесты. Она пишет в ответе строчку «хочу вызвать такой-то инструмент», и на этом её работа заканчивается. Всё остальное делает обвязка: читает эту строчку, проверяет, можно ли, выполняет своим кодом, кладёт результат обратно в контекст и вызывает модель снова.
Отсюда и одиннадцать частей из таблицы. Каждая закрывает одну конкретную нехватку возможностей LLM модели
И один пункт из таблицы я бы выделил отдельно. Строка «проверки» на мой взгляд важнее Агент работает в цикле, а цикл имеет смысл только тогда, когда между попытками что-то улучшается. Улучшается оно от сигнала «вышло плохо». Если такого сигнала в вашей задаче нет, агент будет выдавать правдоподобные черновики, сколько инструментов к нему ни подключай.
Поэтому обвязку стоит начинать не с подключения интеграций, а с вопроса, как будем проверять результат.
Практика
Разберу одну из обвязок, которыми пользуюсь сам.
Возьмём конкретную задачу и доведём её до рабочего состояния, чтобы стало видно, из каких файлов обвязка физически состоит и за что отвечает каждый.
Задача: разбор интервью и сбор инсайтов
Допустим, вы фаундер, продакт или маркетолог, неважно. У вас накопились расшифровки интервью с пользователями, и каждую надо разобрать по одной схеме: выводы, цитаты, повторяющиеся боли. Отдельное требование: в разборе не должно появиться ничего, чего пользователь на самом деле не говорил.
Погнали, разберем детальный каждый файл
1. Создаем папку, назову я ее «интервью» – тут все предельно просто.
2. Создаем файл CLAUDE.md если ваш основной ИИ-агент Claude Code и AGENT.md если Codex
# Разбор интервью Продукт: сервис подбора подрядчиков для ремонта. Пользователи: частные заказчики 30–50 лет, ремонт раз в пять-семь лет. ## Где что лежит - `raw/` — расшифровки. Только чтение, править нельзя ничего. - `out/` — разборы, по файлу на интервью. Имя файла совпадает с исходником. - `state/` — память между сессиями. Читать перед началом, дописывать в конце. ## Что считается выводом Вывод — это утверждение о пользователе, под которым стоит дословная цитата с таймингом. Без цитаты это не вывод, а моя догадка, и в отчёт она не идёт. Вывод, у которого нашлась ровно одна цитата, помечается как слабый. ## Чего не делать - Не пересказывать цитаты своими словами. Дословно или никак. - Не обобщать по одному интервью. Для обобщения есть `state/темы.md`. - Не выносить куски расшифровок наружу: там живые люди с именами.
Обратите внимание на середину: там не описание формата, а определение того, что вообще считается выводом. Это самая полезная строчка во всём файле, потому что именно её агент нарушает чаще всего и именно её потом проверяет скрипт.
3. Дальше пишем свой SKILL.md, разница между CLAUDE.md и SKILL.md в том, если CLAUDE.md отвечают на вопрос «что здесь за проект», SKILL.md на вопрос «в каком порядке делать эту конкретную работу».
--- description: Разобрать интервью из raw/ в формат с цитатами. Использовать, когда просят разобрать интервью, расшифровку или созвон. --- # Как я разбираю интервью 1. Читаю `state/разобрано.md`. Файлы из этого списка пропускаю. 2. Беру самый старый неразобранный файл из `raw/`. 3. Читаю `state/темы.md` — что уже встречалось в прошлых интервью. 4. Выписываю выводы. Под каждым — дословная цитата и тайминг. 5. Пишу результат в `out/` под тем же именем, что и исходник. 6. Дописываю в `state/темы.md` находки со счётчиками, в `state/разобрано.md` — имя файла. 7. Запускаю `bash check.sh`, чиню замечания, показываю вывод. ## Что считается хорошим разбором - Пять-семь выводов, не больше. Длинный список означает, что я не выбрал главное. - Слабые выводы помечены и вынесены в конец отдельным разделом. - Есть раздел «против гипотезы»: что в этом интервью противоречит прошлым.
4. Третий файл это вот главный "Проверка" этот файл назовем check.sh – это скрипт напишет вам сам агент, если объяснить, что проверять. Ваша работа здесь не программирование, а формулировка: по каким признакам вы сами отличаете годный разбор от негодного. Скрипт лишь переводит ваш ответ на язык, который нельзя проигнорировать.
5. Добавим запретов, это будет файл settings.json. В нем лежит то, что агент не может нарушить при всём желании, потому что это уже не текст, а конфиг.
{ "permissions": { "deny": ["Edit(raw/**)", "Write(raw/**)", "WebFetch"] }, "hooks": { "PostToolUse": [ { "matcher": "Write|Edit", "hooks": [ { "type": "command", "command": ".claude/hooks/after-write.sh", "timeout": 30 } ] } ] } }
Верхняя половина запрещает трогать исходники и ходить в интернет.
Первое, чтобы расшифровки нельзя было «поправить» под красивый вывод.
Второе серьёзнее: в интервью лежат живые люди с именами и телефонами, и отключённый выход наружу означает, что эти данные физически не могут никуда уйти.
Нижняя половина хук: после каждой записи файла запускается скрипт after-write.sh, который зовёт check.sh, если запись была в out/.
#!/bin/bash # Прогоняет проверку, если агент только что записал разбор. FILE=$(jq -r '.tool_input.file_path // empty') case "$FILE" in */out/*.md) bash check.sh >&2 ;; esac exit 0
Без хука проверка зависит от того, вспомнит ли агент про седьмой пункт навыка на сороковом шаге. А он вспоминает не всегда. С хуком проверка запускается сама и всегда, независимо от того, что модель себе решила. Разница ровно та же, что между просьбой и правилом.
Итак, папка с расшифровками собрана, обвязка готова. Что дальше?
Дальше вы открываете свой инструмент, Claude Code, Codex, Cursor, чем обычно пользуетесь, выбираете созданную папку и запускаете разбор. Либо обычным сообщением, либо командой /разбор-интервью. Агент проходит по всем расшифровкам в папке и раскладывает каждую по одной схеме.
И небольшой совет, который экономит больше всего времени. Zoom, Google Meet и другие сервисы умеют сохранять записи и расшифровки в выбранную папку автоматически. Укажите там ту самую папку с интервью, и промежуточный шаг со скачиванием и переносом файлов исчезает совсем. Встреча закончилась, расшифровка уже лежит там, где нужно, остаётся запустить разбор.
Спасибо, что прочитали, если что-то было не понятно, пишите и подписывайтесь на тг канал
