Введение: от простых цепочек к агентам, которые действуют

Ещё пару лет назад типичное LLM-приложение представляло собой линейную цепочку: промпт, контекст из векторной базы, вызов модели, ответ. LangChain популяризировал эту модель — chains, retrievers, memory — и она работала для простых задач вроде ответов на вопросы по документации.

Но реальные бизнес-задачи редко укладываются в линейный пайплайн. Пользователь хочет, чтобы система не просто ответила, а что-то сделала: создала тикет, отправила письмо, запросила данные из CRM или проверила погоду перед тем, как сформулировать ответ.

Здесь на сцену выходят AI-агенты — системы, способные автономно решать, какой инструмент использовать, в каком порядке и как интерпретировать результат.

Раньше подключение каждого инструмента требовало написания «клея» — кастомных функций с декоратором @tool в LangChain, ручной аутентификацией, обработкой ошибок и сериализацией. В продакшене это быстро превращалось в неуправляемый зоопарк интеграций.

Model Context Protocol (MCP) от Anthropic решает эту проблему. Это единый стандарт для подключения инструментов и источников данных к LLM-приложениям. Вместо написания адаптеров для каждого API вы запускаете MCP-сервер, который предоставляет инструменты по стандартизированному протоколу. Агент подключается к нему через MCP-клиент и получает доступ ко всем инструментам без лишнего кода.

В этой статье мы создадим агента, который:

• Взаимодействует с внешним миром через MCP (погода, GitHub Issues);
• Доступ к внутренней документации через RAG;
• Принимает решения по ReAct-подходу с помощью LangGraph.

Теоретический минимум: что нужно знать перед погружением в код

AI-агент и ReAct-подход

AI-агент — это система, работающая по циклу: Мысль → Действие → Наблюдение. Этот паттерн называется ReAct (Reasoning + Acting).

1. Агент получает задачу от пользователя.
2. Модель решает, какой инструмент вызвать и с какими параметрами.
3. Агент вызывает инструмент и получает результат («наблюдение»).
4. Цикл повторяется, пока модель не сочтёт информацию достаточной для ответа.

Ключевое отличие от обычной цепочки — модель сама решает, когда и какие инструменты использовать, а не следует жёсткому сценарию.

RAG (Retrieval-Augmented Generation)

RAG — это подход, при котором перед генерацией ответа модель извлекает релевантные документы из векторной базы и использует их как контекст.

Для агента RAG — это просто ещё один инструмент. Когда нужна информация из внутренней документации, он вызывает search_documentation, а не полагается на память модели и не галлюцинирует.

Model Context Protocol (MCP)

MCP — открытый протокол на основе JSON-RPC, стандартизирующий взаимодействие между AI-приложениями и внешними инструментами.

Архитектура включает три компонента:

• MCP Host — AI-приложение (например, Claude Desktop или наш Python-агент);
• MCP Client — компонент внутри хоста, управляющий подключением к MCP-серверу;
• MCP Server — программа, предоставляющая инструменты по стандартизированному протоколу.

MCP делает для AI-агентов то же, что REST API сделал для веб-сервисов — универсальный способ взаимодействия, независимый от реализации.

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

Мы используем следующие технологии:

• Python — поддержка asyncio, современный синтаксис, стабильность;
• LangGraph + LangChain — LangGraph даёт контроль над циклом ReAct и состоянием, LangChain предоставляет удобные абстракции;
• FastMCP — высокоуровневая библиотека для создания MCP-серверов через декораторы функций. Версия 2.0 активно развивается и включает клиентские возможности;
• langchain-mcp-adapters — официальная библиотека, конвертирующая MCP-инструменты в формат LangChain;
• Chroma — лёгкая, встраиваемая векторная база, идеальна для прототипов;
• OpenAI text-embedding-3-small — качественные и недорогие эмбеддинги;
• Claude или GPT-4 — любая модель с поддержкой function calling.

Практическая часть: пишем код

Часть 1. Создание MCP-сервера для работы с внешним миром

Создадим MCP-сервер с двумя инструментами: получение погоды и создание GitHub Issue.

Установим FastMCP и создадим файл tools_server.py.

Что происходит:

• Создаём экземпляр FastMCP и декорируем функции @mcp.tool(). Библиотека автоматически генерирует JSON-схему на основе сигнатуры и docstring.
• get_weather использует бесплатный API Open-Meteo (без ключа).
• create_github_issue требует токен GitHub с правами repo.
• Сервер использует транспорт stdio — общение через стандартный ввод/вывод в формате JSON-RPC.

