2026-07-22 · Обновлено 2026-07-22

[!NOTE] Автоматический перевод Эта статья была автоматически переведена с оригинальной английской версии.

Харнесс-инжиниринг для ИИ-агенты: проектирование цикла вокруг модель

Часть 6 серии «Инженерия стека Агентный»

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

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

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

Чтобы конкретизировать этот путь управления, я воспользуюсь небольшим вымышленным репозиторием магазина. Задача по программированию заключается в снижении порогового значения для автоматической скидки в 10% с $100 до $75. src/checkout.py. В репозитории предусмотрены два обязательных проверочных шага:

• pytest tests/test_checkout.py проверяет расчёт скидки. pnpm playwright test tests/checkout_discount.spec.ts Добавляется товар стоимостью $80 в локальный тестовый магазин, после чего проверяется, отображается ли на странице оформления заказа скидка в размере $8.

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

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

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

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

Что владеет харнесс

OpenAI’s Пошаговый обзор цикла Codex Здесь описывается базовый цикл работы. харнесс формирует промпт, запрашивает у модель следующее действие, отправляет принятое tool call в рантайм, добавляет полученный результат и снова делает запрос, пока харнесс не примет этот результат или не вернёт управление пользователю.

Реализации могут объединять несколько функций в один процесс. Однако границы сбоев остаются разными:

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

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

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

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

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

Отслеживайте изменения стоимости с момента подачи предложения до его одобрения

Для задачи на предоставление скидки, описанной выше, модель предлагает внести изменения calculate_discount в src/checkout.py. До этого происходит несколько этапов: любые изменения уже считаются прогрессом:

1. Механизм построения контекста предоставляет задачу, инструкции к репозиторию, соответствующие файлы, результаты предыдущих операций инструментов и текущий план.
2. модель предлагает вариант edit_file Вызов с указанием пути и текста замены.
3. Граница инструмента (код харнесс между предложением и выполнением) проверяет аргументы, убеждается, что путь находится в допустимом диапазоне, и запрашивает разрешение, если для операции это необходимо.
4. рантайм применяет изменения в сэндбокс и возвращает структурированный результат.
5. харнесс выполняется pytest tests/test_checkout.py, за которым следует pnpm playwright test tests/checkout_discount.spec.ts, и считывает оба кода выхода. Тест в браузере проверяет видимую скидку в размере $8 на корзине с начальной стоимостью $80.
6. харнесс определяет, что означают полученные результаты. Неудачная проверка становится новым контекстом для следующего запуска модель, а успешный прохождение превращает задачу в кандидата на завершение.
7. Результат успешного теста считается доказательством завершения только после того, как харнесс занесёт команду, код выхода и версию тестируемого продукта в трейс.

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

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

Определите, где будет применяться каждое правило

установить tests/checkout_discount.spec.ts В обычной логике программы харнесс отправляет команду Playwright в рантайм, считывает её код выхода и отказывается завершать выполнение, пока возникают сбои. промпт может напомнить модель о необходимости запуска теста. Однако он не может предотвратить, чтобы модель объявил о успехе без соответствующих доказательств.

Другие правила применяются к разным уровням:

Контракты инструментов разделяют процесс подачи предложений и выдачу разрешений

Задача на скидку требует лишь редактирования файлов и выполнения тестовых команд. Состояние, изменяющееся API, имеет иной способ возникновения сбоев, поэтому необходимо заменить примеры в этом разделе. Предположим, что агент может вызывать create_test_order при настройке тестовых данных в условиях работы сервиса обработки заказов на стадии тестирования. Этот инструмент не относится к списку проверок принятия задач с заниженными приоритетами. Он полезен в данном случае, поскольку исчерпание времени ожидания может скрыть информацию о том, создал ли сервис соответствующий заказ.

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

