Вы не модель, вы харнес: анатомия агентной инфраструктуры

Вы собрали чатбота. Подключили ReAct-цикл с парой инструментов. На демо работает отлично. Потом пытаетесь сделать что-то продакшн-готовое и всё разваливается: модель забывает, что делала три шага назад, вызовы инструментов падают без шума, контекстное окно забивается мусором.

Проблема не в модели. Проблема во всём, что вокруг неё.

LangChain доказал это наглядно: они поменяли только инфраструктуру вокруг LLM (та же модель, те же веса) и поднялись с позиции ниже 30-й на 5-ю в TerminalBench 2.0. Отдельный исследовательский проект достиг 76,4% pass rate, просто предоставив LLM оптимизировать саму инфраструктуру, тем самым обойдя системы, спроектированные вручную.

У этой инфраструктуры теперь есть название: agent harness (агентный харнес).

Что такое агентный харнес?

Термин был формализован в начале 2026 года, но концепция существовала давно. Харнес представляет собой полную программную инфраструктуру, оборачивающую LLM: цикл оркестрации, инструменты, память, управление контекстом, хранение состояния, обработка ошибок и ограждения безопасности. Документация Anthropic по Claude Code описывает это так: SDK является “agent harness, который питает Claude Code”. Команда OpenAI Codex использует ту же формулировку, прямо приравнивая “агента” и “харнес” к нон-модельной инфраструктуре.

Вот различие, на котором спотыкаются многие. “Агент” это наблюдаемое поведение: целенаправленная, использующая инструменты, самокорректирующаяся сущность, с которой взаимодействует пользователь. Харнес это механизм, производящий это поведение. Когда кто-то говорит “я создал агента”, он имеет в виду, что создал харнес и направил его на модель.

Beren Millidge точно сформулировал аналогию в своём эссе 2023 года “Scaffolded LLMs as Natural Language Computers”. Сырая LLM это CPU без RAM, без диска и без I/O. Контекстное окно служит RAM (быстро, но ограничено). Внешние базы данных работают как дисковое хранилище (большое, но медленное). Интеграции инструментов выступают драйверами устройств. Харнес это операционная система. Как написал Millidge: “Мы заново изобрели архитектуру фон Неймана”.

Три уровня инжиниринга

Вокруг модели существуют три концентрических уровня инжиниринга. Prompt engineering создаёт инструкции, которые получает модель. Context engineering управляет тем, что модель видит и когда. Harness engineering охватывает оба предыдущих уровня плюс всю инфраструктуру приложения: оркестрацию инструментов, хранение состояния, восстановление после ошибок, циклы верификации, обеспечение безопасности и управление жизненным циклом.

Харнес это не обёртка вокруг промпта. Это полная система, делающая возможным автономное поведение агента.

12 компонентов продакшн-харнеса

Синтезируя опыт Anthropic, OpenAI, LangChain и сообщества практиков, продакшн-агентный харнес состоит из двенадцати компонентов.

1. Цикл оркестрации реализует паттерн Thought-Action-Observation (TAO), также известный как ReAct-цикл: собрать промпт, вызвать LLM, разобрать вывод, выполнить вызовы инструментов, передать результаты обратно, повторить до завершения. Anthropic описывает свой рантайм как “тупой цикл”, где весь интеллект живёт в модели.

2. Инструменты это руки агента. Они определяются как схемы (имя, описание, типы параметров), внедряемые в контекст LLM. Claude Code предоставляет инструменты в шести категориях: операции с файлами, поиск, выполнение, веб-доступ, работа с кодом и порождение субагентов.

3. Память работает на нескольких временных масштабах. Краткосрочная память это история разговора в рамках сессии. Долгосрочная память сохраняется между сессиями: Anthropic использует файлы проекта CLAUDE.md и авто-генерируемые файлы MEMORY.md; LangGraph использует namespace-организованные JSON-хранилища. Claude Code реализует трёхуровневую иерархию: лёгкий индекс (~150 символов на запись, всегда загружен), детальные тематические файлы, подгружаемые по требованию, и сырые транскрипты, доступные только через поиск.

4. Управление контекстом там, где многие агенты молча деградируют. Ключевая проблема: context rot, производительность модели падает на 30%+, когда ключевой контент оказывается в серединных позициях окна (исследования Chroma, подтверждённые Stanford “Lost in the Middle”). Даже миллионно-токенные окна страдают от деградации при росте контекста. Продакшн-стратегии включают компакцию (Claude Code сохраняет архитектурные решения и нерешённые баги, отбрасывая избыточные выводы инструментов), маскировку наблюдений, just-in-time retrieval и делегирование субагентам.

