Представьте обычное рабочее поручение: нужно подготовить понятную статью для новичка с опорой на несколько источников. Языковая модель умеет составлять и редактировать текст, но сама по себе она не открывает ссылки, не сохраняет черновики в папку проекта и не помнит при следующем запуске, на каком шаге остановилась вчера. Чтобы поручение превратилось в готовый материал, вокруг модели выстраивают рабочую среду, которая связывает её ответы с реальными действиями: чтением документов, записью промежуточных заметок, проверкой результата и переходом к следующему шагу. В англоязычных материалах такую систему вокруг модели называют harness (по-русски её обычно называют обвязкой), а работу над её устройством и правилами называют harness engineering.
Это определение обобщает инженерные подходы из публикаций OpenAI и LangChain, а не задаёт единый обязательный стандарт. Сама история с подготовкой статьи ниже служит нашим условным сквозным примером. Проследим по шагам, как поручение проходит путь от первой инструкции до проверенного текста, и посмотрим, в какой момент вокруг модели появляются элементы обвязки.
Как модель получает доступ к источникам и действиям
Начнём с исходного поручения: объяснить незнакомый термин человеку без технической подготовки и опереться на выбранные статьи. Человек формулирует эти требования и передаёт их модели. Получив задачу, модель может определить разумный первый шаг и предложить прочитать первый источник по ссылке. Однако внутри самого ответа модели чтение ещё не произошло: она лишь сформировала запрос на действие, а текст внешней страницы ей пока недоступен.
Чтобы прочитать страницу на самом деле, нужна внешняя программа, способная открыть документ или получить текст по адресу и извлечь его содержимое. В системах вокруг ИИ такие подключаемые программы и функции называют инструментами (tools). Работа строится в три приёма:
- Модель в своём ответе предлагает вызвать подходящий инструмент и указывает, какой именно источник нужно открыть.
- Окружающая программа принимает это предложение, сама запускает инструмент чтения и получает текст материала.
- Система заново обращается к модели и передаёт ей прочитанный текст вместе с исходной задачей.
Только после третьего шага материал действительно оказывается перед моделью. При этом сам факт успешного срабатывания инструмента подтверждает лишь то, что текст был получен технически. Насколько точно модель поняла прочитанное и не исказила ли она мысль авторов при пересказе, предстоит проверять отдельно.
Когда источник получен, встаёт вопрос о том, что именно модель видит в момент очередного обращения к ней. Всю совокупность сведений, переданных модели в текущем вызове, называют контекстом. В нашем примере туда входят исходное поручение, требования к стилю статьи и только что прочитанный текст источника. Как отмечают авторы инженерного материала Anthropic о работе с контекстом, контекст не сводится к одной стартовой инструкции: он включает описание доступных инструментов, внешние материалы и историю шагов, а его состав приходится обновлять по мере продвижения задачи.
Теперь у модели есть текст первого источника, и она может составить по нему выписку или черновой раздел. Но если источников несколько, а работа прервётся или потребует нескольких обращений, нужно понять, как не потерять уже сделанные наработки между вызовами.
Как продолжить работу между шагами и не потерять наработки
Прочитав первый материал, модель составляет краткий конспект с важными тезисами. Чтобы не держать все черновики только внутри одного диалога, окружающая система использует инструмент записи и сохраняет конспект в отдельный файл. Так в проекте появляется промежуточный результат — рабочая заметка. Одновременно система может отдельно зафиксировать этап, на котором сейчас находится поручение: например, записать, что первый источник прочитан, заметка сохранена, а остальные материалы ещё предстоит разобрать. В инженерной практике такую фиксацию текущего этапа и выполненных шагов называют состоянием (state) задачи. Заметка хранит само содержание работы, а запись о состоянии помогает системе и человеку понимать, что уже сделано и какой шаг должен быть следующим.
Различие между хранением файла и текущей работой модели особенно заметно, когда подготовку статьи продолжают в новой сессии или после паузы. Сам по себе файл с заметкой, лежащий на диске, автоматически не попадает в следующий вызов модели. Чтобы модель продолжила статью с учётом вчерашних выводов, окружающая программа перед новым вызовом должна прочитать сохранённую заметку, свериться с текущим состоянием задачи и явно включить эти сведения в новый контекст.
На эту разницу обращают внимание инженеры Anthropic в статье об обвязках для длительно работающих агентов: для продолжения работы между сессиями системе нужны сохранённые рабочие материалы и понятная запись о состоянии задачи, а простое сжатие длинной переписки само по себе не заменяет такой организации. Таким образом, запись результата в файл и подача этого файла обратно в контекст при следующем вызове представляют собой две разные задачи обвязки.
Когда заметки по источникам собраны и переданы модели, она соединяет их и пишет полный черновик статьи. Текст составлен, но прежде чем считать поручение выполненным, остаётся выяснить, отвечает ли этот черновик исходной задаче человека.
Как проверяют результат и управляют ходом работы
Готовый черновик статьи возвращается на проверку. Даже если модель сопроводила ответ сообщением о том, что все требования учтены, такое заявление не заменяет чтения самой статьи. В нашем примере человек открывает текст и проверяет его по сути поручения: поймёт ли объяснение читатель, который впервые видит термин, и действительно ли утверждения опираются на прочитанные источники, а не додуманы по ходу пересказа.
Допустим, при чтении выясняется, что во втором разделе появилось специальное понятие без пояснения, а один из выводов приписан источнику неточно. Человек записывает это замечание, и система передаёт его модели в следующем вызове вместе с черновиком. Сведения о том, что именно в результате оказалось удачным или ошибочным, служат обратной связью (feedback). Опираясь на неё, модель правит проблемный абзац, после чего текст снова проходит оценку. Когда замечаний не остаётся, задачу можно завершать.
Чтобы работа не перескакивала через проверку к публикации или финальному отчёту, в обвязке задают правила переходов между этапами. Здесь важно различать четыре разных механизма, которые на первый взгляд легко спутать:
- Текстовое правило в инструкции. В промпте можно написать: «Не переходи к следующему этапу, пока человек не одобрит черновик». Это ориентир для модели, но модель может ошибиться и проигнорировать строчку текста.
- Техническая возможность и право на действие. Наличие у системы инструмента записи даёт физическую возможность изменить файл, а настройки доступа определяют, разрешено ли вызывать этот инструмент на текущем шаге.
- Программная блокировка. Окружающая программа может сама проверять условие перед выполнением шага: например, искать в данных задачи отметку о согласовании и просто не запускать следующий этап, пока такой отметки нет.
- Человеческая оценка по существу. Человек или специально организованная проверка содержания оценивает, действительно ли статья отвечает на вопрос читателя. Проверка наличия отметки о согласовании сама по себе не оценивает качество текста.
Для наблюдения за тем, какие инструменты вызывались и на каком шаге возникла заминка, система может вести журнал действий. А если нужно автоматически запускать вспомогательную процедуру строго в определённый момент, например перед сохранением файла или при смене этапа, в код обвязки иногда добавляют привязанные к событиям обработчики — hooks (хуки). Ни подробные журналы, ни хуки не являются обязательной частью любой обвязки: их подключают тогда, когда этого требует конкретный рабочий процесс.
Описанная цепочка от чтения источника до проверки черновика показывает работу обвязки целиком. При этом любая обвязка лишь организует среду вокруг модели и работу с её ответами, но не делает любой вывод истинным и не отменяет зависимости от качества самой модели. Теперь, когда весь механизм перед глазами, разберёмся, как harness engineering соотносится со смежными понятиями — работой над промптом и работой над контекстом.
От поручения к оценке текста
Поручение и требования: объяснить термин новичку с опорой на источники
Доступная информация первого вызова
-
Модель предлагает прочитать источник
Первый вызов. Источник ещё не прочитан.
Система вызывает инструмент
-
Инструмент читает источник
Полученный материал возвращается системе
-
Система передаёт полученный материал в контекст
Контекст — информация текущего вызова.
Следующий вызов
-
Модель готовит текст
Та же модель, другой вызов.
Можно сохранить инструментом записи
Сохранённые заметки и сведения об этапеЗаметки — содержание; этап — состояние работы.
К шагу 3. Для продолжения: прочитать нужное и передать модели.
Сохранённый файл ещё не означает, что его содержание передано модели.
Подготовленный текст
-
Человек оценивает текст
- Подходит — завершить
- Нужны исправления — передать замечания в следующий вызов
Через шаг 3: система передаёт замечания в контекст.
Чем harness engineering отличается от работы с промптом и контекстом
При настройке систем с ИИ часто встречаются три выражения: prompt engineering, context engineering и harness engineering. Проще всего различить их по тому, что именно мы меняем в нашем примере с подготовкой статьи и как это сказывается на работе.
В материале Anthropic о контекстной инженерии промптами называют инструкции, которые задают модели задачу и правила ответа, а работой с контекстом — подбор и обновление всей информации, попадающей в очередной вызов модели (включая внешние материалы, инструменты и историю сообщений). В свою очередь, авторы LangChain рассматривают harness как более широкую систему вокруг модели, куда входят и системный промпт, и инструменты, и промежуточная логика, отвечающая за доставку контекста и проверки.
Сопоставим эти три подхода на нашем учебном примере:
| Подход | Что именно мы настраиваем | Пример при подготовке статьи | Что изменится для результата |
|---|---|---|---|
| Prompt engineering | Формулировку инструкции и правил для модели | Уточняем в задании, что статья предназначена новичку, а каждый термин нужно сначала объяснить простыми словами. | Модель получает более ясный ориентир по стилю и подаче, если у неё уже есть нужные сведения. |
| Context engineering | Состав сведений, которые передаются модели в конкретном вызове | Передаём в текущий вызов не всю переписку подряд, а исходный вопрос читателя, текст нужного источника и сохранённую заметку по теме. | Модель получает относящиеся к текущему шагу материалы, на которые может опереться при подготовке текста. |
| Harness engineering | Устройство всей рабочей системы вокруг модели | Настраиваем инструменты чтения и записи, сохранение состояния между сессиями, подачу заметок и правило остановки перед проверкой человеком. | Поручение связывается в управляемый процесс, который можно продолжать по шагам и контролировать на переходах. |
Это сопоставление служит удобной рабочей опорой, а не жёстким делением на три изолированных уровня. На практике задачи постоянно пересекаются. Когда мы меняем текст инструкции, мы одновременно меняем часть контекста. Когда мы перестраиваем обвязку, чтобы она вовремя подгружала сохранённые заметки, мы решаем задачу доставки контекста и часто попутно уточняем системный промпт.
Главное, что даёт такое разграничение на практике, — понимание того, где искать причину неудачи. Ведь даже исправно работающая техническая обвязка со всеми инструментами и проверками сама по себе не гарантирует, что для статьи изначально выбран верный угол подачи. С этим ограничением я столкнулся в реальной работе над текущим материалом.
Как в реальном эпизоде пришлось возвращать статью к вопросу новичка
От учебного примера перейдём к реальному случаю, который произошёл 4–5 октября 2026 года во время подготовки материала о harness engineering. На этапе выбора ракурса ИИ-помощник предложил построить статью вокруг узкого вопроса: как проверять контроль над действиями ИИ-агента.
Для опытного разработчика такая тема могла бы быть интересной, но для вводной статьи она не подходила. Человек, который впервые слышит словосочетание harness engineering, ещё не знает, что такое обвязка, зачем она нужна модели и какие действия в ней вообще происходят. Предлагать ему сразу разбирать контроль над действиями значило бы пропустить самое важное начальное объяснение.
Это смещение заметил я при просмотре предложенного угла темы и вернул подготовку к исходному вопросу новичка: что такое harness engineering и зачем вокруг модели строят обвязку. Помощник выполнял поиск, читал источники и перестраивал анализ после моих замечаний. Смена направления работы сохранилась в истории версий, а после этого разбора требования к предварительной проработке темы зафиксировали в правилах процесса.
Важно точно обозначить границы этого случая. На момент эпизода 4–5 октября 2026 года сама статья ещё не была написана и опубликована: речь шла об исправлении направления работы на предварительном этапе. Один такой эпизод не доказывает, что процесс подготовки статей в целом стал быстрее или эффективнее, и не гарантирует, что подобная ошибка не повторится в будущем. Точно так же сама по себе запись нового требования в текстовые правила процесса не означает, что программа научилась понимать смысл читательского вопроса.
Но если смысловую оценку темы делает человек, то что именно в таком процессе способна проконтролировать сама программа? Чтобы отделить одно от другого, работу программного ограничения проверили в отдельном техническом тесте.
Что показала отдельная проверка программного условия
В настроенном процессе переход от выбора темы к этапу исследования источников требует предварительного согласования темы человеком. Текстовое правило предписывает получить такое одобрение, а программная проверка перед сменой этапа ищет в данных задачи запись о согласовании.
Работу этого механизма проверили в отдельном искусственном сценарии без вызова языковой модели. Условия, результаты и контрольные суммы проверенных версий приведены в обезличенном протоколе проверки. В тестовом запуске программе передали запрос на переход к этапу исследования, но специально не предоставили запись о согласовании темы человеком. Программа заблокировала переход и оставила состояние задачи на прежнем этапе. Дополнительно в том же тесте проверили действие, разрешённое правилами без смены этапа, — сохранение данных внутри текущего шага, и оно выполнилось штатно.
В этом тестовом запуске программная проверка заблокировала переход без записи о согласовании. При этом важно понимать, чего именно такая проверка не делала:
- она не оценивала качество или понятность выбранного вопроса для статьи;
- она не проверяла полноту будущего исследования источников;
- в рамках этого теста не прогонялся полный сценарий успешного перехода с уже заполненным согласием человека;
- она не доказывала, что в будущих задачах модель не предложит слишком узкую тему снова.
В реальном эпизоде соответствие замысла задаче читателя оценил человек. Отдельный тест показал, что программа заблокировала переход при отсутствии записи о согласовании. Остаётся решить практический вопрос: как понять, насколько сложная обвязка нужна в вашей собственной задаче.
Когда стоит усложнять обвязку и с чего начать
Знакомство с устройством обвязки не означает, что для любого поручения нужно сразу строить сложную систему с множеством инструментов, журналами, хуками и хранением состояния. Сложность обвязки должна следовать за реальной потребностью задачи. Более того, избыточный набор подключённых инструментов может даже мешать работе, создавая для модели лишнюю неоднозначность при выборе следующего шага.
Если вам нужно один раз подготовить небольшое объяснение по двум коротким заметкам, которые уже лежат перед вами, достаточно самого простого подхода: передать модели понятную инструкцию вместе с текстами заметок в одном вызове, получить ответ и глазами проверить его качество. Для такой задачи может хватить обычного чата с моделью.
Потребность в развитии обвязки появляется тогда, когда вы видите конкретное ограничение в ходе работы:
- если модели нужно самой обращаться к внешним документам или базам по ходу решения, подключают инструменты чтения и поиска;
- если задача длинная и продолжается в несколько приёмов, организуют сохранение промежуточных файлов, запись состояния и подачу нужных заметок в новый вызов;
- если ошибка на промежуточном шаге стоит дорого или уводит всю дальнейшую работу в сторону, добавляют точки остановки и программную проверку условий перед переходом дальше.
При этом не всякий неудачный ответ модели означает, что ей не хватило контекста или нового инструмента. Если в продолжении статьи модель не учла вчерашние выводы, сначала стоит проверить, действительно ли система передала сохранённую заметку в текущий вызов. Если заметка не передавалась, у вас есть точный предмет для доработки обвязки. После исправления останется убедиться, что заметка теперь попадает в вызов, а новый текст действительно решает исходную задачу. Точно так же можно оценивать и готовые сторонние решения: смотреть не на список заявленных в них возможностей, а на то, как они справляются с вашим проверочным поручением.
Поэтому первый практический шаг после знакомства с термином совсем небольшой: выберите одну понятную задачу, определите, какой результат вы будете считать подходящим, и проверьте на ней самый простой вариант работы с моделью. Всё дальнейшее устройство обвязки будет опираться на то, каких именно действий или проверок вам не хватило на практике.
Если у вас уже есть прикладная задача по встраиванию ИИ в рабочие данные и процессы компании, вы можете написать мне на i.am@timofei-ermolaev.ru.
