Замените GPT-5 на Claude внутри рабочего агента — и в большинстве случаев поведение почти не изменится. Измените способ обработки повторных попыток, или то, что вы подаёте в его контекстное окно, или момент остановки — и весь агент будет вести себя иначе. Этот разрыв всё объясняет: модель — это наименьшая и наиболее заменяемая часть рабочего агента. Вся интересная инженерия сосредоточена в том, что её окружает.
Этот wrapper теперь имеет название. Практики остановились на слове «harness» для обозначения слоя, который превращает генератор текста в нечто, выполняющее действия со временем, а не запускающее фиксированный скрипт. Термин быстро распространился в Twitter и инженерных блогах в начале 2026 года — а значит, его также использовали расплывчато, и одно слово делало немного разную работу в каждом прочитанном посте. Эта статья фиксирует его значение: что такое harness, из чего он состоит, чем он отличается от «framework» и «scaffold», и почему большая часть качества вашего агента скрыта в harness, а не в модели.
Кратко
- Agent harness — это программное обеспечение вокруг LLM, которое управляет циклом выполнения, инструментами, памятью, контекстом, состоянием, обработкой ошибок и ограничителями. Модель генерирует текст; harness решает, что видит модель, что она может делать, когда остановиться и что происходит, когда что-то ломается.
- В production окружении вызов модели зачастую является наименьшей видимой частью поверхности системы. Более слабая модель в хорошо построенном harness может превзойти более сильную модель в небрежном, особенно на долгих задачах с большим количеством инструментов.
- Harness имеет примерно от девяти до одиннадцати повторяющихся компонентов. Большинство из них — это то, чего модель никогда не касается напрямую.
- «Harness» — это не то же самое, что «framework». Framework (LangGraph, agents SDK) — это библиотека, с помощью которой вы строите; harness — это работающий слой, который эта библиотека помогает вам собрать.
Что такое Agent Harness?
Agent harness — это программная инфраструктура вокруг языковой модели, которая управляет циклом выполнения, доступом к инструментам, памятью, контекстом, сохранением состояния, обработкой ошибок и ограничителями. Модель генерирует текст. Harness решает, что модель видит на каждом ходу, какие действия она может предпринять, когда остановиться и что происходит при сбое шага.
Наиболее чёткую формулировку даёт LangChain, сводя это к уравнению: Agent = Model + Harness. Модель обеспечивает интеллект. Обёртка — это то, что позволяет этому интеллекту действовать в реальном мире.
«Harness — это весь код, конфигурация и логика выполнения, которые не являются самой моделью.»
— LangChain, Анатомия харнеса агента
Проще всего почувствовать эту границу через один вопрос: когда ваш агент делает что-то не так, было ли неверным само рассуждение модели, или же окружающая система передала модели неверный контекст, неправильные инструменты или не оставила способа восстановиться? В большинстве случаев в реальных системах это второе. Модель рассуждала нормально — на плохих входных данных. Harness контролирует входные данные.
Главный вывод: Модель генерирует — harness управляет. В этом разделении и состоит вся концепция.
Из каких компонентов состоит харнес агента?
Каждый production-харнес собирается из одних и тех же повторяющихся частей: цикл выполнения, который управляет моделью ход за ходом, доступ к инструментам для действий, память между ходами, управление контекстом для текущего состояния, сохранение состояния, чтобы работа не терялась между сессиями, обработка ошибок для неудавшихся шагов и ограничители, сдерживающие действия модели. Production-системы добавляют циклы верификации и оркестрацию подагентов.
Полезный перечень, составленный на основе того, как практики описывают реальные системы:
- Цикл выполнения / управляющий цикл: то, что управляет агентом шаг за шагом. Вызвать модель, прочитать вывод, выполнить запрошенный инструмент, вернуть результат, повторять до условия остановки.
- Доступ к инструментам: функции, API, выполнение кода и файловая система, доступные модели.
- Память: то, что агент сохраняет между ходами и между сессиями.
- Управление контекстом: что загружается в окно модели на каждом ходу и что вытесняется при переполнении.
- Сохранение состояния / контрольные точки: сохранение состояния агента, чтобы прерванный или приостановленный запуск можно было возобновить.
- Обработка ошибок: повторные попытки, резервные варианты и восстановление при сбое вызова инструмента или модели.
- Защитные ограничители: ограничения на действия агента, такие как разрешённые инструменты, лимиты шагов и валидация вывода.
- Циклы верификации: агент (или harness) проверяет собственную работу перед тем, как объявить её завершённой.
- Оркестрация субагентов: запуск субагентов, делегирование им задач и сбор результатов при выполнении крупных задач.
Не все из них универсальны. Цикл выполнения, инструменты, обработка контекста и обработка ошибок присутствуют даже в прототипе выходного дня. Сохранение состояния, верификация и оркестрация субагентов — это то, где прототипы и производственные системы расходятся. Прототип может их пропустить; долгоработающий производственный агент — нет. Материал Anthropic о долгоработающие агенты — обзор частей, характерных только для продакшна: как агент восстанавливает своё понимание из файла прогресса после сброса контекстного окна и как тестирование встраивается в цикл.
Для тех, кто хочет академическую связку, недавний обзор архитектур агентов сворачивает ту же механику в меньший формальный кортеж базовых компонентов. Список практика и структура обзора — это два уровня масштабирования одной и той же структуры: обзор сжимает, приведённый выше список расширяет. Воспринимайте счёт от девяти до одиннадцати как компоненты, которые разделяют большинство производственных harness, а не как ратифицированный стандарт; область ещё ничего не ратифицировала.
Главный вывод: Большинство подвижных частей агента находятся в harness, а не в модели. Модель — один из многих компонентов.
Почему обвязка важнее модели?
Более слабая модель внутри хорошо спроектированной обвязки нередко превосходит более сильную модель в плохо спроектированной. Причина механическая, а не магическая: end-to-end надёжность агента — это произведение надёжностей каждого шага, и большинство этих шагов (выбор инструмента, сборка контекста, восстановление после ошибок) — задача обвязки, а не модели. Улучшите их — и вся цепочка станет надёжнее, независимо от того, какая модель стоит внутри.
Арифметика делает это конкретным. Предположим, что каждый шаг в задаче из десяти шагов успешен 99% времени. Сквозной успех — не 99%. Это 0,99 в десятой степени, около 90%. Поднимите каждый шаг до 99,9% — и сквозной показатель скачет примерно до 99%. Надёжность на шаге накапливается, и надёжность на шаге — это в первую очередь свойство обвязки. Вот почему выжимание максимума из обработки ошибок и управления контекстом окупается больше, чем замена модели на ту, что на пол-пункта лучше на каком-то бенчмарке.
Есть производственные сигналы, указывающие в том же направлении. MongoDB, ссылаясь на кейс Vercel, сообщает, что Vercel сократила большую часть инструментов своего агента и увидела, как показатель успеха резко вырос на той же модели, с меньшей и более чистой обвязкой. Воспринимайте это как сходящееся свидетельство, а не доказательство: это один производственный случай, а не контролируемый эксперимент, но он указывает в том же направлении, что и накапливаемая арифметика и исследовательские работы выше.
Это эвристика, к которой я постоянно возвращаюсь как инженер платформы: контекст — это узкое место, а не сырые возможности модели, и строительные леса, созданные чтобы замаскировать нынешние пробелы модели, имеют тенденцию поглощаться по мере улучшения моделей. Стройте долговечные части обвязки (цикл, состояние, восстановление) и позвольте модели под ней улучшаться по собственному расписанию.
Главный вывод: Когда ваш агент даёт сбой, подозревайте обвязку прежде модели. Статистика на её стороне.
В чём разница между обвязкой, строительными лесами и фреймворком?
Эти три термина используются как взаимозаменяемые, хотя не должны. A framework — это библиотека или SDK, с которым вы работаете, например LangGraph или agents SDK. A harness — это работающий слой исполнения и управления вокруг модели, который фреймворк помогает вам собрать. A scaffold — самый размытый из трёх: иногда почти синоним harness, иногда его прототипная версия, иногда конкретно слой prompt и описаний инструментов.
Терминология по-настоящему не устоялась, и самое разумное — зафиксировать варианты использования, а не навязывать один. Глоссарий HuggingFace Глоссарий агентов говорит об этом прямо:
«Многие из этих терминов ещё не имеют общепринятых определений, и разные фреймворки используют одно и то же слово по-разному.»
— HuggingFace, Глоссарий агентов
| Термин | Что означает | Связь |
|---|---|---|
| Framework | Библиотека или SDK, с которой вы работаете (LangGraph, SDK агентов) | Инструмент для сборки harness |
| Harness | Исполняемый слой вокруг модели: цикл, инструменты, контекст, состояние, ограничители | То, что вы поставляете и запускаете |
| Scaffold | Используется расширенно: почти синоним harness, или версия уровня прототипа / с��оя промптов | Пересекается с harness; менее точный |
| Цикл | Цикл выполнения внутри harness | Компонент harness |
Практический вывод для рассуждений о собственной системе: когда кто-то говорит «framework», спросите, имеет ли он в виду библиотеку или работающую вещь. Когда кто-то говорит «scaffold», спросите, имеет ли он в виду весь harness или только слой prompt-and-tool. Устранение неоднозначности — это и есть ценность здесь, а не претензия на последнее слово.
Как LangGraph реализует паттерн harness?
LangGraph — популярная реализация паттерна harness на Python с открытым исходным кодом. Она моделирует выполнение агента как направленный граф узлов и рёбер, с типизированным состоянием, передаваемым между ними, и возможностью создания чекпоинта на каждом переходе. Если абстрактные компоненты выше кажутся скользкими, LangGraph — место, где можно увидеть их конкретную форму в реальном инструменте.
Сопоставление близко к один-к-одному. Узлы и рёбра — это цикл выполнения: каждый узел выполняет работу, каждое ребро решает, куда управление перейдёт дальше. Типизированный объект состояния, передаваемый между узлами, — это компонент context-and-state, сделанный явным. Создание чекпоинтов (LangGraph сохраняет состояние через savers например, его реализация на основе Postgres) — это компонент сохранения состояния. Настраиваемый лимит шагов — это защитный барьер условия остановки, предотвращающий бесконечную петлю некорректно работающего агента. Те же компоненты, названные и связанные конкретной библиотекой.
Если вы хотите запустить агент LangGraph на собственном сервере круглосуточно, это вопрос развёртывания, а не концептуальный. Смотрите наш Linux VPS guide для этого пути. Здесь LangGraph — просто разобранный пример: доказательство того, что «цикл выполнения», «сохранение состояния» и «guardrail» — это не абстракции, а вещи, на которые можно указать в реальном коде.
Часто задаваемые вопросы
Что такое Agent Harness?
Agent harness — это программное обеспечение вокруг языковой модели, которое превращает её в агента. Оно управляет циклом выполнения, доступом к инструментам, памятью, контекстом, сохранением состояния, обработкой ошибок и защитными барьерами. Модель генерирует текст; harness решает, что модель видит, что она может делать, когда остановиться и что происходит при сбое.
Является ли обёртка агента тем же, что и фреймворк агента?
Нет. Фреймворк — это библиотека или SDK, с помощью которых вы создаёте систему, например LangGraph или SDK агентов. Обёртка — это работающий слой выполнения и управления вокруг модели (цикл, инструменты, контекст, состояние и ограничители), который фреймворк помогает вам собрать. Фреймворк используется для построения обёртки.
Какие компоненты есть в каждой обёртке агента?
Большинство обёрток имеют общее повторяющееся ядро: цикл выполнения, доступ к инструментам, память, управление контекстом, сохранение состояния, обработку ошибок и ограничители. Производственные обёртки добавляют циклы проверки и оркестрацию субагентов. Прототипы могут пропустить элементы только для продакшна, но цикл, инструменты, управление контекстом и обработка ошибок встречаются почти везде.
Что означает «LLM — это наименьшая часть вашей агентной системы»?
Это означает, что большинство поведения агента и его надёжность обеспечиваются обёрткой, а не моделью. Сквозная надёжность — это произведение показателей успешности каждого шага, и большинство шагов являются работой обёртки. MongoDB, ссылаясь на кейс Vercel, сообщает о скачке показателя успешности только за счёт изменений обёртки на той же модели. Это доказательство того, что исправление обёртки эффективнее исправления модели.
Где живёт качество вашего агента
Обёртка — это место, где сосредоточено большинство качеств агента, и теперь у вас есть словарный запас для поиска проблем в собственной системе. Вы можете дать определение обёртке, назвать её компоненты, отличить её от фреймворка и скаффолда, а также рассуждать о том, является ли данный сбой проблемой модели или обёртки.
Поэтому в следующий раз, когда ваш агент будет плохо себя вести, сначала проверьте слой обёртки: контекст, который вы ему подаёте, инструменты, которые вы открыли, условия остановки, которые вы установили, способ восстановления после неудачного шага. Переходите к более крупной модели только после того, как этот слой проверен. В большинстве случаев это не понадобится.
