Сегодня я прочитал длинную статью о Harness Engineering — десятки тысяч слов, почти наверняка написанных ИИ. Моя первая реакция не была "вау, какой мощный концепт." Это было "есть ли у этих людей какие-либо идеи, кроме как придумывать новые термины для старых?" Меня всегда раздражала эта схема в мире ИИ — постоянное переосмысление существующих концепций. От проектирования подсказок до проектирования контекста, теперь до harness engineering. Каждые несколько месяцев кто-то придумывает новый термин, пишет эссе на 10,000 слов, добавляет несколько примеров из крупных компаний, и вся сообщество начинает гудеть. Но если вы действительно посмотрите на содержание, это одно и то же каждый раз: Проектируйте среду, в которой работает ваша модель — какую информацию она получает, какие инструменты может использовать, как перехватываются ошибки, как управляется память между сессиями. Это существует с момента запуска ChatGPT. Это не становится новой дисциплиной только потому, что кто-то — по какой-то причине — решил дать этому новое имя. Тем не менее, несмотря на жалобы, исследования и примеры, приведенные в статье, действительно имеют ценность — особенно поскольку они сильно пересекаются с тем, что я строил с помощью how-to-sglang. Так что позвольте мне использовать это как возможность поговорить о ошибках, которые я действительно совершил. Сначала немного предыстории. Наиболее распространенные запросы в сообществе SGLang — это вопросы как сделать — как развернуть DeepSeek-V3 на 8 GPU, что делать, когда шлюз не может достучаться до адреса рабочего узла, значительна ли разница между GLM-5 INT4 и официальным FP8. Эти вопросы охватывают чрезвычайно широкий технический спектр, и по мере того как сообщество растет все быстрее, мы все больше не можем успевать с ответами. Поэтому я начал строить многопользовательскую систему для автоматического ответа на них. Первая идея была, конечно, самой наивной — создать единого всезнающего агента, запихнуть в него всю документацию, код и рецепты SGLang и позволить ему отвечать на все. Это не сработало. Вам не нужна теория harness engineering, чтобы объяснить, почему — контекстное окно не является ОЗУ. Чем больше вы запихиваете в него, тем больше внимание модели рассеивается, и тем хуже становятся ответы. Агент, пытающийся одновременно понять квантизацию, PD-дисагрегацию, диффузионное обслуживание и совместимость оборудования, в конечном итоге не понимает ни одно из них глубоко. Дизайн, к которому мы в конечном итоге пришли, — это многоуровенная архитектура экспертов по поддоменам. Документация SGLang уже имеет естественные функциональные границы — продвинутые функции, платформы, поддерживаемые модели — с рецептами, организованными по моделям. Мы превратили каждый поддомен в независимого эксперта-агента, с Менеджером Дебатов Экспертов, отвечающим за получение вопросов, разбиение их на под-вопросы, консультации с Таблицей Маршрутизации Экспертов для активации правильных агентов, решение параллельно, а затем синтезирование ответов. Оглядываясь назад, этот дизайн почти идеально соответствует паттернам, которые пропагандирует сообщество harness engineering. Но когда я его строил, я не имел представления, что у этих паттернов есть названия. И мне это не нужно было. 1. Прогрессивное раскрытие — мы не сбрасывали всю документацию в какой-либо отдельный агент. Каждый эксперт по домену загружает только свои собственные знания, и Менеджер решает, кого активировать в зависимости от типа вопроса. Мое интуитивное чувство говорит, что этот дизайн дал гораздо больше улучшений, чем замена на более сильную модель когда-либо давала. Вам не нужно знать, что это называется "прогрессивное раскрытие", чтобы принять это решение. Вам просто нужно было попробовать подход "запихнуть все" один раз и увидеть, как он проваливается. 2. Репозиторий как источник истины — весь рабочий процесс живет в репозитории how-to-sglang. Все экспертные агенты черпают свои знания из markdown-файлов внутри репозитория, без зависимости от внешних документов или устных соглашений. В начале у нас была тяга написать один огромный sglang-maintain.md, охватывающий все. Мы быстро поняли, что это не работает. Команда Codex OpenAI сделала ту же ошибку — они пытались создать один слишком большой AGENTS.md и наблюдали, как он гниет предсказуемым образом. Вам не нужно было читать их блог, чтобы наступить на эту мину. Это классическая проблема программной инженерии "монолитные документы всегда устаревают", только в контексте агентов последствия хуже — устаревшая документация не просто остается непрочитанной, она активно вводит агента в заблуждение. 3. Структурная маршрутизация — Таблица Маршрутизации Экспертов явно сопоставляет типы вопросов с агентами. Вопрос о GLM-5 INT4 активирует как Эксперта по Рецептам, так и Эксперта по Квантизации одновременно. Менеджер не догадывается; он следует структурированному индексу. Сообщество harness engineering называет это "механизированные ограничения." Я называю это нормальной инженерией. Я не говорю, что идеи, стоящие за harness engineering, плохи. Приведенные исследования солидны, концепция ACI из SWE-agent действительно стоит того, чтобы о ней знать, а архитектура двойного агента Anthropic (агент инициализации + агент кодирования) является ценным справочным материалом для любого, кто занимается долгосрочными задачами. Что меня утомляет, так это постоянное придумывание новых терминов — упаковка устоявшейся инженерной здравой мысли как новой дисциплины, а затем создание тревоги вокруг "вы отстаете, если не знаете это слово." Проектирование подсказок, проектирование контекста, harness engineering — это разные грани одной и той же вещи. В следующем месяце кто-то, вероятно, придумает scaffold engineering или orchestration engineering, напишет еще одно длинное эссе, ссылаясь на ту же статью SWE-agent, и сообщество начнет еще один цикл усиления. Что я на самом деле узнал из how-to-sglang, можно сказать без какого-либо нового словаря: Информация, передаваемая агентам, должна быть минимальной и точной, а не максимальной. Сложные системы должны быть разделены на специализированные подмодули, а не строиться как всезнающие агенты. Все знания должны находиться в репозитории — устные соглашения не существуют. Маршрутизация и ограничения должны быть структурными, а не оставлены на усмотрение агента. Обратные связи должны быть как можно более тесными — в настоящее время мы используем систему логирования для записи полной цепочки рассуждений каждого запроса, и мы начали использовать Codex для проверки LLM как судьи, но мы все еще далеки от идеала. Ничто из этого не ново. В традиционной программной инженерии это называется разделением обязанностей, принципом единственной ответственности, документацией как кодом и ограничениями shift-left. Мы просто применяем их к рабочим средам LLM сейчас, и некоторые люди считают, что это оправдывает новое имя. Я не знаю, сколько еще новых терминов произведет эта область. Но я знаю, что, по крайней мере сегодня, мы никогда не достигали качественного скачка в how-to-sglang, заменяя на более сильную модель. То, что на самом деле привело к прорывам, всегда было улучшениями на уровне среды — более точное разделение знаний, лучшая логика маршрутизации, более тесные обратные связи. Называйте это harness engineering, проектированием контекста или ничем вообще, это просто хорошая инженерная практика. Ничего больше, ничего меньше. Есть один вопрос, на который я искренне не смог разобраться: если возможности моделей продолжают экспоненциально расти, придет ли день, когда модели будут достаточно сильны, чтобы строить свои собственные среды? У меня было это точное недоумение, когда я наблюдал за OpenClaw — он вырос с 400K строк до миллиона за один месяц, полностью благодаря ИИ. Кто построил среду этого проекта? Человек или ИИ? И если это был ИИ, сколько из принципов проектирования, о которых мы сегодня говорим, будут совершенно неактуальны через два года? Я не знаю. Но, по крайней мере сегодня, во всех случаях реальной практики, которые я могу наблюдать, это все еще человеческая работа — и самая ценная.