• проверенные аргументы, благодаря чему некорректный ввод отклоняется до начала выполнения
• структурированный результат, такой как { "order_id": "123", "created": true }, поэтому последующие проверки не требуют парсинга текста свободного формата
• категория эффекта, фиксирующая, запрашивает ли вызов только информацию или изменяет файл, запись в базе данных или внешний сервис. Она также указывает, безопасно ли повторять вызов. Эта метка сообщает харнесс о том, может ли автоматическая попытка повтора привести к дублированию работы: он может попробовать снова get_order_status когда сервис задаёт такой поиск как только для чтения, но он не должен слепо повторять попытки create_test_order поскольку первый вызов уже мог создать заказ; — политика таймаута и повторных попыток, благодаря которой отсутствие ответа не приводит к бесконечной серии вызовов; — правило разрешений, определяющее необходимость утверждения. Чтение статуса заказа может выполняться автоматически, тогда как создание заказа может требовать подтверждения.

Описание на естественном языке — это текст, отображаемый для модель. В нём может быть указано что-то вроде: «Создайте тестовый заказ для проверки процесса оплаты». Такое предложение помогает модель определить, когда следует сделать соответствующее предложение. create_test_order. Это не предоставляет разрешения на выполнение вызова. В данном примере клиент харнесс с использованием MCP проверяет переданные аргументы, применяет собственные правила, а также оценивает надёжность сервера, наличие требуемых разрешений и безопасность повторных попыток перед тем, как отправлять какой-либо запрос.

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

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

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

Появляется более сложная проблема с повторными попытками, когда create_test_order Создаётся заказ, но его HTTP-ответ теряется. Механизм харнесс фиксирует истечение времени ожидания и не может определить, была ли сервером обработана заявка. Повторная попытка выполнения запроса может привести к созданию второго заказа.

Попытку получения статуса можно повторить, если сервис определён как только для чтения. Запрос на создание требует защиты в виде ключа идемпотентности: клиент прикрепляет уникальный идентификатор запроса, и сервис возвращает первый результат вместо того, чтобы создавать новый заказ при повторном обнаружении этого идентификатора. Без такой защиты харнесс должен проверять наличие заказа или запрашивать решение человека перед следующей попыткой. AWS описывает эту практику в своих документациях. Рекомендации по обеспечению идемпотентности API.

Для подтверждения соответствия требуемым критериям необходимы независимые доказательства

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

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

Понадобится помощь с миграцией адаптера платежей

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

До того, как первый сессия достигнет своего лимита контекста, он уже изменил несколько файлов, инициировал локальную оплату сэндбокс и покинул систему tests/payment_migration.spec.ts Не проходит тест на приемлемость в браузере. В ходе его выполнения осуществляется одна оплата через адаптер версии v2 с проверкой зарегистрированного идентификатора поставщика. Краткое резюме диалога может помочь при планировании следующих модель сессия, однако оно не может возобновить сэндбокс и не позволяет определить, какие файлы в настоящее время изменены.

Следующий сессия должен восстановить три компонента:

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

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

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

Используйте трейсы для различения трёх типов сбоев

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

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

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

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

Измеряйте изменения по одному за раз

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

Используйте следующий протокол:

1. Заморозить версию модель, экземпляры задач, среду, инструмент оценки и промпты вне тестируемого компонента.
2. Выделить обеим вариантам одинаковый общий бюджет по токен, времени и деньгам.
3. Перед запуском сравнения определить количество попыток или критерии прекращения работы.
4. Запустить в обоих вариантах одни и те же экземпляры задач. Поскольку результаты, генерируемые модель, могут отличаться, необходимо выполнить каждую задачу несколько раз.
5. Предоставить значение среднего показателя вместе с дисперсией или диапазоном доверия.
6. Подсчитать каждую начатую попытку, включая случаи истечения времени, прекращение работы из-за правил, сбои харнесс и ошибки эвалуатор.

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

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

Этот Статья о SWE-agent Улучшает производительность GPT-4 Turbo на подмножестве тестов SWE-bench Lite из 300 задач, показывая уровень решения проблем в 18,0% при использовании полноценного интерфейса, по сравнению с 11,0% у агента, работающего только через оболочку. В статье также описаны изменения отдельных функций интерфейса:

