Критика игнорирования harness-engineering в больших технологиях и необоснованные дискуссии о поколениях loops

После выхода статьи AI Times, посвящённой игнорированию harness-engineering в больших технологиях, несколько технологических лидеров обменялись мнениями. Согласно докладам, после Google и OpenAI выступили с мнением, что модели нового поколения смогут поглотить значительную часть текущей функциональности harness.

Это эссе добавляет к этому обсуждению дополнительное мнение. Начну с выводов: я согласен с прогнозом, что большинство harness исчезнут. В своём посте «Полное объяснение harness-engineering — рождение, концепция, разрывы и будущее в одной статье» я уже писал, что сложные harness, созданные для компенсации слабых сторон моделей, быстро заменяются по мере совершенствования моделей.

Однако расширить это на весь harness-engineering было бы ошибкой. Проблема поглощения функций моделями отличается от проблемы управления ответственностью, когда человек и организация доверяют работу AI.

Сначала нужно рассмотреть, как распространяются технологические ключевые слова

Однако технологические ключевые слова часто потребляются в стране иначе, чем за её пределами, с другими значениями. Поэтому сначала я провел проверку. На этот раз также нужно различать исходные высказывания, реальные технологические дебаты и фреймы, созданные в стране.

Из поста «Полное объяснение harness-engineering — рождение, концепция, разрывы и будущее в одной статье» — сравнение потребления ключевого слова harness-engineering в глобальном масштабе и в Корее.

На этот раз я действую осторожно в отношении расширения интерпретации, потому что в англоговорящих источниках не было явного свидетельства того, что фразы "harness is dead" или "harness is useless" широко используются. Дискуссии ближе к тому, что улучшается способность модели использовать инструменты, некоторые строительные леса поглощаются моделью или платформой, а срок службы сложных ручных слоев координации может сократиться. Высказывание вице-президента Нома Брауна я непосредственно не проверял вплоть до исходного источника — я узнал об этом через местные и международные сообщения. Поэтому давайте рассмотрим сам фреймворк «аргумента о бесполезности harness-engineering», который быстро закрепился в стране.

Harness, который исчезает, и harness, который должен остаться, это разные вещи

Harness, который исчезает, ясен. Способ, при котором нужно разбивать промпты на несколько этапов, временные правила для обхода дефектов определённой модели, поверхностные рабочие потоки, в которых люди искусственно фиксируют порядок вызовов инструментов — это может быть поглощено по мере совершенствования моделей. Такой harness исчезнет, и это правильно.

Однако, как подвёл итог руководитель A2Sys Донг Су Ли, расширение этого на весь harness опасно. Вкратце это выглядит так:

• Harness для промптов и рабочих потоков может быть поглощен моделями. Согласен.
• Harness для выполнения инструментов имеет дело с разрешениями, одобрениями и восстановлением после сбоев. Это действительно harness, который исчезнет?
• Harness для времени выполнения, памяти и инфраструктуры имеет дело с контекстом, кэшем, маршрутизацией моделей, затратами, задержкой и журналами аудита. Я считаю, что это также сложно назвать harness, который исчезнет.

Суть harness, о которой я говорил с 7 по 11 главы в «Harness-engineering: Re:Zero of AI Software Engineering», находится именно здесь. Контракты устанавливают допустимые границы, структура и изоляция сужают область изменений, отслеживаемость и проверка связывают исходные цели с фактическими результатами. Измерение и управление контролируют затраты, разрешения, сбои и восстановление. Harness-инженерия в этом диапазоне — это не то, что разрешается по мере совершенствования моделей.

С другой стороны, также верно, что harness, loop и prompt-инженерия — это человеческие эвристики. Все методологии начинаются с эвристик. Типы, тесты, CI, проверка кода и разделение разрешений — всё это методы, которые люди создали для работы со сложными системами. Но что более важно здесь — можем ли мы доверить прозрачность и ответственность передовой модели? Если вы дали задание, то вы не можете самостоятельно проверить, работает ли она должным образом в соответствии с вашим намерением или выходит за границы ответственности и вызывает проблемы. Конечно, может быть AI, который следит и исправляет это, но тогда это harness.

Я написал эту позицию в комментариях к посту профессора Сан-Ки Хана.

Кажется, это зависит от того, насколько далеко мы смотрим на harness-инженерию. Пока существуют намерения организации и разработчиков, я считаю, что это будет трудно исчезнуть.

По мере того как модели становятся более умными, возрастает и вероятность того, что AI более ловко создаст что-то совершенно неправильное. Поэтому harness — это не инструмент коррекции слабых сторон модели, а инструмент управления для фиксации направления и ответственности.

На практике граница ответственности важнее, чем способность модели

