Инженерия обвязки: как улучшить AI-агента без смены модели

В индустрии разработки AI-агентов существует заблуждение, что для улучшения результатов нужно ждать выхода новой, более мощной модели. Однако свежий кейс от LangChain доказывает обратное: архитектура системы вокруг модели (так называемая «обвязка» или harness) играет не меньшую роль, чем сам «интеллект» внутри.

Команда разработчиков LangChain поделилась опытом оптимизации своего агента для написания кода. Им удалось поднять его эффективность на бенчмарке Terminal Bench 2.0 с 52,8% до 66,5%, переместившись из топ-30 в пятерку лидеров. Ключевой момент: сама языковая модель (в данном случае использовалась gpt-5.2-codex) осталась неизменной. Весь прирост был получен исключительно за счет инженерных решений.

Что такое Harness Engineering?

Harness (обвязка) — это системная оболочка, которая управляет «интеллектом» модели, направляя его на решение конкретных задач. Если модель — это двигатель, то обвязка — это трансмиссия, рулевое управление и электроника автомобиля. Инженерия обвязки включает в себя работу с системными подсказками (промптами), инструментами, управлением памятью и логикой выполнения задач.

Вместо того чтобы пытаться оптимизировать всё сразу, инженеры LangChain сосредоточились на трех рычагах: системный промпт, доступные инструменты и middleware (промежуточное ПО, перехватывающее вызовы модели).

Анализ следов как навык

Главным инструментом улучшения стал анализ трассировок (traces). Разработчики автоматизировали процесс разбора ошибок. Специальный агент-аналитик просматривал логи неудачных запусков, классифицировал ошибки (например, логические сбои, игнорирование инструкций или отсутствие тестов) и предлагал изменения в обвязку.

Это позволило создать быстрый цикл обратной связи: запуск → ошибка → автоматический анализ → корректировка промпта или логики → новый запуск.

Принудительная самопроверка

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

Чтобы решить эту проблему, в систему внедрили жесткий алгоритм действий:

1. Планирование: прочитать задачу и изучить кодовую базу.
2. Сборка: написать код сразу с тестами.
3. Верификация: запустить тесты и сравнить результат с требованиями задачи (а не с собственным кодом).
4. Исправление: анализ ошибок и повторный цикл.

Технически это было реализовано через middleware, которое перехватывает попытку агента завершить работу и принудительно отправляет его на этап проверки, если тесты не были запущены.

Управление контекстом и временем

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

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

Баланс вычислительных ресурсов

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

Этот кейс наглядно показывает, что мы переходим от эпохи простой «промпт-инженерии» к полноценной системной инженерии агентов, где архитектура приложения важнее, чем просто удачно подобранные слова запроса.