Запуск сервера (для теста):

Для проверки можно использовать MCP Inspector, но мы сразу интегрируем его с агентом.

Часть 2. Настройка RAG-модуля

Создадим RAG-систему, индексирующую PDF-документы и предоставляющую инструмент поиска.

Установим зависимости и создадим файл rag_tool.py.

Ключевые моменты:

• Используем PyPDFLoader для загрузки PDF и RecursiveCharacterTextSplitter для разбивки на чанки с перекрытием.
• Векторное хранилище сохраняется в папке chroma_db/ — при повторных запусках не нужно переиндексировать.
• Инструмент search_documentation обёрнут в декоратор @tool из LangChain — это делает его совместимым с LangGraph.
• Docstring инструмента — часть промпта для модели. Чем точнее он описан, тем лучше агент выбирает, когда и зачем его использовать.

Часть 3. Сборка агента с доступом к MCP

Соберём агента на LangGraph, объединив MCP и RAG.

Установим зависимости и создадим файл agent.py.

Разбор ключевых элементов:

• MultiServerMCPClient — центральный компонент для подключения к MCP-серверам. Принимает конфигурацию с транспортом (stdio или http) и параметрами подключения.
• Транспорт stdio означает, что клиент запускает скрипт как подпроцесс. Удобно для разработки. В продакшене — лучше использовать HTTP.
• create_react_agent из LangGraph — готовая реализация ReAct-агента. Под капотом работает граф с двумя узлами: вызов LLM и выполнение инструментов.
• Агент работает асинхронно (async/await), что критично для эффективной работы с внешними API.

Часть 4. Демонстрация работы

Поместим PDF-документ в папку data/ и запустим агента.

Ваш запрос: Узнай погоду в Москве и создай тикет в репозитории myorg/docs с отчётом о погоде. Перед этим проверь в документации, как правильно оформлять такие тикеты.

