Systems Design Meditation · Edition 1
Агент — это не система
Почему ИИ превращается в инфраструктурную проблему
Edward Calderón
Архитектор ПО
ИИ начинает растворяться в инфраструктуре.
Не потому, что он стал значить меньше. А потому, что он уходит глубже в стек.
Последние несколько лет публичная дискуссия была сосредоточена на модели. Какая модель лучше рассуждает? У какой модели больше контекст? Какая модель пишет код лучше? Эти вопросы по-прежнему полезны. Но их уже недостаточно.
Модель отвечает. Агент способен действовать. Как только система обретает способность действовать, архитектура становится не менее важной, чем интеллект.
Единица анализа изменилась
Языковая модель преобразует входные данные в вероятностный результат. Операционный агент окружает эту модель памятью, инструментами, идентичностью, политиками, очередями, базами данных и обратной связью. Он может прочитать тикет, запросить телеметрию продакшена, изменить конфигурацию и уведомить клиента. Каждый шаг пересекает границу доверия. Качество сгенерированного предложения — лишь небольшая часть результата.
Вот почему модель — это не система. Модель — лишь один из участников системы.
Полезные вопросы теперь выглядят знакомо для любого, кто эксплуатировал облачную или распределённую инфраструктуру: к чему агент имеет доступ? кто делегировал ему полномочия? что он может изменять? какое состояние он поддерживает? как наблюдается действие? что произойдёт, если оно окажется ошибочным? можно ли отменить действие? кто несёт ответственность?
Доступ к инструментам превращает ошибку рассуждения в возможный переход состояния. Если чат-бот выдумает политику возврата средств, ошибочным будет только текст. Если же агент проведёт возврат, обновит журнал учёта и закроет обращение, изменится сама организация вокруг. Модель отказов больше не ограничивается текстом.
Проектирование ограниченных действий
Надёжная инфраструктура агентов требует нескольких границ. Идентичность должна быть привязана к конкретной рабочей нагрузке, а не представлять собой общий API-ключ. Авторизация должна быть узкой, краткосрочной и явно определять допустимые ресурсы и действия. Операции с высоким уровнем влияния требуют шлюзов согласования. Каждый вызов инструмента должен сопровождаться структурированными данными аудита: инициатор, делегирующий, входные данные, решение политики, результат и итоговое состояние.
Наблюдаемость тоже должна выйти за пределы обычной трассировки запросов. Трейс может показать, что вызов прошёл успешно, хотя бизнес-действие было некорректным. Нужно связывать решения модели с вызовами инструментов, а вызовы инструментов — с устойчивыми эффектами. Релевантный показатель — не только задержка или расход токенов. Это то, сохраняется ли заданный инвариант.
Откат изменений столь же конкретен. Некоторые действия можно компенсировать: развёртывание может вернуться к более ранней ревизии. Другие по-настоящему необратимы: письмо отправлено, секрет раскрыт, платёж проведён. Архитектура должна классифицировать действия до того, как их получит агент, а не после инцидента.
Рассмотрим агента, помогающего вносить изменения в инфраструктуру. Он может безопасно изучать метрики и предлагать патч. Применение патча в песочнице может потребовать ограниченных учётных данных. Продакшену нужны оценка политик, согласование человеком для рискованных изменений, поэтапное развёртывание, проверки работоспособности и условие автоматической остановки. Агент может участвовать на всех этапах, не превращаясь в администратора с неограниченными полномочиями.
Этот паттерн напоминает зрелый DevSecOps, потому что лежащая в его основе проблема хорошо знакома: провести изменение через систему, не потеряв контроль над риском. Агенты делают интерфейс гибче, но гибкость не отменяет операционной дисциплины.
Возможности — ещё не надёжность
Очень способная модель в плохо спроектированной инфраструктуре даёт хрупкий продукт. Чуть менее способная модель в превосходной архитектуре может дать куда более надёжную систему. Такая система умеет ограничивать неопределённость, обнаруживать сбои и восстанавливаться.
Поэтому внедрение в корпоративном секторе будет неравномерным. Демонстрации оптимизируются под наглядные возможности. Продакшен-системы должны справляться с жизненным циклом идентичностей, границами данных, реагированием на инциденты, контролем затрат, доказательной базой для регуляторов и деградацией зависимостей. Эти слои — не периферийная сантехника. Именно они определяют, можно ли доверить интеллекту работу.
Появляющиеся стандарты для агентов полезны, но ни один протокол не заменит архитектуру. Фреймворк агентов не может определить допустимый уровень риска организации. Провайдер модели не может решить, какие переходы состояния обратимы. Эти решения принадлежат системе, окружающей модель.
Поэтому практическое направление — не автономия везде и всюду. Это постепенная автономия: наблюдать, рекомендовать, действовать в узких границах и завоевывать более широкие полномочия через подтверждённую надёжность. Так команды получают возможность учиться, не притворяясь, что вероятностные компоненты детерминированы.
Интеллект сам по себе не создаёт надёжную инфраструктуру.
Её создаёт архитектура.