Коли ти даєш coding assistant задачу типу "виправ баг, ось error message" - всередині відбувається приблизно те саме, що робив би розробник. Спочатку треба зібрати контекст - зрозуміти що за помилка, де вона в коді, які файли залучені. Потім сформувати план і виконати дію - оновити файл, запустити тест, перевірити результат
❗️Але певні кроки вимагають від моделі взаємодії з зовнішнім світом - прочитати файл, запустити команду, підтягнути документацію, а мовна модель сама по собі цього не вміє. Модель приймає текст на вхід і віддає текст на виході. Якщо ти напряму запитаєш в чат "що написано у файлі main.go?" - вона скаже, що не має доступу до файлової системи
Сoding assistant як раз вирішує цю проблему. Перед кожним запитом до моделі він додає опис всіх своїх інструментів у вигляді JSON Schema. Кожен tool описаний структуровано - назва, що робить, які параметри приймає і якого типу. Щось типу:
{
"name": "read_file",
"description": "Reads contents of a file",
"input_schema": {
"type": "object",
"properties": {
"file_path": { "type": "string" }
}
}
}
Модель отримує цей список і тепер знає що в неї є ReadFile, WriteFile, RunCommand, Grep і так далі. Коли їй треба щось зробити - вона відповідає не звичайним текстом, а спеціально структурованим блоком. Відповідь від моделі може містити кілька блоків одночасно - текстовий блок (пояснення для тебе) і tool_use блок (інструкція для assistant-а). Виглядає приблизно так:
{
"content": [
{ "type": "text", "text": "Зараз прочитаю файл..." },
{ "type": "tool_use",
"id": "call_abc123",
"name": "read_file",
"input": { "file_path": "main.go" }
}
],
"stop_reason": "tool_use"
}
👉 Зверни увагу на stop_reason: "tool_use". Це сигнал для assistant-а - модель ще не закінчила, вона хоче виконати інструмент. Assistant бачить це, витягує з tool_use блоку назву функції і параметри, виконує дію (читає файл з диска), і відправляє результат назад з тим самим id щоб модель зрозуміла до якого саме запиту це відповідь:
{
"type": "tool_result",
"tool_use_id": "call_abc123",
"content": "package main\nfunc handler()..."
}
Модель отримує вміст файлу, аналізує його, і далі або відповідає завершити (stop_reason: "end_turn"), або робить наступний tool call. І так по колу
Ось як це виглядає покроково:
https://lms.beerphp.club/files/coding-assistant.png
Як модель вирішує який саме інструмент викликати
Вона орієнтується по description в JSON Schema. Саме текстовий опис tool-а - це те, на основі чого модель приймає рішення "мені зараз потрібен grep, а не read_file". Якщо два інструменти мають схожі описи - модель починає плутати їх між собою і викликає не той. За даними Anthropic, якщо дати агенту доступ до 18 інструментів замість 4-5 - якість вибору помітно падає, бо модель має зважити занадто багато варіантів одночасно
Що це цам дає?
📍 Можливість виконувати складніші задачі
📍 Розширюваність. Coding assistant легко отримує нові інструменти через MCP (Model Context Protocol - окремий протокол для підключення зовнішніх тулів). Ти описуєш новий інструмент тією ж JSON Schema, підключаєш сервер, і модель одразу починає ним користуватись
📍 Точність. Замість того щоб індексувати весь твій codebase і відправляти його на зовнішні сервери, assistant шукає потрібний код через tool calls - читає конкретні файли і grep-ає по кодовій базі, звужуючи контекст
👉 Тому звертайте увагу на кількість тулів, обовʼязково на якість їх описів, в ідеалі аналізуйте флоу через котре проходить агент під час виконання задачі, адже зайві кроки з його боку забруднюють ваш контекст і знижують якість вирішення задачі
#AI #agents #tools #architecture