Course
Идея не нова. Разработчики годами строили обёртки, каркасы и среды выполнения вокруг моделей. Термин получил распространение после того, как сооснователь HashiCorp Митчелл Хашимото использовал выражение "harness engineering" в феврале 2026 года в блоге о своём рабочем процессе с ИИ. Смысл был простой: когда агент допускает ошибку, измените среду так, чтобы эта ошибка больше не могла повториться. В ту же неделю OpenAI подхватила термин для своей работы над Codex, а LangChain продолжил в том же ключе.
В этой статье я объясню, что такое agent harness, зачем он нужен ИИ-агентам, чем он отличается от фреймворков и рантаймов и какие инструменты разработчики используют для построения подобных систем.
Что такое Agent Harness?
Одно из определений даёт LangChain: "Если вы не модель, вы — harness". На практике agent harness — это программное окружение вокруг языковой модели: инструменты, память, состояние, исполнение, предохранители и наблюдаемость.
Агент = Модель + Harness
Модель рассуждает. Harness даёт этим рассуждениям место для действий, памяти, проверки результатов и следования правилам.

Модель внутри своего рабочего agent harness. Изображение автора.
Эта формула полезна, но это ментальная модель, а не отраслевой стандарт. Некоторые вендоры по-прежнему используют «harness», «framework» и «scaffold» почти как синонимы.
Почему ИИ-агентам нужен harness
Голая языковая модель ограничена при выполнении многошаговой работы. Она сама по себе не хранит устойчивое состояние, не запускает инструменты, не управляет растущим контекстом и не восстанавливается после неудачных вызовов инструментов без посторонней помощи.

Представьте агента, которому поручили исправить падающий тест в проекте на Python. Без harness модель может написать что-то похожее на исправление, но она не сможет прочитать фактический файл теста, запустить pytest, увидеть реальную ошибку, отредактировать проблемную функцию или подтвердить, что исправление прошло. С harness весь этот цикл превращается в несколько минут автономной работы агента, а каждый шаг где-то записывается для проверки человеком.
Тем не менее, совет Anthropic остаётся в силе: начните с максимально простого подхода и добавляйте сложность только тогда, когда задача действительно этого требует.
Из чего состоит agent harness
Компоненты различаются, но большинство используют одни и те же строительные блоки. Воспринимайте их как чек-лист, а не жёсткую спецификацию. Небольшому агенту нужны лишь некоторые элементы, а производственному — больше.
Системные промпты и правила поведения
Обычно именно harness управляет базовыми инструкциями для модели. Это включает системный промпт, а также правила проекта, стандарты кодирования, ролевые ограничения и политики безопасности. В Deep Agents от LangChain, например, файл AGENTS.md может задать базовые правила до начала задачи.
Некоторые harness в 2026 году используют прогрессивное раскрытие инструкций. Вместо загрузки полных описаний инструментов в контекст на старте, harness добавляет лишь сводку доступных возможностей. Полные инструкции для инструмента загружаются только тогда, когда модель действительно собирается его использовать.
Инструменты: как агенты взаимодействуют с миром
Инструменты позволяют агенту делать больше, чем просто генерировать текст. Частые примеры: веб-поиск, чтение и запись файлов, запросы к базам данных, вызовы API, действия в браузере, выполнение кода и команды терминала. Harness управляет тем, какие инструменты доступны, когда модели разрешено их вызывать и как результаты форматируются и возвращаются в контекст агента.
Model Context Protocol (MCP) к 2026 году стал стандартным интерфейсом для этого. Многие harness, включая Anthropic Agent SDK, LangChain Deep Agents и OpenAI Agents SDK, используют MCP для подключения внешних серверов инструментов без написания индивидуальной интеграции для каждого.
Память и состояние
Агентам нужно помнить, что происходило ранее в задаче. Harness может хранить краткосрочное состояние в активном диалоге и долгосрочное — в файлах, логах, сводках или сохранённых настройках. Некоторые harness также сжимают длинную историю до коротких сводок, чтобы модель не тащила весь массив деталей в контексте.
Среда выполнения: где агент запускается и действует
Многим полезным агентам нужно реальное место для работы. Это может быть файловая система, контейнер, изолированный терминал, экземпляр браузера или облачный рантайм. Без управляемой harness среды выполнения вызовам инструментов попросту некуда приземлиться.
Сейчас многие harness используют изолированные контейнеры-песочницы: краткоживущие окружения в рамках одной сессии, очищаемые по завершении задачи, чтобы записи файлов, установленные пакеты и сетевые вызовы из одной задачи агента не протекали в другую.
Оркестрация и планирование
Некоторые задачи не укладываются в прямую цепочку шагов. Harness может предоставить инструмент планирования, который разбивает цель на подзадачи и отслеживает их статус. Он также может порождать субагентов для решения отдельных частей работы и возвращать в главный агент лишь сводки.
Например, LangChain Deep Agents отслеживает шаги плана в файле на файловой системе, помечая каждый шаг как выполненный по мере продвижения задачи.
Предохранители и разрешения
Именно в harness задаются правила: одобрение человеком, блокировка отдельных вызовов инструментов, ролевые разрешения и проверки выходных данных. OpenAI Agents SDK, LangChain Deep Agents и Microsoft Agent Framework поддерживают такой контроль. Более безопасная схема — по отдельности проверять вход, выход и права на инструменты.
Наблюдаемость и трейсинг
Когда пятидесятишаговая задача падает на тридцать седьмом шаге, трейс показывает, что произошло. Трейсинг записывает вызовы модели, вызовы инструментов, передачи, ошибки, задержки и стоимость за весь прогон. В OpenAI Agents SDK трейсинг включён по умолчанию. LangSmith добавляет отладочные и оценочные панели. OpenTelemetry стал стандартом экспорта трейсов в независимом от вендора формате, чтобы вы не были привязаны к одному инструменту наблюдаемости.
Agent Harness vs. Framework vs. Runtime: в чём разница?
Этот вопрос возникает часто, и ответ сложнее, чем обещают многие обзоры. Таксономия полезна, но не фиксирована.

