Введение
Июль 2026 года — время, когда AI-агенты перестали быть экспериментальной технологией и стали частью корпоративной инфраструктуры. Согласно недавней публикации на Habr, основанной на опыте крупных технологических компаний, роль Solution Architect (архитектора решений) претерпевает фундаментальные изменения. Если раньше архитектор проектировал статичные системы с фиксированными API и заранее определёнными сценариями, то теперь он вынужден работать с динамическими, самообучающимися агентами, которые принимают решения в реальном времени. В этой статье разберём, как именно трансформируются обязанности Solution Architect, какие инструменты становятся ключевыми и с какими проблемами сталкиваются команды при внедрении агентных архитектур. Материал основан на реальном кейсе, описанном в статье Источник.
Суть изменений: от статики к динамике
Традиционно Solution Architect отвечал за выбор технологического стека, проектирование интеграций между сервисами и обеспечение масштабируемости. Однако с появлением AI-агентов, способных самостоятельно выбирать пути выполнения задач, архитектура перестаёт быть «жёсткой». В статье на Habr описывается, как команда разработчиков столкнулась с необходимостью перепроектировать систему, когда классические микросервисы начали заменяться агентами, которые общаются друг с другом через естественный язык.
Ключевое отличие: в классической архитектуре поток данных предопределён — сервис А вызывает сервис Б по строго определённому контракту. В агентной архитектуре агент сам решает, какой инструмент или сервис использовать, исходя из контекста. Это требует от Solution Architect не только понимания API, но и навыков проектирования «пространства решений» — набора правил и ограничений, в рамках которых агент может действовать.
Проблемы, с которыми столкнулась команда
В статье подробно разбирается кейс внедрения AI-агентов в систему управления заказами крупного ретейлера. Разработчики выявили три ключевые проблемы:
-
Неопределённость поведения агентов. В отличие от обычного сервиса, агент может выбрать неоптимальный путь выполнения задачи, если ему не заданы чёткие границы. Например, агент, отвечающий за обработку возвратов, мог самостоятельно решить отправить клиенту подарочную карту вместо денежного возврата, если это «казалось ему логичным».
-
Сложности с мониторингом. Традиционные системы логирования и трейсинга (например, OpenTelemetry) рассчитаны на фиксированные цепочки вызовов. Когда агент динамически выбирает, какие функции вызывать, стандартные инструменты перестают давать полную картину.
-
Проблемы безопасности и соблюдения норм. AI-агенты, особенно работающие с конфиденциальными данными, могут случайно раскрыть информацию, если их не ограничить на уровне архитектуры. Команда столкнулась с ситуацией, когда агент технической поддержки передал агенту по работе с клиентами персональные данные без соответствующего разрешения.
Решение: новый подход к проектированию
Команда проекта применила несколько архитектурных паттернов, которые сейчас становятся стандартом для агентных систем:
1. Контекстные границы (Context Boundaries)
Вместо того чтобы давать агенту полный доступ ко всем данным, архитекторы ввели «контекстные ячейки» — изолированные области, в которых агент может действовать. Например, агент по работе с возвратами имеет доступ только к данным о заказах и платёжной истории, но не к профилю клиента. Это снижает риск утечек.
2. Агент-ориентированные API (Agent-First APIs)
Разработчики перепроектировали API таким образом, чтобы они были «понятны» агенту. Вместо REST-эндпоинтов с жёсткой структурой данных они создали семантические интерфейсы, где агент может запросить «информацию о заказе» без указания точного ID — система сама находит нужный контекст.
3. Наблюдаемость на уровне намерений (Intent Observability)
Для решения проблемы мониторинга команда внедрила систему логирования не вызовов, а
«намерений» агента. Вместо «агент вызвал метод getOrderDetails(id=123)» логи записывают «агент хотел узнать статус заказа для клиента X». Это позволило отслеживать логику принятия решений.
4. Динамические политики безопасности
Вместо статических RBAC (ролевого контроля доступа) архитекторы внедрили политики, которые проверяют не только «кто запрашивает», но и «зачем». Если агент запрашивает данные, система оценивает его намерение и решает, допустимо ли это.
Результаты и метрики
Согласно статье, после внедрения нового подхода команда добилась следующих результатов:
| Показатель | До внедрения | После внедрения |
|---|---|---|
| Доля неверных решений агентов | 23% | 4% |
| Время на отладку инцидентов | 8 часов | 1.5 часа |
| Количество утечек данных (за месяц) | 6 | 0 |
| Производительность агентов (задач в час) | 45 | 120 |
Эти цифры демонстрируют, что правильная архитектура не только повышает безопасность, но и значительно улучшает эффективность агентов.
Практические рекомендации для Solution Architect
На основе разобранного кейса можно сформулировать несколько принципов, которые помогут архитекторам адаптироваться к новой реальности:
- Проектируйте с учётом неопределённости. Агенты будут принимать неожиданные решения. Ваша задача — не предсказать всё, а задать безопасные рамки.
- Используйте эвристики вместо жёстких правил. Например, вместо «запретить всё, кроме А» используйте «разрешить, если вероятность ошибки менее 5%».
- Внедряйте механизмы обратной связи. Агенты должны учиться на своих ошибках, но архитектура должна позволять «откатить» нежелательное поведение.
- Пересмотрите инструменты мониторинга. OpenTelemetry и Jaeger хороши для микросервисов, но для агентов нужны инструменты, понимающие контекст.
Заключение
Роль Solution Architect в эпоху AI-агентов становится более стратегической. Если раньше архитектор был «строителем мостов» между сервисами, то теперь он — «дизайнер пространства возможностей» для автономных агентов. Как показывают результаты из статьи на Habr, компании, которые уже перестроили свои архитектуры под агентный подход, получают значительное преимущество в скорости и безопасности. Однако это требует от архитекторов новых компетенций: понимания работы больших языковых моделей, навыков проектирования семантических интерфейсов и умения работать с вероятностными системами. Те, кто освоит эти навыки, станут ключевыми фигурами в цифровой трансформации ближайших лет.
Комментарии