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

Наиболее наглядный публичный разбор того, что это на самом деле подразумевает, можно найти в Lenny's Newsletter, где описано, как инструмент управления продуктом ChatPRD построил обвязку для автоматической отладки багов из Sentry. Эту статью стоит прочитать целиком, если вы взвешиваете, стоит ли специализироваться в этой области, потому что в ней есть момент, который легко упустить: модель никогда не была узким местом. Команда использовала Claude Agent SDK в качестве основы, а затем потратила основную часть инженерных усилий на создание собственного терминального интерфейса и набора адаптеров, соединяющих агента с Sentry, Linear, GitHub и Vercel. Вот, в миниатюре, в чём заключается эта работа. Четыре системы, четыре разные схемы авторизации, четыре разных формата данных и интерфейс, позволяющий человеку наблюдать и вмешиваться, не приглядывая за каждым шагом.

Из чего на самом деле складывается «обвязка»

Если вы пытаетесь понять, стоит ли развивать этот набор навыков, полезно разбить его на части, которые нанимают по отдельности — или, по крайней мере, оценивают по отдельности на собеседовании:

  • Проектирование прав доступа. Решение о том, что агенту разрешено делать без присмотра (прочитать тикет, набросать PR), а что требует участия человека (слияние, деплой, удаление, трата денег) — и закрепление этого в виде реальной политики в коде, а не в виде инструкции в промпте, которую модель может проигнорировать под давлением. Это ближе к инженерии контроля доступа, чем к написанию промптов.
  • Адаптеры инструментов. Тонкие, хорошо протестированные обёртки вокруг каждой внешней системы (Sentry, Linear, GitHub, Vercel — или что там есть в стеке вашей компании), которые переводят намерение агента в безопасный, валидированный вызов API и переводят ответ обратно в форму, понятную модели для рассуждений. Это обычная разработка ПО — обработка ошибок, повторные попытки, валидация схем — применённая к новому потребителю.
  • Терминальный или консольный интерфейс. Способ для человека видеть, что делает агент, одобрять или отклонять действия и вмешиваться, когда тот застревает. ChatPRD создали собственный интерфейс; многие команды вместо этого будут использовать готовые консоли для агентов, но кому-то всё равно придётся решать, что показывать, что скрывать и что требует клика перед выполнением.
  • Выбор инструментов в масштабе. Материал от Machine Learning Mastery отмечает нечто, что стоит знать, если вы строите что-то более сложное, чем демо: точность работы агента с вызовами инструментов, как правило, снижается, когда каталог инструментов превышает примерно дюжину вариантов — модель начинает неправильно вызывать инструменты, галлюцинировать параметры или зависать на неудачных вызовах. Перечисленные меры смягчения (ограничение того, какие инструменты вообще видны в данном контексте, поиск инструментов на основе retrieval, маршрутизация к специализированным субагентам, явные шаги планирования, логика отката и эталонные тесты для отслеживания регрессий) сами по себе представляют собой чек-лист вещей, которые инженер, строящий обвязку, должен уметь реализовать, а не просто знать о них.
  • Инженерия контекста и памяти. Тот же источник проводит различие, которое стоит усвоить: инженерия контекста (что попадает в один вызов инференса и куда) и инженерия памяти (что сохраняется между сессиями, как это хранится, как извлекается) — это разные дисциплины с разными сценариями отказа. Утверждается, что большинство сбоев в долгоживущих, многосессионных агентах восходят к смешению этих двух вещей — когда память сессии трактуют просто как ещё один контекст, или наоборот — особенно в тот момент, когда система решает, что именно извлекать.

Свидетельства того, что это реальная, финансируемая роль — а не просто нишевое увлечение любителей

Скептики резонно спросят, является ли «инженер обвязки» отдельной должностью или просто задачей внутри чьей-то другой работы. Два факта из подборки говорят о том, что дело движется в первом направлении. Во-первых, команда Aspire из Microsoft — состоящая из 10 человек — использовала GitHub's Agentic Workflows для автоматизации PR с документацией между репозиториями и за два релиза влила 82 PR со средней задержкой 44,8 часа после выхода соответствующего PR с продуктом, без найма новых сотрудников и без переобучения процессов. Это небольшая команда, получающая непропорционально большой рычаг влияния именно потому, что кто-то вложился в создание каркаса (определения workflow, маршрутизация ревью, логика триггеров), а не заставлял инженеров вручную писать PR с документацией. Во-вторых, проект SkillOpt от Microsoft Research рассматривает файлы «навыков» агента — инструкции и ограничения, формирующие поведение агента внутри его обвязки — как нечто, подлежащее систематической оптимизации, а не ручному редактированию, и сообщает, что этот подход показал лучший или сопоставимый с лучшим результат во всех 52 ячейках сетки бенчмарков (шесть бенчмарков, семь моделей, три режима исполнения), причём оптимизированные навыки переносились между разными моделями и разными обвязками. Станет ли этот конкретный инструмент стандартом или нет, он сигнализирует, что индустрия начинает относиться к конфигурации обвязки как к инженерному артефакту со своим собственным инструментарием и бенчмарками — та же траектория, что превратила «DevOps» из набора самодельных скриптов в отдельную дисциплину.

Также сейчас строится инфраструктура, создаваемая специально для этого уровня. Недавно анонсированные Google возможности «Managed Agents» в Gemini API — фоновое и асинхронное исполнение, интеграция с удалёнными MCP-серверами, пользовательский вызов функций, обновление учётных данных между взаимодействиями — по сути представляют собой готовую сантехнику для тех самых проблем, которые команда ChatPRD решала вручную. Это обычная закономерность: то, что одна команда собирает кустарным способом в этом году, поставщик платформы превращает в продукт в следующем. Это не устраняет роль инженера обвязки; это поднимает планку и смещает работу в сторону интеграции и настройки управляемых примитивов, а не написания каждого адаптера с нуля — примерно так же, как облачная инфраструктура не устранила инженеров эксплуатации, а изменила то, на что они тратят своё время.

Что это значит, если вы нацелены на эту роль

Несколько конкретных, проверяемых вещей, которые стоит добавить в портфолио или резюме, если вы хотите выглядеть убедительно в этой работе: постройте один адаптер полностью, от начала до конца, для реального API, который вы не контролируете (включая авторизацию, обработку ошибок, лимиты запросов, а не демо по счастливому сценарию); спроектируйте и задокументируйте модель прав доступа для агента, различающую действия «прочитать/предложить/выполнить», и покажите, почему каждая граница проведена именно там; и постройте или настройте интерфейс ревью, где человек одобряет действия агента перед их выполнением, поскольку это тот элемент, на котором будет настаивать большинство компаний, прежде чем позволить агенту касаться продакшена. Если вы оцениваете предложение о работе инженером обвязки или очерчиваете собственные обязанности, спросите прямо, кто отвечает за модель прав доступа, кто отвечает за адаптеры и кто отвечает за поверхность ревью человеком — во многих командах сейчас у этих трёх вещей нет чёткого владельца, и именно этот пробел эта роль и формируется, чтобы заполнить.

Одна оговорка, которую стоит проговорить прямо: ни один из вышеперечисленных источников не приводит конкретных цифр по рынку найма для этой должности, и «инженер обвязки» — это пока не то название должности, которое вы увидите в вакансиях, — оно фигурирует внутри таких названий, как «инженер по инфраструктуре ИИ», «инженер платформы агентов» или просто «старший бэкенд-инженер, ИИ-системы». Относитесь к этому как к набору навыков, который нужно развивать и точно описывать, а не как к названию должности, которое стоит искать на LinkedIn.