Своя обвязка: harness, конвейеры и графы вокруг вайбкодинга

Модель сама по себе умеет одно: получить текст и продолжить его. Всё остальное, что делает её агентом, — это harness, и у любого harness шесть частей. Научись видеть их в каждом инструменте. «Настроить агента» всегда означает изменить одну из них.

Напомню из темы «Терминальные агенты: настройка под себя»: команды и скиллы — одно и то же, стандарт — папка скилла с SKILL.md. А событий у хуков гораздо больше четырёх названных там: SubagentStop, SessionStart, UserPromptSubmit и десятки других.

Вся эта конструкция — просто файлы в папке .claude/ внутри репозитория. Значит, обвязка версионируется в git вместе с кодом, переезжает к коллеге вместе с проектом и правится так же, как любой другой текст.

После знакомства со словами «мультиагентная система» тянет сразу строить сложное. Рабочее правило обратное: не переходи на следующий уровень, пока предыдущий не упёрся в конкретную, названную проблему. Каждый уровень добавляет стоимость, задержку и места, где всё может сломаться.

1. Один агент с хорошим контекстом. Правила в CLAUDE.md, пара скиллов, разумные разрешения. Этого хватает для большинства проектов дизайнера: лендинга, прототипа, небольшого продукта. Если результат нестабилен, первым делом чини контекст, а не добавляй агентов.
2. Конвейер: фиксированная цепочка шагов. Задача проходит одни и те же стадии в одном и том же порядке: спецификация → план → реализация → ревью → тесты. На каждой стадии отдельный вызов с узкой задачей и чистым контекстом. Нужен, когда один агент «теряет нить» на длинной задаче или сам себе всё одобряет.
3. Граф: шаги с ветвлениями и циклами. То же, что конвейер, но маршрут зависит от результата. Заявка уходит в разные ветки по типу. Текст возвращается на доработку, пока не пройдёт проверку. Несколько веток идут параллельно и сходятся. Нужен, когда логику «если… то…» уже невозможно описать словами в одном промпте так, чтобы она соблюдалась.

Отдельно от этой лестницы стоит автономный агент. Ему дают цель, а план он строит сам (Manus из темы «Автоматизация процессов с ИИ», режимы глубокого ресёрча). Он хорош там, где путь заранее неизвестен, и плох там, где нужен предсказуемый, повторяемый результат. Конвейер и граф существуют именно затем, чтобы забрать у модели свободу там, где она не нужна.

Эти схемы описаны в статье Anthropic «Building effective agents» и с тех пор стали общим словарём. Узнавать их полезно по той же причине, что и UX-паттерны из темы «UX-паттерны для ИИ-функций»: так быстрее договориться с разработчиком и точнее поставить задачу агенту.

• Цепочка (prompt chaining). Выход одного шага — вход следующего. Между шагами можно поставить проверку. Пример: бриф → структура лендинга → тексты → вёрстка.
• Роутер (routing). Первый шаг только классифицирует вход и отправляет его в нужную ветку с собственным промптом. Пример: входящая заявка → «новый проект» / «правки по текущему» / «вопрос по счёту».
• Параллельные ветки (parallelization). Одна задача делится на независимые части. Или один результат оценивается несколькими узкими критиками одновременно. Это тот самый приём с тремя сабагентами-ревьюерами: доступность, бюджет, бренд.
• Оркестратор и исполнители (orchestrator-workers). Главный агент сам решает, на какие части разбить задачу, раздаёт их исполнителям и собирает результат. Пример: «собери сайт из шести секций». Секции делаются параллельно, оркестратор следит за общим стилем.
• Генератор и критик (evaluator-optimizer). Один шаг создаёт, другой оценивает по рубрике и возвращает на доработку, пока не пройдёт или не кончится лимит попыток. Это автоматизированная версия цепочки «черновик → критика → доработка» из темы «Написание контента и UX-текстов».

Плюс шестой элемент. Это не паттерн, а обязательная деталь любого из них: человек в цикле. Точка, где перед необратимым или дорогим действием конвейер останавливается и ждёт подтверждения.

Схему удобно рисовать до того, как что-то собирать. Хватит стрелок в текстовом файле:

заявка → [роутер] → новый проект   → [вопросы по брифу] → бриф → ЧЕЛОВЕК: ок? → в таблицу
                  → правки         → [сверка с макетом] → список задач → в трекер
                  → прочее         → ЧЕЛОВЕК

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

