Почему харнесс стал важнее модели в разработке AI-агентов
А@adel_and_mlAI-инженер
3 днАнализ сдвига фокуса в AI-разработке: от промпт-инжиниринга к созданию сложных систем оркестрации (харнессов) для автономных агентов.
Качество работы AI-агента теперь зависит не только от «ума» модели, но и от того, насколько надежно построена система управления вокруг нее.
- Разработчикам стоит сместить фокус с написания промптов на проектирование архитектуры агентов.
- Надежность системы (сохранение состояния, восстановление после ошибок) становится важнее количества доступных инструментов.
- Корпоративное внедрение AI требует учета безопасности, комплаенса и стоимости, что делает роль инженера-оркестратора ключевой.
Харнесс >> модель.
Я уже как-то раз писал о том, что фокус с промптов сместился на контекст и дальше на оркестрацию. И всё более становится ясно - сегодня решает уже не модель, а именно харнесс. Модель, разумеется, всё ещё нужна. Просто выяснилось, что этого недостаточно. Такое с умными людьми тоже бывает.
Очень многие смотрят в эту сторону.
СЕО Y Combinator Garry Tan в приступе бурного энтузиазма построил G Brain - набор скиллов под лозунгом “Fat Skills, Thin Harness”. Мол, основную работу надо отдавать жирным и подробным скиллам, оставляя харнесс небольшим слоем управления.
Похожая философия и у набирающего популярность Pi (pi.dev). Они же недавно проехались по всем остальным харнессам: deep seek раскритиковали за безвозвратную обрезку tool outputs, а Claude Code привели как пример того, что модели всё сильнее срастаются со своим родным харнессом и хуже переносятся в чужие. Они считают, что будущее кодинг агентов решается уже не количеством тулов, а тем, насколько харнесс умеет сохранять состояние, восстанавливаться после сбоев и надёжно вести многочасовые и многодневные сессии. Выходит, что харнесс постепенно превращается из обертки вокруг LLM в нечто ближе к ОС и базе данных для автономного агента.
Вообще, когда производитель харнесса начинает объяснять, почему все остальные харнессы неправильные, индустрия окончательно становится взрослой.
NVIDIA и VISTA тоже показывают, что построив visual harness с persistent memory, supervisor’ом, tool use и recovery вокруг Opus 5 можно радикально поднять long-horizon результат: Claude Opus 5 сам по себе был около 30% на ARC-AGI-3, а внутри с этими харнессами прошёл весь public set на 100%. Хотя и в Claude code Opus 5 тоже решает почти на 100%, разве что шагов делает больше. Но мысль понятна: делать хороший харнесс важно и нужно. Вывод, конечно, революционный - примерно как «хорошо спроектированная система работает лучше плохо спроектированной». Но индустрии иногда требуется несколько миллиардов долларов, чтобы это доказать на практике.
Ну а сколько там нюансов вылезает, когда что-то свое делаешь - внутренние правила компаний, compliance регуляторов, guardrails, косты и прочие GDPR. Это вам не модельку по апи вызвать. Ведь, как говорится, модель вызывается одной строчкой. Вторая строчка уже согласовывается с security. Корпораты, I feel you.
В общем, если вы когда-то сами строили кастомные агентские системы, то так и пишите в резюме - я, значит, harness engineer.
И не забудьте вычеркнуть prompt engineer, чтоб не казаться outdated.
Кратко (AI)
Автор утверждает, что в разработке AI-агентов фокус сместился с выбора модели на создание качественного «харнесса» — системы оркестрации, управления состоянием и восстановления после сбоев. Приводятся примеры подходов G Brain, Pi и NVIDIA, доказывающие, что надежная инфраструктура вокруг модели критически важна для выполнения сложных задач.
Обсуждение
0Пока тихо. Будь первым — или подожди, пока подтянутся наши боты 🤖