Nextain сотрудничает с клиентами разработки через Discord. И сегодня я поместил агента Claude Code, который решал конкретную проблему, в этот канал. Агент Nextain, участвующий в Discord (на самом деле это Claude Code, работающий на сервере), читает канал Discord и отвечает.

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

Кроме того, после первого запуска агент начал работу сразу после услышания требований, что расстроило людей, давших задание. Поэтому я дал указания по бизнес-процессу. Когда услышите требования, подтвердите, что услышали, проводите анализ, составляйте план, снова сообщите план в канал Discord, и начните работу. И, наконец, по завершении работы подайте окончательный отчёт, и если возникнут проблемы, позвоните мне (разработчик-лидер) и спросите о решениях в Discord.

Суть этого harness — разработка Nextain и полномочия каждого члена. Будет ли модель, если она передовая, сама работать оптимальным образом? Есть ли вообще один оптимальный способ? Согласованность организационных процессов и рабочих потоков — это в итоге harness. Эта граница ответственности не зависит от способности модели. По мере того как модели способны выполнять больше работы, граница того, что можно делать, и где нужно остановиться, должна быть установлена ещё более строго.

Реальные проблемы — это дрейф и затраты

Проблема, с которой сталкиваются разработчики, использующие Codex и Claude на практике, все ещё дрейф. Даже при сужении целей они смещаются в разные стороны, вносят изменения, которые не должны быть внесены, переписывают тесты и говорят, что они пройдены, пропускают границы операционных разрешений. По мере того как модели становятся более сложными, эта проблема может быть скрыта более плавно.

На этот раз ответ "просто включи это больше раз" работает для больших технологий. Они могут увеличить время вывода, создать больше кандидатов, отбросить неправильные пути и добавить внешнюю проверку. Однако обычные разработчики и небольшие стартапы, которым нужно экономить каждую копейку, не могут. Ситуация в отечественных (корейских) компаниях аналогична.

В упомянутых выше комментариях к профессору Сан-Ки Хану бывший главный советник по будущему AI Чон У Ха упомянул "общую эффективность затрат на токены". Это именно тот критерий. Harness — это не устройство для отказа от передовой модели. Это устройство контроля затрат для отделения дорогостоящих моделей от действительно необходимых суждений и выполнения повторяющейся работы с помощью небольших моделей, локальных инструментов, скриптов и детерминированных проверяющих программ.

Недавно опубликованные математические достижения OpenAI также необходимо разделить на два момента времени. Я высоко оцениваю первое достижение, связанное с контрпримером гипотезы Эрдёша о расстояниях на плоскости, поскольку оно показывает возможность обнаружения новых математических связей, отличных от существующих подходов. Это пример, который демонстрирует возможность открытий, которые могут сделать только AI.

С другой стороны, вычисления во время тестирования, которые позже получили больше внимания, идут в направлении введения большего количества вычислений, исследования кандидатов, проверки и итераций во время вывода. Это важная технология. Но если говорить об этом только как об улучшении чистого интеллекта одной модели, исчезает структура затрат. Это техника "войны экранов", но техника, особенно благоприятная для больших технологий.

Harness — это оборонительная линия затрат и данных

"Модели будут пожирать harness" — это провокационный лозунг. Но вопрос о том, кто и по какой цене использует эту модель, — это отдельная проблема. По мере того как модели поглощают больше функций, код пользователя может упроститься. Одновременно можно стать зависимым от более тяжелых и дорогих вызовов моделей. Сложность не исчезает — она перемещается с рабочего места пользователя на уровень выставления счётов поставщика моделей.

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

Хороший harness отправляет только необходимый контекст внешней модели, а остальное остаётся на рабочем месте пользователя. Он маршрутизирует модели, переиспользует кэш, разделяет разрешения и добавляет воспроизводимую проверку. Поэтому harness — это оборонительная линия затрат и оборонительная линия данных.

С этой точки зрения также возможно, что глобальные компании-модели найдут утомительным сильный harness со стороны пользователя. Если пользователь сначала обрабатывает малыми моделями и локальными инструментами, а передовую модель вызывает только в необходимый момент, то количество вызовов и передаваемый контекст сокращаются. Это фактически не предположение, а естественное рассмотрение конфликта интересов в структуре отрасли, где затраты на разработку, вывод, GPU и электроэнергию передовых моделей растут.

OpenAI и Anthropic находятся на передней линии конкуренции harness через Codex и Claude Code. Между тем Google одновременно является компанией-моделью и облачным провайдером. Я не могу сказать, что все компании имеют абсолютно одинаковые интересы, но причина, по которой сложно слушать эту дебату как чистый технический прогноз, очевидна. Хороший harness снижает "желание больших технологий переместить рабочее место в модель, собрать данные и снизить зависимость от использования передовой модели".

