PRO то, что под капотом у агента 🤖 (часть 03).
Цикл замкнулся.

В прошлой части☝ модель выбрала инструмент jira_get_issue и вернула нам function_call.

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

Наша программа получает примерно такой ответ:

{
  "type": "function_call",
  "name": "jira_get_issue",
  "call_id": "call_123",
  "arguments": "{\"issue_key\":\"TASK-123\"}"
}

Теперь работа переходит к нашему коду. Он разбирает arguments, находит функцию jira_get_issue и вызывает уже настоящий Jira API.

Jira возвращает данные:

{
  "key": "TASK-123",
  "summary": "Добавить оплату картой",
  "status": "In Progress",
  "description": "..."
}

Но и здесь работа ещё не закончена.

Полученные данные нужно вернуть модели. Для этого мы отправляем в Responses API результат выполнения функции:

{
  "type": "function_call_output",
  "call_id": "call_123",
  "output": "{\"key\":\"TASK-123\",\"summary\":\"Добавить оплату картой\",\"status\":\"In Progress\"}"
}


call_id здесь важен: по нему модель понимает, к какому именно вызову инструмента относится результат.
После этого модель снова получает управление. Теперь у неё есть не только исходная команда, но и реальные данные из Jira.

Она может продолжить анализ и уже сформировать ответ пользователю.

Получилась первая полноценная цепочка:
1⃣ наш вопрос к модели + доступная функция →
2⃣ модель выбирает нужную функцию →
3⃣ модель возвращает function call →
4⃣ наш код парсит function call и делает запрос в JIRA →
5⃣ JIRA нам отвечает →
6⃣ наш код получает результат и отправляет в модель →
7⃣ модель получает дополнительные данные →
8⃣ модель возвращает нам ответ на наш вопрос.

И это, пожалуй, самый важный момент во всей конструкции.

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

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


——

17 сентября, будем проводить открытое онлайн мероприятие, где расскажем про то, что изменилось в работе аналитиков за последний год из-за появления ИИ и что делать, чтобы не быть замененным "простым скриптом". 📅

Пока ждёте эфир можете:
➖потренируйтесь выявлять потребности у заказчика в нашем тренажере - это бесплатно 🔥
➖Так же продолжает улучшаться наш бот по оценке резюме (подробнее вот тут👆). На текущий момент уже 114👍 регулярных пользователей)

😳 Когда пилил, не думал, что будет такой спрос.

——

✌️ ПРО СА| 🆕НСА 2.0

PRO function calling

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

Начали тут☝с обычного запроса к модели:

«Проанализируй задачу TASK-123 в JIRA».

Затем вот тут☝ посмотрели, что происходит внутри API и почему сама модель не может просто взять и прочитать нашу Jira.

После этого вот тут ☝ описали модели инструмент jira_get_issue и увидели, как она сама сформировала function_call.

Модель не вызвала Jira напрямую. Она сообщила нашей системе: «Мне нужны данные TASK-123, вызови вот эту функцию».

Дальше наша система выполнила функцию, получила данные из Jira и вернула результат обратно модели.

На этом месте мы фактически разобрали function calling.

И здесь стоит зафиксировать терминологию.

Function calling - это частный случай более общего понятия tool calling.

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

То есть пока мы собрали довольно простой механизм:
модель → tool call → наша система → внешний сервис → результат → модель.

Но это ещё не полноценный агент.

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

И вот тут уже появляются agent loop, MCP, Skills и другие элементы агентной архитектуры.

Но куда двигаться дальше?

🌟Что разобрать следующим?

1️⃣ Как модель выбирает нужный инструмент из десятков доступных
2️⃣ Как устроен agent loop и несколько последовательных вызовов
3️⃣ MCP и как через него подключать инструменты
4️⃣ Skills и чем они отличаются от инструментов

Пишите номер в комментариях и по результатам продолжим серию.

——

✌️ ПРО СА| 🆕 НСА 3.0

Уже завтра! 📊

Напоминание! ⚠️

Сегодня в 19:00 живой эфир. Поговорим о профессии аналитика и о том, как сделать, чтобы тебя не заменил ИИ.

Самых активных ждут подарки, а в конце устроим розыгрыш. 🎁

Вход по ссылке: ссылка 👆

Начинаем через 5 минут. ⌛

Вход по ссылке: ссылка 👆

PRO то, зачем нам MCP 🤖
(часть 01).

По результатам опроса вот тут: ссылка 👆 была выбрана тема MCP. Поэтому на этой неделе ее и раскроем и продолжим рассматривать нашу ситуацию, когда мы что-то хотим получить из JIRA.

До этого мы подключали Jira к нашей модели вручную.

Описали функцию jira_get_issue, получили от модели function_call, сами вызвали Jira API и вернули результат обратно.

Для одного инструмента всё довольно просто.

Но теперь представим, что у нашего агента есть Jira, Confluence, GitLab, корпоративная БД и ещё несколько внутренних сервисов. Для каждого нужно описать инструменты, реализовать вызовы, разобраться с авторизацией, обработать ошибки и поддерживать всё это при изменениях внешних систем.

И здесь появляется MCP.

Model Context Protocol предлагает стандартный способ подключать модель к внешним источникам данных и инструментам. Вместо того чтобы для каждого агента отдельно писать интеграцию с Jira, можно иметь MCP-сервер Jira, который предоставляет набор доступных возможностей.

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

Получается следующая последовательность:
1⃣ модель →
2⃣ MCP-клиент →
3⃣ MCP-сервер (со списком инструментов) →
4⃣ внешняя система

