Типичная архитектура 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