Понимание ИИ-агентов: вызов инструментов, MCP и цикл агента

Когда люди начинают изучать ИИ-агентов, повсюду появляется один и тот же набор терминов:

Агенты. Инструменты. Вызов функций. MCP. Контекст. Память.

На первый взгляд это кажется набором не связанных между собой технологий.

Но если уделить достаточно времени изучению того, как построены реальные агентные системы, особенно ознакомившись с техническими материалами Anthropic об агентах и MCP, становится ясно, что существует гораздо более простая основная архитектура.

В этой статье рассматривается эта архитектура с практической точки зрения, ориентированной на разработчиков.

Что на самом деле делает ИИ-систему агентом?

Типичное приложение, основанное на больших языковых моделях, может быть представлено следующим образом:

User
  ↓
LLM
  ↓
Response

Здесь модель просто принимает входные данные и генерирует выходные.

Но многие реальные задачи невозможно решить только путем генерации текста.

Возьмём этот запрос в качестве примера:

«Ознакомьтесь с этим репозиторием GitHub в поисках открытых проблем, выберите ту, которая кажется наиболее важной, и дайте краткий обзор того, что ещё нужно исправить».

Чтобы справиться с подобной задачей, система должна:

1. Понять запрос.
2. Определить, какая информация необходима.
3. Выбрать подходящий инструмент.
4. Запустить этот инструмент.
5. Проверить результат.
6. Решить, что делать дальше.
7. Возможно, вызвать другой инструмент.
8. Сформировать окончательный ответ.

Именно здесь и проявляется ценность понятия агентной системы.

Компания Anthropic проводит чёткое различие между рабочими процессами и агентами.

Рабочий процесс выполняется в строгой последовательности определённых шагов:

LLM → Step 1 → Step 2 → Step 3 → Answer

Агент же самостоятельно определяет, какие действия и инструменты использовать:

             ┌──────────────┐
             │     LLM      │
             └──────┬───────┘
                    │
               choose action
                    ↓
                 Tool
                    ↓
                Result
                    │
                    └──────────→ LLM
                                  │
                             choose next action

Ключевой момент заключается не просто в том, что где-то в процессе используется LLM.

Дело в том, что сам LLM имеет возможность влиять на формирование процесса.

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

Усиленный LLM

Особенно полезной идеей из материалов Anthropic является концепция усиленного LLM.

Вместо того чтобы представлять LLM просто как:

LLM → Text

его можно представлять как:

             ┌─────────────┐
             │     LLM     │
             └──────┬──────┘
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
    Retrieval     Tools        Memory

Согласно этому подходу, LLM обретает способность выходить за рамки собственных обученных параметров и взаимодействовать с внешней информацией и ресурсами.

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

Это важно, потому что это проясняет тот факт, что сама модель не превращается магическим образом в полноценную программную систему.

Именно приложение, окружающее модель, обеспечивает эти дополнительные возможности.

Что такое вызов инструментов?

Прежде чем перейти к MCP, полезно рассмотреть что-то более простое.

Представьте, что вы предоставляете нейронной сети доступ к такому инструменту:

get_weather(city)

Затем пользователь задает вопрос:

"Какая погода в Коломбо?"

Вместо того чтобы сразу ответить, модель может запросить выполнение соответствующей функции:

{
  "name": "get_weather",
  "arguments": {
    "city": "Colombo"
  }
}

Фактически эту функцию выполняет окружающее приложение.

Результат такой обработки может выглядеть примерно так:

{
  "temperature": 29,
  "condition": "Partly cloudy"
}

Этот результат возвращается обратно в окно контекста модели.

Оттуда модель может сгенерировать ответ вроде следующего:

«В Коломбо сейчас 29°C и небольшая облачность.

Ключевой момент здесь заключается в следующем:

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

Модель никогда не устанавливает прямое соединение с самой службой погоды.

Вызов инструментов — это не MCP

Это, пожалуй, самое важное различие, которое необходимо понимать во всей этой области.

Вызов инструментов и MCP решают две разные проблемы.

Вызов инструментов по сути сводится к обмену между:

LLM
 ↓
Tool request
 ↓
Application
 ↓
Tool result

MCP, напротив, — это протокол, предназначенный для стандартизации способа подключения ИИ-приложений к внешним инструментам, источникам данных и контексту.

Anthropic выпустила MCP в ноябре 2024 года как открытый стандарт, призванный соединять ИИ-ассистентов с системами, в которых находятся реальные данные и инструменты.

