Agent harness: как мы ускорили Norman

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

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

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

Что такое agent harness?

Agent harness, или харнес агента, это программная среда вокруг модели, которая управляет её работой: передаёт контекст, предоставляет инструменты, хранит состояние и определяет условия завершения задачи. Модель предлагает действия. Харнес исполняет их и задаёт, какие подтверждения нужны приложению, чтобы принять работу как завершённую.

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

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

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

Зачем финансовому агенту нужен харнес?

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

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

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

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

Почему харнес может замедлять ответы агента?

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

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

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

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

Как мы ускорили агента в Norman?

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

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

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

Мы также сократили контекст каждого шага. В локальном сравнении для поиска транзакций подбор под запрос уменьшил каталог примерно с шестидесяти инструментов до менее десяти. Сериализованные описания сократились примерно с 60 тысяч до 12 тысяч символов, то есть примерно на 80%. Это число символов в конкретном сравнении, а не измеренная экономия токенов или универсальное ускорение. Общий принцип мы разбирали в статье о выборе инструментов для агента.

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

Насколько быстрее стал Norman?

Мы сравнили около четырёхсот успешных запусков ассистента со стримингом за два полных дня по UTC во время сентябрьского внедрения. Медианное время завершения снизилось примерно с 20 до 10 секунд. Девяностый перцентиль снизился примерно с 90 до 30 секунд. Последнее число описывает медленную часть успешных запросов: около девяти из десяти завершились в пределах этого времени.

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

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

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

Как тестировать agent harness?

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

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

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

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