Архитектура LLM-агентов для самых маленьких

Являясь LLM активистом, регулярно обсуждаю всякое про новостиинструментытренды в ИИ. И к моему удивлению зачастую люди из IT не понимают базовых вещей в работе LLM и сопутствующих инструментах. Эта статья — переложение доклада на внутреннем митапе. Основная ее цель – обозначить как из сервера с моделью получаются полноценные агентные системы.

А начнем мы с того, что представим сервер с развернутой LLM, как рыбку Дори.

И у нее:

1. Есть долгосрочная память ^[1]. Те самые веса, полученные в результате обучения ^[2] в AI лабораториях за сумасшедшие деньги.

2. Не помнит, о чем говорила только что.

3. Не знает, что было в ближайшем прошлом. Например, последние новости.

4. Даже лапок нет. Поэтому она не может сделать ничего, о чем вы ее попросите.

А все потому, что она сервер, она не хочет хранить состояние, она хочет общаться вопрос-ответ.

И читатель справедливо заметит, что его пользовательский опыт ^[3] работы с LLM отличается от написанного. Он вполне успешно поддерживает длительные диалоги с LLM, возвращается к ним спустя время и модель все помнит.

Чаты и хранение контекста в чате

И тут мы подходим к первому элементу поддержки нашей LLM – обвязка, обеспечивающая работу в режиме чата. Основная задача этой обвязки – сохранение контекста текущего общения, его обобщение и длительное хранение.  Модель при этом работает в том же режиме, как и раньше, но у нас появляется кратковременная память ^[4], позволяющая поддерживать диалог. И вот тут всплывает окно контекста. Общаясь с LLM, мы чаще всего отправляем ей совсем небольшие по меркам окна контекста сообщения. Но забивать его будет все, что дальше будет упомянуто в статье.

Интернет поиск

Вторым важным шагом, который привнесли нам чаты – дополнение контекста через интернет поиск. То, что было изначально киллер фичей Perplexity и позже стало одним из базовых компонентов в работе любого чата. Любой запрос неплохо было бы начать с поиска в интернете, вероятно, там есть данные, которых нет в обучающей выборке или актуальные новости по теме. И вот наша LLM знает все, что случалось в мире в последнее время. Бонусом мы получаем фокусировку на том, что мировая общественность считает важным в запрашиваемой тематике и о чем активно пишет в интернете. При этом весь поиск также может работать в цепочке вызовов самой LLM, чтобы иметь возможность корректировать запрос и уточнять данные, которых не хватает.

Локальный поиск

Очевидно, что не все данные, которые нам могут понадобиться, есть в открытом интернете. Например, локальные базы знаний, внутренние регламенты, файлы, базы данных, корпоративный код и т.п. Тут возникает потребность ^[5] искать еще и внутри своего периметра.

Именно при работе с приватными данными чаще всего и применяется RAG (Retrieval-Augmented Generation). В классическом понимании RAG — это когда мы извлекаем (Retrieval) релевантные куски текста из локальных векторных баз данных и подмешиваем (Augment) их в контекст перед отправкой в LLM.

Альтернативой RAG выступают Ресурсы (Resources). Концептуально они решают одну и ту же проблему — обогащение запроса локальными данными. Оба термина появлялись параллельно. RAG — как архитектурный подход к извлечению данных для модели, включающий векторизацию и поиск. Ресурсы — как перечень доступных источников.

Глобально и интернет-поиск, и локальный RAG, и работа с ресурсами решают одну задачу — Grounding («заземление» модели). Мы не даем модели галлюцинировать, подсовываем ей готовые факты, на которые она может опереться. Так мы даем нашей рыбке специфические знания.

Инструменты

И вот наша LLM уже помнит, о чем общалась, знает последние новости и понимает контекст текущей работы, читая локальные источники. С ней уже интересно общаться, она почти не говорит глупостей и не подменяет факты. Но хочется большего. Хочется, чтобы она что-то могла делать. Делать сама, а не просто давать рекомендации.

