Инженерия автономных ИИ-агентов: обвязки harness, пайплайны от ТЗ до MR и контроль архитектурного дрейфа

Показать красивую демонстрацию возможностей современной нейросети сегодня способен любой школьник: достаточно попросить большую языковую модель решить алгоритмическую задачу из LeetCode или набросать страницу авторизации на чистом HTML. Но в реальной промышленной разработке эйфория быстро сменяется похмельем. Когда автономному агенту доверяют крупную кодовую базу с десятками микросервисов или сотнями экранов мобильного приложения, через две-три недели проект рискует погрузиться в хаос.

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

На третьем митапе инженерного сообщества Devhands AI Club ведущие практики из Wildberries, 2ГИС и сервиса «Звук» под кураторством Алексея Рыбака поделились реальным промышленным опытом: как обуздать автономию генеративных моделей, выстроить вокруг них строгие инженерные обвязки (harness), разделить путь задачи на четкие контрольные фазы и программно заблокировать архитектурную деградацию системы.

Почему изолированная модель неизбежно разрушает систему

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

Если агенту поручить добавить отправку аналитики при нажатии кнопки в интерфейсе, он без колебаний импортирует сетевой HTTP-клиент прямо в UI-компонент, вместо того чтобы пробросить доменное событие через слои архитектуры. Локальный тест кнопки проходит успешно, но чистота слоев нарушается. Через двадцать подобных правок проект перестает масштабироваться.

Успех внедрения автономной разработки определяется не генеративными параметрами LLM, а строгостью внешней инженерной среды: структурой harness-обвязок, автоматическими гейтами верификации и тестами, блокирующими дрейф архитектурных абстракций.

Анатомия надежного harness: изоляция, контекст и разделение ролей

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

Опыт Дмитрия Полищука из объединенной компании RWB (Wildberries) при создании фреймворка xpowers для автономной генерации мобильных приложений раскрывает ключевые принципы построения такой обвязки:

1. Изоляция файловой системы: агент никогда не должен работать в основной рабочей ветке. Для каждой задачи динамически создается изолированный Git worktree. Сетевые вызовы наружу блокируются, за исключением явно разрешенных локальных эмуляторов или прокси-серверов.
2. Разделение моделей по специализации: попытка использовать одну универсальную флагманскую модель на всех этапах неэффективна как экономически, так и архитектурно. В xpowers используется четкое ролевое разделение: модели с сильным пространственным мышлением (такие как семейство Claude) отвечают за проектирование UI-компонентов, экранных переходов и дизайн-системы, тогда как генерацию типового бойлерплейта, сетевых DTO и адаптеров баз данных делегируют быстрым специализированным моделям (например, DeepSeek-Coder или Qwen).
3. Отказ от статичных многостраничных ТЗ: подробные документы Software Design Document (SDD) на десятки страниц устаревают в первый же час автономной работы. Гораздо надежнее работают короткие итеративные циклы обратной связи: микрозадача → генерация кода → мгновенный прогон компилятора и линтера → корректировка ошибок на лету.

Сквозной конвейер: как 2ГИС делит путь от ТЗ до мердж-реквеста

Второй важнейший аспект промышленной автоматизации — структурирование жизненного цикла задачи. Никита Федосов из 2ГИС продемонстрировал, как неструктурированная разработка превращается в прозрачный дискретный пайплайн из пяти последовательных стадий.

Первая стадия — уточнение требований (Clarification). Агент получает исходный тикет из таск-трекера и сканирует репозиторий. Если в описании задачи обнаружены противоречия или не описаны граничные сценарии обработки ошибок, агент формирует список вопросов человеку. До получения ответов кодогенерация не начинается.

Вторая стадия — декомпозиция и план изменений (Task Breakdown). Агент составляет список файлов, подлежащих созданию или правке, и описывает сигнатуры новых интерфейсов. Этот план фиксируется в контракте задачи.

Третья стадия — цикл реализации (Implementation Loop). Здесь агент получает полную локальную свободу: он редактирует файлы, запускает локальные юнит-тесты и исправляет возникающие ошибки компиляции без участия человека. Количество итераций в цикле строго лимитируется (например, не более 8–10 попыток), чтобы предотвратить зацикливание модели при сложных багах.

Четвертая стадия — контрольный гейт (Verification Gate). Это автоматический шлюз, не зависящий от агента. На этой фазе запускаются полные проверки кодовой базы: строгий тайпчекинг, линтинг, форматирование, интеграционные тесты и проверка архитектурных инвариантов.

Пятая стадия — формирование мердж-реквеста (Pull Request Assembly). Если все проверки пройдены, агент оформляет ветку в репозитории, генерирует понятное описание изменений и отправляет PR живому инженеру на код-ревью. Окончательное решение о слиянии кода с основной веткой всегда остается за человеком.

Контроль архитектурного дрейфа: проект «Атлас» и инварианты как код