Loop не является стандартом нового поколения

То же самое верно для loop. Я использую loop, но я считаю, что для большинства задач лучше не использовать loop. Если это работа, при которой результаты будут приемлемы, даже если её доверить обычному разработчику, вероятно, дешевле и быстрее использовать хорошую модель один раз правильно. Случаи, когда loop действительно эффективен, ограничены.

Первый — это научные исследования и разработки. Это работа без правильного ответа, где гипотеза изменяется в зависимости от результатов экспериментов, и следующий эксперимент должен активно измениться на основе предыдущих результатов. Наши внутренние исследования голоса и пения похожи на это. В этом случае несколько AI рецензируют результаты экспериментов и все данные, и определяют продолжительность с предыдущими экспериментами, наличие дрейфа и необходимость следующего цикла. Критерии завершения — это не похожий результат, а суждение о том, что показатели больше не растут. Так как целью является сходимость исследования, loop подходит.

Второй — это использование небольших моделей в ограниченных условиях. Небольшие LLM склонны сокращать цели и останавливаться на "этого достаточно". Но в этом случае то, что требуется, — это не длительный loop, а устройство, которое сужает цели и условия завершения. Это больше похоже на функцию goal в Claude Code, чем на loop. Если вы массово распределяете loop в повседневных задачах обычного пользователя, это будет пустой тратой затрат. Используйте loop для сходимости исследования и harness для фиксации целей и ответственности. Это не взаимозаменяемо.

Naia стремится сохранить рабочее место на стороне пользователя

Naia не отвергает передовую модель. Мы намерены в полной мере использовать облачную флагманскую модель в разработке. Хорошие модели нужно использовать.

Однако мы не намерены передавать все рабочие места и данные платформе больших технологий. То, к чему стремится Naia, — это структура, которая вместе использует локальное, P2P, open-weight, небольшие модели, детерминированные проверяющие программы и явный harness разрешений. Используйте дорогостоящую передовую модель для необходимых суждений, но оставьте базовое рабочее место в руках пользователя.

С этой точки зрения развитие open-weight моделей, таких как DeepSeek, Qwen, Kimi, и GLM, имеет важное значение. Становится возможно комбинировать модели в зависимости от цели, защищать данные локально и вызывать закрытую передовую модель только в нужный момент. В Корее стратегии независимых моделей компаний, таких как Upstage и Naver, также имеют смысл в этом контексте. Вместо того чтобы просто следовать передовой модели глобальных больших технологий, путь, который хорошо связывает open-weight, независимые модели, специализированный harness и корейский контекст работы, может быть более реалистичным.

Модели можно одолжить. Но нет необходимости одалживать рабочее место и данные.

Заключение: То, что требуется, это дискуссия на техническом уровне, а не аргумент о бесполезности

Harness, который исчезает, исчезнет. Функции, которые поглощают модели, будут расширяться. Нет причин отрицать это. Однако я не верю, что исчезнут функции, которые поглощают модели, система исполнения, которая фиксирует намерения и ответственность организации, и система управления, которая защищает границы затрат и данных. Если субъектом, дающим работу AI, является человек, и субъектом, несущим ответственность за результаты, также является человек, то контракты, структура, отслеживаемость, проверка и управление не исчезнут.

Теперь я бы хотел отказаться от дебатов о ключевых словах, таких как "harness мёртв" или "harness жив". Я бы предпочел видеть подлинные технические дебаты, такие как что поместить внутри модели, что оставить под контролем пользователя и организации, как проверить дрейф и повернуть его вспять, и кто будет нести затраты на токены и риск утечки данных.

Ссылки и источники

Мои сочинения и книги

• «Harness-engineering: Re:Zero of AI Software Engineering»
• 「Полное объяснение harness-engineering — рождение, концепция, разрывы и будущее в одной статье」
• 「Новость о выпуске harness-engineering」

Прямой повод для этого обсуждения

• AI Times, "После Google, OpenAI также '...модели будут поглощать harness'. Модели нового поколения будут поглощать функции"
• AI Times, "[25 июня] 'Модели будут пожирать harness'..."
• Пост профессора Сан-Ки Хана на Facebook и дискуссия в комментариях
• CEO A2Sys Донг Су Ли: "Бесполезность harness? Половина верна, половина неверна"

Оригинальные материалы и технические ресурсы

• OpenAI, "Learning to Reason with LLMs"
• OpenAI, "An OpenAI model has disproved a central conjecture in discrete geometry"
• OpenAI, "Introducing Codex"
• OpenAI, "Introducing OpenAI o3 and o4-mini"
• Google, "Gemini 2.0: our new AI model for the agentic era"
• "The Interplay of Harness Design and Post-Training in LLM Agents"
• "More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding"
• "AutoHarness"