Анатомия агентного харнесса (обвязки)

Мы решили перевести для вас статью Vivek Trivedy и дополнить нашими комментариями

Главное

Что надо знать: Агент = Модель + Харнесс. Проектирование харнесса — это то, как мы строим системы вокруг моделей, превращая их в рабочий движок. Интеллект сидит в модели, а харнесс делает этот интеллект полезным. В статье я разбираю, что такое харнесс, и вывожу основные компоненты, которые нужны агентам сегодня и понадобятся завтра.

Так что такое этот «харнесс»?

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

Если ты не модель — значит, ты харнесс.

Харнесс — это весь код, конфиги и логика выполнения, которые не являются самой моделью. «Голая модель» — это ещё не агент. Она становится агентом, когда харнесс даёт ей такие штуки, как состояние, выполнение инструментов, циклы обратной связи и принудительные ограничения.

Если конкретно, в харнесс входят:

• Системные промпты

• Тулзы, скиллы, MCP — и их описания

• Встроенная инфраструктура (файловая система, песочница, браузер)

• Логика оркестрации (запуск (спавн) субагентов, передача задач, роутинг моделей)

• Хуки и middleware для детерминированного выполнения (сжатие контекста, продолжение работы, lint-проверки)

Можно по-разному проводить границу между моделью и харнессом в агентной системе. Но, на мой взгляд, это определение — самое чистое, потому что оно заставляет думать о том, как проектировать систему вокруг интеллекта модели.

Зачем вообще нужен харнесс. Взгляд со стороны модели

Есть вещи, которые мы хотим от агента, но которых модель не умеет «из коробки». Вот тут и появляется харнесс.

Модели (в основном) принимают на вход текст, картинки, аудио, видео — и выдают текст. Всё. Из коробки они не умеют:

• держать устойчивое состояние между взаимодействиями,

• выполнять код,

• доставать знания в реальном времени,

• разворачивать окружения и ставить пакеты, чтобы делать работу.

Всё это — функции уровня харнесса. Сама архитектура LLM требует какой-то обвязки, чтобы они делали полезную работу. Например, чтобы получить продуктовый UX «чата», мы заворачиваем модель в while-цикл, который хранит предыдущие сообщения и подкидывает новые от пользователя. Этим харнессом уже пользовался каждый, кто это читает. Главная идея: мы хотим превращать желаемое поведение агента в реальную фичу харнесса.

От желаемого поведения агента — к проектированию его обвязки

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

Я не буду пытаться перечислить все возможные фичи харнесса. Цель — вывести их, отталкиваясь от задачи «помочь модели делать полезную работу». Схема будет такая:

Поведение, которое нам нужно (или которое надо починить) → дизайн харнесса, который помогает модели это сделать.

Файловая система: устойчивое хранилище и управление контекстом

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

Модель напрямую может оперировать только тем, что лежит в её контекстном окне. До файловых систем приходилось копипастить контент прямо в модель — это неудобный UX, и для автономных агентов он не работает в принципе. Файловые системы к тому моменту были повсеместным инструментом, поэтому модели естественным образом обучились на миллиардах токенов тому, как с ними обращаться. Решение напрашивается само:

Харнесс приходит со своими абстракциями файловой системы и тулзами для работы с файлами.

Файловая система — пожалуй, самый базовый строительный блок харнесса: она разом открывает целый набор возможностей:

• У агента появляется воркспейс для чтения данных, кода и доков.

• Работу можно дописывать и выгружать инкрементально, а не держать всё в контексте. Агент сохраняет промежуточные результаты и держит состояние, которое переживает одну сессию.

• Это естественная среда для коллаборации. Несколько агентов и людей могут координироваться через общие файлы. На этом строятся архитектуры вроде Agent Teams.

• Git добавляет к файловой системе версионирование — агент может отслеживать работу, откатывать ошибки и ветвить эксперименты.

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

Bash + код как универсальный тул

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

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

Харнесс идет в комплекте с Bash-тулзом, чтобы модель решала задачи автономно — писала код и сама же его исполняла.