Самый коварный вызов автономной кодогенерации — архитектурный дрейф (code drift). Павел Литвиненко из сервиса «Звук» в рамках проекта «Атлас» исследовал феномен постепенной деградации кодовой базы при регулярной работе агентов.

Агент мыслит локально: для него зеленый статус тестов означает безупречное выполнение работы. Однако если в проекте принята чистая или гексагональная архитектура (Clean Architecture), агент может легко нарушить правило направленности зависимостей. Стоит модели единожды завязать доменную сущность на конкретную библиотеку работы с сетью или базой данных, как архитектурная чистота начинает расползаться по всему проекту.

Решением проблемы выступает концепция «архитектурных инвариантов как кода». В тестовый набор проекта добавляются автоматические тесты структуры, анализирующие AST (абстрактное синтаксическое дерево) и граф модульных зависимостей:

• Модули ядра (Domain) не имеют права импортировать ничего из слоя инфраструктуры (Infrastructure) или пользовательского интерфейса (UI);
• Любое внешнее взаимодействие должно осуществляться только через явные интерфейсы (порты и адаптеры);
• Запрещено прямое межмодульное связывание в обход публичных фасадов (public API packages).

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

Практический контракт: конфигурация пайплайна и тесты целостности

Взглянем, как описывается подобный многостадийный пайплайн в конфигурационном файле оркестратора. Декларативная структура фиксирует роли агентов, доступные инструменты и строгие условия прохождения гейтов:

# pipeline-agent-config.yaml — Конфигурация сквозного пайплайна разработки с контрольными гейтами
pipeline:
  name: automated-feature-delivery
  stages:
    - id: requirements-refinement
      role: architect
      skills:
        - issue_reader
        - prompt_human_clarification
      gate:
        type: human_approval_required

    - id: autonomous-implementation
      role: coder
      skills:
        - filesystem_edit
        - run_local_tests
      max_iterations: 8
      harness:
        isolate_git_worktree: true
        allow_network: false
      gate:
        type: automated_command_suite
        commands:
          - "npm run lint"
          - "npm run typecheck"
          - "npm run test:unit"

    - id: architectural-integrity-gate
      role: auditor
      skills:
        - dependency_graph_analyzer
      gate:
        type: automated_command_suite
        commands:
          - "npm run test:architecture-invariants"

    - id: pull-request-handoff
      role: release_manager
      skills:
        - git_push_branch
        - create_pull_request
      gate:
        type: human_merge_required

Второй ключевой элемент защиты — автоматический тест архитектурных инвариантов, написанный на стандартном тестовом фреймворке (например, Vitest или Jest) с использованием статического анализатора импортов:

// tests/architecture-invariants.test.ts — Тест защиты от архитектурного дрейфа ИИ-агентов
import { describe, it, expect } from "vitest";
import { scanModuleImports } from "./tools/ast-dependency-scanner";

describe("Контроль архитектурных инвариантов репозитория", () => {
  it("Доменный слой не должен зависеть от инфраструктурных адаптеров", () => {
    // Сканируем все файлы доменной логики на предмет прямых импортов из папки infrastructure
    const illicitImports = scanModuleImports({
      scanDirectory: "src/core/domain",
      disallowedPatterns: [
        /^@infrastructure\/.*/,
        /^\.\.\/.*infrastructure\/.*/,
        /^axios$/,
        /^pg$/,
      ],
    });

    // Если автономный агент напрямую подключил базу данных или HTTP-клиент в домен,
    // тест падает с перечислением конкретных строк и файлов нарушений
    expect(illicitImports).toEqual([]);
  });

  it("Все сервисы приложения обязаны реализовывать типизированные интерфейсы", () => {
    const uncontractedServices = scanModuleImports({
      scanDirectory: "src/core/services",
      enforceInterfaceContracts: true,
    });

    expect(uncontractedServices).toHaveLength(0);
  });
});

Если агент попытается обойти интерфейс или зашить прямой SQL-запрос внутрь доменной модели, контрольный гейт не пропустит изменения, а модель получит четкую ошибку валидации и перестроит архитектуру в соответствии с правилами проекта.

Инженерный вердикт: новая роль разработчика в агентную эпоху

Переход от диалоговых ассистентов к автономным агентным конвейерам коренным образом меняет профессию разработчика. Программист перестает быть простым наборщиком символов, тратящим дни на реализацию рутинных CRUD-операций и механическое сопоставление типов.

В новой парадигме главная ценность инженера смещается в сторону системного проектирования:

1. Проектирование обвязок (Harness Engineering): настройка безопасных изолированных сред, управление инструментами и динамическим контекстом;
2. Формализация инвариантов: формулирование правил архитектуры в виде исполняемого кода и статических анализаторов;
3. Качественная декомпозиция задач: четкое описание бизнес-требований и критериев приемки;
4. Финальное ревью: критическая оценка предложенных агентом решений на верхнем уровне архитектуры.

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