Стек инфраструктуры ИИ-агента — это набор взаимосвязанных технологий, который превращает сырую языковую модель в систему, способную планировать, запоминать, действовать и восстанавливаться после сбоев — надёжно и в масштабе. Это руководство последовательно разбирает каждый ключевой слой: ядро LLM, системы памяти и поиска, фреймворки оркестрации, API инструментов и среды исполнения. Вы увидите, как эти компоненты взаимодействуют в реальной продакшн-системе, что сегодня разворачивают современные команды и где находятся острые углы. В итоге у вас сложится конкретная мысленная модель, которую можно спроецировать на вашу собственную разработку.
Слой LLM: мозг агента
Каждый агент начинается с базовой модели. LLM отвечает за рассуждение, планирование и генерацию структурированных выходных данных, которые управляют дальнейшими действиями. Выбор правильной модели — это не только вопрос возможностей, но и инфраструктурное решение. Задержка, размер контекстного окна, стоимость за токен и доступность тонкой настройки задают рамки того, что можно построить вокруг неё.
Облачные API против собственных моделей
Команды, строящие решения на OpenAI GPT-4o, Anthropic Claude 3.5 или Google Gemini 1.5 Pro, получают высокую скорость итераций ценой утечки данных и привязки к вендору. Самостоятельный хостинг open-weight моделей вроде Meta Llama 3 или Mistral на выделенной GPU-инфраструктуре — через vLLM или TGI — обменивает операционную сложность на контроль. Для регулируемых отраслей, работающих с чувствительными данными, собственный хостинг зачастую обязателен. Платформы вроде IngestAI абстрагируют часть этой сложности, предоставляя защищённый слой middleware для интеграции корпоративного генеративного ИИ, чтобы командам не приходилось самостоятельно прокладывать каждое соединение.
Управление контекстным окном
Контекстное окно в 128K токенов кажется щедрым, пока вы не запускаете многотуровые циклы агента с историей вызовов инструментов, извлечёнными документами и системными промптами, сложенными вместе. Продакшн-системы редко забивают контекст целиком — они расходуют его осознанно. Суммаризация прошлых ходов, выборочный поиск и усечение скользящим окном — все это стандартные паттерны. Статья «Lost in the Middle» от Стэнфорда и UC Berkeley показала, что LLM хуже справляются с информацией, погружённой в середину длинного контекста, а значит стратегия размещения внутри промпта важна не менее того, что именно вы включаете.
Архитектура памяти: краткосрочная, долгосрочная и эпизодическая
Именно память отличает stateless-чатбот от настоящего агента. Агентам нужен доступ к разным типам памяти в зависимости от масштаба задачи — и правильно связать их между собой — одна из самых сложных инженерных задач в стеке.
In-Context память (рабочая память)
Всё, что находится внутри активного окна промпта, — это рабочая память. Она быстрая и с нулевой задержкой, но испаряется между сессиями и стоит токенов. Продакшн-агенты используют in-context память для текущей траектории задачи, последних результатов работы инструментов и активного плана. Всё, что старше нескольких ходов, должно быть вынесено наружу.
Внешняя память на векторных базах данных
Для долгосрочного фактического вспоминания агенты обращаются к векторной базе данных. Конвейер прост: разбить исходные документы на чанки, встроить их моделью эмбеддингов вроде text-embedding-3-large от OpenAI или Cohere Embed v3, сохранить векторы, а затем извлекать top-k ближайших чанков во время запроса с помощью приближённого поиска ближайших соседей. Pinecone, Weaviate, Qdrant и pgvector (на Postgres) — доминирующие решения в 2026 году. У каждого свои компромиссы по задержке запросов, возможностям фильтрации и стоимости управляемого и собственного хостинга. Инструменты вроде лучших ИИ-инструментов для ведения заметок и управления знаниями всё чаще строятся именно на такой архитектуре поиска — они встраивают пользовательские заметки и поднимают их контекстно, а не полагаются на поиск по ключевым словам.
Эпизодическая и процедурная память
Эпизодическая память хранит записи прошлых запусков агента — какие действия были предприняты, что сработало, что провалилось. Обычно это структурированная база данных (Postgres, DynamoDB), а не векторное хранилище, потому что запросы идут по session ID и временной метке, а не по семантическому сходству. Процедурная память — переиспользуемые определения навыков и схемы инструментов — живёт в конфигурационных файлах или выделенном реестре, к которому оркестратор обращается во время выполнения.
Оркестрация: плоскость управления
Слой оркестрации — это место, где архитектура становится по-настоящему интересной. Это код, который решает, когда вызвать LLM, какой инструмент задействовать, как обрабатывать ошибки и когда задача действительно завершена. Это не сама LLM — это каркас вокруг неё.
Фреймворки: LangChain, LlamaIndex и AutoGen
LangChain остаётся самым широко применяемым фреймворком оркестрации — во многом благодаря своей экосистеме интеграций. LlamaIndex сильнее в агентах с большим уклоном в поиск и работу с документами. Microsoft AutoGen обеспечивает многоагентные диалоги, где специализированные агенты передают задачи друг другу — паттерн, который хорошо масштабируется для сложных рабочих процессов. Выбор сырого фреймворка менее важен, чем то, насколько чисто вы определите интерфейсы инструментов и управление состоянием. Небрежная работа с состоянием вызывает больше продакшн-инцидентов, чем любой выбор модели.
Многоагентные паттерны
Однопользовательские циклы подходят для простых задач. Сложные задачи — исследовательский синтез, автоматизированная разработка ПО, многошаговые конвейеры данных — выигрывают от многоагентных архитектур, где агент-планировщик разбивает цель, а агенты-исполнители параллельно обрабатывают подзадачи. Планировщик использует рассуждающие способности LLM; исполнители зачастую легче, быстрее и дешевле. Исследование Anthropic о построении эффективных агентов описывает несколько надёжных паттернов — включая цепочки промптов, маршрутизацию и параллелизацию — которые стоит прочитать до проектирования слоя оркестрации.
Конечные автоматы и структурированные выходы
Неструктурированные выходы LLM молча ломают агентские конвейеры. Решение — принудительно использовать структурированные выходы: JSON-схемы, валидируемые моделью Pydantic, или форматы вызова инструментов, которые оркестратор детерминированно разбирает. Использование конечного автомата (LangGraph создавался именно для этого) делает путь исполнения агента явным и отлаживаемым, а не эмерджентным и непрозрачным. Когда что-то ломается в продакшне, вам нужна трассировка, а не загадка.
API инструментов и внешние интеграции
Агент без инструментов — просто чатбот. Инструменты — это то, что позволяет агентам писать код, запрашивать базы данных, вызывать REST API, просматривать веб, отправлять письма и запускать рабочие процессы. Слой инструментов обычно определяется как реестр вызываемых функций, каждая из которых описана именем, схемой и обработчиком.
Определение и версионирование схем инструментов
Схемы инструментов — это контракт между LLM и вашей средой исполнения. Они должны быть точными — неоднозначные описания параметров заставляют модель галлюцинировать аргументами. Делайте схемы минимальными: чем меньше параметров у инструмента, тем меньше модель может ошибиться. Явно версионируйте схемы; изменение схемы — это ломающее изменение для любого агента, который научился работать со старым интерфейсом. Для команд, быстро строящих внутренние инструменты, ИИ-конструктор приложений Retool показывает, как готовые интеграционные блоки ускоряют эту обвязку без ущерба для корпоративной надёжности.
Аутентификация, лимиты запросов и отказоустойчивость
Каждый вызов внешнего API — это поверхность отказа. Истечение токенов, лимиты запросов, сетевые таймауты и некорректные ответы — всё это случается в продакшне. Надёжный слой инструментов оборачивает каждый вызов логикой повторов (экспоненциальный backoff с джиттером), контролем таймаутов и структурированными сообщениями об ошибках, которые LLM может интерпретировать. Храните учётные данные API в менеджере секретов — AWS Secrets Manager, HashiCorp Vault — и никогда в переменных окружения, которые попадают в логи.
Среды исполнения и развёртывание
Где агент фактически работает — так же важно, как и то, что он запускает. Среды исполнения определяют границы безопасности, пределы масштабируемости и операционные накладные расходы. Правильный выбор зависит от длительности задачи, требований к изоляции и того, насколько рабочая нагрузка хранит состояние.
Serverless против контейнерных рантаймов
Короткие, не сохраняющие состояние задачи агента хорошо ложатся на serverless-функции (AWS Lambda, Google Cloud Run). Задержка холодного старта — основной штраф. Долгоиграющие циклы агента — представьте исследовательский агент, работающий несколько минут — требуют контейнерных рантаймов на Kubernetes или ECS, где вы контролируете жизненный цикл. Многие команды используют гибрид: оркестратор — долгоживущий сервис; отдельные исполнения инструментов — serverless-вызовы. Это снижает расходы, сохраняя доступность плоскости управления.
Песочница для исполнения кода
Агенты, которые пишут и запускают код, нуждаются в надлежащей песочнице. Предоставление LLM прямого доступа к вашему продакшн-шеллу — очевидно катастрофа. Стандартный паттерн — поднимать эфемерный контейнер (Docker, микро-VM Firecracker или песочница интерпретатора кода E2B) на каждое исполнение, с сетевым выходом, ограниченным одобренными конечными точками, и доступом к файловой системе, ограниченным временным томом. Песочница уничтожается после завершения задачи. Никакого постоянного состояния, никакого бокового перемещения.
Наблюдаемость и оценка
Вы не можете улучшить то, что не видите. Продакшн-стеки агентов требуют распределённой трассировки через каждый вызов LLM, вызов инструмента и обращение к памяти — а не только логов приложения. LangSmith, Arize AI и Helicone — все предоставляют нативную наблюдаемость для агентов. Помимо трассировки, нужен оценочный стенд: набор тестовых случаев с ожидаемым поведением, который вы прогоняете против каждого деплоя. Агенты недетерминированы; регрессионное тестирование требует вероятностных утверждений, а не точных строковых совпадений.
Современный продакшн-стек: что команды реально разворачивают
Собирая всё это в цельную картину: продакшн-система агента в 2026 году обычно использует размещённую передовую модель (или open-weight модель на собственном хостинге за vLLM) как ядро рассуждений. LangGraph или собственный конечный автомат обрабатывает оркестрацию. Поиск работает на Qdrant или Pinecone с эмбеддингами OpenAI. Внешние инструменты определяются как типизированные функции Python, оборачиваются в реестр инструментов и вызываются через структурированные JSON-выходы. Вся система работает на Kubernetes, с serverless-вызовами для коротких обращений к инструментам и долгоживущими подами для оркестратора. LangSmith или сопоставимая платформа фиксирует каждую трассировку. Слой данных — пользовательские документы, базы знаний, структурированные записи — питает и векторное хранилище, и базу эпизодической памяти. Агенты, построенные на платформах вроде IngestAI, часто применяют ту же многослойную архитектуру под капотом, открывая её через управляемый API-интерфейс, чтобы корпоративные команды могли сосредоточиться на логике приложения, а не на инфраструктурной обвязке.
Агенты на основе документов
Распространённый продакшн-паттерн — агент на основе документов: агент, способный рассуждать над корпусом PDF, контрактов, отчётов или статей базы знаний. Лучшие ИИ-инструменты для управления документами на рынке сегодня — по сути специализированные реализации этого паттерна: встраивают документы в хранилище поиска, открывают разговорный интерфейс и используют структурированное извлечение для поднятия конкретных полей. Построить с нуля — больше контроля; купить готовый инструмент — скорость. Архитектура в обоих случаях одна и та же.
Вопросы масштабирования и типичные режимы отказов
Масштабирование агентской системы — не то же самое, что масштабирование обычного веб-API. Режимы отказов другие и часто сложнее в диагностике.
Бюджет токенов и контроль расходов
Неконтролируемые циклы агента — реальный финансовый риск. Агент, который неверно оценивает завершённость задачи, может закрутиться через сотни вызовов LLM, пока его не остановит таймаут. Устанавливайте жёсткие бюджеты токенов на задачу, на сессию и на день. Оповещайте о стоимостных аномалиях в реальном времени — а не после прихода месячного счёта. Кэширование идентичных промптов через семантический кэш (GPTCache, Redis с поиском по эмбеддингам) может сократить расходы на LLM на 30–40% для рабочих нагрузок с повторяющимися запросами.
Инъекция промптов и безопасность
Агенты, обрабатывающие данные, предоставленные пользователем, уязвимы к инъекции промптов — состязательным входам, которые перехватывают инструкции агента. Это не теоретический риск; он неоднократно демонстрировался в развёрнутых системах. Меры защиты включают санитизацию входа, разделение привилегий между системным промптом и пользовательским контентом, а также валидацию выхода перед выполнением любого действия. Относитесь к каждому внешнему входу как к недоверенному — так же, как ко входу пользователя в веб-приложении.
Плавная деградация
Планируйте частичные отказы. Падение API инструмента не должно обрушивать весь агент — оно должно вернуть структурированную ошибку, которую оркестратор может обойти. Проектируйте обёртки инструментов так, чтобы они возвращали осмысленные сигналы отказа, а логику оркестрации — так, чтобы она умела с ними справляться. Агент, который корректно деградирует и ясно сообщает о проблеме, гораздо полезнее в продакшне, чем тот, который безупречно отрабатывает happy path и взрывается на первом неожиданном ответе.
Стек инфраструктуры ИИ-агента ещё молод, но базовые паттерны стабилизируются. Команды, которые инвестируют в чистые границы абстракций — между LLM, слоем памяти, оркестратором и средой исполнения — гораздо проще подменяют компоненты по мере развития экосистемы. Модель, которую вы используете сегодня, не будет той моделью, которую вы используете через восемнадцать месяцев. Стройте стек так, чтобы ему было всё равно.