[AGENT LOG] Thought: Мне нужно выполнить три действия: проверить документацию, узнать погоду, создать тикет.
Action: search_documentation
Action Input: {“query”: “как оформлять тикеты о погоде”}
Observation: [Фрагмент 1 из docs/internal-guide.pdf] Все отчёты о погоде должны содержать: город и дату, температуру и скорость ветра, рекомендации на основе погодных условий…
Thought: Теперь я знаю формат. Получу погоду в Москве.
Action: get_weather
Action Input: {“city”: “Moscow”}
Observation: Погода в Moscow: Температура: 18.5°C, Скорость ветра: 12 км/ч…
Thought: Теперь создам тикет с отчётом.
Action: create_github_issue
Action Input: { “repo”: “myorg/docs”, “title”: “Ежедневный отчёт о погоде в Москве”, “body”: “## Погода в Москве\n- Температура: 18.5°C\n- Ветер: 12 км/ч\n- Рекомендации: комфортная погода для прогулок”, “labels”: [“weather-report”, “automated”] }
Observation: Issue успешно создан.
Ответ: Я выполнил все запрошенные действия: проверил документацию, узнал погоду, создал тикет.

Что произошло:

• Агент самостоятельно спланировал последовательность действий.
• Вызвал RAG-инструмент для получения правил оформления.
• Использовал MCP-инструмент для получения погоды.
• Вызвал MCP-инструмент для создания Issue.
• Сформировал финальный ответ.

Сравнение с альтернативами и выводы

Критерий	Классический подход (@tool)	Подход с MCP
Интеграция нового API	Писать функцию-обёртку, декорировать @tool, управлять ошибками вручную	Запустить готовый MCP-сервер или написать свой с FastMCP
Переиспользование	Инструмент жёстко привязан к коду агента	Один MCP-сервер могут использовать несколько агентов и приложений
Безопасность	Ключи API в коде или окружении агента	MCP-сервер работает в изолированном окружении со своими секретами
Стандартизация	Каждый инструмент — уникальная реализация	Единый протокол JSON-RPC, понятная структура
Сложность для простых задач	Минимальная	Требуется запуск отдельного процесса или сервера

Преимущества MCP

• Масштабируемость: Экосистема MCP-серверов растёт — уже есть готовые решения для GitHub, Slack, Google Drive, PostgreSQL и других сервисов.
• Разделение ответственности: Команда интеграций может независимо разрабатывать MCP-серверы, а команда агентов — использовать их.
• Единый стандарт: MCP поддерживается Anthropic, OpenAI (через Agents SDK) и другими крупными игроками.

Минусы MCP

• Дополнительная прослойка: Для простых прототипов запуск MCP-сервера может быть избыточным.
• Молодость протокола: Спецификация ещё эволюционирует, возможны breaking changes.
• Отладка: Взаимодействие через JSON-RPC сложнее, чем прямой вызов функции (хотя MCP Inspector помогает).

Заключение

MCP — это не просто фреймворк, а стандарт взаимодействия, меняющий подход к построению AI-агентов. Вместо изобретения велосипеда для каждого API мы можем использовать готовые MCP-серверы или быстро создавать свои с FastMCP.

Мы построили агента, который:

• Использует внешние инструменты через стандартизированный MCP-протокол;
• Имеет доступ к внутренней базе знаний через RAG;
• Принимает решения автономно, следуя ReAct-паттерну.

Это архитектура, легко масштабируемая: добавить сервис — значит подключить ещё один MCP-сервер. Добавить документы — положить PDF в папку data/.

Будущее за модульными AI-системами. MCP — один из ключевых кирпичиков в этом фундаменте. Пора внедрять.

Введение: от простых цепочек к агентам, которые действуют

Ещё пару лет назад типичное LLM-приложение выглядело как последовательная цепочка вызовов: взяли промпт, добавили контекст из векторной базы, отправили в модель, получили ответ. LangChain популяризировал эту парадигму — chains, retrievers, memory — и это работало для простых сценариев вроде «ответь на вопрос по документации».Но бизнес-задачи редко укладываются в линейный пайплайн. Пользователь хочет не просто получить ответ, а чтобы системасовершила действие: создала тикет в Jira, отправила письмо, запросила данные из CRM, проверила погоду и только потом сформулировала ответ. Именно здесь на сцену выходятAI-агенты— системы, которые не просто генерируют текст, а автономно принимают решение,какой инструмент вызвать, в каком порядке, и интерпретируют результат. Проблема в том, что до недавнего времени подключение каждого нового инструмента требовало написания «клея» — кастомных функций, обёрнутых в@toolдекоратор LangChain, с ручным управлением аутентификацией, обработкой ошибок и сериализацией данных. Для продакшена это быстро превращалось в зоопарк нестандартных интеграций, который сложно поддерживать и масштабировать.Model Context Protocol (MCP)от Anthropic решает эту проблему, предлагая единый стандарт для подключения инструментов и источников данных к LLM-приложениям. Вместо того чтобы для каждого API писать свой адаптер, мы просто запускаем MCP-сервер, который предоставляет инструменты по стандартизированному протоколу. Агент подключается к этому серверу через MCP-клиент и получает доступ ко всем инструментам без лишнего кода.В этой статье мы соберём полноценного агента, который:1. Умеет работать с внешним миром через MCP (узнавать погоду и создавать GitHub Issues);2. Имеет доступ к внутренней базе знаний через RAG;3. Принимает решения по ReAct-подходу с использованием LangGraph.

Теоретический минимум: что нужно знать перед погружением в код

AI-агент и ReAct-подход

В контексте LLMагент— это система, которая работает в цикле:Мысль → Действие → Наблюдение. Этот паттерн называетсяReAct(Reasoning + Acting).1. Агент получает задачу от пользователя.2. Модель анализирует («думает»), какой инструмент нужно вызвать и с какими параметрами.3. Агент вызывает инструмент и получает результат («наблюдение»).4. Цикл повторяется, пока модель не решит, что информации достаточно для финального ответа.

Ключевое отличие от обычного chain —модель сама решает, когда и какие инструменты использовать, а не следует жёстко заданной последовательности.

RAG (Retrieval-Augmented Generation)

RAG — это техника, при которой перед генерацией ответа мы извлекаем из внешнего хранилища (векторной базы) релевантные документы и добавляем их в контекст модели. Для агента RAG — это простоещё один инструмент. Когда агенту нужна информация из внутренней документации, он вызывает инструментsearch_documentation, а не пытается ответить по памяти (и, возможно, галлюцинировать).

Model Context Protocol (MCP)

MCP — это открытый протокол, построенный поверх JSON-RPC, который стандартизирует взаимодействие между AI-приложениями и внешними источниками данных и инструментами. Архитектура включает три ключевых компонента:1.MCP Host— AI-приложение (например, Claude Desktop или наш Python-агент).2.MCP Client— компонент внутри хоста, который поддерживает соединение с одним MCP-сервером.3.MCP Server— программа, которая предоставляет инструменты, ресурсы и промпты по стандартизированному протоколу.Проще говоря: MCP делает для AI-агентов то же, что REST API сделал для веб-сервисов — универсальный способ взаимодействия, не зависящий от конкретной реализации.

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

Обоснование

Поддержкаasyncio, современный синтаксис, стабильность

Фреймворк агента

LangGraph + LangChain

LangGraph даёт явный контроль над циклом ReAct и состоянием; LangChain предоставляет удобные абстракции для инструментов и моделей-

MCP-сервер

Высокоуровневая Python-библиотека, которая сводит создание MCP-сервера к декорированию функций. FastMCP 1.0 был включён в официальный MCP Python SDK, а версия 2.0 активно развивается и добавляет возможности клиента

MCP-адаптер

langchain-mcp-adapters

Официальная библиотека от LangChain, которая конвертирует MCP-инструменты в формат, понятный LangChain/LangGraph-

Векторная БД

Лёгкая, встраиваемая, отлично работает для прототипов и небольших проектов

Эмбеддинги

OpenAItext-embedding-3-small

Качественные и недорогие эмбеддинги

Claude (через Anthropic API) или GPT-4

Любая модель, поддерживающая function calling

Практическая часть: пишем код

Часть 1. Создание MCP-сервера для работы с внешним миром

Начнём с создания MCP-сервера, который предоставит агенту два инструмента: получение погоды и создание GitHub Issue.Установим FastMCP:

Создадим файлtools_server.py:

Что здесь происходит:1. Мы создаём экземплярFastMCPи декорируем функции@mcp.tool()— FastMCP автоматически генерирует JSON-схему для параметров на основе сигнатуры функции и docstring.2.get_weatherиспользует бесплатный Open-Meteo API (не требует API-ключа).3.create_github_issueтребует токен GitHub с правами на создание issues (создайте его в настройках GitHub с scoperepo).4. Сервер запускается с транспортомstdio— это значит, что клиент будет запускать этот скрипт как подпроцесс и общаться с ним через стандартный ввод/вывод по протоколу JSON-RPC.Запуск сервера (локально, для теста):

Для проверки можно использовать MCP Inspector, но мы сразу перейдём к интеграции с агентом.

Часть 2. Настройка RAG-модуля

Теперь создадим RAG-систему, которая будет индексировать PDF-документацию и предоставлять агенту инструмент для поиска.Установим зависимости:

Создадим файлrag_tool.py:

Ключевые моменты:1. Мы используемPyPDFLoaderдля загрузки PDF иRecursiveCharacterTextSplitterдля разбивки на чанки с перекрытием.2. Векторное хранилище сохраняется на диск в папкеchroma_db/— при повторных запусках не нужно переиндексировать документы.3. Инструментsearch_documentationобёрнут в декоратор@toolиз LangChain — это делает его совместимым с LangGraph-агентом.4. Важно: docstring инструмента — это часть промпта для модели. Чем точнее описано,когдаизачемиспользовать инструмент, тем лучше агент будет принимать решения.

Часть 3. Сборка агента с доступом к MCP

Теперь соберём всё вместе: агент на LangGraph, который использует и MCP-инструменты, и RAG. Установим оставшиеся зависимости:

Создадим файлagent.py:

Разбор ключевых моментов:1.MultiServerMCPClient— центральный компонент для подключения к MCP-серверам. Он принимает конфигурацию, в которой для каждого сервера указывается транспорт (stdioилиhttp) и параметры подключения.2.Транспорт stdioозначает, что клиент запускает Python-скрипт как подпроцесс и общается с ним через стандартный ввод/вывод. Это удобно для локальной разработки. Для продакшена можно использовать HTTP-транспорт, запустив сервер отдельно.3.create_react_agentиз LangGraph — это готовая реализация ReAct-агента. Под капотом создаётся граф с двумя узлами:1.Agent Node: вызывает LLM с текущим состоянием и инструментами.2.Tools Node: выполняет выбранные инструменты и возвращает результат.4. Агент работаетасинхронно(async/await), что важно для эффективной работы с внешними API.

Часть 4. Демонстрация работы

Поместим в папкуdata/PDF-файл с документацией (например, руководство по работе с GitHub API или внутренний регламент создания тикетов) и запустим агента:

Ваш запрос: Узнай погоду в Москве и создай тикет в репозитории myorg/docs с отчётом о погоде. Перед этим проверь в документации, как правильно оформлять такие тикеты.[AGENT LOG] Thought: Мне нужно выполнить три действия:Проверить документацию по оформлению тикетовУзнать погоду в МосквеСоздать тикет в GitHub с отчётомAction: search_documentation Action Input: {“query”: “как оформлять тикеты о погоде”} Observation: [Фрагмент 1 из docs/internal-guide.pdf] Все отчёты о погоде должны содержать:Город и датуТемпературу и скорость ветраРекомендации на основе погодных условий…Thought: Теперь я знаю формат. Получу погоду в Москве.Action: get_weather Action Input: {“city”: “Moscow”} Observation: Погода в Moscow: Температура: 18.5°C Скорость ветра: 12 км/ч…Thought: Теперь создам тикет с отчётом.Action: create_github_issue Action Input: { “repo”: “myorg/docs”, “title”: “Ежедневный отчёт о погоде в Москве”, “body”: “## Погода в Москве\n- Температура: 18.5°C\n- Ветер: 12 км/ч\n- Рекомендации: комфортная погода для прогулок”, “labels”: [“weather-report”, “automated”] } Observation: Issue успешно создан.Ответ: Я выполнил все запрошенные действия:Проверил документацию по оформлению тикетов — все отчёты должны включать температуру, ветер и рекомендации.Узнал текущую погоду в Москве: 18.5°C, ветер 12 км/ч.Создал тикет в репозитории myorg/docs.

Что произошло:1. Агент самостоятельно спланировал последовательность действий.2. Вызвал RAG-инструмент для получения правил оформления.3. Вызвал MCP-инструмент для получения погоды.4. Вызвал ещё один MCP-инструмент для создания Issue.5. Синтезировал финальный ответ.

Сравнение с альтернативами и выводы

Классический подход (@tool)

Подход с MCP

Интеграция нового API

Писать функцию-обёртку, декорировать@tool, управлять ошибками вручную

Запустить готовый MCP-сервер или написать свой с FastMCP

Переиспользование

Инструмент жёстко привязан к коду агента

Один MCP-сервер могут использовать несколько агентов и даже разные AI-приложения (Claude Desktop, Cursor, etc.)

Безопасность

Ключи API хранятся в коде агента или его окружении

MCP-сервер может работать в изолированном окружении со своими секретами

Стандартизация

Каждый инструмент — уникальная реализация

Единый протокол JSON-RPC, понятная структура

Сложность для простых задач

Минимальная

Требуется запуск отдельного процесса (для stdio) или HTTP-сервера

1. Масштабируемость: Экосистема MCP-серверов растёт — уже есть готовые серверы для GitHub, Slack, Google Drive, PostgreSQL и десятков других систем.
2. Разделение ответственности: Команда, отвечающая за интеграцию с внешними сервисами, может разрабатывать и поддерживать MCP-серверы независимо от команды, строящей агентов.
3. Единый стандарт: MCP поддерживается Anthropic, OpenAI (через Agents SDK) и другими крупными игроками-.

Минусы MCP

1. Дополнительная прослойка: Для простых прототипов запуск отдельного MCP-сервера может быть избыточным.
2. Молодость протокола: Спецификация всё ещё эволюционирует, могут быть breaking changes.
3. Отладка: Отлаживать взаимодействие через JSON-RPC сложнее, чем просто вызвать Python-функцию (хотя MCP Inspector частично решает эту проблему).

Заключение

Model Context Protocol — это не просто очередной фреймворк, астандарт взаимодействия, который меняет подход к построению AI-агентов. Вместо того чтобы каждый раз изобретать велосипед для интеграции с очередным API, мы можем использовать готовые MCP-серверы или быстро создавать свои с помощью FastMCP.

В этой статье мы построили агента, который:

• Использует внешние инструменты через стандартизированный MCP-протокол;
• Имеет доступ к внутренней базе знаний через RAG;
• Принимает решения автономно, следуя ReAct-паттерну.

Это архитектура, которая легко масштабируется: добавить поддержку нового сервиса — значит просто подключить ещё один MCP-сервер в конфигурацииMultiServerMCPClient. Добавить новые документы — бросить PDF в папкуdata/.

Будущее за модульными AI-системами, и MCP — один из ключевых кирпичиков в этом фундаменте. Пора внедрять.