1. Вход — спецификация, а не промпт. Задача оформляется как spec.md с критериями приёмки (spec-driven development из темы «Вайбкодинг: интерфейсы»). По критериям приёмки потом будет судить ревьюер, поэтому без них конвейер слеп.
2. Реализация — основной агент с правилами из CLAUDE.md и токенами дизайн-системы (тема «AI-first дизайн-системы»).
3. Ревью — отдельный сабагент с чистым контекстом. Он не видел, как писался код, и потому не защищает собственные решения. В его описании одна задача: сверить результат с spec.md и правилами и вернуть список расхождений, ничего не исправляя самому.
4. Проверка — детерминированная. Тесты, линтер, сборка, а не «на взгляд модели». Хук на событие Stop не даёт агенту объявить задачу законченной, пока проверка не пройдена. «Готово» перестаёт быть мнением.
5. Страховка — хук на PreToolUse, блокирующий опасные команды (тема «Безопасность вайбкодинг-проекта»), и список разрешений, где деплой и удаление файлов требуют подтверждения всегда.
6. Память — файлы. В конце задачи агент обновляет ROADMAP.md и короткий журнал решений. Следующая сессия начинается с их чтения, а не с чистого листа.
7. Запуск — один скилл, который проводит задачу через все шаги по порядку. Так не придётся вспоминать последовательность каждый раз.

Сабагент-ревьюер — обычный markdown-файл:

---
name: spec-reviewer
description: Сверяет готовую работу со спецификацией. Вызывать после завершения реализации, до коммита.
tools: Read, Grep, Glob
---
Ты ревьюер. Ты не писал этот код и не обязан его защищать.
Прочитай specs/<задача>/spec.md и изменённые файлы. Для каждого критерия приёмки ответь: выполнен / не выполнен / нельзя проверить — с указанием файла и строки.
Отдельно перечисли нарушения правил из CLAUDE.md: цвета и отступы не из токенов, инлайн-стили, дубли компонентов.
Ничего не исправляй. Если данных для оценки не хватает — так и напиши, не додумывай.

Обрати внимание на строку tools: ревьюеру выданы только инструменты чтения. Ограничение прав — такая же часть роли, как текст инструкции. И оно надёжнее любой просьбы «ничего не меняй».

Собирать всё это руками не обязательно. Это типичная задача для самого агента, пример промпта есть в конце темы. Но спроектировать схему должен ты: какие шаги, где проверка, где останавливаемся и ждём человека.

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

• Постоянно — только то, что нужно в каждой задаче: короткий CLAUDE.md со стеком, правилами и запретами. Если он вырос до нескольких экранов, агент перестаёт его соблюдать.
• По требованию — процедуры и справочники. Скиллы (загружаются, когда понадобились). Документация через MCP (ровно поэтому у Astryx из темы «AI-first дизайн-системы» есть флаг плотного вывода). Файлы, которые агент сам открывает при необходимости.
• В отдельный контекст — всё объёмное и побочное: поиск по кодовой базе, разбор логов, ревью. Сабагент делает грязную работу у себя и возвращает в основной диалог только вывод.
• Между сессиями — ничего, кроме файлов. «Агент помнит» означает «агент прочитал то, что было записано». Что не записано в репозиторий, того в следующей сессии не существует.

Практический признак, что с контекстом беда: агент начинает нарушать правило, которое соблюдал час назад. Повторять правило капсом бесполезно. Лечится новой сессией с чистым контекстом и записанным итогом предыдущей.

Любая правка в CLAUDE.md или в скилле что-то улучшает и что-то ломает, и на глаз этого не видно. Сегодняшняя удачная генерация ничего не говорит о завтрашней. Эвалы (evals, от evaluation) заменяют ощущение измерением. Это набор эталонных задач с заранее известным критерием успеха, который прогоняется после каждого изменения обвязки.

Для дизайнерского проекта достаточно скромной версии:

1. Собери 10–20 реальных задач из истории проекта. Типовые и те, на которых агент раньше ошибался: «добавь секцию с тарифами», «сделай форму с валидацией», «поправь отступы в карточке на мобильном».
2. Для каждой запиши проверку. Лучше всего объективную: сборка проходит, тесты зелёные, в изменённых файлах нет цветов не из токенов, не появилось новых зависимостей. Там, где объективно нельзя, подойдёт рубрика для модели-судьи, как в теме «Оценка и критика результатов ИИ», с оценкой по каждому критерию отдельно.
3. Прогоняй набор целиком после каждой правки обвязки и записывай долю пройденных. Терминальные агенты умеют работать без диалога, у Claude Code это запуск с флагом -p. Поэтому скрипт прогона агент напишет сам. Но в таком режиме некому отвечать на запросы разрешений: без --permission-mode acceptEdits и списка --allowedTools правки будут отклонены или прогон встанет на первом изменении файла. И ограничь стоимость: --max-turns на число шагов, --max-budget-usd на деньги. Одна задача из набора выглядит так:

claude -p "Выполни задачу из evals/01.md" --permission-mode acceptEdits --allowedTools "Read,Edit,Bash(npm test)" --max-turns 30 --max-budget-usd 2

4. Каждый новый провал в реальной работе добавляй в набор. Через месяц набор становится самым ценным файлом проекта: в нём записано всё, что когда-либо шло не так.

Важная деталь: один прогон ничего не доказывает, потому что модель вероятностна (тема «Фундамент»). Задача считается решённой, если проходит стабильно, два-три раза подряд.

