ADLC

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

Что остаётся тем же

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

Если ADLC подаётся как что-то принципиально новое, команда начинает изобретать заново то, что уже умеет.

Что ломает классический процесс

В обычной системе поведение определяется кодом и сравнительно детерминировано. В агентной добавляется четыре источника изменчивости:

  • поведение модели вероятностно — один и тот же вход даёт разные траектории;
  • инструкции и рабочие процедуры влияют на результат не хуже кода, но живут вне кодовой базы;
  • извлечение и память меняют вход в систему без единой правки бизнес-логики (Agent Retrieval Policy, Memory Write Policy);
  • инструменты создают реальные побочные эффекты, и откат кода их не отменяет (Rollback Boundary).

Третий пункт самый коварный: корпус извлечения меняется сам по себе, то есть система меняет поведение без релиза вообще.

Следствие: тестов уже недостаточно

Классический набор тестов проверяет код при фиксированном входе. Здесь меняться может вход, инструкция, политика и корпус — по отдельности и без пересборки. Поэтому в ADLC рядом с тестами обязательно стоят оценки на наборе (Agent Evals) и оценки на трассах, а решение о выпуске принимается по обоим контурам.

Второе следствие — отдельный жизненный цикл нужен и заверению безопасности: проверенный однажды артефакт не остаётся проверенным, потому что ландшафт атак меняется быстрее релизного цикла (Continuous Red Teaming).

Начинается не с релиза

Зрелый ADLC начинается с приёма инициативы и архитектурной проверки, а не с момента, когда код готов к выкатке. Причина практическая: большая часть решений, определяющих релизный риск — какой класс автономии, какие возможности записи, какая граница отката, — принимается до первой строки кода и позже меняется дорого (ADR, CTO Challenge).

Связано с

  • Agent First Repository — довод, при котором жёсткие блокирующие гейты перестают окупаться
  • Change Classification Agent — что считается изменением и с каким риском
  • Agent Evals — контур оценок, замещающий недостающие тесты
  • Canary Release LLM — управляемый выпуск как звено цикла
  • IaC CICD AI — четырёхчастный релизный артефакт
  • Trusted Artifacts — что вообще допускается в промышленную среду
  • Agent Decommissioning — конец цикла, который обычно забывают
  • Delivery Stages AI — стадии проекта до входа в цикл эксплуатации
  • Continuous Red Teaming — жизненный цикл заверения рядом с релизным