Эти значения соответствуют ограничениям модель, бенчмарк, а также лимиту в 4 доллара за задачу. without linting, full file, и full history Строки представляют собой полезные тесты с одной изменяемой характеристикой: в каждом из них менялась та или иная функция интерфейса, при этом модель и конфигурация оценки оставались неизменными.

LangChain опубликовал более широкую версию фиксированное сравнение модель для deepagents-cli. Он показывает рост по метрике Terminal-Bench 2.0 с 52,8% до 66,5% gpt-5.2-codex Проблема была устранена после того, как команда изменила системный промпт, инструменты и среду промежуточной обработки. Данный пакет содержит несколько изменений, но в нём отсутствуют интервал уверенности, сравнение с фиксированным общим бюджетом, а также таблица абляции для отдельных изменений. Поэтому на основе этих результатов невозможно определить, какое именно изменение оказалось полезным.

Anthropic’s Отчёт о приложении с длительным временем выполнения Это качественное, специфичное для конкретного продукта кейс-исследование, а не контролируемое бенчмарк. В ходе спринта 3 его эвалуатор проверил 27 критериев редактора уровней. Команда отмечает, что вызовы эвалуатор стали дополнительной нагрузкой на задачи, которые версия Opus 4.6 могла выполнять надежно самостоятельно, однако они всё равно были полезны в условиях, близких к пределам работоспособности модель; поэтому после обновления модель компоненты харнесс удалялись по одному. Этот пример служит основанием для повторной проверки старой инфраструктуры при изменениях модель, при этом он не позволяет оценить общий размер влияния.

Обеспечьте возможность редактирования харнесс после того, как он займёт своё место

Абляция позволяет сохранить харнесс небольшой, но его код всё равно может просуществовать дольше модель Он был настроен для реализации такой задачи. Запрос вроде «скрыть секреты в каждом пути кэпчера» указывает на конкретное поведение, а не на файл. В продакшене харнесс, такое поведение может спан этапы выполнения и общее состояние. Человек или агент для написания кода должен обнаружить все места реализации, прежде чем безопасно внести в них изменения.

предварительная публикация 2026 года от Wang и соавт. Харнесс Руководство, В этом шаге данный процесс называется behavior localization. Руководство создаёт карту, ориентированную на поведение, на основе кодовой базы харнесс. В ходе статического анализа извлекается граф программы без модель вызовов, после чего LLM сгруппировывает её компоненты в этапы выполнения.

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

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

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

Этот Оценка руководства соответствует протоколу, за который выступает данная статья. На двух репозиториях с открытым исходным кодом (Terminus-2 с шестью файлами на Python и монорепозиторий Codex с 2 267 файлами на Rust) средство с режимом только чтения планировщик, работающее на базе DeepSeek-V4-Pro, либо анализировало репозиторий напрямую, либо выполняло операции через соответствующее руководство. Запросы, права доступа к репозиторию и инструментам, а также процесс декодирования были одинаковыми в обоих случаях. Три модели джаджи (GPT-5.5, Opus 4.8, DeepSeek-V4-Pro) оценивали каждый план изменений с точки зрения локализации, контроля объёма работ и ризонинг:

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

В предыдущих разделах для объяснения причин существования того или иного компонента используется трейсы. Данная схема отвечает на следующий вопрос: где находится этот компонент в случае необходимости его изменения?

Попробуйте этот метод в сопутствующей лаборатории

Этот харнесс — демо-проект в коммите 517353f3 это небольшое детерминистичное упражнение, включающее 12 универсальных синтетических задач, охватывающих такие изменения в коде, как fix-parser-edge-case, split-large-module, и wire-browser-test. Он не реализует вымышленный репозиторий хранилища.

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

Команды отвечают на разные вопросы:

• make check запускает Ruff и семь тестов на единицы, включая валидатор, который отклоняет любую пару абляций, изменяющую более одного компонента. make run выводит кумулятивную матрицу обучения, а затем пять корректных сравнений с исключением одного компонента. make failures присваивает имя неразобранной причине сбоя для каждой неудачной задачи. Полное харнесс должно заканчиваться all synthetic tasks pass.