Согласно собственной документации Anthropic, MCP стандартизирует способ подачи контекста в LLM, причем для сравнения говорится, что он функционирует как порт USB-C для ИИ-приложений.

Подводя итог:

Tool Calling
     ↓
How an LLM requests an action

MCP
     ↓
How AI applications can standardize connections
to external tools and data

Другими словами, эти две концепции дополняют друг друга, а не конкурируют.

Что на самом деле добавляет MCP

Представьте ИИ-приложение, которому необходимо получить доступ к:

• GitHub
• PostgreSQL
• Google Drive
• Slack
• локальной файловой системе
• внутренним API компании

системы мониторинга

Без общего протокола каждое из этих соединений может потребовать собственной индивидуальной проводки. В результате можно легко оказаться в ситуации, подобной этой:

AI Application
 ├── Custom GitHub integration
 ├── Custom Slack integration
 ├── Custom PostgreSQL integration
 ├── Custom filesystem integration
 └── Custom internal API integration

MCP решает эту проблему, определяя стандартизированный протокол, который находится между приложением ИИ и внешними системами, обеспечивающими необходимые функции. Концептуально это выглядит примерно так:

                AI Application
                       │
                 MCP Client(s)
                       │
       ┌───────────────┼────────────────┐
       ↓               ↓                ↓
   MCP Server      MCP Server       MCP Server
    GitHub          Database          Files
       │               │                │
       ↓               ↓                ↓
    GitHub API      PostgreSQL       Filesystem

Благодаря такой схеме приложению ИИ больше не требуется глубокие индивидуальные знания каждой из систем бэкенда. Вместо этого серверы MCP предоставляют свои возможности через общий протокольный слой.

Архитектура MCP

MCP построен на основе модели клиент-хост-сервер. На высоком уровне это выглядит так:

┌─────────────────────────────────────┐
│              HOST                   │
│                                     │
│        AI Application               │
│                                     │
│    ┌──────────────────────────┐     │
│    │       MCP Client         │     │
│    └────────────┬─────────────┘     │
└─────────────────┼───────────────────┘
                  │
                  │ MCP
                  ↓
        ┌──────────────────┐
        │    MCP Server    │
        │                  │
        │  Tools           │
        │  Resources       │
        │  Prompts         │
        └────────┬─────────┘
                 │
                 ↓
        External System

Ключевые роли в этой архитектуре описаны ниже.

Хост

Хост — это приложение ИИ, отвечающее за организацию всего взаимодействия. Это может быть что-то вроде:

• помощник по программированию на ИИ
• десктопное приложение ИИ
• инструмент для разработчиков
• специально созданное приложение-агент

MCP-клиент

MCP-клиент находится внутри хоста и отвечает за поддержание активной и рабочей связи с сервером MCP.

MCP-сервер

MCP-сервер — это просто программа, которая предоставляет возможности через протокол MCP. Он может обеспечивать функционал, связанный с такими вещами, как:

GitHub
Databases
Files
Cloud services
Internal systems
Development environments

Важно отметить, что сам MCP-сервер не обязательно должен быть агентом или содержать какие-либо механизмы рассуждения ИИ. Его задача — просто сделать определенные возможности доступными.

MCP — это не только инструменты

Одна из причин, по которой люди часто ошибаются, — это предположение, что MCP — это всего лишь «протокол вызова инструментов». На самом деле MCP определяет несколько отдельных примитивов помимо инструментов.

Инструменты

Это действия, которые может выполнять модель, например:

create_issue()
search_repository()
query_database()
send_message()

Ресурсы

Ресурсы — это фрагменты информации, которые приложение может получить и передать модели в качестве контекста, например:

file://project/README.md
database://schema

Запросы

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

В документации MCP от Anthropic четко разграничены те, кто контролирует каждый из этих элементов: инструменты находятся под контролем модели, ресурсы — приложения, а запросы — пользователя. Именно такая иерархия контроля делает MCP чем-то большим, чем просто усовершенствованный механизм вызова функций.

Полный пример

Возьмем такой запрос:

«Покажите мне открытые проблемы в этом репозитории GitHub».

Упрощённая версия получившейся схемы может выглядеть так:

User
  │
  │ "Show me the open issues"
  ↓
AI Application
  │
  ↓
LLM
  │
  │ decides a GitHub tool is needed
  ↓
Tool Call
  │
  ↓