Файлов в .claude/ хватает, пока обвязка нужна тебе самому и внутри терминала. Код появляется в двух случаях. Агент должен работать без тебя: по расписанию, по событию, внутри продукта для других людей. Или маршрут настолько ветвистый, что его нужно описать явно и держать под контролем. Здесь достаточно знать карту.

• Agent SDK (Claude Agent SDK, OpenAI Agents SDK, Google ADK) — библиотеки для Python и TypeScript. Они дают тот же агентный цикл, инструменты и управление контекстом, что и готовый агент, но как деталь для своей программы. У Claude Agent SDK это буквально Claude Code в виде библиотеки: те же skills, сабагенты, hooks и MCP подхватываются из папки .claude/. Работает по API-ключу с оплатой по токенам, а не по подписке (тема «ИИ как функция внутри прототипа», там про юнит-экономику).
• Графовые фреймворки (LangGraph и похожие) — способ описать третий уровень явно. Узлы-шаги, переходы между ними, общее состояние, которое передаётся по графу, точки остановки для человека, возможность продолжить с места сбоя. Их берут, когда нужен строгий контроль маршрута, а не свобода агента.
• Визуальные конструкторы (n8n, Make — тема «Автоматизация процессов с ИИ») — тот же граф без кода: узлы на холсте, среди которых есть ИИ-шаги. Для роутера заявок или еженедельного отчёта этого часто достаточно. Для дизайнера это самый короткий путь к работающему графу.

Собрать прототип на SDK можно тем же вайбкодингом. Ставь задачу агенту схемой из раздела про паттерны: «роутер, три ветки, в ветке правок генератор и критик, перед записью в трекер подтверждение человека». Слова «сделай умного агента» не сработают.

• Стоимость и время. Пять шагов — это пять вызовов модели, а цикл «критик вернул на доработку» умножает их ещё. Конвейер, который делает за двадцать минут и два доллара то, что один агент делал за три минуты, должен окупаться качеством. Лимит попыток в любом цикле обязателен.
• Ошибки накапливаются. Если каждый шаг надёжен на 90%, цепочка из пяти шагов надёжна примерно на 60%. Поэтому между шагами ставят проверки, а не надеются на финальное ревью.
• Критик той же модели слеп там же, где автор. Ревьюер на той же модели пропускает те же ошибки. Помогают детерминированные проверки и, для важного, другая модель в роли судьи.
• Автономные ветки читают чужой текст. Любой шаг, который ходит в интернет или читает входящие письма, — поверхность для prompt injection (тема «CLI и терминальные ИИ-агенты»). Такому шагу нельзя давать инструменты с необратимыми действиями.
• Нечего отлаживать. Когда результат плохой, нужно понять, на каком шаге он испортился. Каждый шаг должен оставлять след: что получил, что вернул. Без логов многошаговая схема не чинится, а только переписывается.
• Обвязка устаревает. Правило, которое полгода назад компенсировало слабость модели, с новой версией может только мешать. Раз в пару месяцев пробуй убрать что-нибудь из CLAUDE.md и смотри на эвалы. Хорошая обвязка со временем становится короче.

Посмотри на этот проект и на историю последних задач. Предложи минимальную обвязку в папке .claude: что вынести в CLAUDE.md, какие 2–3 скилла завести под повторяющиеся задачи, какой сабагент-ревьюер нужен и какие хуки. Сначала покажи план и структуру файлов, ничего не создавай без подтверждения

Заведи сабагента spec-reviewer: только инструменты чтения, задача — сверить изменения с specs/<задача>/spec.md и правилами из CLAUDE.md и вернуть список расхождений, ничего не исправляя

Настрой хук на событие Stop: задача не считается законченной, пока не проходят быстрая сборка и линтер. Если проверка упала, хук завершается с кодом 2 и пишет ошибку в stderr, чтобы ты её увидел и продолжил работу. Проверяй stop_hook_active, чтобы не зациклиться

Полная сборка на каждом Stop замедлит каждую реплику, поэтому в хук ставь быструю проверку, а полную — перед коммитом.

Собери скилл /ship, который проводит задачу по шагам: прочитать spec.md → реализовать → вызвать spec-reviewer → исправить найденное → прогнать проверки → обновить ROADMAP.md → показать мне итог и ждать подтверждения перед коммитом

Собери папку evals: 10 задач из истории этого проекта, для каждой — проверка, которую можно выполнить скриптом. Напиши скрипт, который прогоняет все задачи в режиме без диалога (claude -p с --permission-mode acceptEdits, --allowedTools, --max-turns и --max-budget-usd) и печатает таблицу прошёл / не прошёл

Вот процесс, который я хочу автоматизировать: [описание]. Разложи его на шаги и скажи, какой уровень мне нужен: один агент, конвейер или граф, — и почему не следующий по сложности. Нарисуй схему стрелками и отметь, где обязательно должен подтверждать человек

Вот мой CLAUDE.md (вставить). Он вырос до трёх экранов, и агент перестал его соблюдать. Раздели его: что оставить как постоянные правила, что вынести в скиллы, что удалить как очевидное для современной модели