Я в последнее время много общался с людьми, работающими над RL, и заметил нечто интересное — всякий раз, когда разговор заходит о RL Infra, он почти всегда сводится к одной теме: согласование обучения и вывода. Как сохранить согласованность между политиками обучения и вывода. Как контролировать степень офф-политики. Как справляться с разницей логарифмических вероятностей после введения асинхронности. Все это важные вопросы, без сомнения. Но я все больше убеждаюсь, что RL Infra страдает от значительного неправильного распределения внимания. Заимствуя формулировку из недавнего обсуждения с коллегой, я называю это Эффектом Бочки RL Infra. Бочка удерживает только столько воды, сколько позволяет ее самая короткая планка. Пропускная способность и корректность системы обучения RL работают так же — они не определяются модулем, который вы оптимизировали больше всего, а тем, который вы пренебрегли больше всего. Согласование обучения и вывода может быть той планкой, которую вы отшлифовали и отполировали до совершенства. Но если ваша стабильность песочницы — это катастрофа, ваш конвейер вознаграждений постоянно застревает, а ваша сквозная наблюдаемость практически отсутствует — какая польза от идеального согласования? Вместимость системы уже ограничена каждой другой слабой связью. Это принципиально отличается от того, как работает оптимизация системы вывода. В качестве движка вывода SGLang имеет огромное пространство стратегий для оптимизации, но его конвейер относительно линейный — обработка запроса, предварительное заполнение, декодирование. Вы можете изолировать узкие места модуль за модулем, и связь между компонентами управляемая. Обучение RL — это совершенно другое дело — кошмарно сложный многосистемный цикл: генерация развертываний зависит от движка вывода, вычисление вознаграждения может зависеть от внешних сред, обновления политики зависят от обучающей структуры, а следующий раунд развертываний зависит от обновленной политики. Если любая отдельная связь ломается, весь цикл рушится. К сожалению, судя по тому, что я видел за последний год, все еще существует много серьезно недооцененных слабых мест: Надежность песочницы агента. Это, вероятно, самая грязная, самая изнурительная и наименее академически гламурная работа в RL Infra сегодня. Агентный RL нуждается в надежной песочнице для выполнения развертываний — звучит просто, но оказывается настоящим кошмаром. Стабильность контейнеров, задержка холодного старта, надежность изоляции ресурсов, управление состоянием песочницы — эти вещи кажутся разъединенными на бумаге, но продукты песочницы, доступные на рынке, постоянно не соответствуют ожиданиям. Песочница агента не является проблемой алгоритма, но она напрямую определяет вашу эффективность генерации данных, что, в свою очередь, определяет вашу скорость обучения. Наблюдаемость. Отладка предварительного обучения относительно проста — смотрите на кривую потерь, проверяйте норму градиента, и вы обычно можете точно определить проблему. Но отладка RL требует возможностей сквозного отслеживания: распределения качества развертываний, статистики вознаграждений, степени офф-политики, величины обновлений политики и даже атрибуции разницы логарифмических вероятностей (приходит ли разница со стороны вывода или из-за задержки версии асинхронного обучения?). К сожалению, большинство команд, с которыми я сталкивался, по сути, действуют вслепую в этих измерениях. Это приводит к неловкой ситуации — когда результаты обучения плохие, вы даже не знаете, какой модуль винить. Дилемма масштаба. Многие оптимизации RL Infra показывают измеримый эффект только при достаточном масштабе. Эксперименты малого масштаба часто не показывают значительных различий — не потому, что оптимизация бесполезна, а потому, что шум слишком высок, а количество шагов слишком мало, чтобы сигнал проявился. Однако эксперименты большого масштаба prohibitively дороги. Это создает порочный круг: вы не можете доказать, что ваша оптимизация работает на малом масштабе, поэтому не можете получить ресурсы для экспериментов большого масштаба; а без валидации большого масштаба ваша оптимизация навсегда застревает на "теоретически это должно помочь." Инвестиции отрасли в RL Infra серьезно не соответствуют его фактической сложности. Большинство команд рассматривают это как временное решение поверх инфраструктуры предварительного обучения — берут готовую обучающую структуру, прикрепляют движок вывода, склеивают их вместе с помощью скриптов и называют это RL Infra. Но системная сложность обучения RL и предварительного обучения даже не в одной лиге. Конвейеры предварительного обучения линейные, однородные и практически не имеют внешних зависимостей. Конвейеры обучения RL циклические, гетерогенные и сильно зависят от внешних сред. Применение архитектурного мышления первого к последнему гарантированно приведет к стене на масштабе. Настоящая сложность в системной инженерии не в том, чтобы довести любой отдельный модуль до предела — это понимание связи между модулями и глобального пространства компромиссов. Это верно для систем вывода, и тем более для RL Infra, где размеры связи больше, обратные связи длиннее, а плотность информации для отладки гораздо ниже. Я хочу закончить двумя вопросами, над которыми я размышлял, и мне было бы интересно услышать мнение других, работающих в этой области: Где именно начинают уменьшаться предельные доходы от согласования обучения и вывода? Как только асинхронность введена, степень офф-политики уже значительна. На этой основе, действительно ли дополнительная выгода от дальнейшего согласования выше ROI, чем инвестиции тех же инженерных усилий в стабильность песочницы, оптимизацию конвейера вознаграждений или инфраструктуру наблюдаемости? У меня есть свой предварительный ответ, но я думаю, что этот вопрос заслуживает серьезного обсуждения от большего числа людей — вместо того, чтобы по умолчанию считать согласование высшим приоритетом просто потому, что это самая заметная тема. И есть причина, по которой это наиболее заметно: согласование обучения и вывода имеет четкую математическую формализацию и производит элегантные абляции — это естественно подходит для статей. Но как написать статью о стабильности песочницы? Как представить надежность оркестрации контейнеров как академическую историю? На самом деле, вы не можете. Поэтому эти проблемы коллективно игнорируются. Даже если система RL Infra достигает битового согласования обучения и вывода, общая эффективность все равно может быть ужасной — потому что узкое место переместилось куда-то еще давно. В какой степени RL Infra может быть стандартизирована? Системы вывода имеют относительно четко определенные бенчмарковые метрики — TTFT, TBT, Пропускная способность. Эти объективные индикаторы позволяют нам четко оценить влияние оптимизаций. Но какие стандарты оценки для RL Infra? Пропускная способность обучения? Эффективность образцов? Время в реальном времени от начала до конца? Оптимальная архитектура может сильно варьироваться в зависимости от сценариев (генерация кода против агента против рассуждений). Если у нас даже нет согласия по поводу того, как выглядит "хорошая RL Infra", то накопить и повторно использовать инженерные знания в этой области будет крайне сложно. Является ли RL критическим путем для улучшения возможностей модели — это суждение все еще развивается. Но если ответ да, то Infra является самым недооцененным узким местом на этом пути. Не потому, что никто не работает над этим, а потому, что коллективное внимание неправильно распределено. Жестокость Эффекта Бочки заключается в том, что независимо от того, насколько высока ваша самая высокая планка, она не может спасти систему.

инженер по трубопроводам в Хьюстоне разработал программное обеспечение для производства за 8 недель, не имея никакого опыта в программировании, в то время как большинство стартапов YC с 5 инженерами не могут выпустить продукт за 12 недель. Разница в том, что у него 20 лет опыта в понимании того, что нужно отрасли, и ни минуты, потраченной на споры о архитектуре. Это будущее вертикального программного обеспечения - созданное экспертами в своей области, поддерживаемое API вывода и абсолютно пугающее для каждой универсальной SaaS-компании, взимающей $50k/год за функции, которые специалист по торговле разработал за выходные @toddsaunders