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
Цикл замкнулся.
В прошлой части☝ модель выбрала инструмент 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