Почему ИИ-агенты терпят неудачу в производственных условиях: объяснение принципов инженерии harness

Представьте разработчика в 2 часа ночи, который три недели переписывал инструкции, пробовал самую новую флагманскую модель и настраивал размеры фрагментов данных RAG. В среде тестирования агент работает отлично. Но в реальных условиях он срывается: забывает решение, принятое двумя шагами ранее, объявляет о успехе прямо перед тем, как вернуть сломанный результат, а его процент успешного выполнения задач составляет 68%, независимо от используемой модели. Достичь уровня выше 70% кажется невозможным.

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

Три этапа работы с LLM

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

Этап первый: инжиниринг запросов

Все начинают с этого, проверяя, понял ли модель запрос. ГЛМ крайне чувствительны к тому, как ими управляют. Хорошо подобранная роль, несколько примеров и четко определенный формат вывода могут кардинально изменить результаты, и для задач с ограниченным количеством шагов хороший формулировки запросов необходимы.

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

Этап второй: инжиниринг контекста

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

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

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

Третий этап: инженерия управления

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

Ментальная модель: агент — это модель плюс система управления

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

Представьте, что вы посылаете младшего коллегу на важную встречу с клиентом.

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

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

Шесть уровней зрелого механизма управления

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

Уровень 1: границы информации

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

Уровень 2: система инструментов

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

The harness should govern when tools get used, not just which ones exist. It should stop the model from guessing when it ought to search, and from searching when it already knows. And one rule has no exceptions: don't pipe raw tool output straight back to the LLM. A 50-item JSON reply from an API poisons the context. Filter, parse and summarise results before the model sees them.

Layer 3: execution orchestration

Models often fail not for lack of individual skills but because they can't chain them in order. They run in a stream of consciousness, hopping between steps, skipping checks and writing output before they have what they need. The harness sets fixed rails: understand the goal, assess what information is held, fetch what's missing, analyse, generate, verify, then output.

Это превращает управление проектами из вероятностной модели в детерминированную систему. Модель не должна определять порядок выполнения работ — такая структура относится к инструментам управления проектами.

Слой 4: память и состояние

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

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

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

Слой 5: оценка и наблюдаемость

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

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

Слой 6: ограничения, проверка и восстановление

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

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

Тревога из-за контекста

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

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

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

Разделение генерации и оценки

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

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

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

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

OpenAI пошел еще дальше. Как только агенты начали писать код быстрее, чем люди могли просмотреть запросы на внесение изменений, им была предоставлена собственная автоматизированная схема CI/CD. Агенты выполняют свою работу в изолированных средах тестирования, делают скриншоты с помощью браузеров без графического интерфейса, анализируют собственные логи и продолжают работу в цикле до тех пор, пока развертывание не станет успешным, причем при этом никто не наблюдает за процессом. Слово «Готово» больше не означает просто генерацию текста — оно означает, что код был запущен, логи проверены, ошибка найдена и исправлена, а развертывание подтверждено в среде тестирования.

Где на самом деле находится предел

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