MCP Client
  │
  │ MCP
  ↓
GitHub MCP Server
  │
  ↓
GitHub API
  │
  ↓
Issue Data
  │
  ↓
MCP Client
  │
  ↓
LLM
  │
  ↓
Final Answer

Обратите внимание, сколько здесь различных уровней. Модель определяет, какая информация ей нужна. Приложение отвечает за организацию и выполнение операций. MCP обеспечивает стандартизированный канал для взаимодействия с внешними сервисами. Сам внешний сервис выполняет фактическую работу. Это четыре отдельные функции, а не один объединённый этап.

Какова роль Docker?

Часто серверы MCP поставляются в виде контейнеров Docker, например:

AI Application
      │
      │ stdio
      ↓
Docker Container
      │
      ↓
MCP Server
      │
      ↓
External Service

Следует четко понимать, что сам Docker не является MCP. Docker — это лишь удобный способ пакетирования и запуска сервера MCP. Тот же самый сервер может так же легко работать в качестве обычного локального процесса или быть размещенным удаленно в виде сервиса. Сам протокол полностью независим от того, как вы решите его развернуть.

STDIO против Streamable HTTP

MCP работает через несколько механизмов передачи данных.

Когда интеграция происходит локально, клиент MCP может запустить сервер MCP в качестве отдельного процесса и взаимодействовать с ним через STDIO.

Концептуально:

AI Application
      │
      │ stdin/stdout
      ↓
MCP Server Process

В ситуациях, когда сервер находится удаленно, MCP использует вместо этого Streamable HTTP.

AI Application
      │
      │ HTTP
      ↓
Remote MCP Server

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

MCP против REST API

Ещё одно важное отличие — это сравнение MCP с обычным REST API.

Взаимодействие с REST API выглядит так:

Application
     │
     │ HTTP request
     ↓
REST API
     │
     ↓
Data

Взаимодействие с MCP выглядит так:

AI Application
      │
      │ MCP
      ↓
MCP Server
      │
      ↓
REST API / Database / Filesystem / Other system

Интересно, что сервер MCP может свободно использовать REST API в качестве основы.

Следовательно, MCP призван не заменить REST.

Его лучше рассматривать как слой, ориентированный на ИИ и расположенный поверх уже существующих систем.

Почему MCP стал интересным

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

Без общего протокола возникает ситуация, подобная этой:

AI App A ───── Custom ───── GitHub
AI App A ───── Custom ───── Slack
AI App A ───── Custom ───── Database

AI App B ───── Custom ───── GitHub
AI App B ───── Custom ───── Slack
AI App B ───── Custom ───── Database

Каждая новая пара приложения и инструмента может потребовать написания нового кода для интеграции.

Общий протокол полностью меняет эту картину:

MCP
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
     GitHub        Slack       Database
      MCP           MCP           MCP
     Server        Server        Server

Именно по этой причине Anthropic выпустила MCP в качестве открытого стандарта, а не как инструмент, предназначенный исключительно для Claude.

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

Но наличие большего количества инструментов автоматически не делает агента лучше

Именно здесь последующие инженерные разработки Anthropic становятся по-настоящему интересными.

Легко предположить:

Больше инструментов = более способный агент.

Однако на практике это предположение не оправдывается.

Исследования Anthropic в области проектирования инструментов показывают, что агенты могут даже работать хуже, когда у них слишком много перекрывающихся или плохо спроектированных инструментов.

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

В качестве примера, вместо того чтобы использовать три отдельных вызова, как:

list_users()
list_transactions()
list_notes()

более эффективно будет предоставить агенту одну объединенную функциональность, например:

get_customer_context()

поскольку это лучше соответствует тому, что на самом деле пытается сделать агент.

Другими словами, сам интерфейс инструмента становится частью среды, в которой действует агент.

Инструменты — это интерфейс для агента

Это наблюдение указывает на более общую идею, которую стоит подчеркнуть:

Инструменты должны создаваться с учетом потребностей агента, а не просто быть переупаковкой существующего API.

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

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

Ему приходится сталкиваться с:

• ограниченным окном контекста
• вероятностными результатами
• временными ошибками при выборе подходящего инструмента
• временными ошибками при генерации правильных параметров
• неоднозначностью в том, что на самом деле запрашивается

Именно поэтому очень важен способ описания инструмента.

Рассмотрим, насколько нечетким бывает описание:

search(id)

по сравнению с тем, насколько ясным оно может быть:

search_github_issues(
    repository,
    query,
    state
)

Чтобы модель могла эффективно использовать инструмент, ей необходимо знать:

• что на самом деле делает инструмент
• когда следует использовать именно его
• что означает каждый входной параметр
• каков формат вывода
• чего инструмент не может сделать

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

Контекст становится важной частью разработки агентов

Недавно Anthropic также сделал акцент на концепции контекста «в нужный момент».

Примитивный способ обработки контекста выглядит следующим образом:

Load everything
      ↓
Put everything into context
      ↓
Ask the LLM to reason

Такой подход быстро сталкивается с проблемами масштабирования.

Более устойчивый подход выглядит так:

Small amount of initial context
          ↓
Agent identifies what it needs
          ↓
Tool retrieves relevant information
          ↓
Relevant information enters context
          ↓
Agent continues

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

Anthropic рассматривает это как шаг к обработке контекста «в нужный момент» в системах агентов.

Это напрямую связано с MCP.

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

Цикл агента

Как только все эти элементы собраны вместе, общая архитектура становится гораздо понятнее.

Упрощённая версия цикла агента выглядит так:

              ┌──────────────┐
              │     User     │
              └──────┬───────┘
                     ↓
              ┌──────────────┐
              │     LLM      │
              └──────┬───────┘
                     ↓
              Need a tool?
                /       \
              No         Yes
              ↓           ↓
           Answer      Tool Call
                          ↓
                     Tool/MCP
                          ↓
                     Tool Result
                          │
                          └─────────┐
                                    ↓
                                   LLM
                                    │
                         ┌──────────┴──────────┐
                         ↓                     ↓
                      Continue              Answer

Этот цикл находится в центре большинства современных агентских систем.

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

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

А что насчёт фреймворков?

Фреймворки вроде LangGraph могут сделать создание таких систем более управляемым, предоставляя структуру для работы.

Тем не менее существует важное предостережение, которое стоит иметь в виду.

Рекомендация компании Anthropic — понимать то, что происходит внутри фреймворка: прямые вызовы больших языковых моделей, определения инструментов, логику оркестрации и получаемые ответы, вместо того чтобы рассматривать фреймворк как чёрный ящик.

Фреймворк обычно предоставляет что-то вроде:

Agent
 ├── State
 ├── Nodes
 ├── Tools
 ├── Routing
 └── Execution

Но за этой абстракцией реальная механика выглядит так:

LLM
 ↓
Messages
 ↓
Tool calls
 ↓
Tool execution
 ↓
Tool results
 ↓
LLM

Понимание этого низкоуровневого процесса значительно упрощает работу с самим фреймворком, поскольку вы можете видеть, что он автоматизирует, а не просто полагаться на то, что он работает.

MCP не заменяет фреймворки агентов

Стоит чётко понимать, что это разные уровни системы, а не конкурирующие варианты.

Упрощённая стековая архитектура может выглядеть так:

┌─────────────────────────────┐
│        User Interface       │
├─────────────────────────────┤
│       Agent / Workflow      │
├─────────────────────────────┤
│      LLM / Model API        │
├─────────────────────────────┤
│        Tool Calling         │
├─────────────────────────────┤
│             MCP             │
├─────────────────────────────┤
│   External Tools / Systems  │
└─────────────────────────────┘

Фреймворк агентов обычно управляет такими элементами:

• состоянием
• потоком выполнения
• маршрутизацией
• циклами
• повторными попытками
• выполнением инструментов

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

Вызов инструментов предоставляет модели механизм для запроса выполнения определённых действий.

Ни один из этих трёх элементов не является заменой для другого.

Некоторые распространённые заблуждения

«MCP — это модель ИИ».

Это неверно.

MCP — это протокол, и ничего больше.

У него нет возможности генерировать текст или мыслить самостоятельно.

«MCP заменяет вызов функций».

Это тоже неверно.

На самом деле сервер MCP может предоставлять инструменты, после чего приложение ИИ использует свой существующий механизм работы с инструментами, чтобы предоставить эти инструменты модели.

«LLM напрямую обращается к GitHub».

Как правило, нет.

Модель лишь генерирует запрос на использование инструмента.

Фактически операцию выполняют приложение и сопутствующая инфраструктура инструментов.

«Каждому серверу MCP нужен Docker».

Это неверно.

Docker — это лишь один из возможных способов развертывания сервера.