5. Конструирование промпта собирает то, что модель видит на каждом шаге: системный промпт, определения инструментов, файлы памяти, историю разговора и текущее сообщение пользователя. OpenAI Codex использует строгий стек приоритетов: системное сообщение, управляемое сервером (высший приоритет), определения инструментов, инструкции разработчика, инструкции пользователя, затем история разговора.

6. Разбор вывода. Современные харнесы полагаются на нативные вызовы инструментов: модель возвращает структурированные объекты tool_calls вместо свободного текста. Для структурированных выводов и OpenAI, и LangChain поддерживают ответы, ограниченные схемой через Pydantic-модели.

7. Управление состоянием. LangGraph моделирует состояние как типизированные словари, текущие через узлы графа, с редьюсерами, сливающими обновления. Claude Code использует другой подход: git-коммиты как чекпоинты и файлы прогресса как структурированные блокноты.

8. Обработка ошибок. Вот почему это важно: процесс из 10 шагов с 99% успеха на каждом шаге имеет лишь ~90,4% сквозного успеха. Ошибки накапливаются быстро. LangGraph различает четыре типа ошибок: транзиентные (retry с backoff), восстанавливаемые LLM (вернуть ошибку как ToolMessage), исправляемые пользователем (прервать для ввода человека) и неожиданные (передать вверх для отладки). Stripe в продакшне ограничивает число попыток двумя.

9. Ограждения и безопасность. OpenAI SDK реализует три уровня: входные ограждения (на первом агенте), выходные ограждения (на финальном выводе) и ограждения инструментов (на каждом вызове). Механизм “tripwire” немедленно останавливает агента при срабатывании. Anthropic архитектурно разделяет разрешения и рассуждения модели.

10. Циклы верификации отделяют игрушечные демо от продакшн-агентов. Anthropic рекомендует три подхода: обратная связь на основе правил (тесты, линтеры, проверка типов), визуальная обратная связь (скриншоты через Playwright для UI-задач) и LLM-as-judge (отдельный субагент оценивает вывод). Борис Черны, создатель Claude Code, отметил, что предоставление модели способа верифицировать свою работу улучшает качество в 2-3 раза.

11. Оркестрация субагентов. Claude Code поддерживает три модели выполнения: Fork (побайтово идентичная копия родительского контекста), Teammate (отдельная панель терминала с файловым mailbox для коммуникации) и Worktree (собственное git-дерево, изолированная ветка на агента).

Семь решений, определяющих каждый харнес

Каждый архитектор харнеса сталкивается с семью выборами. Первый: одноагентная или многоагентная система. И Anthropic, и OpenAI говорят: максимизируйте возможности одного агента сначала. Многоагентные системы добавляют накладные расходы. Разделяйте только при перегрузке инструментами (более ~10 перекрывающихся) или явно разных доменах задач.

Второй: ReAct против plan-and-execute. ReAct перемежает рассуждение и действие на каждом шаге (гибко, но высокая стоимость на шаг). Plan-and-execute разделяет планирование и выполнение. LLMCompiler сообщает об ускорении 3,6x по сравнению с последовательным ReAct.

Третий: стратегия управления контекстным окном. Пять продакшн-подходов: очистка по времени, суммаризация разговора, маскировка наблюдений, структурированное ведение заметок и делегирование субагентам. Исследования ACON показали сокращение токенов на 26-54% при сохранении 95%+ точности, приоритизируя трассировки рассуждений над сырыми выводами инструментов.

Четвёртый: дизайн цикла верификации. Вычислительная верификация (тесты, линтеры) даёт детерминированную истину. Inferential verification (LLM-as-judge) ловит семантические проблемы, но добавляет задержку. Пятый: архитектура разрешений и безопасности: разрешительная (быстро, но рискованно) против ограничительной (безопасно, но медленно). Шестой: стратегия охвата инструментов. Больше инструментов часто означает хуже производительность. Vercel убрал 80% инструментов из v0 и получил лучшие результаты. Принцип: открывайте минимальный набор инструментов, нужных для текущего шага. Седьмой: толщина харнеса. Насколько много логики живёт в харнесе против модели. Anthropic ставит на тонкие харнесы и улучшение модели.

Харнес и есть продукт

Два продукта на идентичных моделях могут иметь кардинально разную производительность, основанную исключительно на дизайне харнеса. Свидетельства TerminalBench очевидны: изменение только харнеса двигало агентов на 20+ позиций рейтинга.

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

Отрасль движется к более тонким харнесам по мере улучшения моделей. Но сам харнес никуда не денется. Даже самой способной модели нужно что-то для управления контекстным окном, выполнения вызовов инструментов, хранения состояния и верификации работы.

В следующий раз, когда ваш агент упадёт, не вините модель. Смотрите на харнес.

Источник: оригинальная статья @akshay_pachaar на X