Средовой подход к ИИ-агентам - методология проектирования условий, в которых инженер не ведёт агента по шагам, а заранее создаёт среду: границы, стимулы, зоны ответственности, следы и правила отбора. Агенты внутри такой среды сами разбираются с требованиями, пишут код, добавляют тесты и меняют систему. Человек принимает результат по заранее заданным проверкам, а не по ощущению, что он видел каждую строку.
Методологию предложил Руслан Сафин: он описывает средовой подход как способ проектировать условия, в которых агенты создают системы, и определять, на каком основании принимать их результат. Ключевой тезис: скорость генерации кода растёт, а способность осмысленно принимать результат не ускоряется автоматически. Узкое место смещается к проектированию среды и критериев пригодности.
Ниже - практическая разборка подхода: пять примитивов среды, пример с адаптерами к API служб доставки, различие между процессом создания и требованиями к продукту, риски и цикл запуска. Часть механизмов уже знакома по CI и harness-обвязкам. Часть остаётся гипотезами, которые автор предлагает проверять, а не принимать на веру.
Что такое средовой подход и почему он меняет роль инженера
Средовой подход отвечает на вопрос: какие условия создать заранее, чтобы агенту можно было делегировать больше работы и при этом понимать, на каком основании принимать результат. Инженер перестаёт быть диспетчером промптов и становится проектировщиком среды. В этой роли он задаёт не последовательность действий, а свойства пространства, в котором агент действует.
Роль человека, принимающего результат, тоже меняется. Он не пытается прожить весь путь к результату и не читает каждую строку. Он проверяет, что результат прошёл заранее описанные проверки, а сомнительные случаи разбирает точечно. Это снижает нагрузку на внимание, но повышает требования к качеству проверок.
Чем средовой подход отличается от пошагового управления агентом
Пошаговое управление выглядит так: инженер формулирует задачу, читает вывод агента, корректирует, повторяет. Внимание инженера линейно масштабируется с числом шагов. Чем больше задач и агентов, тем больше диспетчерской работы. В пределе инженер становится бутылочным горлышком: агенты готовы работать параллельно, а согласование идёт через одного человека.
Средовой подход меняет точку приложения усилий. Инженер один раз проектирует границы, стимулы и проверки. Дальше агенты работают внутри среды, а человек подключается на этапе приёмки. Аналогия с CI: никто не проверяет вручную каждый коммит, если настроены линтеры, тесты и политики ветвления. Проверка встроена в процесс, а не выполняется отдельным героическим усилием.
Ограничение простое. Средовой подход не отменяет ручной разбор там, где цена ошибки высока или среда ещё не отлажена. На старте проверки могут пропускать классы дефектов, и тогда человеку приходится смотреть больше, чем хотелось бы. Это не провал подхода, а сигнал, что правила среды требуют доработки.
Почему доверие к результату становится отдельной инженерной задачей
Обычно доверие к коду возникает из знания того, как он получился. Инженер сам написал важный кусок, обсудил решение с коллегой, посмотрел diff. Он прожил путь к результату, поэтому может за него отвечать. При агентской разработке этот путь не проживается. Агенты разобрались с требованиями, написали код, добавили тесты, проверки зелёные, а времени на разбор каждого изменения нужно больше, чем на само создание.
Отсюда две крайности. Первая: проверять всё до последней строчки и терять выигрыш от автоматизации. Вторая: махнуть рукой, раз тесты зелёные. Обе плохи. В первом случае человек становится узким местом. Во втором ответственность передаётся набору проверок, качество которых никто не оценивал.
Задача архитектора - сделать так, чтобы доверие опиралось на заранее спроектированные проверки, а не на иллюзию прожитого пути. Для этого нужно ответить на неприятные вопросы. Какие свойства продукта обязаны сохраняться? Какие изменения недопустимы? Кто и как проверил, что тесты действительно проверяют требование, а не подогнаны под код? Что произойдёт, если результат придётся откатить?
Почему код производится быстрее, а способность отвечать за него - нет
Написание кода уже поддаётся автоматизации. Решение о том, что считать пригодным результатом, осталось за человеком. Автор формулирует это прямо: код производить быстрее можно, а способность отвечать за него не ускоряется автоматически. В этом месте и возникает разрыв между скоростью генерации и скоростью приёмки.
Типичный сценарий. Вечером агентам оставлена задача. Утром готова работа: код, тесты, все проверки зелёные. Вопрос «вы будете это релизить?» вскрывает проблему. Зелёные тесты не отвечают, какой продукт изменился и что именно поменялось в поведении. Они не говорят, кто писал тесты и прочие проверки. Не показывают, можно ли будет откатиться и к каким знаниям был доступ у агентов.
Список вопросов к приёмке шире списка проверок:
- Какой продукт получился и какие обещания он выполняет?
- Что изменилось по сравнению с предыдущей версией?
- Кто писал тесты и проверки, не подогнаны ли они под код?
- Можно ли откатить изменение без потери данных и без ручной сборки?
- К каким знаниям и сервисам имели доступ агенты?
Вывод: узкое место смещается к проектированию среды и критериев пригодности. Это новая задача для архитекторов. Нанимать больше ревьюеров можно, но это масштабирует ручной труд, а не уменьшает неопределённость. Тезис о смещении узкого места остаётся авторской гипотезой и позицией, а не измеренным результатом. Проверять его стоит на своём процессе: считать время до принятого результата, а не объём сгенерированного кода.
Этот разрыв между дешёвой генерацией и дорогой проверкой подробно разобран в материале о разработке с ИИ-агентами.
Рабочая модель среды: пять примитивов
Подход опирается на пять примитивов: законы и границы, стимулы, ниши, стигмергию и отбор. В доступном фрагменте первоисточника они названы, но не разобраны детально. Ниже - инженерная расшифровка, которую стоит проверять на своём проекте, а не считать готовым стандартом.
Примитивы работают в связке. Границы без стимулов дают пассивных агентов, которые боятся сделать лишний шаг. Стимулы без отбора приводят к разрастанию лишнего: агент делает то, что измеряется, и игнорирует остальное. Отбор без границ пропускает результаты, которые формально проходят проверки, но ломают архитектуру.
| Примитив | Что задаёт | Проверяемый пример |
|---|---|---|
| Законы и границы | Что агенту можно менять, какие зависимости добавлять, какие команды запускать | Агент пишет только в каталог адаптера и его тестов |
| Стимулы | Что считается успехом и что штрафуется | Изменение принимается, если проходят контрактные тесты |
| Ниши | Кто за какую зону отвечает | Отдельный агент на каждую службу доставки |
| Стигмергия | Какие следы остаются для следующих запусков | Документ с контрактом и найденными особенностями API |
| Отбор | Какие результаты проходят дальше | Контрактные и интеграционные тесты перед приёмкой |
Законы и границы: что агенту можно и чего нельзя
Законы и границы - заранее зафиксированные правила. Они отвечают, какие файлы и модули агент может менять, какие зависимости добавлять, какие команды запускать и что требует человеческого подтверждения. Смысл границ в том, чтобы сузить пространство решений и оставить результат проверяемым.
Пример для интеграционной задачи. Агенту разрешено писать только в каталог адаптера и его тестов. Запрещено трогать общий слой транспорта, конфигурацию продакшена и миграции. Тогда любое изменение в общем слое сразу видно на ревью, а адаптеры можно принимать пачками.
Риск в калибровке. Слишком жёсткие границы мешают агенту решить задачу: он начинает обходить правило нештатными способами. Слишком мягкие границы делают приёмку бессмысленной, потому что агент может переписать половину системы ради одного адаптера. Границы стоит пересматривать по фактам нарушений, а не по ощущению комфорта.
Стимулы: как направить агента к нужному результату
Стимулы заменяют пошаговые указания. Они задают, что в среде вознаграждает поведение агента: прохождение проверок, соответствие контракту, отсутствие регрессий, скорость. Декларативные стимулы не работают. Фраза «пиши чистый код» ничего не измеряет. Правило «изменение принимается, только если проходят контрактные тесты и не падает покрытие» проверяемо.
Побочный эффект предсказуем. Агент оптимизирует именно то, что измеряется. Стимул «зелёные тесты любой ценой» провоцирует подгонку тестов под код. Стимул «больше строк» ведёт к разрастанию. Поэтому к стимулам нужно добавлять проверки, которые сложно обойти: контрактные тесты на внешнее поведение, архитектурные ограничения, запрет на изменение тестов без отдельного подтверждения.
Ниши: как разделить работу между агентами
Ниши закрепляют за агентами зоны ответственности и участки кода. Это снижает конфликты изменений и упрощает приёмку: понятно, чей результат проверяется. Пример: один агент отвечает за адаптер конкретной службы доставки, второй - за общий маппинг статусов, третий - за тестовые фикстуры.
Ограничение в сквозных задачах. Жёсткие ниши плохо работают, когда изменение требует правок в нескольких слоях. Тогда нужен явный протокол согласования: кто принимает решение, какие файлы можно менять при исключении, как фиксируется причина. Без такого протокола агенты начинают дублировать логику в своих зонах, и система обрастает копиями.
Стигмергия: следы, по которым агенты ориентируются
Стигмергия - механизм, при котором агенты оставляют в среде следы, а следующие агенты ориентируются по ним. Следы могут быть разными: заметки, артефакты, результаты проверок, структурированные отчёты. В разработке это ближе всего к документации решений, changelog, комментариям в PR и логам проверок.
Смысл в передаче знаний между запусками. Человеку не нужно каждый раз пересказывать контекст. Агент открывает документ с контрактом, читает найденные особенности API и учитывает их. Знания не теряются при смене сессии и не зависят от того, помнит ли модель предыдущий разговор.
Риск в качестве следов. Устаревшая или неверная заметка тиражирует ошибку быстрее, чем любой отдельный баг. Следы должны иметь владельца, дату и признак актуальности. Иначе среда накапливает археологию, которой никто не доверяет.
Отбор: как среда оставляет пригодные результаты
Отбор задаёт правила, по которым результат проходит дальше или отбрасывается. Это набор обязательных проверок, пороги, контрактные и архитектурные тесты. Отбор должен быть воспроизводимым: один и тот же результат при повторном прогоне даёт то же решение. Если проверка зависит от настроения ревьюера или случайного порядка запуска, это не отбор, а лотерея.
Связь с приёмкой прямая. Человек принимает результат не потому, что посмотрел каждую строку, а потому, что результат прошёл отбор по заранее заданным критериям. Отбор не гарантирует отсутствие ошибок. Он ограничивает их класс и делает границу ответственности явной.
Как это выглядит на практике: адаптеры к API служб доставки
Задача с адаптерами к API служб доставки удобна для разбора: она повторяется, у служб разные форматы статусов, разные схемы авторизации и разные правила ретраев. Оговорка: в доступном фрагменте первоисточника пример не раскрыт, поэтому схема ниже - инженерная реконструкция на основе общих практик интеграции, а не пересказ конкретных результатов.
Границы. Агент пишет только в каталог адаптера и его тестов. Общий слой транспорта, конфигурация продакшена и миграции закрыты. Если адаптеру нужна новая возможность транспорта, агент готовит предложение, а не меняет слой сам.
Стимулы. Контрактные тесты проверяют маппинг статусов и обработку ошибок. Изменение принимается, если проходят контрактные тесты, нет регрессий в общих сценариях и не отключены проверки. Отдельный стимул - не менять тесты без подтверждения, иначе агент подгонит проверку под код.
Ниши. Отдельный агент на каждую службу. Общий маппинг статусов и тестовые фикстуры живут в отдельной зоне. Это снижает конфликты: два агента не правят один и тот же файл маппинга одновременно.
Стигмергия. Общий документ описывает контракт адаптера: обязательные методы, формат статусов, правила ретраев, известные особенности API. После каждой службы документ дополняется найденными нюансами. Следующий агент стартует не с нуля.
Отбор. Перед приёмкой прогоняются контрактные и интеграционные тесты. Проверяется, что необработанная ошибка API не превращается в успешный статус, что ретраи не размножают заказы, что маппинг неизвестного статуса ведёт к явному результату, а не к молчаливому пропуску.
Ценность среды растёт с числом однотипных задач. Первый адаптер требует больше ручной работы: нужно описать контракт, границы и проверки. Последующие адаптеры проходят по уже готовой колее. Конкретные названия служб, цифры и результаты тестов здесь не приводятся, потому что в доступном источнике их нет. Общий каркас работы с API-контрактами разобран в материале о проектировании вместо кода.
Недетерминированный процесс создания и детерминированные требования к продукту
Процесс создания недетерминирован. Агент может пойти разными путями, выбрать разные структуры, переписать лишнее. Это нормально и не дефект само по себе. Требовать от генерации одинакового пути бессмысленно: вы будете тратить время на стандартизацию того, что не влияет на результат.
Требования к поведению готового продукта, наоборот, должны быть проверяемыми и стабильными. Контракты API, маппинг статусов, обработка ошибок, отсутствие регрессий. Здесь недетерминизм заканчивается. Продукт либо выполняет обещание, либо нет.
Практический вывод: стандартизировать нужно проверки результата, а не маршрут агента. Два разных варианта адаптера могут быть одинаково пригодны, если оба проходят один и тот же набор контрактных тестов. Один может быть короче, другой понятнее. Это не повод отбрасывать один из них автоматически.
Часть требований плохо формализуется. Читаемость, поддерживаемость, уместность абстракций остаются зоной человеческого суждения. Их можно поддержать архитектурными тестами и ревью, но нельзя свести к зелёной галочке. Честнее признать это и оставить место для выборочного разбора, чем имитировать полноту проверок.
Риски: когда ошибка в правилах среды тиражируется на всё
Главный риск средового подхода - масштаб последствий. Ошибка в законе, стимуле или критерии отбора применяется ко всем задачам агентов сразу. Один неверный промпт портит одну задачу. Одно неверное правило среды портит поток задач, пока его не заметили.
Класс проблем легко представить. Слишком слабый критерий отбора пропускает результаты с необработанными ошибками API. Слишком узкая граница заставляет агентов обходить правило нештатными способами. Стимул, который легко подогнать, приводит к тестам, проверяющим сами себя. Ошибка не выглядит катастрофой в отдельном случае, но накапливается в системе.
Меры ограничения ущерба:
- версионировать правила среды и хранить историю изменений;
- прогонять новые правила на ограниченном наборе задач, прежде чем включать на весь поток;
- держать возможность отката правил и результатов;
- периодически проверять стимулы на подгонку: смотреть, не стали ли тесты слабее;
- фиксировать случаи, где проверок не хватило, и превращать их в новые проверки.
Автор сам называет часть механизмов гипотезами, которые ещё предстоит проверить. Он отделяет знакомые практики от предположений. Это аргумент за поэтапный запуск: сначала один класс задач, потом расширение. Массовый запуск среды без обкатки превращает ошибку проектирования в системный сбой.
Как средовой подход ложится на harness-обвязки и CI с архитектурными тестами
Инфраструктуру не нужно строить с нуля. Значительная часть примитивов уже есть в привычных инструментах. Harness-обвязка вокруг агента задаёт границы и доступные действия. CI задаёт отбор. Архитектурные тесты фиксируют законы, например запрет импортов из определённых слоёв. Контрактные тесты задают стимулы и критерии приёмки.
Средовой подход в этой оптике - не новый инструмент, а способ осознанно спроектировать то, что часто складывается стихийно. Команда может годами иметь CI, который проверяет форматирование, но не проверяет архитектурные границы. Формально отбор есть. Фактически он не защищает от того, что важно.
Полезная связка - принцип «unknown ≠ OK»: неизвестное состояние не считается успешным. Если агент не смог определить статус заказа, это не повод вернуть «доставлено». Если проверка не запустилась, это не зелёный результат. Такой принцип хорошо ложится на среду, где агенты работают с внешними API и неполными данными. Его практическое применение разобрано в материале об Agent-Ops 0.4.0.
Ограничение CI простое. Он проверяет только то, что сформулировано как тест. Требования, не переведённые в проверки, остаются вне отбора. Поэтому среда должна включать работу над критериями приёмки, а не сводиться к настройке пайплайна. Иначе зелёный CI создаёт ложное чувство полноты.
Цикл из пяти шагов: как внедрять средовой подход
Цикл удобно строить в логике: источник, среда, работа агентов, отбор, пересмотр. Это обобщение логики подхода. В доступном фрагменте первоисточника пошаговый цикл не детализирован, поэтому шаги стоит воспринимать как рабочую рамку для своего проекта.
- Выберите повторяющуюся задачу с понятным критерием готовности. Например, класс однотипных адаптеров к внешним API. Разовая задача с расплывчатым результатом плохо подходит для первого полигона.
- Опишите границы, стимулы, ниши, следы и правила отбора. Зафиксируйте, какие файлы агент может менять, какие проверки обязательны, кто отвечает за общий слой, где хранится документация контракта.
- Запустите агентов внутри среды на ограниченном объёме. Не открывайте весь поток задач сразу. Цель первого запуска - найти дыры в правилах, а не выжать максимум скорости.
- Принимайте результат по заранее заданным проверкам и фиксируйте случаи, где проверок не хватило. Каждый такой случай - кандидат в новое правило или новый тест.
- Пересматривайте правила среды по накопленным случаям. Убирайте стимулы, которые провоцируют подгонку. Уточняйте границы, которые мешают работе. Добавляйте проверки, которые ловят повторяющиеся дефекты.
Среда - не разовая настройка, а объект сопровождения. Если правила не пересматривать, агенты найдут способ их обходить или начнут работать вхолостую. Если пересматривать слишком часто, среда станет нестабильной и перестанет давать предсказуемую приёмку.
Как проверить, окупается ли среда на ваших задачах
Эксперимент стоит ставить на повторяющихся задачах. Возьмите класс однотипных задач, например адаптеры к внешним API. Замерьте затраты на ручную приёмку до запуска среды и после. Отдельно учтите стоимость проектирования и сопровождения правил: написание проверок, поддержку документации, разбор инцидентов.
Критерий окупаемости простой. Среда окупается, если стоимость приёмки на задачу падает быстрее, чем растут затраты на поддержку правил, и если число задач в классе достаточно велико. На разовых задачах среда почти наверняка не окупится. На задачах с высокой ценой ошибки экономия может быть не главным аргументом: там важнее предсказуемость отбора и возможность отката.
Что имеет смысл измерять:
- время до принятого результата, а не время генерации кода;
- долю задач, которые потребовали ручной переработки после отбора;
- число изменений в правилах среды на десять задач;
- частоту откатов и повторных исправлений;
- долю проверок, которые ловят дефекты до приёмки, а не после релиза.
Конкретные пороги зависят от процесса. Не стоит брать цифры из чужой статьи и превращать их в норматив. Сравнивайте свой поток задач до и после, на одинаковых классах работ. Иначе выигрыш от среды смешается с изменением сложности задач.
Что в итоге: кому подходит средовой подход и где его границы
Средовой подход смещает работу архитектора к проектированию условий и критериев пригодности. Приёмка опирается на заранее заданные проверки, а не на попытку просмотреть каждую строку. Скорость генерации кода перестаёт быть главной метрикой. Главной становится время до результата, который можно принять и сопровождать.
Подход подходит командам с повторяющимися задачами, зрелым CI и готовностью сопровождать правила среды. Он хорошо ложится на интеграции, типовые CRUD-сценарии, миграции и рефакторинг с понятными контрактами. Выигрыш растёт, когда задачи похожи, а проверки можно переиспользовать.
Плохо подходит для разовых задач, для областей с плохо формализуемыми требованиями и для команд без базовой тестовой инфраструктуры. В таких условиях среда превращается в дорогую надстройку, которая не даёт предсказуемой приёмки. Ручной разбор остаётся дешевле.
Часть механизмов уже знакома, часть остаётся гипотезами. Поэтому запускать стоит поэтапно, с возможностью отката и с честным учётом затрат на поддержку. Авторство и ответственность за результат при этом никуда не исчезают: агент может предложить вариант, но решение о пригодности остаётся за человеком. Этот аспект подробно разобран в статье о сопротивлении разработчиков ИИ-агентам.
Практический вопрос к читателю: какая повторяющаяся задача в вашем процессе могла бы стать первым полигоном для среды? Выберите один класс задач, опишите пять обязательных проверок и прогоните на нём десять задач. Сравните время до принятого результата с тем, как вы работаете сейчас. Такой эксперимент даст больше, чем спор о том, заменит ли ИИ разработчика.