🏗️ От кода одноразового использования к прочному проектированию

Скрытая ценность моделирования в эпоху агентного ИИ

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

🚨 Предупреждающий выстрел

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

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

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

📉 Ловушка архитектуры «сначала подсказка»

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

Ввод:Пользователь запрашивает что-то сложное.
Процесс:LLM получает огромную системную подсказку с 50 правилами.
Действие:LLM напрямую выводит JSON или вызовы функций.
Риск: Нет отслеживания состояния, нет типовой безопасности, нет ограничителей, кроме «пожалуйста, не испортите всё».

⚠️ Почему это не работает в масштабе

Функция	Подход только с помощью подсказок	Подход с моделированием
Надежность	Вероятностный (надеемся, что сработает)	Определённый (гарантированные ограничения)
Отладка	«Подсказка была слишком неясной»	«Переход состояния нарушил Правило 4»
Масштабируемость	Окно контекста быстро заполняется	Состояние внешнее и управляется
Безопасность	Зависимость от выравнивания модели с большим языком	Зависимость от проверки схемы

💡 Ключевое понимание: Агент без модели — это просто хаотичный стажёр с правами суперпользователя. Агент с моделью — это старший инженер с чек-листом.

🧱 Возрождение моделирования

Моделирование — это не рисование диаграмм UML, которые никто не читает. В эпоху агентов моделирование — этосоздание ограничителей, в рамках которых ИИ может безопасно мыслить.

1. Моделирование домена как «истинной основы» 🌍

Модели с большим языком обучены на всем интернете, а не навашей бизнес-логике. Если вы попросите агента «обработать возврат», он будет догадываться, что это означает, исходя из публичных данных.

Решение: Определите строгуюМодель домена.
Ценность: Вы заставляете ИИ-модель сопоставлять свое понимание естественного языка с вашими конкретными сущностями (Заказ, Клиент, Политика). Это снижает галлюцинации, привязывая ИИ к вашей схеме.

2. Моделирование состояний как «память» 🧠

Агентам нужно знать, где они находятся в рабочем процессе. Цепочки запросов теряют контекст.

Решение: Реализуйте Машины состояний (например, Бездействие → Планирование → Выполнение → Проверка → Готово).
Ценность: Агент не может пропустить шаги. Он не может «выполнить» до «планирования». Он не может «завершить» до «проверки».

3. Моделирование ограничений как «безопасность» 🛡️

Что произойдет, если агент попытается вызвать API, к которому у него нет доступа?

Решение: Онтологии и карты возможностей.
Ценность: Агент знает только о средствах, которые действительны для его текущего состояния. Он буквально не может видеть функцию delete_user функцию, находясь в режиме read_only_mode.

🛠️ Кейс-стади: Схватка между агентами по бронированию путешествий

Рассмотрим два подхода к созданию ИИ-агентов по бронированию авиабилетов и отелей.

❌ Подход A: Одноразовый скрипт

Логика: Один гигантский запрос: «Вы — агент по путешествиям. Забронируйте для пользователя авиабилет и отель. Используйте эти инструменты».
Режим неудачи: Пользователь говорит: «Забронируй мне рейс на Марс». LLM пытается вызвать API рейса с недопустимыми параметрами. Или, он бронирует отель до подтверждения даты рейса, что вызывает конфликт.
Результат: Сломанные бронирования, разгневанные клиенты, блокировки из-за превышения лимита запросов API.

✅ Подход B: Система с моделью

Логика: А Граф рабочего процесса.
1. Состояние намерения: Проверить, существует ли пункт назначения в базе данных.
2. Состояние рейса: Поиск → Выбор → Бронирование (заблокировать инвентарь).
3. Состояние отеля: Поиск → Выбор → Бронирование.
4. Состояние транзакции: Списать с карты → Подтвердить оба → Освободить.
Режим успеха: Если пользователь говорит «Марс», то Модель домена отклоняет пункт назначения до того, как LLM вообще увидит API. Если рейс не удался, машина состояний автоматически отменяет бронирование отеля.
Результат: Надежные, проверяемые, восстанавливаемые транзакции.

🚀 Экономическое обоснование: технический долг против долгов проектирования

Существует заблуждение, что моделирование замедляет разработку. В эпоху ИИ наоборот.

Настройка промтов — это итеративный долг: Вы подстраиваете промт, и что-то другое ломается. Вы добавляете «не делай X», и оно перестает делать «Y». Это долг с высокой стоимостью обслуживания.
Моделирование — это инвестиции на старте: Вы определяете типы и состояния один раз. ИИ адаптируется к модели. Когда меняется бизнес-логика, вы обновляете модель, а не 50-страничный системный промт.

📉 Кривая затрат:

Неделя 1: Подсказки работают быстрее.

Месяц 1: Моделирование работает с той же скоростью.

Год 1: Подсказки — это неподдерживаемый спагетти. Моделирование — это актив.

🧭 Набор инструментов архитектора (M.A.P.)

Чтобы выжить в эпоху агентов, примите M.A.P. Фреймворк для вашего следующего проекта ИИ:

1. MМоделируйте данные

Не позволяйте LLM выводить сырые строки. Принудительно выводите данные в модели Pydantic или схемы JSON.

Правило: Если это не типизировано, то это не реальность.

2. AАрхитектура потока

Не позволяйте LLM определять порядок операций. Используйте Машины состояний или Движки рабочих процессов (например, Temporal или LangGraph).

Правило: LLM заполняет слоты; код управляет автомобилем.

3. PЗащитите границы

Определите Предусловия и Постусловия для каждого инструмента, который может использовать агент.

Правило: Доверяй, но проверяй. Всегда проверяйте вывод агента перед выполнением.

🔮 Будущее: Архитектор как садовник

Раньше разработчики были каменщиками, вручную укладывая каждую строку кода.
В будущем разработчики будут садовниками.

Вы не выравниваете каждый лист. Вы проектируете решетку (модель), обогащаете почву (данные) и обрезаете опасные ветви (ограничения). Затем вы позволяете ИИ расти.

Код, который можно выбросить, создает демонстрации.
Прочный дизайн строит империи.

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

🏁 Основной вывод

Не прекращайте писать код. Начните моделировать. ИИ — это двигатель, но вы вы — руль.