Типичная архитектура harness

Автор: Алексей Пасечник (Arhellist). Канонический адрес: https://arhellist.ru/blog/tipichnaya-arhitektura-harness/.

Опубликовано: 2026-10-11.

Серия «Как я строил HarnessOS», часть 2 из 10.

Есть хорошая новость: harness’ы устроены похоже. Даже если их делают разные люди для разных задач.

Я разобрал несколько открытых harness’ов — от простых до продакшн-уровня. И увидел четыре слоя, которые есть почти везде.

Слой 1. Оркестрация

Это то, что решает, что делать дальше. Какой агент, с каким контекстом, какие инструменты, что проверить. По сути, оркестрация — это цикл событий (event loop). Не «модель думает», а «модель предложила → система проверила → система решила, что дальше».

Слой 2. Изоляция

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

Слой 3. Память

Что агент помнит. Не «история чата», а структурированная база знаний. Что делал вчера. Какие решения принял и почему. Какие грабли уже собрал.

Слой 4. Верификация

Как проверить результат. Не «агент сказал „готово“», а «тесты прошли, линтер чист, план выполнен». Верификация — это детерминированный фильтр. Не мнение модели, а факт.

Есть и пятый слой. Он встречается не всегда, но отличает зрелые harness’ы от самоделок: governance. Это правила. Лимиты. Эскалация. Что делать, если агент не может решить задачу. Когда звать человека.

Когда я это увидел, стало проще. Не надо изобретать. Надо сделать каждый слой нормально.

В следующем посте — почему я не взял готовый инструмент, а начал строить свой.

Больше о разработке и AI — Мой Телеграм

#HarnessOS #AIразработка #КакЯСтроилHarnessOS #AIагенты #разработка

О чём пишем

  • Архитектура и эксплуатация веб-продуктов
  • AI-агенты, RAG и практические контуры
  • Кейсы LMS, маркетплейсов и защищённых коммуникаций
  • Заметки по Next.js, Node.js, PostgreSQL и realtime