Есть особый тип PR в release notes, который нужно прочитать дважды, потому что с первого раза не понимаешь, что произошло. Соответствующая запись в Hermes Agent v0.8.0:
Самооптимизированная guidance для tool-use на GPT/Codex — Агент диагностировал и исправил 5 режимов отказа в вызовах инструментов GPT и Codex через автоматический поведенческий бенчмаркинг, резко повысив надёжность на моделях OpenAI. (#6120)
В первый раз я решил, что кто-то слишком вольно обошёлся со словом «самооптимизированная». Во второй раз дошло — это буквально. Агент прогнал бенчмарк-набор на самом себе, нашёл систематические сбои в том, как модели OpenAI вызывали его инструменты, сгенерировал прицельные guidance-строки для их исправления, и измерил, что исправления действительно работают. Люди одобрили результат. Но весь шаг диагноз и патч был автоматическим.
Это стоит разобрать, потому что это из тех возможностей, которые заползают в релиз одной строчкой — и меняют то, как могут выглядеть следующие релизы.
Конкретная проблема
Связка Hermes Agent с моделями OpenAI — GPT-5, Codex — последние несколько релизов заметно шаталась. Пользователи жаловались: Anthropic Claude работает гладко, а GPT-5 иногда выдаёт аргументы не той формы, пропускает шаги или забывает, что уже сделал в цепочке из нескольких tool-вызовов. Это не скрытые баги — их видно невооружённым глазом. Но чинить руками — мучение: режимы отказа привязаны к конкретной модели и зависят от формулировок промпта способами, которые интуитивно не угадаешь.
Согласно описанию PR, было пять повторяющихся паттернов:
- •Пропуск рекомендованных предпроверок перед деструктивными вызовами инструментов.
- •Выдача аргументов tool-вызова как сырых строк, когда схема ожидала структурированные объекты или числа.
- •Потеря отслеживания того, какой вызов в цепочке уже успешно выполнен, — отсюда дублирование вызовов.
- •Отказ от повторной попытки после транзиентных ошибок, хотя guidance прямо говорила это делать.
- •Сползание с «выполнять план» на «перепланировать план» при длинных контекстах.
Ничего из этого не теория. За каждым пунктом — цепочка GitHub issues.
Цикл, который их починил
Подход в PR #6120 состоит из трёх подвижных частей.
Первая — автоматический набор поведенческих бенчмарков. Тестовый фреймворк прогоняет агента через набор синтетических сценариев, спроектированных так, чтобы спровоцировать каждый из пяти режимов отказа. По каждому сценарию бенчмарк записывает: что модель сделала, что должна была сделать, и считается ли разница одним из известных паттернов.
Вторая — шаг генерации guidance. Когда бенчмарк фиксирует отказ, фреймворк создаёт кандидатские guidance-строки: короткие, модель-специфичные инструкции для добавления в системный промпт, направленные точно на тот паттерн, который провалился. Не «будь аккуратнее», а вещи вроде: «перед вызовом любого деструктивного инструмента сначала вызови соответствующий preview-инструмент с теми же аргументами и отрапортуй его вывод». Кандидаты генерируются по конкретным наблюдаемым ошибкам, не по общей рубрике.
Третья — повторный прогон бенчмарка. Каждая кандидатская строка проверяется на том же наборе сценариев. Guidance, которая улучшает метрики, — остаётся. Guidance, которая ухудшает другие сценарии, — отбрасывается. Выжившие строки собираются в системный промпт для GPT/Codex, который Hermes отгружает.
Почему это другой тип вещей
Исторически промпты, которые идут в комплекте с agent-фреймворком, пишут люди — иногда один человек, иногда небольшая команда — которые вырабатывают мнения о том, что работает, а что нет, глазами просматривая разговоры. У этого процесса три проблемы: он не масштабируется на много моделей; его нельзя дёшево перезапустить, когда модель обновляется; и он порождает промпты, в которых настоящие наблюдения закодированы вперемешку с суевериями автора.
Замена цикла «человек пишет, человек оценивает» на «бенчмарк генерирует кандидатов, бенчмарк их оценивает» — это не то же самое, что позволить ИИ тюнить себя без присмотра. Итоговую guidance по-прежнему одобряют люди. Но сама работа по поиску паттернов и предложению исправлений теперь измерима и воспроизводима. Когда выйдет GPT-6, тот же фреймворк прогонится снова. Когда появится новый режим отказа, добавят новый сценарий — и цикл запустится заново. Расходы на синхронизацию промпта с реальным поведением модели падают на порядок.
Сопутствующие изменения в v0.8.0 указывают в ту же сторону. Thinking-only prefill continuation (#5931) обрабатывает случай, когда модель выдаёт блок рассуждений без блока содержания и зависает. Guidance по дисциплине выполнения (#5414) добавляет в системный промпт общее правило: «не перепланируй, пока что-то реально не изменилось». Приведение аргументов tool-вызовов (#5265) молча конвертирует строки в числа и булевы значения, когда JSON-схема этого ожидает, — закрывая ровно ту ошибку типизации, которую поймал бенчмарк. В changelog эти три PR выглядят несвязанными. Если прочитать их вместе с PR #6120, они — видимая поверхность целенаправленной кампании: сделать агента надёжнее на конкретном семействе моделей через цикл «измерить, исправить, перемерить».
Тихое следствие
То, из-за чего этот момент ощущается переломным, а не просто хорошим релизом, — это намёк на то, как выглядит инженерия агентов, когда перестаёшь писать промпты вручную. Репозиторий вроде Hermes должен целиться в двенадцать провайдеров и тридцать моделей. Отслеживать поведение каждой вручную уже невозможно. Если вместо этого относиться к вопросу «как нам промптить модель X» как к задаче тюнинга, которую решает бенчмарк-фреймворк, — получается процесс, который масштабируется вместе с зоопарком моделей, а не тонет в нём.
Ничего из этого не было заголовком v0.8.0. Заголовком была «intelligence release», а демо — смена модели в реальном времени. Но тихая штука под половицами — в том, что у Hermes теперь есть способ поддерживать агента умным на каждой поддерживаемой модели, без того чтобы человек тратил выходные на каждую модель, перенастраивая системный промпт. Это из тех возможностей, которые и в следующем релизе не появятся как отдельная фича — они проявятся как «надёжность GPT на Hermes продолжает расти» на протяжении шести следующих релизов подряд.
А если ты, как и я, читаешь release notes для удовольствия — это именно та форма вещей, за которой стоит следить.