make check
make run
make failures

секция, отвечающая за анализ причинно-следственных связей make run Выглядит так:

component                 control  treatment  delta
retry_policy              8/12     12/12       +4
progress_handoff          7/12     12/12       +5
evaluator                 8/12     12/12       +4
fail_closed_acceptance    7/12     12/12       +5
context_reset            10/12     12/12       +2

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

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

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

from dataclasses import dataclass, fields


@dataclass(frozen=True)
class Config:
    progress_handoff: bool = False
    evaluator: bool = False
    retry_policy: bool = False
    fail_closed_acceptance: bool = False
    context_reset: bool = False


def changed_components(control: Config, treatment: Config) -> tuple[str, ...]:
    return tuple(
        field.name
        for field in fields(control)
        if getattr(control, field.name) != getattr(treatment, field.name)
    )


control = Config(progress_handoff=False, evaluator=True, retry_policy=True)
treatment = Config(progress_handoff=True, evaluator=True, retry_policy=True)
assert changed_components(control, treatment) == ("progress_handoff",)

Начните с одного цикла и одной проверки приемлемости

Я бы начал создание кодинг-агента харнесс с одного функционального модель, инструкций по работе с репозиторием, нескольких специализированных инструментов, сэндбокс, а также одного чётко сформулированного теста на принятие. Все tool calls, полученные результаты, затраты и данные этого финального теста я бы записал в одном трейс, чтобы первые значимые сбои были видны сразу, без необходимости восстановления информации из логов терминала или записей чатов. Речь идёт о предложенной базовой конфигурации, а не о результатах работы уже развернутой системы.

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

Шесть месяцев спустя кто-то, кто увидит progress_handoff=True Необходимо уметь находить тот неудачный трейсы, который стал причиной данной ситуации, а также случаи регрессии, из‑за которых он по‑прежнему остаётся в системе. трейсы объясняет, зачем существует данный компонент; актуальная карта поведения указывает, в каких частях его следует изменять.

Список литературы

• OpenAI, Раскрытие кодекса агентный цикл.
• OpenAI, Харнесс-инжиниринг: использование Codex в мире, ориентированном на агенты.
• Лопополо, Харнесс-инжиниринг: набор контекстной информации для антологии, руководства по области и агента.
• Anthropic Engineering, Эффективные механизмы управления для агентов с длительным временем выполнения.
• Anthropic Engineering, Харнесс проектирование для разработки приложений с длительным временем работы.
• LangChain, Улучшение глубоких агентов с харнесс-инжиниринг.
• Ян и др., SWE-agent: Интерфейсы агента и компьютера обеспечивают автоматизацию процессов разработки программного обеспечения.
• Ванг и др., Харнесс Руководство: сделать развивающиеся хабы агентов читаемыми, удобными для навигации и модификации, arXiv:2607.13285, 2026 год.
• AWS, Обеспечение безопасности повторных попыток с помощью идемпотентных операций APIs.
• Модель Протокол контекста, Спецификация инструментов.

Серия: Проектирование стека Агентный

• Часть 1: ИИ-агент Ризонинг Циклы в 2026 году: ReAct, ReWOO и подход «планирование — выполнение» Часть 2: ИИ-агент Архитектура памяти в 2026 году: чекпоинты, векторные хранилища и память документов Часть 3: ИИ-агент Tool Use в 2026 году: MCP, интерфейс командной строки, навыки, выполнение кода и ACI
• Часть 4: ИИ-агент Безопасность в 2026 году: гардрейлы, права доступа, сэндбоксы, HITL и ограничение области действия MCP Часть 5: Долгосрочная работа ИИ-агент Рантайм в 2026 году: сессии, сэндбоксы, чекпоинты, механизмы интеграции и деплой формирования структур
• Часть 6: Харнесс-инжиниринг для ИИ-агенты (эта статья)