PRO шум вокруг ИИ 🤖

Здесь у нас канал про системных аналитиков, а значит вот эти все концепции: промты, скиллы, агенты, харнес, обсер(прошу прощения)вабилити, должны быть раскрыты до уровня вызовов API, а не поверхностно на уровне: "запилим агента".

У меня кончились лимиты (включился Fable 5.1 и за ночь все съел), а поэтому:

лет ми спик фром май хард

, т.е. пишу без использования ИИ. ✍️

Так вот, весь вот этот шум и суета: все вокруг пары вызовов API, а все остальное - это уже надстройки, пристройки, подстройки и прочая история, которая служит тому, чтобы сделать такой вызов максимально эффективным и полезным.

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

Вот две ссылки, по которым стоит перейти и изучить информацию, если хочешь понимать, как это действительно работает:
1⃣OpenAI: Responses API
2⃣Anthropic: Messages API

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

--

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

Информация будет полезна:
➖как тем, кто уже в теме и планирует расти в профессии,
➖так и тем, кто кто хочет стать в 2026-2027 годах новым системным аналитиком.

----

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

PRO то, что под капотом у агента 🤖 (часть 01).
Первый запрос.

Вчера написал (прямо вот тут👆), что весь этот шум вокруг ИИ в конечном итоге сводится к нескольким вызовам API. Давайте проверим.

Возьмем обычную задачу:

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

Если запустить это через Codex или Claude Code, мы просто напишем задачу и через какое-то время получим готовый результат (ну или нет).

Что там происходило в фоне, можно вообще не знать.
Но давайте не будем брать готового агента. Попробуем собрать своего, используя только API.

И будем идти прямо по шагам. Запрос. Ответ. Следующий запрос. И так далее.
Начинаем с самого простого.

Отправляем модели POST /v1/responses:

{
"model": "gpt-5.6-luna",
"input": [
{
"role": "user",
"content": [
{
"type": "input_text",
"text": "Проанализируй задачу TASK-123 в JIRA"
}
]
}
],
"tools": []
}

На этом моменте ничего особенного не происходит. Мы просто отправили модели текст.

➖"model" говорит, какую модель использовать.
➖"input" содержит нашу задачу.

И всё.

Модель при этом не может зайти в Jira. У неё нет ни логина, ни доступа к API Jira, вообще ничего.

Поэтому вполне ожидаемый ответ:

Пришлите содержимое задачи TASK-123.

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

Вот это и посмотрим в следующем посте.

А дальше уже доберемся до tool calls, MCP, Skills и в итоге соберем весь этот «агентский» конструктор своими руками, чтобы понимать как эта "черная коробка" работает на самом деле.

----

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

PRO то, что под капотом у агента 🤖 (часть 02).
Как агенту сходить в JIRA

В прошлом посте мы отправили модели простую команду: «Проанализируй задачу TASK-123 в JIRA». Модель получила текст, но не получила саму задачу. Она не знает, что такое наша Jira и тем более не может самостоятельно сходить туда за данными.

Значит, нужно дать ей такую возможность.

Для этого мы описываем доступную функцию для модели:

{
  "type": "function",
  "name": "jira_get_issue",
  "description": "Получает полную информацию о задаче из JIRA по её идентификатору",
  "parameters": {
    "type": "object",
    "properties": {
      "issue_key": {
        "type": "string",
        "description": "Идентификатор задачи, например TASK-123"
      }
    },
    "required": ["issue_key"]
  }
}

Обратите внимание: мы пока ничего не вызываем.

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

Теперь модель получает исходную команду, описание этой функции и может вернуть уже не обычный текст, а структурированный function_call:

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

По сути, модель говорит нашей системе:

Мне нужны данные задачи TASK-123. Вызови для этого функцию jira_get_issue

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

Модель: принимает решение, какую операцию нужно выполнить.
Наша система: реально вызывает Jira.

Но пока мы остановимся на этом месте. Инструмент выбран, но действие ещё не выполнено.

В следующем посте замкнём эту цепочку: разберём function_call, вызовем Jira API, получим результат и вернём его обратно модели.

После этого у нас впервые появится полный цикл взаимодействия модели с внешней системой.

——

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

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

——

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

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