Agent Harness: одна LLM, разные результаты — в чем секрет?

Agent Harness: одна LLM, разные результаты — в чем секрет?

Использование кодовых агентов — таких как Codex, Cursor и Claude Code — стало повседневной практикой. При этом зачастую в их основе лежит одна и та же языковая модель, но результаты работы сильно отличаются.

Например, Cursor может быстрее создавать качественный UI, Claude Code — эффективнее проектировать архитектуру приложения, а WindSurf — лучше справляться с прототипированием систем. Почему так происходит, если «мозг» у них один?

Ответ — в системе, которая окружает модель. В англоязычной терминологии её называют agent harness. Слово "harness" можно перевести как «упряжь», «обвязка» или «доспехи», но точного русского аналога пока нет. В этой статье используется транслитерация — харнесс.

Часть 1. LLM — мозг системы

Большая языковая модель (LLM) — это по сути генератор текста. Её задача: по последовательности токенов предсказать следующий. В «чистом» виде модель не имеет памяти, состояния, доступа к файловой системе или инструментам.

Каждый запрос к ней независим. Она видит только текущий контекст и свои внутренние знания. Сама по себе LLM не может выполнять действия — только генерировать текст.

Часть 2. Agent и ReAct

Чтобы модель могла решать сложные задачи, её интегрируют в архитектуру агента. К ней добавляют память, инструменты и цикл выполнения. Один из ключевых подходов — ReAct (Reason + Act). Он включает четыре шага:

  • Reason — модель анализирует задачу и решает, что делать дальше.
  • Act — вызывается инструмент (например, редактор кода или терминал).
  • Observe — результат действия возвращается модели как новый контекст.
  • Repeat — процесс повторяется, пока задача не будет выполнена.

Этот цикл превращает пассивную модель в активного агента, способного действовать, анализировать и адаптироваться.

Часть 3. Agent Harness

Команда LangChain даёт ёмкое определение:

Агент = Модель + Харнесс

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

Он выступает посредником между моделью и внешним миром: файловой системой, пользователем, инструментами и состоянием. Без харнесса модель остаётся просто генератором текста.

Такие продукты, как Claude Code, Cursor, Codex и другие, — это по сути разные реализации харнесса. Инженерная ценность таких систем — не в модели, а в том, как она используется.

При этом харнессы создаются под конкретные задачи: кодинг-агенты, шоппинг-агенты, исследовательские агенты — у всех разная логика и структура.

Часть 4. Почему одна LLM ведёт себя по-разному в разных агентах

Когда вы переходите от одного агента к другому, вы меняете не только интерфейс, но и всю инфраструктуру вокруг модели. У каждого агента — свой харнесс. Вот что влияет на различия:

  • Системные промпты — определяют стиль, уровень автономности и подход к решению задач.
  • Управление контекстом — как сохраняется, сжимается или подгружается информация при ограничениях по объёму.
  • Набор инструментов — доступ к терминалу, навигации по файлам, запуску тестов и другим функциям.
  • Уровень автономности — насколько агент действует самостоятельно или требует участия человека.
  • Механизмы верификации — возможность проверить результаты своих действий. Как отмечает Борис Черный, создатель Claude Code: «Если у модели есть обратная связь, качество результата растёт в 2–3 раза».
  • Изолированная среда выполнения — безопасность и возможности для запуска кода.
  • Цикл планирования — как агент разбивает задачу и организует выполнение шагов.

Часть 5. Иерархия LLM-инжиниринга

Развитие LLM-систем прошло три ключевых этапа:

  • Промпт-инжиниринг — улучшение инструкций, примеров и цепочек рассуждений.
  • Инжиниринг контекста — управление информацией, подаваемой в модель: суммаризация, RAG, история сессий.
  • Харнесс-инжиниринг — создание полноценных приложений с циклами, памятью, инструментами и контролем поведения.

Сейчас ключевой вопрос — не только «какую модель использовать», но и «в каком харнессе». При грамотной архитектуре вы можете заменить модель на новую SOTA — и система продолжит работать, но с улучшенным «мозгом».

При этом по мере роста силы моделей часть функций харнесса может упрощаться или удаляться. Например, раньше активно использовался подход SGR для корректного вызова инструментов, но теперь некоторые системы могут обходиться без него.

Бонус: аналогия

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

Кухня — это харнесс. Она определяет, что может быть приготовлено:

  • Инструменты — духовка, ножи, сковородки.
  • Субагенты — су-шефы и повара, выполняющие поручения.
  • Рецепты и мизансцены — структурированная информация и организация рабочего места.
  • Холодильник и кладовка — память и файловая система.
  • Санитарные нормы — ограничения и безопасность.

Один и тот же шеф на кухне студенческого общежития приготовит простую еду. На профессиональной кухне с командой — шедевр.

Для сложных задач нужна команда и оборудование. Для простых — достаточно базового набора. От выбора инструментов зависит и качество, и стоимость. Выбирайте модель и харнесс под задачу. Тратьте токены с умом.

Заключение

Разница в эффективности AI-агентов часто объясняется не моделью, а харнессом. Именно он определяет, что модель знает, что может делать, как планирует и проверяет себя.

Измените харнесс — и вы измените агента, даже если модель осталась прежней. Будущее LLM-приложений — в инжиниринге харнессов.

Читать оригинал