Harness engineering: как сделать ИИ-агента управляемым

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

Эту работу часто называют harness engineering — инженерией агентной обвязки. Harness здесь не просто промпт или набор подключённых инструментов. Это окружающая модель система: инструкции, инструменты, исполнение, состояние и память, правила доступа, проверки, ограничения ресурсов и обратная связь. В публикациях LangChain формула описывается кратко: агент — это модель плюс harness. Практический смысл в том, что одна и та же модель может показывать разные результаты в зависимости от того, как устроена система вокруг неё.

Обвязка — это система исполнения, а не только системный промпт

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

Инструменты предоставляют агенту конкретные возможности: например, найти запись, создать черновик или отправить сообщение. Сама модель выбирает, какой инструмент вызвать и с какими аргументами; среда исполнения проверяет вызов, передаёт его инструменту или MCP-серверу, получает результат и возвращает его агенту. Harness также может управлять состоянием между шагами, временем выполнения, повторами, логированием и условиями остановки.

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

Контекстная инженерия помогает агенту ориентироваться в задаче

Длинная инструкция не обязательно делает агента компетентнее. Ему нужны нужные сведения в нужный момент: цель, критерии готовности, ограничения, структура среды, доступные инструменты и способ проверить результат.

Для долгих задач обвязка может сокращать историю диалога, сохранять промежуточное состояние во внешнем хранилище, выделять отдельные контексты для подзадач или подгружать справочные материалы по запросу. Такую работу называют context engineering. Она входит в более широкую задачу разработки harness: решить, что модель должна знать сейчас, как получить эту информацию и как не потерять важное состояние между шагами.

Например, coding-агенту мало сказать «исправь ошибку». Полезно дать ему описание ожидаемого поведения, нужные файлы, правила проекта, команды тестирования и точный способ проверить, что исправление работает. Тогда часть контекста становится проверяемой, а не только текстовой рекомендацией.

Нужны и упреждающие правила, и обратная связь

Биргитта Бёкелер описывает два дополняющих механизма контроля. Упреждающий контроль (feedforward) направляет поведение до действия: инструкции, ограничения инструментов, доступы, архитектурные правила, примеры и критерии готовности. Контроль по обратной связи (feedback) проверяет результат после действия и сообщает, что нужно исправить: тесты, линтеры, проверки схемы, анализ журналов, рецензия человека или измерение результата.

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

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

Ограничения ресурсов помогают вовремя остановиться

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

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

Как улучшать обвязку на практике

Начинать можно с одного конкретного процесса и небольшой контрольной выборки. Опишите ожидаемый результат и ошибки, которые особенно дороги. Дайте агенту только нужные инструменты и права. Добавьте контекст и критерии проверки результата. Ограничьте время, число действий и допустимый расход. Сохраняйте трассы: вход, решения, вызовы инструментов, результаты проверок и ошибки. Разберите неудачные запуски и внесите точечные изменения; затем проверьте, улучшились ли результаты на новых примерах.

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

Вывод: надёжность агента проектируют вокруг модели

Harness engineering — это инженерная работа над всей системой, которая превращает языковую модель в агента для конкретной задачи. В неё входят контекст, инструменты и их исполнение, состояние, права, проверки, наблюдаемость, лимиты и обратная связь.

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

Материалы для дальнейшего изучения

Martin Fowler: Harness engineering for coding agent users — упреждающий контроль, обратная связь и роль человека: https://martinfowler.com/articles/harness-engineering.html

LangChain: Improving Deep Agents with harness engineering — контекст, самопроверка, трассы и бюджеты в агентной системе: https://www.langchain.com/blog/improving-deep-agents-with-harness-engineering

LangChain: The Anatomy of an Agent Harness — состав harness и его роль вокруг модели: https://www.langchain.com/blog/the-anatomy-of-an-agent-harness

Philipp Schmid: The importance of Agent Harness in 2026 — взгляд на длительные агентные задачи и управление контекстом: https://www.philschmid.de/agent-harness-2026

Heeki Park: Building an agent harness — пример конфигурации инструментов, MCP и памяти: https://heeki.medium.com/building-an-agent-harness-31942331d605