Практическое руководство по 3 слоям, которые люди постоянно путают
Большинство людей говорят об AI-агентах так, будто это что-то единое.
Но это не так.
Когда агент выходит за рамки игрушечного демо и начинает работать с файлами, API, документами, клиентами или продакшн-кодом, вы больше не просто «промптируете модель».
Вы проектируете систему.
И в этой системе три понятия постоянно путают:
- Инженерия харнеса
- Инженерия циклов
- Инженерия графов
Все они находятся вокруг одной модели.
Все они влияют на надежность.
И да, все они могут содержать циклы.
Но они решают разные проблемы.
Если их перепутать, вы будете отлаживать не тот слой.
Ответ за 30 секунд
Вот чистая версия:
- Инженерия харнеса создает окружение вокруг модели
- Инженерия циклов проектирует повторяющийся цикл работы и обратной связи
- Инженерия графов делает топологию рабочего процесса явной
Хорошая ментальная модель:
Окружение → Обратная связь → Поток
- Харнес дает модели инструменты, память, управление и рабочее пространство
- Цикл решает, как работа повторяется, проверяется и улучшается
- Граф определяет, какой шаг разрешен следующим
Вот в чем разница.
Почему эти термины важны сейчас
Сырая модель не может выполнять реальную работу сама по себе.
Она не может:
- поддерживать состояние проекта между сессиями
- безопасно вызывать инструменты
- просматривать браузер
- применять права доступа
- повторять неудачную работу
- проверять качество вывода
- распределять задачи между специалистами
- останавливаться в нужный момент
Все это обеспечивает система вокруг нее.
По мере развития агентного ПО вырисовывается практический стек:
- Харнес дает модели условия для работы
- Циклы делают работу повторяемой и проверяемой
- Граф делает сложные рабочие процессы явными и управляемыми
Как только вы увидите эти слои отдельно, многие заблуждения в архитектуре AI исчезнут.
Что обычно включает серьезный харнес
- Внедрение контекста
Что модель видит перед действием:
- инструкции
- извлеченные знания
- состояние разговора
- память
- политики
- правила для конкретной задачи
- Поверхности действий
Что модель может делать:
- вызовы API
- действия в браузере
- команды оболочки
- выполнение кода
- инструменты MCP
- базы данных
- пользовательские функции
- Персистентность
Что сохраняется со временем:
- файлы
- контрольные точки
- состояние сессии
- журналы прогресса
- история git
- долговременная память
- Управление выполнением
Как управляется запуск:
- повторные попытки
- тайм-ауты
- бюджеты
- выбор модели
- запуск подчиненных агентов
- шлюзы утверждения
- Безопасность и управление
Что обеспечивает безопасность системы:
- разрешения с минимальными привилегиями
- изоляция
- белые списки
- обработка секретов
- утверждение человеком
- Наблюдаемость
Что позволяет отлаживать:
- трассировки
- входы и выходы инструментов
- переходы состояний
- задержка
- стоимость
- результаты оценки
Почему важна инженерия харнеса
Две команды могут использовать одну и ту же модель и получать совершенно разные результаты.
Почему?
Потому что одна команда дает модели:
- чистые инструменты
- стабильное состояние
- структурированную память
- четкие разрешения
- наблюдаемое выполнение
А другая дает:
- расплывчатый промпт
- грязные инструменты
- шумный контекст
- без памяти
- без проверки
Модель может быть той же самой.
Условия работы — нет.
Инженерия харнеса важна, когда агент:
- не может получить доступ к нужной возможности
- теряет контекст между сессиями
- действует непоследовательно в разных средах
- не подлежит аудиту
- имеет слишком много разрешений
- не может чисто восстановиться после прерывания
Если модель не может работать надежно, первое, что нужно проверить — харнес.
2. Инженерия циклов
Что это такое
У любого агента, использующего инструменты, уже есть встроенный крошечный цикл:
- вызвать модель
- наблюдать результат
- запустить инструменты
- передать наблюдения обратно
- повторять до готовности
Инженерия циклов начинается, когда вы намеренно проектируете дополнительные циклы вокруг этого поведения.
Не просто «спросить снова».
Не просто «повторить попытку».
А настоящая система работы и обратной связи.
Анатомия хорошего цикла
Триггер
Что запускает новый цикл?
- запрос пользователя
- неудачный тест
- новый документ
- запланированный запуск
- вебхук
- обратная связь от оценщика
Цель
Какое конкретное условие мы пытаемся достичь?
Не «продолжать улучшать».
Реальная цель.
Состояние
Что нужно знать следующему циклу?
- текущий черновик
- предыдущая попытка
- результаты инструментов
- ошибки
- статус прогресса
Политика действий
Что агенту разрешено делать?
- редактировать
- делегировать
- вызывать инструменты
- тратить токены
- записывать файлы
- открывать PR
Доказательство
Как мы узнаем, сработало ли?
- тесты
- валидация схемы
- цитирования
- различия (diff)
- метрики
- одобрение ревьюера
Обратная связь
Что именно не удалось?
Обратная связь должна быть компактной и применимой.
Правило остановки
Когда это заканчивается?
- успех
- тайм-аут
- исчерпан бюджет
- достигнут максимум попыток
- неисправимый сбой
- эскалация человеку
Самый важный принцип в инженерии циклов
**Не циклите на уверенности.
Циклите на доказательствах.**
«Агент говорит, что готово» — это не условие остановки.
Настоящее условие остановки выглядит так:
- тесты проходят
- схема валидируется
- цитирования разрешаются
- ревьюер одобряет
- проверка политики чиста
Вот что такое инженерия циклов.
Почему инженерия циклов — это не просто инженерия промптов
Промпт говорит модели, что делать во время вызова.
Цикл определяет, что делает система после вызова.
Это включает:
- как она проверяет результаты
- как реагирует на сбой
- как сохраняет прогресс
- как решает продолжить
- как завершает работу
Промптинг улучшает ответ.
Цикл улучшает процесс.
Это совершенно разные инженерные задачи.
3. Инженерия графов
Что это такое
Инженерия графов делает структуру рабочего процесса явной.
Она отвечает на другой вопрос:
Не просто «что должен сделать агент?» А «что разрешено делать дальше?»
В инженерии графов:
- шаги — это узлы
- переходы — это ребра
- ветвление явное
- параллельная работа явная
- соединения явные
- повторные попытки явные
- прерывания человеком явные
Граф становится картой управления для системы.
Что на самом деле проектируют инженеры графов
Границы узлов
Что входит в:
- детерминированную функцию
- вызов LLM
- агента-специалиста
- шаг проверки человеком
Схема состояния
Что каждый узел может читать или записывать.
Условия маршрутизации
Какие доказательства перемещают задачу:
- вперед
- назад
- в сторону
- на эскалацию
Параллелизм
Что может выполняться параллельно, а что должно ждать.
Циклы и выходы
Где разрешены повторные попытки, сколько их разрешено и как они останавливаются.
Устойчивость
Где происходят контрольные точки и как рабочий процесс возобновляется после прерывания.
Когда графы оправданы
Графы ценны, когда процесс включает:
- значимое ветвление
- утверждения
- передачу между специалистами
- параллельную работу
- пути восстановления
- многошаговые рабочие процессы с явными точками контроля
Они менее полезны, когда задача просто:
«Дайте одному агенту несколько инструментов и позвольте ему работать».
В этом случае может быть достаточно надежного харнеса и пары циклов.
Граф добавляет ясность, но также добавляет структуру.
Слишком много структуры слишком рано может сделать систему хрупкой.
Как работают вместе 3 слоя
Допустим, вы создаете агента для исследования и публикации.
Он должен:
- определить тему
- собрать источники
- отфильтровать цитирования
- написать черновик отчета
- пройти юридическую проверку
- опубликовать только после одобрения
Вот как слои отображаются:
Харнес
Предоставляет:
- доступ к браузеру
- инструменты поиска
- файловое рабочее пространство
- память
- цитирования
- утверждения
- трассировки
- маршрутизацию модели
Цикл
Обрабатывает:
- повторный поиск источников, когда доказательства слабые
- исправление ошибок цитирования
- запуск проверок оценщика
- обновление работы при изменении рынка
Граф
Управляет путем:
- определение темы
- исследование
- фильтрация
- синтез
- написание черновика
- рецензирование
- публикация
С шлюзом человека перед выпуском.
Вот почему 3 слоя не взаимозаменяемы.
Они работают вместе, но это не одно и то же.
Диагностируйте сбой, прежде чем выбирать исправление
Вот практическое правило:
Если агент не может работать, исправьте харнес
Примеры:
- отсутствует доступ к инструменту
- устаревшее состояние
- слабая память
- плохие разрешения
- нет наблюдаемости
Если агент почти работает, но ненадежен, исправьте цикл
Примеры:
- первый черновик близок, но слаб
- успех непоследователен
- повторные попытки неконтролируемы
- нет доказательств завершения
Если сам процесс сложен, исправьте граф
Примеры:
- много специалистов
- утверждения
- логика ветвления
- параллельные пути
- структурированные передачи
Распространенные ошибки
1. Построение графа слишком рано
Команды часто рисуют огромный рабочий процесс, не видя, как работа ведет себя на самом деле.
Лучший подход:
- начать с более простого харнеса
- собрать трассировки
- найти стабильные паттерны
- формализовать только то, что заслуживает контроля
2. Позволять одной и той же модели писать и оценивать без защиты
Саморецензия может помочь, но у нее те же слепые зоны.
Предпочтительнее:
- детерминированные проверки, где возможно
- отдельный контекст рецензента
- внешние оценщики
- утверждение человеком для действий с высоким влиянием
3. Использование «продолжай пытаться» как цикла
Это не дизайн цикла.
Это неконтролируемая утечка затрат.
Каждому циклу нужны:
- измеримая цель
- реальные доказательства
- лимиты повторных попыток
- правила эскалации
4. Отношение к харнесу как к ящику для хлама
Больше инструментов не означает автоматически лучших агентов.
Слишком много инструментов создают:
- ошибки выбора
- шумный контекст
- слабую надежность
- более широкую поверхность риска
Хороший харнес не перегружен.
Он точен.
5. Обвинение модели в сбоях оркестрации
Модель не может компенсировать:
- сломанные API
- устаревшее состояние
- отсутствие условий выхода
- расплывчатые схемы инструментов
- невидимые режимы отказа
Исправьте слой, которому принадлежит сбой.
Простой производственный чек-лист
Харнес
- Инструменты узкие и документированы?
- Состояние сохраняется?
- Разрешения с минимальными привилегиями?
- Операторы могут приостановить, проверить и возобновить?
- Трассировки видны?
Цикл
- Какие доказательства подтверждают успех?
- Какая обратная связь возвращается при сбое?
- Сколько попыток разрешено?
- Каково правило остановки?
- Что происходит, когда бюджет исчерпан?
Граф
- Какие пути должны быть детерминированными?
- Что может выполняться параллельно?
- Где находятся шлюзы человека?
- Какое состояние является общим?
- Где начинаются пути восстановления?
Оценка
- Можете ли вы воспроизвести реальные трассировки?
- Можете ли вы сравнить версии?
- Можете ли вы отнести улучшение к реальному изменению?
Операции
- Отслеживаете ли вы стоимость?
- задержку?
- частоту сбоев?
- частоту вмешательств?
- успех задач в продакшне?
Самый простой способ запомнить разницу
Если вы запомните только одно, запомните это:
- Инженерия харнеса делает модель работоспособной
- Инженерия циклов делает работу итеративной и проверяемой
- Инженерия графов делает путь выполнения явным и управляемым
Ничто не заменяет другое.
Идеальный граф не спасет слабый харнес.
Сильный харнес все равно будет тратить деньги без хороших циклов.
А чистые циклы становятся трудноуправляемыми, когда ветвление и утверждения остаются скрытыми в ad hoc коде.
Надежные агентные системы появляются, когда все 3 слоя спроектированы намеренно.
Это фактический стек архитектуры.
Итоговый вывод
Люди продолжают говорить об AI-агентах так, будто прорыв — это модель.
В продакшне это редко бывает реальным отличием.
Отличие — это система вокруг модели:
- харнес, который позволяет ей работать
- циклы, которые позволяют ей улучшаться
- граф, который позволяет ей работать под контролем
Вот так игрушечные агенты становятся реальными системами.
Если вы дочитали до этого места:
- ДОБАВЬТЕ В ЗАКЛАДКИ.
- Подпишитесь на @LunarResearcher
- Подпишитесь на мой Substack
- Подпишитесь на мой Приватный Telegram-канал