И тут появляются инструменты (tools). При этом, понятно, что LLM продолжает отдавать только текст, и сама ничего не делает. Мы описываем доступные инструменты в контексте запроса, и модель, если сочтет нужным, возвращает структурированный запрос на их вызов, а обвязка исполняет этот запрос. Так у нашей LLM появляются лапки.

Роль и типовая задача

Наша LLM будет вести себя примерно одинаково при любом использовании. У нее есть накопленный опыт (данные обучения), кратковременная память ^[6] (Grounding). Но мы хотим, чтобы она обрела еще определенные паттерны поведения ^[7] в разных контекстах. Когда мы используем ее для генерации кода, нам хочется меньше креатива, но простое и рабочее решение. Если мы пишем статьи с ее помощью, то мы можем захотеть придерживаться определенных стилевых приемов. Мы можем захотеть для решения определенных проблем сфокусировать LLM на одних нюансах, а другие игнорировать. Так появится постоянный контекст использования или системный промпт.

Самостоятельность и свобода воли

И вот уже вроде бы все хорошо. LLM понимает нас с полуслова, дает нужную информацию и делает что-то по нашему поручению. Но чего-то не хватает. Хочется, чтобы в типовых сценариях LLM не ждала от нас запроса в чате, а сама реагировала на происходящее. Передавала данные по цепочкам вызовов, строила планы и могла жить своей жизнью. И вот тут появляется часть оркестрации. Эта часть может быть элементом агентского CLI или чата. Может быть полноценным внешним оркестратором (n8n и подобные). Но именно это сделает нашу LLM самостоятельнее и отпустит ее в свободное плавание.

Обычно оркестраторы оборачивают в подобие классического цикла управления (PDCA)  Планировать (Plan) -> Действовать (Do) -> Наблюдать за результатом (Check). Последний шаг Act, включающий улучшение процесса, почему-то в известных кейсах не включают, но как будто зря.

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

Один язык, чтобы управлять всеми

И вот мы уже готовы выделить LLM набор функций для работы с чем-то обособленным, например, с нашим ПО. Мы понимаем, что у нас есть основной контекст (system prompt), источники информации ^[8] о его текущем состоянии (resources), есть ручки, за которые можно подергать (tools) и ситуации в которых эти ручки надо дергать. И мы понимаем, что у нас есть множество мест, куда мы хотели бы это прикрутить: IDE, чат, CLI. И тут к нам приходит унификация в виде протокола MCP. Он позволяет оформить работу с нашим ПО в виде MCP-сервера и подключать его ко всему, что может выполнять функции MCP-клиента (на сегодняшний момент это фактически любая обвязка вокруг LLM).

Сценарии автоматизации изначально были частью MCP, но в последних спецификациях удалены из него, для поддержания концепции, что MCP сервер должен работать без состояния. 

Где мы сейчас

И вот наша рыбка-LLM, которая вначале пути казалась беспомощной и нелепой, обзавелась нехитрым окружением. И уже представляется всемогущим воплощением Искусственного Интеллекта ^[9] из фантастических произведений прошлого столетия, которые пророчат человечеству скорую гибель под гнетом машин. Но мы понимаем, что внутри все та же милая глупышка Дори.

Модели сами по себе становятся умнее, и сами по себе умеют все больше (какое-то время назад с инструментами могли работать единицы моделей), со временем вокруг них все придумывают все больше обвязок, практик и протоколов, позволяющих делать невероятные вещи:

1. Фреймворки создания агентов (LangChain, CrewAI, Dify)

2. Готовые RAG компоненты (LlamaIndex)

3. Валидация результата работы LLM с помощью LLM

4. Открытые модели huggingface

5. Развертывание локальных моделей в один клик (Llama, LMstudio)

6. Универсальные и специализированные обвязки OpenCode, OpenClaw, AI-native IDE  и т.п.

Страшно представить, как далеко мы еще сможем зайти со всем этим, а может, это уже потолок?

Но кажется, что первый этап становления технологии AI мы уже прошли.