Почему качество AI-агента зависит не только от модели: что такое harness engineering

Качество AI-агента определяется всей системой, а не только моделью

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

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

Harness engineering можно определить как проектирование среды, правил и обратной связи, в которых модель решает задачу. В эту работу входят интерфейсы инструментов, управление состоянием, права доступа, лимиты, песочница, трассировка, критерии готовности и порядок эскалации. Практическая схема такого подхода разобрана в материале о harness для AI-агентов.

Модель предлагает следующий шаг, система отвечает за конечный результат

Агентный запуск состоит из повторяющейся цепочки действий:

1. Агент получает цель, ограничения и критерии готовности.
2. Модель формулирует план или выбирает ближайшее действие.
3. Скаффолд передаёт вызов подходящему инструменту.
4. Инструмент возвращает наблюдение: файл, результат команды, ошибку, превью или измерение.
5. Модель сопоставляет наблюдение с задачей и решает, нужен ли следующий шаг.
6. Проверка принимает результат, отправляет его на исправление или останавливает запуск с эскалацией.

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

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

Почему сравнение моделей без одинакового harness даёт неполную картину

Сравнивать модели корректно можно только при фиксированном окружении. В эксперименте нужно заранее закрепить:

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

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

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

Архитектура AI-агента: четыре слоя, которые работают вместе

Удобная схема AI-агента состоит из четырёх слоёв. Такое разделение помогает локализовать сбой и не пытаться исправить ошибку промптом, если причина находится в правах, оркестрации или критериях приёмки.

Модель: рассуждение, генерация и выбор следующего действия

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

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

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

Скаффолд: цикл работы агента и состояние задачи

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

Минимальный цикл можно представить так:

1. создать состояние задачи;
2. передать модели цель и доступные действия;
3. исполнить выбранный вызов;
4. добавить наблюдение в состояние;
5. запустить проверку или вернуть наблюдение модели;
6. повторить цикл до принятия, остановки по лимиту или эскалации.

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

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

Практический пример архитектуры самописного агента с оркестрацией, памятью, инструментами и обработкой ошибок приведён в разборе AI-агента на Python.

Технический харнесс: инструменты, среда выполнения и ограничения

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

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

Хороший технический харнесс отвечает на пять вопросов:

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

Процессный харнесс: спецификация, проверки и критерии готовности

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

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

Слабый процессный слой принимает фразу готово как доказательство завершения. Сильный слой просит предъявить артефакт и результаты гейтов. Эти границы полезно описывать в проектной документации. В разборе governance для агентной разработки показано, как политики, навыки и фазы рабочего процесса ограничивают автономные действия команды.

Harness engineering: что это и где заканчивается обычная обвязка

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

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

Обвязка как замкнутый цикл обратной связи

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

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

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

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

Какие решения относятся к harness, а какие - к продуктовой логике

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

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

Разделение удобно фиксировать в таблице ответственности:

Если смешать эти уровни, диагностика усложняется. Исправление промпта не поможет инструменту с неясной схемой, а добавление нового API не решит отсутствие критерия готовности.

Инструменты для AI-агентов: хороший интерфейс важнее длинного списка функций

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

Инструмент должен возвращать наблюдение, а не только статус успеха

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

Для операции генерации изображения подходящая схема может содержать такие поля:

• status, например completed или rejected;
• artifact_path, путь к созданному файлу;
• width и height;
• preview_path для визуальной проверки;
• validation_errors со списком нарушенных условий;
• estimated_cost и факт подтверждения платной операции.

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

Права, подтверждения и стоимость операции

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

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

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

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

Кейс mostai-mcp: от задания до файлов в репозитории

Заявленный сценарий mostai-mcp показывает, как цепочка инструментов формирует рабочий harness вокруг агентной среды. Интеграция подключает Claude Code, Codex, Cursor и MCP-агентов к более чем 60 моделям MostAI.

В сценарии с афишей агент получает задачу создать изображение концерта в стиле 1960-х, сделать обложку формата 16:9 и сохранить материалы в public/events/. Последовательность действий выглядит так:

1. estimate_price оценивает стоимость операции;
2. generate_image создаёт исходную афишу;
3. preview_media возвращает результат для проверки;
4. edit_image используется при необходимости исправления;
5. готовые файлы сохраняются в репозитории проекта.

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