MCP касается коммуникации и предоставления возможностей, а не способа контейнеризации.

«Сервер MCP — это агент ИИ».

Не обязательно.

Сервер MCP может просто предоставлять обычные, детерминированные операции, такие как:

search()
read()
create()
update()
delete()

«MCP полезен только для GitHub».

Совсем нет.

MCP был создан как универсальный протокол для связи ИИ-приложений с внешними данными и ресурсами. В первоначальном объявлении компании Anthropic уже упоминались интеграции с такими системами, как GitHub, Slack, Google Drive, базами данных и различными средами разработки.

Более важный урок: инженерия агентов — это не просто инженерия подсказок

Это, пожалуй, самое значимое изменение в подходе, которое возникает при изучении этого материала.

Создание действительно полезных агентных систем — это не просто вопрос:

Write a clever prompt
        ↓
Use a powerful model
        ↓
Get a smart agent

Здесь задействовано несколько отдельных инженерных уровней:

Model
               ↓
        Tool Selection
               ↓
        Tool Definitions
               ↓
        Tool Execution
               ↓
        Context Management
               ↓
          State / Memory
               ↓
       Control / Guardrails
               ↓
          Evaluation

Собственные технические материалы компании Anthropic всё чаще отражают более широкий, системный взгляд на то, что на самом деле требуется для создания агента.

В качестве примера их недавняя работа по оценке агентов сосредоточена на анализе многоэтапного поведения, использования инструментов, изменений состояния и адаптации со временем, а не на оценке качества исключительно на основе финального блока сгенерированного текста.

Это представляет собой существенно иной подход к проектированию приложений ИИ.

Что мне кажется самым интересным

Важный переход здесь на самом деле не в том:

Chatbot → Agent

Более точно это выглядит так:

LLM
 ↓
LLM + Tools
 ↓
LLM + Tools + External Context
 ↓
LLM + Tools + Context + Control Loop
 ↓
Agentic System

MCP вписывается в эту последовательность, предоставляя приложениям ИИ стандартизированный способ доступа к внешним возможностям.

Модель обеспечивает интеллектуальную составляющую.

Приложение обеспечивает управление.

Инструменты обеспечивают действия.

Внешние системы обеспечивают информацию и возможности реального мира.

MCP обеспечивает стандартизированный связующий слой, соединяющий приложения ИИ с этими возможностями.

Моя текущая когнитивная модель

После изучения механизмов вызова инструментов, концепции MCP и более общих материалов Anthropic о агентных системах, вот самая простая архитектурная схема, отражающая, как все эти элементы взаимосвязаны:

USER
                           │
                           ↓
                    ┌─────────────┐
                    │     LLM     │
                    │             │
                    │ Reasoning   │
                    │ Decision    │
                    └──────┬──────┘
                           │
                    Tool request
                           │
                           ↓
                  ┌─────────────────┐
                  │ Agent Runtime   │
                  │                 │
                  │ State           │
                  │ Control Flow    │
                  │ Tool Execution  │
                  └────────┬────────┘
                           │
                           ↓
                     MCP / Tools
                           │
              ┌────────────┼────────────┐
              ↓            ↓            ↓
           GitHub       Database      Files
              │            │            │
              └────────────┼────────────┘
                           ↓
                    Tool Results
                           │
                           ↓
                          LLM
                           │
                           ↓
                         USER

Сама модель не является полноценным агентом.

Так же как и отдельный инструмент.

И MCP тоже не является агентом.

То, что на самом деле получается под названием «агент», возникает благодаря системе, окружающей модель — той части, которая позволяет ей рассуждать, принимать действия, наблюдать за происходящим и продолжать работу над достижением цели.

Итоговый вывод

Если вы собираетесь создавать ИИ-агентов, стоит тщательно освоить четыре ключевых концепции:

1. Вызов инструментов

Модель может попросить приложение выполнить определенный инструмент.

2. Циклы действий агента

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

3. MCP

Стандартизированный протокол для подключения ИИ-приложений к внешним инструментам, ресурсам и контексту.

4. Инженерия инструментов

Качество ваших инструментов, их описания, параметры, контекст, который они возвращают, и степень их оценки могут существенно повлиять на эффективность работы агента.

Возможно, самый важный урок из практики инженерии Anthropic заключается в следующем:

Не добавляйте сложности просто потому, что можете.

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

Цель никогда не заключалась в создании самого сложного возможного агента.

Цель — создать систему, которая надежно выполняет задачу.