Bash + выполнение кода — это большой шаг к тому, чтобы дать модели компьютер и предоставить ей самой разбираться с остальным. Модель может на лету собирать себе инструменты через код, а не быть запертой в фиксированном наборе предзаготовленных тулзов. Другие тулзы в харнессе по-прежнему есть, но code execution стал дефолтной универсальной стратегией для автономного решения задач.

Песочницы и тузлы для исполнения и верификации

Агенту нужно разумное дефолтное окружение, чтобы он мог безопасно действовать, видеть результат и двигаться вперёд.

Мы дали модели хранилище и возможность выполнять код, но это всё должно где-то происходить. Гонять сгенерированный агентом код локально — рискованно, и одно локальное окружение не вытягивает агентские нагрузки.

Песочницы дают агентам безопасное окружение для работы. Вместо локального исполнения харнесс подключается к песочнице, в ней запускает код, читает файлы, ставит зависимости и делает задачу. Получается изо��ированное и защищённое исполнение. Для пущей безопасности харнесс может держать allow-list команд и резать сеть. Песочницы ещё и масштабируются: окружения создаются по требованию, разворачиваются веером под кучу задач и сносятся, когда работа сделана.

Хорошее окружение уже по умолчанию укомплектовано нужным тулингом. Это ответственность харнесса — настроить тулзы так, чтобы агент мог реально работать: предустановленные рантаймы и пакеты, CLI для Git и тестирования, браузер для взаимодействия чееррез веб и проверки результата.

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

Модель сама себе окружение не настраивает. Где запускается агент, какие у него тулзы, к чему он имеет доступ и как он проверяет свою работу — это всё решения уровня харнесса.

Память и поиск для непрерывного обучения

Агент должен помнить то, что видел, и иметь доступ к информации, которой не существовало в момент его обучения.

У модели нет никаких знаний помимо того, что в неё зашито при обучении, и того, что лежит в текущем контексте. Изменить то, что зашито при обучении, нельзя — поэтому единственный способ «добавить знания» — впрыснуть их в контекст.

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

Из-за knowledge cutoff модель не видит новые данные — например, свежие версии библиотек, — если пользователь сам их не подкинет. Чтобы добывать актуальное, есть веб-поиск и MCP-тулзы вроде Context7 — они дают агенту доступ к информации за пределами cutoff'а: новые версии библиотек, текущие данные, всё, чего не было на момент окончания обучения.

Веб-поиск и тулзы для свежего контекста — полезные примитивы, которые имеет смысл вшивать в харнесс.

Борьба с “context rot”

Производительность агента не должна проседать по ходу работы.

Context rot — это про то, как модель становится хуже в рассуждении и решении задач по мере заполнения контекстного окна. Контекст — ресурс дорогой и дефицитный, так что харнессу нужны стратегии управления им.

Харнессы сегодня в значительной мере — это механизм доставки хорошего context engineering.

Компакшен (compaction) отвечает на вопрос, что делать, когда контекстное окно вот-вот переполнится. Без компакшена — что произойдёт, когда диалог перерастёт окно? Один вариант — API вернёт ошибку. Это плохо. Харнесс должен что-то с этим делать. Компакшен умно выгружает и суммирует существующий контекст, чтобы агент мог продолжать работать.

Оффлоадинг вывода тулов (tool call offloading) решает проблему больших текстовых выводов, которые шумно засоряют контекст, не давая ничего полезного. Харнесс оставляет в контексте только начальные и конечные токены вывода (выше определённого порога), а полный текст выгружает в файловую систему — модель залезет туда, если понадобится.

Скиллы решают проблему, когда при старте агента в контекст грузится слишком много тулов или MCP-серверов — производительность проседает ещё до того, как агент начнёт что-то делать. Скиллы — это примитив уровня харнесса, который решает это через ленивую подгрузку: вместо того чтобы сразу тащить всё в контекст, нужное подгружается по мере необходимости. Модель не выбирала, чтобы описание скилла подгружалось ей при старте — но харнесс делает это сам, чтобы защитить её от context rot.

Долгая автономная работа

Мы хотим, чтобы агент выполнял сложную работу — автономно, корректно, на длинной дистанции.