При этом важно не перепутать MCP с самим инструментом.
jira_get_issue может оставаться инструментом.

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

И это принципиальное отличие от того, что мы делали раньше.

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

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

——

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

Практикум {НСА} 3.0 🎓 даёт тот же принцип: готовый путь вместо сборки с нуля

Уже вот-вот стартуем наш практикум {НСА} 3.0 🎓, который не просто поднял свою версию, а существенно обновил подход к обучению. Теперь кроме стандартной практики появляется возможность многократно отточить навыки в наших тренажерах:
✔️ тренажер по разработке требований
✔️ тренажер по работе с базами данных
✔️ тренажер по работе с интеграциями
✔️ тренажер по работе с нотациями
✔️ тренажер по работе с пользовательским интерфейсом

После работы в тренажерах вы будете ощущать себя еще более уверенными как на собеседованиях, так и на испытательном сроке. 😎

За информацией обращайтесь в личку или пишите под постом + и я напишу вам сам.

——

✌️ ПРО СА|🎓 НСА 3.0

PRO то, зачем нам MCP 🤖
(часть 02).

В прошлых постах мы сами описывали модели функцию jira_get_issue.

Но что если Jira подключена через MCP?

Тогда первый вопрос уже не «Как описать модели функцию?», а:

откуда вообще модель узнает, какие инструменты у неё есть?

Здесь появляется MCP-клиент. Он подключается к MCP-серверу и запрашивает список доступных инструментов.

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

MCP client → MCP server
    tools/list

Сервер возвращает каталог доступных инструментов примерно такого вида:

{
  "tools": [
    {
      "name": "jira_get_issue",
      "description": "Получает задачу из JIRA",
      "inputSchema": {
        "type": "object",
        "properties": {
          "issue_key": {
            "type": "string"
          }
        },
        "required": ["issue_key"]
      }
    },
    {
      "name": "jira_search",
      "description": "Ищет задачи в JIRA",
      "inputSchema": {
        "type": "object",
        "properties": {
          "query": {
            "type": "string"
          }
        }
      }
    }
  ]
}

И здесь становится интересно.

Если внимательного взглянуть на этот JSON, то по сути, мы уже видели его структуру:
➖name,
➖description,
➖inputSchema
очень похожи на то описание инструмента, которое мы вручную передавали модели через API вот тут ☝.

Именно так MCP и связывает внешний инструмент с нашим агентом. ✔️

Дальше MCP-клиен передаёт полученный каталог модели.

Модель видит доступные инструменты и, если для решения задачи нужен Jira, формирует обычный tool call.

Например:

jira_get_issue
{
  "issue_key": "TASK-123"
}

А MCP-клиент уже превращает этот вызов в протокольный запрос к серверу:

MCP-клиент → MCP-сервер
   tools/call
   jira_get_issue(TASK-123)

Сервер выполняет свою логику и возвращает результат.

Получается важное разделение:
1⃣ MCP-сервер знает, как работать с внешней системой.
2⃣ MCP-клиент знает, как разговаривать с MCP-сервером.
3⃣ модель решает, какой инструмент ей нужен.

И мы больше не пишем для каждого агента отдельную интеграцию с каждой системой.

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

Потому что MCP сам по себе моделью не является.

——

✌️ ПРО СА|🎓НСА 3.0

PRO то, зачем нам MCP 🤖
(часть 03).
Кто связывает MCP и модель

В первых двух постах мы разобрались, зачем нужен MCP и как MCP-сервер сообщает о доступных инструментах через tools/list.

Но остаётся один важный вопрос:

кто передаёт эти инструменты модели?

MCP-сервер с моделью напрямую не разговаривает.

У нас есть MCP-клиент. Он подключается к MCP-серверу, получает список инструментов и передаёт эту информацию нашему Agent/Host.

Дальше Agent/Host формирует обычный запрос к LLM:

Запрос:
«Проанализируй TASK-123»

Tools:
- jira_get_issue
- jira_search
- ...

Для модели уже неважно, откуда эти инструменты появились. Она просто видит доступные tools и может выбрать нужный.

Например:

function_call:
jira_get_issue({
  "issue_key": "TASK-123"
})

Теперь Agent/Host получает этот вызов и передаёт его MCP-клиенту.

MCP-клиент обращается к MCP-серверу:

tools/call
jira_get_issue(TASK-123)

MCP-сервер выполняет необходимую работу с Jira и возвращает результат.

А Agent/Host передаёт этот результат обратно модели.

Если собрать всё вместе, получается схема на картинке 👆

И теперь вся конструкция, которую мы разбирали последние посты, складывается в одну картину:

➖LLM решает, какое действие нужно выполнить.
➖Agent/Host управляет циклом и связывает компоненты.
➖MCP-клиент взаимодействует с MCP-сервером по протоколу MCP.
➖MCP-сервер предоставляет инструменты и работает с внешней системой.

При этом сама модель не обязана знать, что за jira_get_issue стоит MCP. Для неё это просто доступный инструмент.

На этом тему MCP закрываем. ✔️

Мы разобрали MCP ровно настолько, чтобы понимать, что происходит под капотом, а не просто знать расшифровку Model Context Protocol.

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

🌟Что разобрать следующим?

1️⃣ Как модель выбирает нужный инструмент
2️⃣ Agent loop и несколько последовательных вызовов
3️⃣ Skills: что это и чем отличаются от tools
4️⃣ Контекст агента: что модель получает на каждом шаге

Пишите номер в комментариях и по результатам продолжим серию.

——

✌️ ПРО СА|🎓НСА 3.0