Команда LangChain подняла эффективность своего агента с 52% до 66% только за счет изменения архитектуры обвязки, не трогая саму модель. Разбираем их подход к harness engineering.
3 мин
В индустрии разработки AI-агентов существует заблуждение, что для улучшения результатов нужно ждать выхода новой, более мощной модели. Однако свежий кейс от LangChain доказывает обратное: архитектура системы вокруг модели (так называемая «обвязка» или harness) играет не меньшую роль, чем сам «интеллект» внутри.
Команда разработчиков LangChain поделилась опытом оптимизации своего агента для написания кода. Им удалось поднять его эффективность на бенчмарке Terminal Bench 2.0 с 52,8% до 66,5%, переместившись из топ-30 в пятерку лидеров. Ключевой момент: сама языковая модель (в данном случае использовалась gpt-5.2-codex) осталась неизменной. Весь прирост был получен исключительно за счет инженерных решений.
Harness (обвязка) — это системная оболочка, которая управляет «интеллектом» модели, направляя его на решение конкретных задач. Если модель — это двигатель, то обвязка — это трансмиссия, рулевое управление и электроника автомобиля. Инженерия обвязки включает в себя работу с системными подсказками (промптами), инструментами, управлением памятью и логикой выполнения задач.
Вместо того чтобы пытаться оптимизировать всё сразу, инженеры LangChain сосредоточились на трех рычагах: системный промпт, доступные инструменты и middleware (промежуточное ПО, перехватывающее вызовы модели).
Изображение из источника
Главным инструментом улучшения стал анализ трассировок (traces). Разработчики автоматизировали процесс разбора ошибок. Специальный агент-аналитик просматривал логи неудачных запусков, классифицировал ошибки (например, логические сбои, игнорирование инструкций или отсутствие тестов) и предлагал изменения в обвязку.
Это позволило создать быстрый цикл обратной связи: запуск → ошибка → автоматический анализ → корректировка промпта или логики → новый запуск.
Одна из главных проблем современных моделей — чрезмерная самоуверенность. Агент часто пишет код, бегло его просматривает и считает задачу выполненной. В реальности же код может не работать или не покрывать граничные случаи.
Чтобы решить эту проблему, в систему внедрили жесткий алгоритм действий:
Технически это было реализовано через middleware, которое перехватывает попытку агента завершить работу и принудительно отправляет его на этап проверки, если тесты не были запущены.
Изображение из источника
Агенты плохо ориентируются в незнакомой среде и не умеют оценивать время. Инженеры добавили автоматическое сканирование директорий при старте, чтобы агент сразу понимал структуру проекта и доступные инструменты. Кроме того, агенту начали сообщать об истекающем бюджете времени, подталкивая его переходить от размышлений к действиям.
Также была решена проблема «циклов обреченности» (doom loops), когда агент раз за разом пытается исправить ошибку одним и тем же неработающим способом. Система теперь отслеживает количество правок одного файла и, если их слишком много, вмешивается с советом полностью пересмотреть подход.
Интересное наблюдение касается использования вычислительных ресурсов для рассуждений (reasoning). Оказалось, что максимальное использование мощных моделей на каждом этапе не всегда эффективно и часто приводит к тайм-аутам. Оптимальной стратегией стал «сэндвич»: высокая мощность на этапе планирования, средняя на этапе написания кода и снова высокая на этапе финальной проверки.
Этот кейс наглядно показывает, что мы переходим от эпохи простой «промпт-инженерии» к полноценной системной инженерии агентов, где архитектура приложения важнее, чем просто удачно подобранные слова запроса.
Изображение из источника
Изображение из источника
Изображение из источника
Улучшение окружения модели (обвязки) может дать двузначный прирост эффективности без смены самой модели.
Автоматизированный анализ ошибок другим агентом работает эффективнее ручного разбора, создавая быстрый цикл самообучения системы.