Автономное создание софта — это святой Грааль для кодинг-агентов. Но сегодняшние модели страдают от ранней остановки, плохо декомпозируют сложные задачи и теряют связность, когда работа растягивается на несколько контекстных окон. Хороший харнесс должен это всё учитывать.

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

Файловая система и Git для отслеживания работы между сессиями. За длинную задачу агент производит миллионы токенов, и файловая система устойчиво фиксирует эту работу, чтобы можно было отслеживать прогресс во времени. Git позволяет новому агенту быстро войти в курс дела — увидеть последнее состояние и историю проекта. Если агентов несколько, файловая система играет роль общего журнала работы, через который они координируются.

Ralph Loop для продолжения работы. Ralph Loop — это паттерн харнесса, который перехватывает хуком попытку модели завершиться и переинъектит исходный промпт в чистое контекстное окно, заставляя агента продолжать работу до достижения цели. Это работает именно благодаря файловой системе: каждая итерация стартует с чистого контекста, но читает состояние, оставленное предыдущей итерацией.

Планирование и самоверификация, чтобы не сбиваться с курса. Планирование — это когда модель разбивает цель на серию шагов. Харнессы помогают этому хорошими промптами и подсовыванием напоминаний о том, как пользоваться plan-файлом в файловой системе. После каждого шага полезно, чтобы агент проверял корректность того, что сделал — через самоверификацию. Хуки в харнессе могут запускать заранее подготовленный набор тестов и при падении возвращать модель к работе с текстом ошибки; либо саму модель промптом просят самостоятельно оценить свой код. Верификация заземляет решение на тесты и даёт сигнал обратной связи для самосовершенствования.

Будущее харнессов

Сцепка обучения моделей и проектирования харнесса

Современные агентные продукты — Claude Code, Codex — обучаются с харнессом в петле. Это позволяет модели становиться лучше именно в тех вещах, в которых авторы харнесса хотят видеть её сильной по умолчанию: работа с файловой системой, запуск bash-команд, планирование, распараллеливание задач через субагентов.

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

У такой совместной эволюции есть интересные побочки в плане генерализации. Они проявляются, например, в том, что изменение логики тулза роняет качество модели. Хороший пример описан в гайде по промптингу Codex-5.3 — про инструмент apply_patch для редактирования файлов. По-настоящему интеллектуальная модель не должна особенно мучиться при переключении между разными способами патча, но обучение «с харнессом в петле» приводит к такому оверфиту.

Но это не значит, что лучший харнесс для вашей задачи — это тот, с которым модель пост-трейнили. Лидерборд Terminal Bench 2.0 — хорошая иллюстрация. Opus 4.6 в Claude Code набирает заметно меньше, чем Opus 4.6 в других харнессах. В одном из прошлых постов мы показывали, как наш кодинг-агент переехал с Топ-30 на Топ-5 в Terminal Bench 2.0 — изменением одного только харнесса. На оптимизации харнесса под конкретную задачу можно вытянуть очень много.

Куда движется проектирование харнессов

По мере того как модели становятся мощнее, часть того, что сегодня живёт в харнессе, переедет в саму модель. Модели станут лучше планировать, верифицировать себя и держать связность на длинной дистанции нативно — а значит, им потребуется меньше инъекций в контекст.

Из этого вроде бы следует, что харнессы со временем будут значить меньше. Но так же, как промпт-инжиниринг до сих пор остаётся полезным, проектирование харнессов, скорее всего, продолжит быть нужной для строительства хороших агентов.

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

Проектирование харнесса — очень живая область, в которой мы копаем, развивая нашу библиотеку deepagents в LangChain. Вот несколько открытых и интересных проблем, над которыми мы сейчас работаем:

• оркестрация сотен агентов, параллельно работающих над общей кодовой базой;

• агенты, которые анализируют собственные трейсы, чтобы находить и чинить отказы на уровне харнесса;

• харнессы, которые динамически собирают нужные тулзы и контекст just-in-time под конкретную задачу, а не идут предзаготовленными.

Этот пост был упражнением в том, чтобы определить, что такое харнесс и как он формируется под ту работу, которую мы хотим, чтобы модели делали.

Интеллект сидит в модели, а харнесс — это система, которая делает этот интеллект полезным.

За новые харнессы, лучшие системы и лучших агентов.