Харнес — это продукт: практическое руководство по использованию харнесов в агентных ИИ-системах.
Узнайте, что такое агентский харнес и каковы его семь компонентов — от инструментов и контекста до ограничений и механизмов оценки, а также субагентов, способов сбоев и полезных фреймворков.
Источники: The Harness Is the Product: An End-to-End Guide to Harnessing in Agentic AI
Представьте, что одна и та же модель языка предоставлена двум разным командам. Команда А создаёт агента, который исправляет ошибки в огромном репозитории, запускает набор тестов и отправляет аккуратный запрос на слияние кода. Команда Б создаёт чат-ассистента, который уже после нескольких сообщений теряет нить разговора и с радостью выдумывает корпоративные правила. Веса модели одинаковы, но результаты совершенно разные.
Этот «комплект инструментов» — это всё, что создаётся вокруг модели. Он включает цикл, позволяющий модели действовать, инструменты, которые она может использовать, механизм управления её окном контекста, ограничения, предотвращающие совершение глупых действий, а также обратную связь, указывающую на успех её действий. Далее рассматривается всё с нуля: что такое агент, составляющие его «комплекта инструментов», паттерны работы, такие как использование подагентов и процедура компактизации, несколько известных систем и существующие сегодня фреймворки. Предварительный опыт работы с агентами не требуется.
Основы
Что означает искусственный интеллект-агент
Без всей этой шумихи агент — это просто:
Агент — это языковая модель, работающая в цикле с использованием инструментов до достижения поставленной цели.
Для этого требуются три компонента: модель, способная рассуждать и выбирать следующий шаг, инструменты, которые модель может использовать, такие как поиск в Интернете, доступ к файлам, выполнение кода, поиск в базе данных или отправка писем, и цикл, который возвращает результаты каждого инструмента обратно модели, чтобы она могла решить, что делать дальше.
Чат-бот отвечает один раз и прекращает работу. Агент продолжает действовать: он совершает действие, оценивает его результат, затем совершает ещё одно. Именно этот цикл позволяет модели, предсказывающей текст, выполнять реальную работу, а далее в этой статье рассматриваются детали этого процесса.
Что такое «харнес»
Представьте «харнес» как среду выполнения для этого цикла. Модель выбирает, что должно произойти дальше, в то время как «харнес» реализует это и обеспечивает безопасность, экономичность, прозрачность и контроль над всем процессом. Название намекает на тестовый харнес в программном обеспечении или на уздечку на лошади: огромная сила требует структуры, чтобы быть направленной на полезную работу.
В конкретных терминах «сборка» выполняет запросы инструмента к модели, контролирует то, что видит модель на каждом шаге, обеспечивает соблюдение правил доступа, обрабатывает сбои, попытки повтора и бесконечные циклы, отслеживает прогресс и определяет момент завершения работы или необходимость остановки и обращения к человеку.
Полезный способ представления этого: у модели нет памяти между этапами работы. Каждый раз, когда её вызывают, она начинает с чистого листа, читает предоставленный текст и выдает один результат. Всё остальное — скрипт, реквизиты, сцена и механизмы безопасности — это и есть «сборка». Измените их расположение, и тот же актер будет вести себя совершенно иначе.
Почему важна «сборка»
Выделяются три практических причины.
Результаты работы моделей сходятся, в то время как преимущества использования инструментальных платформ — нет. Модели нового поколения становятся всё более схожими по базовым способностям. В тестах, оценивающих устранение реальных проблем в программном обеспечении, одна и та же модель может показывать существенно разные результаты в зависимости от используемых инструментов, подсказок и механизмов обратной связи. В определённый момент именно эти инструменты становятся определяющим фактором.
Длительные задачи усиливают незначительные ошибки. Если модель надёжна на 99 процентов на каждом шаге, вероятность успешного выполнения задачи из 50 шагов составляет лишь около 60 процентов, поскольку 0,99 в степени 50 равно примерно 0,605. Проверка, повторные попытки, контрольные точки и корректировка курса — это механизмы, предотвращающие накопление ошибок. Они отличают демо-версию от готового продукта.
Свобода требует ограничений. Любой агент, способный выполнять команды оболочки, перемещать деньги или взаимодействовать с клиентами, должен иметь ограничения на права доступа, среду тестирования и журналы аудита. Все это входит в состав инструментальной платформы, а модель не предоставляет ничего из этого.
Структура инструментальной платформы
Агенты для программирования, исследований и поддержки обычно имеют семь общих компонентов. Рассмотрим их по порядку.
1. Системное указание, постоянные правила
Здесь агенту указывается его роль, ограничения, правила поведения и назначение каждого инструмента. В зрелых продуктах такой текст насчитывает тысячи слов и поддерживается с такой же тщательностью, как и исходный код, с учетом тона, безопасности, порядка задавания вопросов и способов обработки неоднозначных инструкций.
Новичок может написать всего одну строку, указав, что агент является полезным помощником для программирования. Однако инструкция для производственного использования содержит подробные процедуры: открывать файл перед его редактированием, предпочитать небольшие изменения, выполнять тесты после каждой правки, останавливаться и сообщать о проблемах после двух неудачных тестов, а также никогда не добавлять изменения непосредственно в основную ветку, причем далее перечисляются ещё множество подобных правил.
2. Слой инструментов, «руки»
Инструмент — это функция, которую модель может вызывать; она определяется названием, описанием и схемой типов для аргументов. Модель запрашивает выполнение функции в структурированном виде, после чего механизм обработки выполняет её и возвращает результат.
Проектирование инструментов — это недооценённое искусство. По сути, это проектирование API для очень прямолинейного пользователя:
- Описания служат подсказками. Модель выбирает инструменты на основе их описаний, поэтому расплывчатое описание приводит к неправильному инструменту.
- Несколько хорошо структурированных инструментов лучше, чем множество перекрывающихся друг друга. Чрезмерное количество инструментов сбивает с толку модели так же, как меню из сорока позиций сбивает с толку посетителей ресторана.
- Возвращайте ошибки, с которыми может справиться модель. Сообщение о том, что файл является только для чтения и требуется сначала запросить доступ, лучше, чем простой стек ошибок.
- Сделайте опасные инструменты более ограниченными. Инструмент, который отправляет только заранее одобренные черновики, гораздо безопаснее того, который выполняет произвольный код.
Важным достижением в этой области является Protocol Model Context, который Anthropic сделал открытым в конце 2024 года, и его уже приняло большинство компаний отрасли. Он стандартизирует способ, которым поставщики инструментов делают их доступными для любого агента, фактически создавая универсальный соединитель: достаточно разработать интеграцию один раз, и её можно использовать в любой системе.
3. Управление контекстом, рабочая память
Окно контекста представляет собой весь воспринимаемый мир модели. Объем таких окон обычно составляет от сотен тысяч до миллиона токенов, что кажется огромным количеством, пока агент не прочитает сорок файлов и не выполнит шестьдесят команд.
Выбор того, что модель будет видеть на каждом этапе, вероятно, является самым важным фактором в системе; специалисты теперь называют это проектированием контекста, которое в основном заменило проектирование промптов в качестве ключевой навыка. Существуют техники от простых до сложных: обрезка (сохранение только последних сообщений или части файла), поиск (индексация базы знаний и извлечение только необходимой информации в данный момент) и сжатие. При сжатии, когда объем окна приближается к пределу, модель пишет краткое резюме сессии, которое заменяет оригинальный текст, и работа продолжается. Именно так агенты могут выполнять задачи в течение нескольких часов.
4. Память — долгосрочное хранилище
Контекст действует в течение одной сессии, но память сохраняется. Обычно используются следующие уровни хранения памяти:
- память проекта, например файлы инструкций в репозитории, которые объясняют агенту по программированию ваши стандарты и команды по сборке и читаются при начале сессии,
- память пользователя, то есть предпочтения, сформированные в ходе различных разговоров,
- эпизодическая память, которая хранит записи о прошлых запусках, часто в векторном хранилище, чтобы их можно было восстановить при возникновении похожих ситуаций.
5. Ограничения, разрешения и изоляция, «тормоза»
Слой безопасности постоянно проверяет, действительно ли необходимо выполнить ту или иную операцию. На практике это означает:
- Уровни разрешений. Чтение осуществляется свободно, запись проходит проверку политик, а необратимые действия, такие как развертывание, отправка, удаление или оплата, требуют явного одобрения человека.
6. Проверка и обратная связь — «глаза»
Нет ничего, что могло бы более надежно улучшить агента, чем способ тестирования его собственных результатов. Агенты-кодеры компилируют код, проверяют его на наличие ошибок и запускают тесты после каждой правки. Исследовательские агенты сравнивают утверждения из различных источников. Агенты-браузеры фиксируют экран, чтобы увидеть, что на самом деле загружается. Некоторые решения включают в себя рецензента — вторую модель, которая оценивает ответ первой модели по определенным критериям перед тем, как он будет принят.
Это позволяет напрямую бороться с проблемой кумулятивных ошибок. Агент, который может заметить свою ошибку, может попробовать снова, тогда как агент, не способный этого сделать, с уверенностью предоставит бесполезный результат.
7. Наблюдаемость, «бортовой самописец»
В режиме производства фиксируется каждый запрос к модели, каждый вызов инструмента и каждый потраченный токен. С помощью этих записей можно воспроизвести неудачную попытку выполнения, определить шаг, в котором возникла ошибка, и исправить проблемный промпт, инструмент или правила. Вокруг этого возникла целая категория продуктов, включая LangSmith, Langfuse, Braintrust, а также стандарты OpenTelemetry для генеративного ИИ, поскольку отладка агента без возможности наблюдения так же сложна, как отладка распределенных сервисов без логов.
Эффективная работа в цикле
Называние компонентов — это простая часть задачи. Разница между системой, способной выдержать демонстрацию, и системой, способной функционировать в обычных рабочих условиях, заключается в следующих практиках.
Планирование, действие, проверка
Простые агенты сразу приступают к работе. Более зрелые решения обеспечивают определённый ритм: составляется план путём разбиения цели на список задач, делаются небольшие шаги, каждый результат проверяется перед продолжением, затем план корректируется и процесс повторяется. Письменный план выполняет две функции: он помогает модели сосредотачиваться на длительных задачах, поскольку его перечитывают на каждом этапе, и позволяет наблюдающему человеку видеть прогресс в реальном времени, что оказывается более ценным, чем ожидалось.
Структурированные результаты
Каждый раз, когда программа будет использовать результаты работы модели, необходимо ограничить их с помощью схемы. Современные API поддерживают принудительные вызовы инструментов и генерацию с проверкой по схеме. Проза предназначена для людей; код должен иметь структуру.
Затраты и задержки
Агенты быстро тратят токены, что делает экономику ресурсов важной проблемой. Хранение большого статического префикса (системного запроса и определений инструментов) между раундами стоит гораздо дешевле, чем его повторная отправка, что является значительным преимуществом при длительных сессиях. Механизм маршрутизации направляет рутинные шаги на небольшую, быструю модель, а сложные задачи, требующие логических рассуждений, — на специализированную модель. Независимые подзадачи, такие как чтение десяти файлов или проверка пяти источников, могут выполняться одновременно.
Многоагентные системы и что дальше
Подагенты и оркестрация
Когда задачи выходят за рамки одного окна контекста, системы переходят на многоагентную архитектуру. Оркестратор делим цель на части и создаёт подагентов, у каждого из которых есть свой собственный контекст, обычно ограниченный набор инструментов и чётко сформулированное задание. Каждый подагент выполняет свою работу и возвращает только свой вывод, а не всю историю своей деятельности.
Практическая польза менее очевидна, чем скорость: каждый подагент работает в своем изолированном контексте, а не просто параллельно. Десять подагентов могут заполнить целое окно одной подсистемой каждый, в то время как оркестратор сохраняет лишь десять кратких краткосписков.
К распространенным топологиям относятся оркестратор и рабочие элементы (это самый распространенный вариант), конвейеры вроде «набросок», «критика» и «исправление», а также дискуссионные группы, в которых несколько агентов независимо решают проблему, а судья обобщает ответы. Дискуссии требуют много ресурсов, но подходят для вопросов высокой значимости.
Команды, подготовившие этот отчет, извлекли несколько важных уроков:
- Укажите ожидаемый уровень усилий для каждой задачи, иначе даже тривиальный вопрос может спровоцировать десятки поисков.
- Пишите инструкции, которые будут подробными и самодостаточными, поскольку подагент не может видеть контекст своего родителя.
Чекпоинты и надежность
Агенты, работающие длительное время, могут сбоить на середине выполнения из-за сбоев, ограничений по частоте запросов и перезагрузок. В производственных средах используется механизм чекпоинтов, сохраняющий информацию о ходе выполнения, списке задач и результатах работы инструментов, что позволяет возобновить выполнение с того же момента, а не начинать заново. Это сфера деятельности надежных движков рабочих процессов, и несколько фреймворков для агентов разрабатываются непосредственно на основе таких технологий.
Evals — набор тестов для среды управления
Поведение агента имеет вероятностный характер, поэтому инструкция, которая сработает в понедельник, может не сработать во вторник. Сильные команды используют набор инструментов для оценки, включающий от десятков до тысяч реалистичных задач, результаты которых можно автоматически проверять. Прошли ли тесты, был ли найден правильный ответ, осталась ли стоимость в рамках бюджета? Изменения в инструкциях, новые инструменты и замена моделей проходят проверку через этот набор перед выпуском. Он выполняет ту же функцию, что и CI/CD в других системах, и его игнорирование означает работу без соответствующих инструментов.
Использование компьютера — финальный экзамен
На передовой агентам предоставляют экран, клавиатуру и мышь, что позволяет им запускать любые приложения, независимо от наличия у них API. Это увеличивает сложность всех предыдущих проблем: скриншоты потребляют огромное количество токенов, поэтому контроль контекста должен быть строгим; неверный клик может причинить серьезный ущерб, поэтому разрешения ужесточаются; а верификация подразумевает фактическое просмотрение экрана после каждого шага.
Как известные системы применяют эти идеи
Claude Code — инструмент для программирования. Это компактный пример хорошего дизайна. Набор инструментов небольшой, но функциональный: он включает чтение, запись и редактирование файлов, выполнение команд оболочки и поиск кода, без сотен мелких инструментов. Верификация занимает центральное место: программа запускает компиляторы, инструменты проверки кода и тесты, а также повторяет попытки при их неудаче. Файл с инструкциями к проекту выполняет роль памяти. Ничто из этого не является возможностью модели, и именно поэтому внутри нее та же модель ведет себя иначе.
Продукты глубоких исследований — это инструменты для исследований. Инструменты, разработанные крупными лабораториями, превращают запрос в автономное исследование, продолжающееся несколько минут, и в итоге формируют отчет с ссылками на источники. Особенностью этих инструментов является заранее составленный план исследования, который иногда представляется на утверждение, что позволяет вовлечь человека на самом раннем этапе, до начала дорогостоящей работы. Механизмы поиска анализируют результаты, выявляют пробелы и продолжают поиск, а метаданные о цитатах передаются вместе с фактами на всех этапах обработки.
Manus и школа проектирования контекста. Команда Manus опубликовала необычайно откровенные заметки о внутреннем устройстве инструмента непосредственно перед его выпуском в 2025 году, и несколько из этих положений получили широкое распространение. Рассматривайте кэш KV как ограничение конструкции: сохраняйте структуру входного запроса неизменной (без временных меток в начале системного запроса), поскольку количество токенов входных данных может значительно превышать количество токенов выходных данных. Избегайте добавления или удаления инструментов во время сессии, так как это делает кэш недействительным и сбивает модель с толку, когда в предыдущих запросах упоминаются исчезнувшие инструменты; сохраняйте список инструментов неизменным и маскируйте те, которые в настоящее время недоступны для выбора.
Курсор и среда разработки IDE. Редактор, ориентированный на ИИ, отражает иной подход к глубокой интеграции с окружением. Он использует семантический индекс кодовой базы для быстрого поиска, сохраняет изменения в виде различий, подлежащих проверке, чтобы человек, утверждающий слияние, выполнял функцию модели разрешений, маскируемую под интерфейс; кроме того, он запускает фоновые агенты на отдельных ветках и возвращает результаты инструментов проверки кода и типов обратно в цикл обработки. Те же семь компонентов присутствуют, но в другом исполнении.
Специалисты поддержки в компаниях, где ключевым фактором является соблюдение нормативов. Сотрудники, работающие непосредственно с клиентами, меняют приоритеты: важнее избегать неправильных действий, чем просто обладать необходимыми возможностями. Поэтому они опираются на определенные правила: рабочий диапазон ограничен утвержденными знаниями, действия проверяются согласно схемам бизнес-систем (суммы возвратов ограничены, сначала подтверждается личность), при низком уровне уверенности обязательно передается задача другим специалистам, а также ведутся полные журналы аудита. В регулируемых секторах такие правила фактически являются самим продуктом.
Существующие фреймворки и инструменты
В наши дни редко создаются решения исключительно на основе простых API-запросов. Вот распространенные варианты, условно разделенные по подходам:
- Claude Agent SDK. Инструментарий, лежащий в основе Claude Code; представлен в виде библиотеки с встроенными циклами, инструментами, подагентами, механизмами разрешений и функциями сжатия данных. Идеален для быстрого создания серьезных агентов на платформе Claude.
- OpenAI Agents SDK. Легковесные инструменты для агентов, передачи задач, ограничений, сессий и отслеживания. Идеально подходит для многопроцессных приложений в экосистеме OpenAI.
- LangGraph. Агенты как явные машины состояний с возможностью сохранения состояния, прерываний с участием человека и надежной работы. Отлично подходит для сложных, контролируемых долгосрочных рабочих процессов.
- CrewAI. Команды на основе ролей, такие как исследователи и авторы. Подходит для быстрой разработки прототипов с участием нескольких агентов и создания потоков обработки контента.
- AutoGen, AG2 и Semantic Kernel. Многопроцессная работа, ориентированная на диалог, которая трансформируется в корпоративные инструменты. Идеально подходит для проектов на .NET и Azure, а также для исследовательских экспериментов.
- smolagents. Минималистичная библиотека, в которой агенты пишут код в качестве своих действий. Подходит для гибких решений с использованием открытых моделей.
- Pydantic AI. Агенты с типобезопасностью и схемами во главе, обеспечивающие проверку результатов. Идеально подходит для команд на Python, требующих строгой типизации.
- Vercel AI SDK. Примитивы на основе TypeScript с возможностью управления циклами агентов. Лучший выбор для инженеров веб-приложений и продуктов в экосистеме JavaScript.
Вокруг этих инструментов существует вспомогательная инфраструктура: MCP для стандартных инструментов, платформы для отслеживания и оценки, мощные движки выполнения и провайдеры сандбоксов для безопасной эксплуатации кода.
Совет по выбору: при обучении напишите самостоятельно простой цикл с использованием API модели, цикла while и двух инструментов примерно из ста строк. После этого ни один фреймворк не покажется волшебством, что и является целью. При выпуске продукта выберите фреймворк, ближайший к вашему поставщику моделей и языку, и потратите сэкономленное время на то, чего не может предоставить ни один фреймворк — а именно на ваши собственные инструменты, механизмы оценки и правила безопасности.
# The whole idea, in miniature
while not done:
response = model.generate(context, tools) # model decides
if response.tool_calls:
results = execute(response.tool_calls) # harness acts (safely!)
context = manage(context + results) # harness curates memory
else:
done = verify(response) # harness checks the work
Виды сбоев
Вот типичные способы сбоев агентов, каждый из которых сопровождается соответствующим решением:
- Ухудшение контекста. Окно постепенно заполняется устаревшими результатами работы инструментов, качество снижается, и через несколько часов цель забывается. Решение: компактизация информации, ведение записей и периодическое повторение цели.
- Циклы безвыходности. Одна и та же неэффективная команда повторяется бесконечно, при этом каждая попытка стоит несколько центов. Решение: обнаружение циклов, установление лимитов на количество итераций и принудительное изменение стратегии.
- Чрезмерное количество инструментов. При наличии сорока похожих инструментов модель выбирает неподходящий в самый неподходящий момент. Решение: использование меньшего набора более эффективных инструментов с четкими описаниями.
- Вставка промптов. Текст на веб-странице или в электронном письме указывает агенту игнорировать его инструкции и выгружать базу данных, и поскольку агент не может по своей природе разделять данные и команды, он может подчиниться. Решение: фильтрация входных данных, инструменты с минимальными привилегиями, песочницы и утверждение человеком важных действий; многократные меры защиты, поскольку ни одна из них не является надежной.
- Ложное завершение. Агент сообщает о успехе, хотя работа еще не завершена. Решение: проверять результаты с помощью независимого источника и не позволять агенту самостоятельно ставить отметку о завершении работы.
- Чрезмерные расходы. Работа нескольких агентов может тайно увеличить счет во много раз. Решение: установление бюджетов, оптимизация маршрутизации, кэширование и тщательная оценка того, хватило бы ли одного способного агента.
- Незаметное изменение функционала. Обновление модели меняет её поведение, и подсказки, настроенные для более ранней версии, перестают работать. Решение: запускать набор тестов после каждого изменения.
Что стоит запомнить
Модель обеспечивает интеллект, а механизм преобразует его в практическую деятельность. Механизм состоит из цикла и семи компонентов: постоянных правил, инструментов, управления контекстом, памяти, ограничений, проверки и возможности наблюдения. Вокруг них существуют шаблоны для выполнения длительных задач, такие как планирование, действие и проверка, сжатие данных, контрольные точки, подагенты и тестирование. Большинство сбоев агентов связаны с неисправностями механизма, а большинство улучшений — с улучшениями этого механизма. Поэтому, когда агент работает недостаточно хорошо, сначала проверьте структуру механизма, а уже затем меняйте модель.
Связанные материалы
- Практическое применение сабагентов: роли, бюджеты, запреты и скрытые сбои — Как создавать надежных сабагентов Claude Code: роли, файлы передачи данных, состояние выполнения, бюджеты, механизмы блокировки, проверки на скрытые сбои, а также дополнительные компоненты вроде Copilot shim, на примере агентов, используемых в десятках репозиториев.
- Агентные аналитические системы — это нечто большее, чем просто текст в формате SQL: уроки от Anthropic — Что говорит статья Anthropic о самообслуживающихся аналитических системах относительно семантических слоев, навыков, методов оценки и основ данных, и почему один лишь формат текста в SQL создает ложное впечатление точности.