Это пример архитектуры цепочки, а не независимый тест качества mostai-mcp. Он показывает важный принцип: инструментальный слой должен поддерживать цену операции, наблюдение, исправление и сохранение артефакта. Сам список подключённых моделей такого результата не гарантирует.

Управление контекстом AI-агента: что хранить, что сжимать и что кэшировать

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

Жизненный цикл контекста от первого запроса до финальной проверки

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

Контекст удобно разделять на четыре слоя:

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

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

Кэширование промптов: экономия без скрытой рассинхронизации

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

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

Практическая проверка рассинхронизации состоит из трёх шагов:

1. изменить правило или схему инструмента;
2. убедиться, что старый контекст больше не используется;
3. запустить контрольную задачу и сравнить полученный формат результата.

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

Компакция контекста и сохранение состояния задачи

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

Минимальная структура компактного состояния:

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

Нельзя удалять исходные критерии готовности, ограничения доступа, решения пользователя, причины отклонения и ссылки на финальные артефакты. Сжатие этих данных заставляет агента угадывать уже принятые решения.

Субагенты: декомпозиция без потери общей цели

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

Перед делегированием нужно зафиксировать:

• границы подзадачи;
• разрешённые файлы и инструменты;
• формат итогового отчёта;
• критерии проверки;
• условия остановки и передачи ошибки наверх.

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

Песочница и технический харнесс: как ограничить последствия ошибок

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

Изоляция, права и границы побочных эффектов

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

Полезная матрица прав может выглядеть так:

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

Логи, трассировка и воспроизводимость агентного запуска

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

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

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

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

Процессный харнесс: Spec-Driven Development и проверка результата

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

Спецификация как контракт для агента

Хорошая спецификация отвечает на семь вопросов:

1. Какую пользовательскую проблему нужно решить?
2. Какие входные данные доступны и какие из них имеют приоритет?
3. Какие файлы, поля или действия должны появиться на выходе?
4. Какие ограничения нельзя нарушать?
5. Какие результаты считаются ошибочными?
6. Какие проверки подтверждают готовность?
7. Какие действия требуют вопроса пользователю?

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

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

Гейты: проверять не намерение, а артефакт

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

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

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

Граница между автоматикой и человеческим ревью

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

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

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

Как измерять AI-агента: цена принятого результата, а не только ответ модели

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

Метрики качества и полноты

Базовый набор метрик может включать:

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

Метрики стоимости и скорости

Полная стоимость запуска включает токены, вызовы инструментов, платные операции, повторные попытки, инфраструктуру и время ревью. Для практического сравнения удобно считать cost_per_accepted_result = total_cost / accepted_results.

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

Полезные дополнительные показатели:

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

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

Как сравнивать модели и harness в контролируемом эксперименте

Для отделения эффекта модели от эффекта обвязки нужна матрица из двух направлений:

• одна модель в нескольких harness;
• несколько моделей в одном зафиксированном harness.

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

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

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

Практический порядок сборки harness для собственного проекта

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

Шаг 1. Зафиксировать задачу и базовую линию

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

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

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

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

Шаг 2. Спроектировать инструменты и ограничения

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

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

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

Шаг 3. Добавить контекст, проверки и логи

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

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

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

Шаг 4. Масштабировать только доказавшие пользу механизмы

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

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

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

Что harness engineering не исправит

Harness engineering помогает связать способности модели с безопасным и проверяемым процессом. Он не превращает любую модель в универсального исполнителя и не заменяет качественную постановку задачи, данные и предметную экспертизу.

Когда проблема действительно в модели

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

• модель стабильно неверно интерпретирует предметный термин;
• не справляется с требуемым преобразованием при корректном формате входа;
• пропускает критическое условие в короткой и ясной задаче;
• плохо работает с нужной модальностью;
• демонстрирует низкую устойчивость к допустимым формулировкам.

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

Когда обвязка стала слишком сложной

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

Признаки чрезмерной сложности:

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

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

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

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

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

Сильный результат возникает там, где агент видит ясную спецификацию, действует через узкие инструменты, получает проверяемое наблюдение, сохраняет состояние и останавливается при неопределённости. Если хотя бы один слой остаётся без владельца и измерений, итоговая оценка качества AI-агента будет неполной.

Подписаться на канал