Три слоя, абстракция растёт снизу вверх. Изображение автора.
Начну с фреймворка, поскольку многие разработчики уже работали с одним из них.
Что такое агентный фреймворк?
Агентный фреймворк даёт разработчикам строительные блоки для создания агентов. Он покрывает вызовы модели, определение инструментов, шаблоны памяти и структуру агентного цикла. Примеры: ранний LangChain, CrewAI и Google ADK. Фреймворк подсказывает, как структурировать агента, но не всегда — как надёжно запускать его в продакшене.
Что такое агентный рантайм?
Агентный рантайм — это слой, который помогает агенту стабильно работать со временем. Он обеспечивает устойчивое исполнение, сохранение состояния, повторы, шаги с участием человека и стриминг. LangGraph, Temporal и Inngest — примеры. Харрисон Чейз предложил такую аналогию: если Node.js — это рантайм, а Express — фреймворк, то harness похож на Next.js.
Чем отличается harness?
Harness — это более высокий уровень, чем фреймворк. Фреймворк даёт компоненты, а harness обычно приходит с уже принятыми решениями: инструменты, планирование, доступ к файловой системе и управление контекстом.
Сценарии применения agent harness: код, исследования, данные и энтерпрайз
Те же строительные блоки встречаются в очень разных задачах, но меняются пропорции. И кодирующий агент, и агент для бизнес-процессов нуждаются в harness, но нагружают разные его части. Эти категории — не формальные стандарты, а практичный способ увидеть, как одна и та же идея подстраивается под конкретную работу.
Harness для кодирующих агентов
Кодирующие агенты — хороший актуальный пример, поскольку harness здесь нагляден. Чтобы приносить пользу в коде, агенту нужны доступ к файлам, контекст git, выполнение в терминале, запуск тестов, установка зависимостей и правила проекта. Claude Code и Codex — примеры такого подхода: оба опираются на значительный слой harness-кода, а не на голый API модели.
Разница между хорошим и посредственным harness для кода обычно проявляется в мелочах: как он восстанавливается после неудачного теста, умеет ли откатывать плохое изменение, насколько аккуратно открывает модели историю git. Именно в этих деталях и сосредоточено большинство инженерных усилий.
Harness для исследовательских агентов
Исследовательским агентам нужен иной набор инструментов: веб-поиск, отслеживание источников, ведение заметок, управление цитированием и суммирование. Harness управляет тем, как хранятся результаты поиска, как атрибутируются источники и как длинные документы режутся на фрагменты и выносятся за пределы контекстного окна, чтобы не съедать его целиком.
Harness для анализа данных
Агентам для данных нужны доступ к наборам данных, SQL-базам, средам выполнения Python и контекст по схемам, чтобы понимать доступные таблицы и столбцы до написания запросов. Harness также проводит границы разрешений, что важно, когда агент может взаимодействовать с продукционными данными.
Harness для корпоративных процессов
В корпоративных внедрениях добавляется ещё один слой требований: аутентификация, аудиторские логи, процессы одобрения, ролевой доступ и интеграции с внутренними системами. AWS AgentCore — один из управляемых примеров этой категории, с включённой идентификацией, VPC-сетями и наблюдаемостью. Microsoft Agent Framework покрывает схожие потребности для команд в Azure или .NET.
Инструменты для построения agent harness в 2026 году
К середине 2026 года чаще всего упоминаются несколько продуктов. Они располагаются в разных точках спектра «фреймворк — рантайм — harness», и границы всё ещё смещаются.
LangChain Deep Agents
LangChain Deep Agents — это открытый harness от LangChain, построенный на LangGraph как на рантайме. Поставляется с инструментом планирования, виртуальной файловой системой, порождением субагентов, автоматическим сжатием контекста и промежуточным ПО для согласования человеком и обнаружения PII. Он модельно-агностичен, поддерживает совместимые с OpenAI эндпоинты и подключается к провайдерам песочниц, включая Modal, Runloop и Daytona, для исполнения кода.
Anthropic Agent SDK
Anthropic Agent SDK (имя пакета: claude-agent-sdk) был выделен из Claude Code и выпущен как самостоятельное решение. Включает встроенный агентный цикл, инструменты для выполнения bash, чтения и записи файлов, веб-поиска, интеграцию MCP и сжатие контекста. Работает только с моделями Claude через API Anthropic, Amazon Bedrock, Vertex AI и Azure.
OpenAI Agents SDK
Как я уже упоминал, OpenAI Agents SDK со временем перешёл от фреймворка к harness по мере расширения функциональности. Релиз апреля 2026 добавил нативное выполнение в песочнице, сжатие памяти и инструменты для файловой системы. Доступен на Python и TypeScript, поддерживает использование инструментов, передачу между агентами и предохранители.
Google Agent Development Kit
Google ADK поддерживает оркестрацию мультиагентных систем с готовыми классами для последовательных, параллельных и циклических структур. Включает инструменты для оценки, работает с Vertex AI для управляемого деплоя и поддерживает MCP для подключения инструментов. Доступен на Python, Java, TypeScript и Go, оптимизирован под Gemini, но заявлен как модельно-агностичный.
Microsoft Agent Framework
Microsoft Agent Framework — текущий путь миграции Microsoft для проектов AutoGen. Поддерживает Python и .NET, работает с сервисами Azure AI и включает поддержку MCP для подключения инструментов.
CrewAI
CrewAI использует ролевой подход к мультиагентным системам. Вы определяете агентов с конкретными ролями, назначаете задачи, собираете «команды» и декларативно настраиваете память и предохранители. Подходит для задач, которые естественно ложатся на команду специалистов.
Temporal и Inngest
Это сами по себе не harness. Это платформы устойчивого выполнения, которые обеспечивают работу, когда задача агента должна идти часами или днями без потери состояния. При сбое движок воспроизводит с последней успешной контрольной точки, а не начинает заново.
Проблемы и компромиссы Agent Harness
Добавляя harness, вы расширяете возможности системы, но каждый новый инструмент, разрешение и агент — это ещё один потенциальный источник сбоев. По мере удлинения задач предохранители, трейсинг и устойчивое состояние перестают быть опцией и становятся главным, что делает длительный прогон восстанавливаемым.
Есть и риск связности, о который команды часто спотыкаются. LangChain сообщил о росте на 10–20 пунктов на подмножестве tau2-bench после добавления модель-специфичных профилей harness. Artificial Analysis сделал похожий вывод в своём индексе кодирующих агентов: результаты зависят от модели и harness вместе, а стоимость, токены и время на задачу сильно меняются в разных сочетаниях. Модель не менялась. Менялись окружающие промпты, инструменты и промежуточное ПО. Этот профиль — тоже работа harness.
А нужен ли вам вообще agent harness?
Вот прямой способ понять, нужен ли он вам.
Скорее всего, он нужен, если ваша система отвечает одному или нескольким условиям:
- Нужно использовать внешние инструменты
- Нужно помнить прогресс между сессиями
- Нужно выполнять код в реальной среде
- Нужно координировать несколько агентов
- Нужно восстанавливаться после частичных сбоев без потери работы
- Требуется одобрение человеком
Скорее всего, harness не нужен, если задача — предсказуемый процесс с заранее определёнными шагами.
Полезный тест: если задачу можно решить одним вызовом модели или небольшим детерминированным скриптом с несколькими условными операторами, harness, вероятно, избыточен. Как только задача требует, чтобы агент принимал решения, использовал инструменты и реагировал на результаты со временем, harness начинает выполнять реальную работу.
Распространённый паттерн: команды тянутся к harness слишком рано, строя трейсинг и песочницу для по сути одношаговой генерации текста. Обратная ошибка куда болезненнее: выпускать модель напрямую, а затем на втором упавшем тесте, третьем вызове инструмента или пятом рестарте понимать, что никакой инфраструктуры для отката нет.
Заключение
Как уже говорилось, вендоры используют разную терминологию, и границы между фреймворком, рантаймом и agent harness по-прежнему смещаются.
Для одноразовой генерации обёртка избыточна. Для агентов, которым нужно действовать, помнить и восстанавливаться в течение длительных сессий, agent harness становится ключевой частью системы. Выбор подходящего harness всё чаще — отдельное решение от выбора модели. Любопытно, какую часть этого слоя следующее поколение моделей возьмёт на себя, поскольку некоторые шаги OpenAI и Anthropic намекают, что границы будут и дальше смещаться. Базовая идея остаётся прежней: агент — это модель плюс agent harness.
Если хотите глубже разобраться в построении агентных систем, наш курс Building Scalable Agentic Systems охватывает паттерны использования инструментов, оркестрации и долгоживущих агентных процессов.
Вопросы и ответы об Agent Harness
В чём разница между agent harness и системным промптом?
Системный промпт — это один из входов, который агент читает в начале. Agent harness — более широкий слой, управляющий инструментами, состоянием, правами и обработкой сбоев. Самая простая формулировка, которую я нашёл: системный промпт говорит модели, что делать, а agent harness контролирует, что она может делать. Можно иметь отполированный системный промпт и не иметь harness — в итоге это всё равно без状態вый вызов API. Agent harness — это то, что превращает промпт в систему.
Могу ли я построить собственный agent harness с нуля?
В принципе, да. В простейшем виде harness — это цикл: вызвать модель, распарсить ответ, выполнить её вызовы инструментов, вернуть результаты, повторить. Такой цикл можно написать за пару десятков строк Python за один день. Сложности начинаются после цикла: переполнение контекста, неудачные вызовы инструментов, потеря состояния при рестартах, соблюдение прав и трейсинг. На практике эта «послециковая» работа всегда занимает больше времени, чем планируют команды, поэтому открытые harness-проекты растут, а не худеют.
Знает ли модель, что она внутри harness?
Неявно — нет. Некоторые harness сообщают модели о доступных инструментах через системный промпт, но у модели нет представления о harness как о системе вокруг неё. Она видит лишь предоставленный контекст, генерирует ответ и иногда формирует вызов инструмента. Следствие: когда что-то ломается, модель часто не может объяснить почему, потому что не знает о существовании harness. Отладка агента в основном оказывается отладкой harness, а не самой модели.
Как выбор модели влияет на выбор harness?
Больше, чем обычно ожидают. Передовые модели для кодирования иногда дообучают с собственным harness в цикле, поэтому замена на другой harness может оставить часть эффективности на столе. Практическая эвристика: если команда привязана к одному семейству моделей, короткий список harness обычно определяется сам собой. Сложнее — сменить модель позже: это чаще означает переписать логику harness, а не просто поменять значение в конфиге.
Отличается ли это от того, что раньше называли «LLM scaffolding»?
Не особо. Это та же идея под новым именем. «LLM scaffolding», «agent wrapper» и «execution environment» указывают в одном направлении. Тонкий сдвиг 2026 года в том, что «scaffolding» подразумевает временную конструкцию, которую снимают, когда модель достаточно хороша, а «agent harness» — то, что модель сохраняет вокруг себя. Это меняет бюджетирование: scaffolding удаляют, а agent harness становится частью системы.