Сегодня я прочитал длинную статью о 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, можно сказать без какого-либо нового словаря:...