Building with Claude API

Повний інтерактивний курс українською. Від першого API-запиту до побудови агентних систем з інструментами, RAG та MCP.

уроків

модулів

20+

вправ

10+

квізів

1.1 Моделі Claude

Модуль 1 · Основи Claude

Цілі уроку

Зрозуміти три сімейства моделей Claude та їх відмінності
Навчитися обирати модель під конкретну задачу
Засвоїти підхід з комбінуванням моделей у одному застосунку

Ви отримали задачу: побудувати AI-помічника для вашого стартапу. Він має миттєво відповідати на прості запитання, грамотно генерувати маркетингові тексти і час від часу робити глибокий аналіз ринку. Одна модель не впорається з усім однаково добре -- але три моделі, що працюють разом, створять ідеальну команду. Давайте розберемось, як це працює.

Три сімейства: Opus, Sonnet, Haiku

Уявіть, що моделі Claude -- це три різних інструменти у вашій майстерні. Кожен оптимізований для свого типу роботи, і досвідчений майстер знає, коли який використовувати.

Метафора: Автомобілі

Подумайте про три авто. Opus -- це преміум-седан з найпотужнішим двигуном. Він ідеальний для складних маршрутів, але дорогий у обслуговуванні. Sonnet -- це надійний кросовер: збалансований, доступний, підходить для більшості щоденних поїздок. Haiku -- це спортбайк: блискавично швидкий, дешевий, але не для перевезення меблів.

Характеристика	Opus	Sonnet	Haiku
Інтелект	Найвищий	Збалансований	Базовий
Швидкість	Повільніший	Середня	Найшвидший
Вартість	Найдорожчий	Середня	Найдешевший
Reasoning	Глибоке міркування	Гарне міркування	Без reasoning
Найкраще для	Складні багатокрокові задачі	Практичне використання, код	Реальний час, великі обсяги

Тепер, коли ви бачите загальну картину, виникає практичне запитання: як обрати правильну модель для конкретної задачі?

Фреймворк вибору моделі

Як обирати?

Пріоритет -- інтелект? Opus. Коли потрібне глибоке розуміння, складне планування, дослідження.
Пріоритет -- швидкість? Haiku. Коли потрібна миттєва відповідь для користувача або масова обробка.
Збалансовані вимоги? Sonnet. Коли потрібно і якість, і розумна ціна.

Комбінування моделей

Але що якщо вам потрібні і швидкість, і інтелект? Ось тут починається справжня магія. Найефективніший підхід -- використовувати кілька моделей в одному застосунку, як команду спеціалістів у лікарні: медсестра (Haiku) робить первинну оцінку, терапевт (Sonnet) лікує типові випадки, а хірург (Opus) бере найскладніші операції. Наприклад:

Haiku класифікує вхідний запит (швидко і дешево)
Sonnet генерує відповідь для типових запитів
Opus обробляє найскладніші випадки, що потребують глибокого аналізу

Реальний сценарій: Інтернет-магазин

Уявіть e-commerce платформу з тисячами запитів на день. Haiku миттєво класифікує запит клієнта: "повернення", "питання про товар" чи "скарга". Sonnet генерує відповідь для 90% типових запитів. Opus підключається лише для складних випадків -- наприклад, коли клієнт загрожує судом або описує нетипову ситуацію. Результат: швидкість + якість + економія до 60% бюджету на API.

Спільні можливості

Всі три моделі мають базові можливості: генерація тексту, написання коду, аналіз зображень. Різниця -- у фокусі оптимізації, а не у наявності функцій.

Перевірка знань: Урок 1.1

1. Яка модель найкраще підходить для масової обробки у реальному часі?

Opus

Sonnet

Haiku

2. Який підхід найефективніший у продакшені?

Завжди використовувати Opus

Комбінувати моделі залежно від задачі

Завжди використовувати Haiku для економії

3. Яка модель має можливості глибокого reasoning?

Opus та Sonnet

Тільки Opus

Всі три моделі

1.2 Доступ до API

Модуль 1 · Основи Claude

Цілі уроку

Зрозуміти 5-кроковий процес від запиту до відповіді
Розібратися в токенізації, ембедінгах та генерації
Дізнатися про SDK для різних мов програмування

Ви написали свій перший "Hello, World!" і тепер хочете, щоб Claude працював у вашому додатку. Але як саме ваш код "розмовляє" з Claude? Чи це магія? Ні -- це чітко визначений протокол, подібний до того, як ви замовляєте їжу через Glovo: формуєте замовлення, платформа передає його кухарю, кухар готує, кур'єр доставляє.

5-кроковий процес API

Метафора: Поштова служба

API -- це повноцінна поштова служба. Ви пишете листа (формуєте JSON-запит), кладете його в конверт з маркою (додаєте API-ключ), несете на пошту (надсилаєте на сервер Anthropic). Поштар (SDK) доставляє його експерту (Claude). Експерт читає, пише відповідь і відправляє назад. При цьому поштар може нести лише обмежену кількість листів на хвилину (rate limits) -- і якщо ви завалите його роботою, він попросить зачекати. Ніколи не відправляйте запити напряму з клієнтського коду -- API-ключ має залишатися на сервері!

Крок за кроком

Клієнт → Ваш сервер: Користувач надсилає текст вашому серверу
Ваш сервер → Anthropic API: Сервер формує запит з API-ключем, моделлю, повідомленнями та max_tokens
Генерація тексту: Чотири етапи обробки всередині Claude
Зупинка: Модель зупиняється за max_tokens або end_of_sequence
API → Ваш сервер → Клієнт: Відповідь з текстом, використанням токенів та stop_reason

Тепер, коли ви розумієте зовнішній потік, давайте заглянемо "під капот" -- як саме Claude перетворює ваш текст на відповідь?

Як Claude генерує текст: 4 етапи

Метафора: Перекладач-поліглот

Уявіть перекладача, який: (1) розбиває речення на окремі слова, (2) дивиться кожне слово у гігантському словнику значень, (3) уточнює значення за контекстом сусідніх слів, (4) обирає найкраще наступне слово. Саме так працює Claude!

Етап	Назва	Що відбувається
1	Токенізація	Текст розбивається на токени -- слова, частини слів, символи
2	Ембедінг	Кожен токен перетворюється на список чисел, що представляють всі можливі значення
3	Контекстуалізація	Числа коригуються на основі сусідніх токенів для точного визначення значення
4	Генерація	Вихідний шар видає ймовірності для наступного слова, модель обирає та повторює

Розуміння цих етапів не просто теорія -- воно допоможе вам писати кращі промпти. Наприклад, знаючи, що Claude генерує текст по одному токену, ви зрозумієте, чому стрімінг працює саме так (про це -- в Модулі 2).

SDK для різних мов

Щоб не формувати HTTP-запити вручну, Anthropic надає офіційні SDK -- бібліотеки, що беруть на себе всю технічну роботу. Доступні для: Python, TypeScript/JavaScript, Go, Ruby. Також можна використовувати чистий HTTP-запит.

Обов'язкові параметри кожного запиту

API Key -- ваш секретний ключ доступу
model -- назва моделі (claude-sonnet-4-20250514, тощо)
messages -- список повідомлень розмови
max_tokens -- ліміт довжини відповіді

Реальний сценарій: Вибір SDK для проєкту

Ваша команда будує SaaS-платформу: бекенд на Python (FastAPI), фронтенд на React. Для бекенд-інтеграції з Claude використовуйте Python SDK -- він найзріліший, з найкращою документацією. Для серверних Next.js API routes підійде TypeScript SDK. Для мікросервісів на Go є Go SDK. Головне правило: API-ключ живе ТІЛЬКИ на сервері, ніколи у фронтенд-коді.

Що таке токен?

Токен -- це шматочок тексту: слово, частина слова або символ. Наприклад, слово "programming" може бути одним токеном, а "unpredictable" -- двома ("un" + "predictable"). В середньому 1 токен -- це приблизно 4 символи англійського тексту. Українські токени зазвичай коротші.

Що таке stop_reason?

stop_reason повідомляє, чому модель зупинилася: end_turn (закінчила думку), max_tokens (досягнуто ліміту), tool_use (хоче викликати інструмент), stop_sequence (зустріла стоп-послідовність).

1.3 Перший запит до Claude API

Модуль 1 · Основи Claude

Цілі уроку

Налаштувати середовище: встановити SDK, створити .env
Зробити перший API-запит через Python
Зрозуміти структуру повідомлень та відповіді

Пам'ятаєте той момент, коли ви вперше написали print("Hello, World!") і побачили результат? Зараз буде такий самий момент -- але замість простого виводу тексту, ви "оживите" штучний інтелект. Через 5 хвилин ваш код буде спілкуватися з Claude. Готові?

Налаштування середовища

Перш ніж писати код, потрібно підготувати робоче місце. Це як налаштувати кухню перед готуванням: встановити інструменти, дістати інгредієнти, перевірити все необхідне.

Крок 1: Встановлення пакетів

pip install anthropic python-dotenv

Крок 2: API-ключ у .env файлі

# Створіть файл .env у корені проєкту ANTHROPIC_API_KEY="sk-ant-ваш-ключ-тут"

Ніколи не комітьте .env!

Додайте .env у файл .gitignore. Витік API-ключа може коштувати вам сотні доларів.

Реальний сценарій: Запуск на сервері

У продакшені API-ключ зберігається у змінних середовища сервера (environment variables), а не у файлах. На Heroku це heroku config:set ANTHROPIC_API_KEY=sk-ant-..., на AWS -- через Secrets Manager, на Google Cloud -- через Secret Manager. Локально -- .env файл. Головне правило: ключ ніколи не потрапляє в git.

Крок 3: Ініціалізація клієнта

Ці три рядки -- фундамент будь-якого проєкту з Claude API. Без них жоден запит не працюватиме.

from dotenv import load_dotenv from anthropic import Anthropic load_dotenv() # Завантажує ANTHROPIC_API_KEY з .env client = Anthropic() # Клієнт автоматично знаходить ключ MODEL = "claude-sonnet-4-20250514"

Перший запит

Середовище готове. Тепер -- момент істини. Цей код робить саме те, що ми обговорювали в попередньому уроці: формує повідомлення, надсилає його Claude і отримує відповідь.

message = client.messages.create( model=MODEL, max_tokens=1024, messages=[ {"role": "user", "content": "Що таке квантові обчислення?"} ] ) # Повна відповідь -- об'єкт з метаданими print(message) # Тільки текст відповіді: print(message.content[0].text)

Розбір структури

model -- яку модель використовувати
max_tokens -- максимальна кількість токенів у відповіді (ліміт безпеки, не ціль)
messages -- список повідомлень, кожне з role та content
message.content[0].text -- витягує текст з першого блоку контенту

Формат повідомлень

Розуміючи структуру відповіді, давайте заглибимось у формат повідомлень. Кожне повідомлення -- це словник з двома полями:

{"role": "user", "content": "Ваш текст тут"} {"role": "assistant", "content": "Відповідь Claude"}

Метафора: Сценарій п'єси

Повідомлення -- це як сценарій п'єси. Кожна репліка має зазначено, хто говорить (role) і що говорить (content). user -- це ваш персонаж, assistant -- це Claude.

Вправа: Ваш перший запит

Створіть Python-скрипт, який:

Завантажує API-ключ з .env
Надсилає запит: "Назви 5 найбільших міст України та їх приблизне населення"
Виводить тільки текст відповіді

from dotenv import load_dotenv from anthropic import Anthropic load_dotenv() client = Anthropic() message = client.messages.create( model="claude-sonnet-4-20250514", max_tokens=1024, messages=[ {"role": "user", "content": "Назви 5 найбільших міст України та їх приблизне населення"} ] ) print(message.content[0].text)

1.4 Багатокрокові розмови

Модуль 1 · Основи Claude

Цілі уроку

Зрозуміти, що API не зберігає стан розмови
Навчитися підтримувати історію повідомлень
Створити хелпер-функції для зручної роботи

Ви вже вмієте ставити Claude одне запитання і отримувати відповідь. Але уявіть чат-бот підтримки: клієнт каже "Мій замовлення не прийшло", потім "Номер замовлення 12345", потім "Можете повернути гроші?". Якщо бот забуде контекст після кожного повідомлення -- він буде марним. Як зробити так, щоб Claude "пам'ятав" розмову?

API без пам'яті

Метафора: Лікар з амнезією

Уявіть лікаря, який після кожного прийому повністю забуває пацієнта. Наступного разу ви приходите -- і він дивиться на вас як на незнайомця. Щоб він пам'ятав контекст, ви приносите повну медичну картку кожного разу. Anthropic API працює так само: кожен запит незалежний, і ви маєте надсилати всю історію розмови.

Підтримка історії

Рішення елегантно просте: ви зберігаєте всі повідомлення у списку і кожного разу надсилаєте весь список. Ось базовий код, який це робить -- він стане основою для всіх ваших чат-ботів.

# Ініціалізуємо порожню історію conversation = [] # Хелпер-функції def add_user_message(messages, text): messages.append({"role": "user", "content": text}) def add_assistant_message(messages, text): messages.append({"role": "assistant", "content": text}) def chat(messages): response = client.messages.create( model=MODEL, max_tokens=1024, messages=messages ) return response.content[0].text

Приклад багатокрокової розмови

Подивіться, як це працює на практиці. Зверніть увагу на третій крок -- Claude розуміє займенник "воно" лише тому, що бачить повну історію.

# Крок 1: Перше питання add_user_message(conversation, "Що таке машинне навчання?") reply = chat(conversation) add_assistant_message(conversation, reply) print(reply) # Крок 2: Друге питання (Claude пам'ятає контекст!) add_user_message(conversation, "Наведи приклад з реального життя") reply = chat(conversation) add_assistant_message(conversation, reply) print(reply) # Крок 3: Claude розуміє, що "воно" = машинне навчання add_user_message(conversation, "Чим воно відрізняється від deep learning?") reply = chat(conversation) print(reply)

Ключовий принцип

Без історії повідомлень Claude не знає контексту. З повною історією -- він підтримує зв'язну розмову, розуміє займенники та відсилання до попередніх тем.

Реальний сценарій: Чат-бот для HR

Ваша компанія будує HR-бот для відповідей на запитання працівників. Працівник питає: "Скільки днів відпустки мені залишилось?" -- бот відповідає. Потім: "А чи можу я перенести невикористані на наступний рік?" -- без історії Claude не зрозуміє, що мова про відпустку. З історією -- відповідь точна і контекстна. Саме ця техніка робить різницю між "іграшковим" ботом і продакшн-рішенням.

Увага: зростання контексту

Кожен наступний запит надсилає ВСЮ попередню розмову. Це означає: більше токенів = вища вартість і повільніша відповідь. Уявіть, що ви кожного разу перечитуєте ВЕСЬ щоденник перед тим, як додати новий запис. Для довгих розмов слід зрізати або стискати історію -- як робити конспект замість повного перечитування.

Перевірка знань: Урок 1.4

1. Чому потрібно надсилати всю історію з кожним запитом?

Claude зберігає частину контексту

API не зберігає жодних повідомлень між запитами

Це потрібно тільки для першого запиту

2. Що станеться, якщо надіслати лише останнє повідомлення без історії?

Claude відповість з повним контекстом

Виникне помилка

Claude не зрозуміє контекст попередніх повідомлень

2.1 System Prompts

Модуль 2 · Налаштування поведінки

Цілі уроку

Зрозуміти призначення system prompt
Навчитися задавати ролі та обмеження
Побачити вплив system prompt на поведінку моделі

Уявіть ситуацію: ви запускаєте двох ідентичних Claude -- одному кажете "Ти -- строгий професор математики", іншому "Ти -- веселий друг-програміст". Один і той самий запит "Поясни рекурсію" дасть кардинально різні відповіді. Ця "невидима рука", що формує характер Claude -- і є system prompt. Він як режисерські нотатки перед п'єсою: глядач (користувач) їх не бачить, але актор (Claude) грає відповідно до них.

Що таке System Prompt?

Метафора: Режисер і актор

System prompt -- це як вказівки режисера акторові перед виходом на сцену. Ви не змінюєте текст п'єси (запит користувача), але задаєте як актор має його виконувати: весело чи серйозно, формально чи дружньо, стисло чи розгорнуто.

System prompt контролює як Claude відповідає, а не що він відповідає. Він задає роль, тон, обмеження та формат.

Реалізація

Давайте подивимось, як це виглядає в коді. Один додатковий параметр system -- і Claude перетворюється з універсального асистента на спеціалізованого експерта.

response = client.messages.create( model=MODEL, max_tokens=1024, system="Ти -- терплячий репетитор з математики. Замість прямих відповідей давай підказки та направляй учня до самостійного розв'язку. Використовуй прості аналогії.", messages=[ {"role": "user", "content": "Як розв'язати рівняння 2x + 5 = 15?"} ] )

Структура ефективного System Prompt

Формула: Роль + Стиль + Обмеження

Роль: "Ти -- досвідчений фінансовий аналітик"
Стиль: "Відповідай стисло, використовуй списки та таблиці"
Обмеження: "Ніколи не давай інвестиційних порад. Завжди вказуй джерела."

Тепер, коли ви розумієте структуру, давайте зробимо це зручним для повторного використання.

Реалізація з хелпер-функцією

Цей хелпер -- ваш "швейцарський ніж" для будь-якого проєкту. Він дозволяє легко перемикати поведінку Claude між різними сценаріями.

def chat(messages, system_prompt=None): params = { "model": MODEL, "max_tokens": 1024, "messages": messages } if system_prompt: params["system"] = system_prompt response = client.messages.create(**params) return response.content[0].text

Реальний сценарій: Юридичний асистент

Юридична фірма будує бот для первинної консультації клієнтів. System prompt: "Ти -- юридичний асистент. Відповідай формально. НІКОЛИ не давай конкретних юридичних порад -- завжди рекомендуй консультацію з адвокатом. Якщо запитання не стосується права -- ввічливо відхиляй." Без цього system prompt Claude міг би дати небезпечну юридичну пораду. З ним -- бот корисний, але безпечний.

Вправа: Створіть свій System Prompt

Напишіть system prompt для бота-помічника у кав'ярні, який:

Рекомендує каву під настрій клієнта
Відповідає коротко і дружньо
Ніколи не рекомендує каву з кофеїном після 18:00

system = """Ти -- дружній бариста-консультант у затишній кав'ярні. Правила: - Рекомендуй каву, виходячи з настрою та побажань клієнта - Відповідай коротко, тепло, з легким гумором - Якщо зараз після 18:00, рекомендуй ТІЛЬКИ декаф або трав'яні напої - Завжди пропонуй десерт до напою"""

2.2 Temperature

Модуль 2 · Налаштування поведінки

Цілі уроку

Зрозуміти, як temperature впливає на генерацію
Навчитися обирати правильне значення для задачі
Побачити різницю між детермінованими та креативними відповідями

Ви будуєте два додатки: парсер рахунків-фактур (має витягати точні цифри) і генератор маркетингових слоганів (має бути креативним). Один і той самий Claude, але потрібна зовсім різна поведінка. Як налаштувати "рівень креативності"? Відповідь -- параметр temperature.

Що таке Temperature?

Метафора: Радіоприймач

Temperature -- це як перемикач каналів на радіо. Temperature 0 -- це новинний канал: завжди точні факти, жодної імпровізації. Claude завжди обирає найвірогідніше слово, як диктор, що читає з суфлера. Temperature 0.5 -- це FM-станція з ведучим: є структура, але і живе спілкування. Temperature 1 -- джазова станція: повна імпровізація, несподівані повороти, кожен ефір унікальний. Claude частіше обирає менш очевидні слова, і відповіді стають по-справжньому креативними.

Шкала Temperature

Значення	Поведінка	Використання
0.0	Детерміновано, передбачувано	Витяг даних, класифікація, код
0.3	Легка варіативність	Переклад, резюме, Q&A
0.7	Помітна креативність	Маркетинг, копірайтинг
1.0	Максимальна випадковість	Брейнсторм, поезія, жарти

Реалізація

Додати temperature до запиту -- одна строчка. Але ця строчка може кардинально змінити якість вашого додатку. Ось два протилежних сценарії в одному коді.

response = client.messages.create( model=MODEL, max_tokens=1024, temperature=0.0, # Детерміновано messages=[ {"role": "user", "content": "Витягни email-адреси з цього тексту: ..."} ] ) response_creative = client.messages.create( model=MODEL, max_tokens=1024, temperature=1.0, # Максимально креативно messages=[ {"role": "user", "content": "Придумай 5 жартів про програмістів"} ] )

Реальний сценарій: A/B тестування температури

Маркетингова агенція генерує 10 варіантів заголовків для email-розсилки. Вони запускають один промпт з temperature 0.9 десять разів -- і отримують 10 різних креативних варіантів. Потім обирають найкращий через A/B тест. Якби використали temperature 0 -- отримали б 10 майже ідентичних заголовків. Для генерації контенту підвищена temperature -- це не баг, а фіча.

Важливо

Вища temperature не гарантує різних відповідей -- вона лише збільшує ймовірність варіативності. При temperature 0 відповіді будуть (майже) ідентичними при однакових вхідних даних.

Перевірка знань: Урок 2.2

1. Яке значення temperature найкраще для витягу структурованих даних?

0.0

0.5

1.0

2. Що робить temperature на рівні токенів?

Збільшує кількість токенів

Змінює значення токенів

Впливає на розподіл ймовірностей наступного токена

2.3 Стрімінг відповідей

Модуль 2 · Налаштування поведінки

Цілі уроку

Зрозуміти різницю між блокуючим та стрімінговим режимом
Реалізувати стрімінг відповідей
Навчитися отримувати фінальне повідомлення після стріму

Ви коли-небудь користувалися ChatGPT або Claude.ai? Помічали, як текст з'являється слово за словом, наче хтось друкує в реальному часі? Це не анімація -- це стрімінг. І саме ця техніка перетворює "мертвий" інтерфейс з 15-секундним очікуванням на живий, інтерактивний чат.

Навіщо потрібен стрімінг?

Метафора: Офіціант у ресторані

Без стрімінгу офіціант чекає, поки вся страва буде готова, і приносить все разом (10-30 секунд очікування). Зі стрімінгом офіціант приносить страву по шматочках: спочатку хліб, потім салат, потім основне. Ви починаєте їсти одразу!

Різниця в UX -- колосальна. Без стрімінгу користувач дивиться на порожній екран 10-30 секунд і думає "воно зависло?". Зі стрімінгом -- перші слова з'являються за 200-500 мс, і користувач одразу бачить, що система працює.

Базовий стрімінг

Перший спосіб -- низькорівневий. Ви отримуєте "сирі" події і самі їх фільтруєте. Підходить, коли потрібен повний контроль.

# Спосіб 1: stream=True stream = client.messages.create( model=MODEL, max_tokens=1024, stream=True, messages=[{"role": "user", "content": "Розкажи історію"}] ) for event in stream: # event.type: message_start, content_block_delta, message_stop if hasattr(event, 'delta') and hasattr(event.delta, 'text'): print(event.delta.text, end='', flush=True)

Спрощений стрімінг

Другий спосіб -- рекомендований для більшості проєктів. SDK бере на себе фільтрацію подій, а ви отримуєте чистий потік тексту. Бонус: метод get_final_message() повертає повне повідомлення для збереження в базу даних.

# Спосіб 2: client.messages.stream() -- зручніший with client.messages.stream( model=MODEL, max_tokens=1024, messages=[{"role": "user", "content": "Розкажи історію"}] ) as stream: for text in stream.text_stream: print(text, end='', flush=True) # Отримати повне повідомлення для збереження в БД final = stream.get_final_message() print(final.content[0].text)

Реальний сценарій: Чат-бот на сайті

Ви будуєте чат-віджет для сайту магазину. Без стрімінгу: користувач натискає "Відправити", чекає 8 секунд, бачить повну відповідь. 40% користувачів закривають сторінку, не дочекавшись. Зі стрімінгом: перші слова з'являються через 300мс, текст "друкується" в реальному часі. Користувач зайнятий читанням, а не очікуванням. Bounce rate падає на 25%.

Типи подій стріму

Кожен стрім проходить через чітку послідовність подій -- як акти у п'єсі. Розуміння цих подій допоможе вам будувати прогрес-бари та обробляти помилки.

Подія	Опис
`message_start`	Початок, підтвердження від API
`content_block_start`	Початок генерації тексту
`content_block_delta`	Шматочок тексту (найважливіший!)
`content_block_stop`	Блок контенту завершено
`message_stop`	Генерація повністю завершена

2.4 Контроль виводу та структуровані дані

Модуль 2 · Налаштування поведінки

Цілі уроку

Опанувати stop sequences для зупинки генерації
Навчитися pre-filling для направлення відповіді
Отримувати чисті структуровані дані (JSON, код) без зайвого тексту

Ось типова проблема: ви просите Claude повернути JSON, а він відповідає "Звичайно! Ось JSON для вас:" і далі обгортає його в markdown-блок з поясненнями. Ваш парсер ламається. Як змусити Claude видати ТІЛЬКИ дані, без "балачок"? Два потужних інструменти -- stop sequences та pre-filling -- вирішують це елегантно.

Stop Sequences

Stop sequence -- це як стоп-кран у потязі: рядок, при генерації якого Claude негайно зупиняється. Сам рядок НЕ включається у відповідь.

response = client.messages.create( model=MODEL, max_tokens=1024, messages=[{"role": "user", "content": "Порахуй від 1 до 10"}], stop_sequences=[", п'ять"] ) # Результат: "один, два, три, чотири" # (зупинився перед ", п'ять")

Pre-filling: направлення відповіді

Метафора: Початок речення

Pre-filling -- це коли ви починаєте речення за Claude, і він продовжує. Як у грі: "Кава краща за чай, тому що..." -- і Claude продовжить саме з цієї позиції.

response = client.messages.create( model=MODEL, max_tokens=1024, messages=[ {"role": "user", "content": "Що краще: Python чи JavaScript?"}, {"role": "assistant", "content": "Python кращий, тому що"} ] ) # Claude продовжить з аргументами на користь Python

Але справжня сила з'являється, коли ви комбінуєте обидва прийоми. Ось тут на сцену виходить найпотужніша техніка цього уроку.

Комбінація для чистого JSON

Цей патерн -- ваш найкращий друг для будь-якого API, що повертає структуровані дані. Він гарантує чистий JSON без жодного зайвого символу.

response = client.messages.create( model=MODEL, max_tokens=1024, messages=[ {"role": "user", "content": "Створи JSON з трьома фруктами та їх кольорами"}, {"role": "assistant", "content": "```json\n"} # Pre-fill ], stop_sequences=["```"] # Зупинка перед закриваючим блоком ) # Результат -- чистий JSON без markdown-обгортки та пояснень import json data = json.loads(response.content[0].text) print(data)

Чому це працює?

Claude бачить, що він "вже почав" відповідь з ```json. Він думає: "Ага, я вже відкрив блок коду, значить мені потрібно генерувати тільки JSON." А stop_sequence ``` зупиняє його перед закриваючим блоком. Результат -- чистий JSON без обгортки.

Реальний сценарій: API для мобільного додатку

Ваш бекенд генерує JSON-відповіді для мобільного додатку. Мобільний клієнт очікує чистий JSON -- будь-яке зайве слово зламає парсер. Комбінація pre-filling + stop_sequences гарантує, що Claude поверне виключно JSON, без "Ось ваш результат:" на початку та пояснень в кінці. Це критично для machine-to-machine комунікації.

Вправа: Витягніть Python-код

Використовуючи pre-filling та stop_sequences, отримайте чистий Python-код (без markdown та пояснень) для функції, що обчислює факторіал числа.

response = client.messages.create( model=MODEL, max_tokens=1024, messages=[ {"role": "user", "content": "Напиши функцію factorial(n) на Python"}, {"role": "assistant", "content": "```python\n"} ], stop_sequences=["```"] ) code = response.content[0].text print(code) # Чистий Python-код

3.1 Основи промпт-інженерії

Модуль 3 · Prompt Engineering

Цілі уроку

Зрозуміти, що таке промпт-інженерія та чому вона важлива
Засвоїти ітеративний підхід до покращення промптів
Побачити різницю між поганим і хорошим промптом

Два розробники отримали одну і ту саму задачу: побудувати AI-асистента для аналізу резюме. Обидва використовують Sonnet. У першого точність 45% -- клієнт незадоволений. У другого -- 92%, клієнт в захваті. Різниця? Не в коді, не в моделі. Тільки в промпті. Промпт-інженерія -- це навичка, що перетворює "іграшковий" AI на продакшн-інструмент.

Промпт-інженерія -- це наука експериментів

Метафора: Настроювання радіо

Промпт-інженерія -- це як настроювання старого радіо. Ви крутите ручку, шукаючи чистий сигнал. Початковий промпт -- це перша спроба. Ви тестуєте, бачите шуми (погану якість), крутите далі (змінюєте промпт), і поступово знаходите ідеальну частоту.

Зрозуміли аналогію з радіо? Тепер подивимось, як розробники зазвичай працюють з промптами -- і чому більшість роблять це неправильно.

Три типових підходи (і тільки один правильний)

Підхід	Опис	Результат
1. Спробував раз -- і в продакшн	Тестуєте 1-2 рази, здається "працює"	Проблеми в edge cases
2. Ручне тестування	Тестуєте з кількома вхідними, робите правки	Краще, але непередбачувано
3. Eval pipeline	Автоматичне тестування з об'єктивними оцінками	Найкращий результат

Більшість розробників недотестовують промпти. Використовуйте evaluation pipelines для об'єктивних оцінок перед деплоєм.

Приклад еволюції промпта

Поганий: "Зроби план харчування"

Кращий: "Створи одноденний план харчування для спортсмена"

Найкращий: "Створи одноденний план харчування для спортсмена вагою 80 кг, зростом 185 см, який хоче набрати м'язову масу. Дієтичні обмеження: без лактози. Формат: таблиця з калоріями."

Оцінка моделі-грейдера: 2.3 → 3.9 → 7.9

3.2 Чіткість, конкретність, XML-теги

Модуль 3 · Prompt Engineering

Цілі уроку

Навчитися писати чіткі та прямі промпти
Опанувати два типи конкретності (атрибути та кроки)
Структурувати промпти за допомогою XML-тегів

Уявіть, що ви даєте завдання стажеру: "Ну, подивись на ці дані і зроби щось корисне." Що ви отримаєте? Непередбачуваний результат. А тепер: "Проаналізуй дані продажів за Q3, визнач три найприбутковіших товари, поверни у вигляді таблиці з відсотками." Абсолютно інша справа. Claude працює так само -- чіткість промпту напряму визначає якість відповіді.

Метафора: Шафа-картотека

XML-теги -- це як підписані ящики у шафі-картотеці. Без них усі документи лежать в одній безладній купі, і Claude мусить здогадуватись, де закінчуються інструкції і починаються дані. З тегами -- кожна частина промпту має свій підписаний ящик: <instructions>, <data>, <format>. Claude точно знає, що є що.

Правило 1: Будьте прямими

Перший рядок промпта -- найважливіший. Починайте з дієслова та чіткої задачі:

# Погано: "Мені б хотілося, щоб ти подумав про те, як можна..." # Добре: "Напиши три абзаци про те, як працюють сонячні панелі" "Визнач три країни, що використовують геотермальну енергію"

Правило 2: Конкретність

Тип A: Атрибути (що хочу отримати)

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

Тип B: Кроки (як думати)

Задавайте конкретні кроки для міркування, щоб модель розглянула ширшу перспективу.

Але що робити, коли промпт містить і інструкції, і дані, і формат? Як Claude зрозуміє, де що? Ось тут на допомогу приходить третє правило.

Правило 3: XML-теги для структури

Коли ви вставляєте дані у промпт, XML-теги допомагають Claude розрізняти частини. Цей патерн -- один з найважливіших у промпт-інженерії, і ви будете використовувати його постійно.

prompt = """Проаналізуй наступний код та знайди баги: <my_code> def calculate(x, y): return x / y # Потенційне ділення на нуль! </my_code> <docs> Функція має повертати результат ділення або повідомлення про помилку. </docs> Поверни результат у форматі JSON."""

Реальний сценарій: Аналіз коду

Ви будуєте code review бот. Промпт містить три різних блоки: код, документацію до нього і критерії оцінки. Без XML-тегів Claude може сплутати код з інструкціями. З тегами <code_to_review>, <documentation>, <criteria> -- кожна частина чітко відокремлена, і Claude точно знає, де що шукати.

Чому XML-теги працюють?

Claude навчений розпізнавати XML-структуру. Теги з описовими іменами (як <athlete_information> замість просто <data>) дають додатковий контекст про природу даних. Навіть для коротких блоків XML робить промпт кращим.

Вправа: Переписати промпт з XML

Перепишіть цей промпт, використовуючи XML-теги та правила чіткості:

"Подивись на ці дані продажів і скажи щось розумне. Дані: iPhone 120шт, Samsung 95шт, Pixel 30шт."

"""Проаналізуй дані продажів та визнач тренди. <sales_data> iPhone: 120 одиниць Samsung: 95 одиниць Pixel: 30 одиниць </sales_data> Для кожного продукту визнач: 1. Частку ринку (у відсотках) 2. Позицію відносно конкурентів 3. Рекомендацію для збільшення продажів Формат відповіді: структурований список."""

3.3 Few-shot приклади

Модуль 3 · Prompt Engineering

Цілі уроку

Зрозуміти one-shot та multi-shot prompting
Навчитися створювати ефективні приклади
Опанувати обробку edge cases через приклади

Ви пояснюєте Claude складний формат звіту: "Перший рядок -- заголовок великими літерами, потім дефіс, потім дата у форматі DD.MM.YYYY, далі три пункти з маркерами..." Через п'ять абзаців інструкцій Claude все одно помиляється. А тепер уявіть: замість цих абзаців ви просто показуєте ОДИН готовий приклад. Claude миттєво "схоплює" формат. Це і є сила few-shot prompting.

Покажіть, а не розказуйте

Метафора: Навчання нового працівника

Ви можете годинами пояснювати новому працівнику правила заповнення звітів. Або дати заповнений приклад і сказати: "Роби так само." Другий спосіб працює краще -- і для людей, і для Claude.

Структура прикладу

Подивіться, як три приклади (multi-shot) повністю визначають поведінку класифікатора -- включно зі складними випадками на кшталт сарказму. Цей код -- готовий шаблон для будь-якої задачі класифікації.

prompt = """Класифікуй відгук як позитивний, негативний або нейтральний. <example> Вхід: "Ця кава чудова, буду замовляти ще!" Вихід: позитивний Пояснення: Клієнт висловлює задоволення та намір повернутися. </example> <example> Вхід: "Найгірший сервіс у моєму житті." Вихід: негативний Пояснення: Клієнт використовує суперлатив з негативною конотацією. </example> <example> Вхід: "Ну, нормально, мабуть." Вихід: нейтральний Пояснення: Відсутність явно позитивних чи негативних маркерів. </example> Тепер класифікуй: "О, дякую за підказку, це було ооочень корисно 🙄" """

Обробка edge cases

Останній приклад у промпті вище -- саркастичний. Додайте контекст для corner cases:

"Будь особливо уважним до сарказму. Emoji та перебільшення можуть змінювати тон на протилежний."

Реальний сценарій: Підтримка клієнтів

Компанія будує автоматичну маршрутизацію тикетів підтримки. Few-shot приклади визначають категорії: "Мій пакет не прийшов" → delivery, "Не працює кнопка оплати" → technical, "Хочу повернути товар" → returns. Один приклад з неоднозначною ситуацією ("Товар прийшов, але пошкоджений -- хочу заміну") показує Claude, що це returns, а не delivery. Без цього прикладу Claude класифікував би 30% таких тикетів неправильно.

Найкращі практики

Додавайте пояснення, чому приклад ідеальний
Використовуйте найкращі результати з попередніх eval як шаблони
Розміщуйте приклади після основних інструкцій
Включайте edge cases (сарказм, двозначності)

3.4 Оцінка промптів (Eval Pipeline)

Модуль 3 · Prompt Engineering

Цілі уроку

Побудувати eval pipeline для об'єктивної оцінки промптів
Зрозуміти три типи грейдерів
Навчитися ітеративно покращувати промпти

Як ви дізнаєтесь, що ваш промпт дійсно хороший? "Мені здається, він працює" -- це не відповідь. Уявіть хірурга, який каже: "Мені здається, операція пройшла нормально" -- без жодних аналізів. У промпт-інженерії eval pipeline -- це ваші "аналізи": об'єктивна, вимірювана оцінка якості, що дозволяє порівнювати версії промптів, як науковий експеримент.

Метафора: Лабораторія з контролю якості

Eval pipeline -- це як лабораторія контролю якості на виробництві. Кожна "партія" (версія промпту) проходить через стандартизовані тести. Якщо нова партія набирає менше балів за попередню -- вона не потрапляє на полиці (в продакшн). Без лабораторії ви випускаєте продукт наосліп.

6-кроковий eval workflow

Напишіть початковий промпт
Створіть тестовий датасет (3 або 1000 прикладів)
Згенеруйте варіації промпту з тестовими даними
Отримайте відповіді Claude на кожну варіацію
Оцініть відповіді за допомогою грейдера (1-10)
Ітеруйте: змініть промпт, повторіть, порівняйте

Три типи грейдерів

Тип	Як працює	Плюси	Мінуси
Code-based	Валідація JSON, Python, regex	Об'єктивний, швидкий	Тільки для структурованих даних
Model-based	Інший виклик Claude для оцінки	Гнучкий, розуміє якість	Може бути нестабільним
Human-based	Людина оцінює відповіді	Найточніший	Повільний, дорогий

Тепер, коли ви знаєте три типи грейдерів, давайте подивимось, як вони виглядають у коді. Почнемо з найпростішого -- code-based.

Приклад code-based грейдера

Цей грейдер ідеальний для задач, де відповідь має бути у конкретному форматі. Він працює миттєво, не потребує API-викликів і абсолютно об'єктивний.

import json, ast, re def validate_json(output): try: json.loads(output) return 10 # Валідний JSON except: return 0 # Невалідний def validate_python(output): try: ast.parse(output) return 10 # Валідний Python except: return 0 def validate_regex(output): try: re.compile(output) return 10 # Валідний regex except: return 0 # Фінальна оцінка = (model_score + syntax_score) / 2

Model-based грейдер

grader_prompt = """Оціни відповідь за шкалою 1-10. Критерії: - Відповідність завданню - Якість та повнота - Дотримання формату Поверни JSON: {"score": N, "reasoning": "...", "strengths": "...", "weaknesses": "..."}"""

Перевірка знань: Урок 3.4

1. Який тип грейдера найкращий для перевірки якості тексту?

Code-based

Model-based

Ніякий -- достатньо ручної перевірки

2. Скільки мінімум кроків у eval workflow?

4.1 Введення в Tool Use

Модуль 4 · Tool Use

Цілі уроку

Зрозуміти, навіщо потрібні інструменти (tools)
Побачити повний потік tool use
Написати першу функцію-інструмент

Користувач питає вашого бота: "Котра зараз година?" Claude -- надзвичайно розумний, але він не знає, котра година. Його знання "заморожені" на момент тренування. Або клієнт каже: "Перевір статус мого замовлення #4521" -- Claude не має доступу до вашої бази даних. До цього моменту Claude міг тільки говорити. Інструменти дають йому можливість ДІЯТИ.

Навіщо інструменти?

Метафора: Руки для генія

Без інструментів Claude -- це геніальний мозок у банці: може думати, аналізувати, генерувати тексти, але не може взаємодіяти зі світом. Інструменти -- це руки. З ними Claude може дізнатися поточний час, перевірити погоду, прочитати базу даних, надіслати email, забронювати зустріч. Без інструментів Claude тільки говорить. З інструментами -- він ДІЄ.

Потік Tool Use

Ви надсилаєте запит + схеми доступних інструментів
Claude вирішує: чи потрібен інструмент?
Якщо так -- повертає tool_use блок з назвою та аргументами
Ваш код виконує функцію і отримує результат
Ви надсилаєте результат назад як tool_result
Claude генерує фінальну відповідь з урахуванням даних

Тепер давайте перетворимо теорію в код. Ось ваш перший інструмент -- проста функція, яку Claude зможе "попросити" виконати.

Приклад: функція-інструмент

Ця функція -- основа будь-якого інструменту. Без неї Claude не зможе дізнатися поточну дату. Зверніть увагу на валідацію входу -- Claude побачить текст помилки і зможе спробувати ще раз.

from datetime import datetime def get_current_datetime(date_format="%Y-%m-%d %H:%M:%S"): """Повертає поточну дату та час.""" if not date_format: raise ValueError("Формат дати не може бути порожнім") return datetime.now().strftime(date_format)

Реальний сценарій: Асистент з календарем

Ваш AI-асистент отримує запит: "Запланувати зустріч на завтра о 15:00". Для цього йому потрібні три інструменти: get_current_datetime (дізнатися, який сьогодні день), add_duration_to_datetime (обчислити "завтра"), create_calendar_event (створити подію). Claude сам вирішує, які інструменти викликати і в якому порядку.

Правила хорошої функції-інструменту

Описове ім'я: get_current_datetime, а не func1
Описові аргументи: date_format, а не fmt
Валідація входу: перевіряйте аргументи та кидайте зрозумілі помилки
Зрозумілі помилки: Claude побачить текст помилки і зможе спробувати ще раз

4.2 Схеми інструментів (Tool Schemas)

Модуль 4 · Tool Use

Цілі уроку

Зрозуміти структуру JSON Schema для інструментів
Навчитися описувати параметри з типами та описами
Побачити реальний приклад схеми

У попередньому уроці ви написали функцію-інструмент. Але Claude поки не знає, що вона існує. Як пояснити Claude, які інструменти у нього є, які аргументи вони приймають і коли їх використовувати? Через JSON Schema -- формальний "паспорт" кожного інструменту.

Метафора: Каталог інструментів

Уявіть будівельний магазин. Кожен інструмент має бирку: назва ("дриль"), опис ("для свердління отворів у дереві та металі"), характеристики ("потужність: 500-1500 Вт, тип: обов'язковий"). JSON Schema -- це саме така бирка для Claude. Чим детальніший опис -- тим точніше Claude обирає та використовує інструмент.

Структура схеми

Ось як виглядає "паспорт" для функції get_current_datetime з попереднього уроку. Зверніть увагу на опис -- він пояснює Claude не лише ЩО робить функція, а й КОЛИ її використовувати.

from anthropic.types import ToolParam get_datetime_schema = ToolParam( name="get_current_datetime", description="Повертає поточну дату та час у заданому форматі. Використовуй для відповідей на запити про поточний час, дату або день тижня.", input_schema={ "type": "object", "properties": { "date_format": { "type": "string", "description": "Формат дати (strftime). Наприклад: '%Y-%m-%d %H:%M:%S'", "default": "%Y-%m-%d %H:%M:%S" } }, "required": [] } )

Розбір компонентів

Поле	Призначення	Поради
name	Ідентифікатор інструменту	Використовуйте snake_case, описове ім'я
description	3-4 речення: що робить, коли використовувати, що повертає	Чим детальніший опис, тим краще Claude зрозуміє
input_schema	JSON Schema для аргументів	Вказуйте типи, описи та значення за замовчуванням

Лайфхак: генерація схеми через Claude

Візьміть Python-функцію, надішліть її Claude.ai з промптом: "Напиши JSON Schema для tool calling для цієї функції, дотримуючись best practices з документації Anthropic." Claude згенерує коректну схему!

Вправа: Напишіть схему

Створіть JSON Schema для функції add_duration_to_datetime(start_datetime, days, hours, minutes), яка додає тривалість до дати.

add_duration_schema = ToolParam( name="add_duration_to_datetime", description="Додає тривалість (дні, години, хвилини) до заданої дати. Використовуй для обчислення майбутніх дат.", input_schema={ "type": "object", "properties": { "start_datetime": { "type": "string", "description": "Початкова дата у форматі YYYY-MM-DD HH:MM:SS" }, "days": {"type": "integer", "description": "Кількість днів", "default": 0}, "hours": {"type": "integer", "description": "Кількість годин", "default": 0}, "minutes": {"type": "integer", "description": "Кількість хвилин", "default": 0} }, "required": ["start_datetime"] } )

4.3 Обробка повідомлень Tool Use

Модуль 4 · Tool Use

Цілі уроку

Зрозуміти multi-block повідомлення
Навчитися обробляти tool_use та tool_result блоки
Побудувати повний цикл: запит → tool_use → виконання → tool_result → відповідь

Ви описали інструмент і його схему. Тепер -- найцікавіша частина: як саме відбувається "діалог" між Claude і вашим кодом? Це нагадує танець на двох: Claude каже "мені потрібно дізнатися час", ваш код виконує функцію, повертає результат, і Claude формулює фінальну відповідь. Давайте розберемо кожен крок цього танцю.

Multi-block повідомлення

Метафора: Лист з вкладеннями

Звичайна відповідь Claude -- це простий лист з текстом. Відповідь з tool_use -- це лист з вкладеннями: текстова частина ("Зараз перевірю...") + вкладення-запит ("виконай функцію X з аргументами Y"). Ваш код "відкриває вкладення", виконує запит, і надсилає "лист-відповідь" з результатом.

Коли Claude використовує інструменти, його відповідь -- це не просто текст. Вона містить кілька блоків різних типів:

# Відповідь Claude (response.content) містить: [ {"type": "text", "text": "Зараз перевірю час..."}, {"type": "tool_use", "id": "toolu_123", "name": "get_current_datetime", "input": {"date_format": "%H:%M"}} ]

Надсилання tool_result

Ось ключовий момент: ви виконуєте функцію і повертаєте результат Claude. Зверніть увагу -- tool_result додається як user повідомлення, а не assistant. Це інтуїтивно: ваш код "відповідає" Claude.

# Крок 1: Виконати функцію result = get_current_datetime("%H:%M") # "14:32" # Крок 2: Створити tool_result блок tool_result = { "type": "tool_result", "tool_use_id": "toolu_123", # Той самий ID! "content": json.dumps(result), "is_error": False } # Крок 3: Додати як USER повідомлення (не assistant!) messages.append({"role": "user", "content": [tool_result]}) # Крок 4: Надіслати Claude для фінальної відповіді final = client.messages.create( model=MODEL, max_tokens=1024, tools=[get_datetime_schema], # Схеми все ще потрібні! messages=messages )

Критично: tool_use_id

tool_use_id зв'язує запит інструменту з його результатом. Коли Claude робить кілька запитів одночасно, кожен має унікальний ID. Результати МАЮТЬ посилатися на відповідні ID.

Повний потік повідомлень

User: "Котра зараз година?"
Assistant: [text: "Зараз перевірю"] + [tool_use: get_current_datetime]
User: [tool_result: "14:32"]
Assistant: [text: "Зараз 14:32"]

4.4 Багатокрокові розмови з інструментами

Модуль 4 · Tool Use

Цілі уроку

Реалізувати цикл автоматичного виклику інструментів
Обробляти ланцюжки з кількох інструментів
Зрозуміти stop_reason та його роль у циклі

У попередньому уроці ви навчилися обробляти один виклик інструменту. Але в реальному житті все складніше. Уявіть: користувач каже "Запланувати нагадування на день мого народження через 3 місяці". Claude має: 1) дізнатися сьогоднішню дату, 2) додати 3 місяці, 3) створити нагадування. Три інструменти в ланцюжку! Як автоматизувати цей процес, не знаючи наперед, скільки кроків буде?

Проблема: непередбачувана кількість інструментів

Коли користувач питає "Який день буде через 103 дні?", Claude може викликати спочатку get_current_datetime, потім add_duration_to_datetime. Ви не знаєте заздалегідь, скільки інструментів знадобиться.

Метафора: Робот-офіціант

Уявіть робота-офіціанта в ресторані. Клієнт каже: "Хочу замовити піцу з доставкою." Робот: 1) перевіряє меню (tool_use: get_menu), 2) отримує меню (tool_result), 3) підтверджує замовлення (tool_use: create_order), 4) отримує номер замовлення (tool_result), 5) перевіряє час доставки (tool_use: get_delivery_time), 6) отримує час (tool_result), 7) каже клієнту: "Ваша Маргарита буде через 30 хвилин!" (end_turn). Скільки кроків потрібно -- вирішує сам робот.

Рішення: цикл run_conversation

Цей код -- серце будь-якого серйозного додатку з Tool Use. Він автоматично "крутить" цикл: запит → інструмент → результат → знову запит -- доки Claude не вирішить, що роботу завершено.

def run_conversation(messages, tools): while True: response = client.messages.create( model=MODEL, max_tokens=4096, tools=tools, messages=messages ) # Додаємо відповідь assistant до історії messages.append({"role": "assistant", "content": response.content}) # Якщо Claude не хоче інструмент -- кінець if response.stop_reason != "tool_use": break # Обробляємо всі tool_use блоки tool_results = [] for block in response.content: if block.type == "tool_use": result = run_tool(block.name, block.input) tool_results.append({ "type": "tool_result", "tool_use_id": block.id, "content": json.dumps(result), "is_error": False }) # Додаємо результати як user повідомлення messages.append({"role": "user", "content": tool_results}) return response def run_tool(name, input_data): if name == "get_current_datetime": return get_current_datetime(**input_data) elif name == "add_duration_to_datetime": return add_duration(**input_data) elif name == "set_reminder": return set_reminder(**input_data) else: return {"error": f"Unknown tool: {name}"}

Ключовий момент: stop_reason

Поле stop_reason повідомляє, чому Claude зупинився. Якщо це "tool_use" -- Claude хоче викликати інструмент. Будь-яке інше значення означає, що Claude завершив роботу.

Реальний сценарій: Туристичний помічник

Клієнт каже: "Хочу полетіти в Барселону на вихідні." Claude: 1) get_current_datetime -- дізнається, що сьогодні середа, 2) search_flights -- шукає рейси на п'ятницю-неділю, 3) search_hotels -- шукає готелі на ті ж дати, 4) check_weather -- перевіряє погоду, 5) формує повну відповідь з усіма варіантами. П'ять інструментів у ланцюжку -- і цикл run_conversation обробив кожен автоматично.

Перевірка знань: Урок 4.4

1. Коли цикл run_conversation зупиняється?

Після першого інструменту

Коли stop_reason не дорівнює "tool_use"

Після 10 ітерацій

2. Де додаються tool_result блоки?

У user повідомлення

У assistant повідомлення

В окремий system блок

4.5 Просунуті інструменти

Модуль 4 · Tool Use

Цілі уроку

Побудувати batch tool для паралельного виклику
Використовувати tools для витягу структурованих даних
Познайомитися з вбудованими інструментами: Text Edit та Web Search

Ви опанували основи Tool Use. Тепер -- три просунуті техніки, що перетворять інструменти з простих "рук" на потужний арсенал. Перша -- batch tools для паралельного виконання, друга -- перетворення tools на машину витягу структурованих даних, третя -- вбудовані інструменти Anthropic.

Batch Tool: паралельні виклики

Claude зазвичай надсилає tool_use блоки по одному. Batch tool -- це хитрий обхід, що дозволяє згрупувати кілька викликів в один:

batch_schema = ToolParam( name="batch", description="Виконує кілька інструментів одночасно.", input_schema={ "type": "object", "properties": { "invocations": { "type": "array", "items": { "type": "object", "properties": { "tool_name": {"type": "string"}, "arguments": {"type": "string"} } } } }, "required": ["invocations"] } )

Tools для структурованих даних

Пам'ятаєте pre-filling з Модулю 2 для отримання чистого JSON? Є ще елегантніший спосіб. Замість хитрощів з форматом, ви просто описуєте потрібну структуру як tool schema, і Claude заповнює її автоматично. Параметр tool_choice гарантує, що Claude обов'язково викличе інструмент.

extract_schema = ToolParam( name="extract_info", description="Витягає структуровану інформацію з тексту", input_schema={ "type": "object", "properties": { "name": {"type": "string"}, "email": {"type": "string"}, "company": {"type": "string"} }, "required": ["name", "email"] } ) response = client.messages.create( model=MODEL, max_tokens=1024, tools=[extract_schema], tool_choice={"type": "tool", "name": "extract_info"}, messages=[{"role": "user", "content": "Олена Коваль, olena@startup.ua, CTO у TechStartup"}] ) # Дані у response.content[0].input data = response.content[0].input # {"name": "Олена Коваль", "email": "olena@startup.ua", "company": "TechStartup"}

Реальний сценарій: Парсинг візиток

Ваша CRM отримує сотні листів з текстом на кшталт "Олена Коваль, olena@startup.ua, CTO у TechStartup". Замість regex або NLP-парсера, ви використовуєте Claude з tool_choice -- і отримуєте гарантований JSON з полями name, email, company. Точність 98%+, нуль парсерів для підтримки.

Окрім ваших власних інструментів, Anthropic надає вбудовані -- їх не потрібно реалізовувати, достатньо підключити.

Вбудовані інструменти

Web Search Tool

web_search = {"type": "web_search_20250305", "name": "web_search", "max_uses": 5, "allowed_domains": ["docs.python.org"]}

Claude автоматично шукає в інтернеті. Відповідь включає цитати з джерелами.

Text Editor Tool

Вбудована схема для файлових операцій (read, write, replace, undo). Тільки JSON Schema вбудована -- реалізацію потрібно писати самостійно.

5.1 Введення в RAG

Модуль 5 · RAG

Цілі уроку

Зрозуміти, що таке RAG та яку проблему вирішує
Порівняти прямий підхід vs RAG
Побачити архітектуру RAG-пайплайну

Ваша компанія має 500 внутрішніх документів: політики, інструкції, звіти. Працівники витрачають годину на пошук потрібної інформації. Ви хочете побудувати "розумний пошук" на базі Claude. Але є проблема: всі 500 документів -- це мільйони токенів, і вони не вмістяться в один запит. Навіть якби вмістились -- Claude "загубиться" в такому обсязі тексту. RAG вирішує цю проблему елегантно: замість того, щоб запихати все в промпт, він знаходить тільки релевантні фрагменти.

Проблема: великі документи

Метафора: Іспит з відкритою книгою

RAG -- це як іспит з відкритою книгою (open-book exam). Без RAG Claude мусить відповідати "з голови" -- лише на основі того, що він вивчив під час тренування. З RAG -- він може "відкрити підручник" і знайти точну відповідь. Але ключова різниця: замість гортання всіх 500 сторінок, "розумний бібліотекар" (vector search) одразу відкриває правильну сторінку.

Два підходи

	Прямий підхід	RAG
Як	Весь документ у промпт	Тільки релевантні шматки
Ліміти	Жорсткий ліміт токенів	Масштабується на будь-який розмір
Вартість	Дорого (багато токенів)	Дешево (мало токенів)
Якість	Знижується з довжиною	Фокус на релевантному
Складність	Простий	Потребує налаштування

Тепер, коли ви розумієте ЧОМУ потрібен RAG, давайте подивимося ЯК він працює -- від завантаження документів до фінальної відповіді.

Архітектура RAG

Реальний сценарій: Корпоративна база знань

IT-компанія з 500 працівниками має 2000 внутрішніх документів: процедури, технічні гайди, FAQ. Новий працівник питає: "Як запросити доступ до staging-серверу?" Без RAG -- годинний пошук по Confluence. З RAG -- Claude знаходить потрібний фрагмент за 2 секунди і дає чітку інструкцію з посиланням на джерело. Час onboarding скорочується вдвічі.

Весь пайплайн складається з двох фаз: індексація (один раз) та пошук + генерація (для кожного запиту).

Документ → [Розбиття на чанки] → [Ембедінги] → [Векторна БД] | Запит → [Ембедінг запиту] → [Пошук схожих] → [Релевантні чанки] | [Промпт + чанки] → Claude → Відповідь

5.2 Чанкінг та ембедінги

Модуль 5 · RAG

Цілі уроку

Опанувати три стратегії чанкінгу
Зрозуміти, як працюють text embeddings
Навчитися використовувати Voyage AI для ембедінгів

У попередньому уроці ви побачили архітектуру RAG. Два ключових компоненти -- чанкінг (розрізання документів) та ембедінги (перетворення тексту в числа) -- визначають якість всього пайплайну. Подумайте про це як про підготовку інгредієнтів перед готуванням: правильно нарізані овочі (чанки) та правильні спеції (ембедінги) -- основа смачної страви.

Три стратегії чанкінгу

Метафора: Різання піци

Чанкінг -- це як різання піци. За розміром -- рівні шматки лінійкою: просто, але можна розрізати начинку навпіл. За структурою -- по лініях між начинками: ідеально, якщо піца з чіткими секціями. За семантикою -- AI визначає, де природні межі: найточніше, але потребує "розумного ножа".

1. За розміром (Size-based)

Ділимо текст на рівні шматки по N символів. Просто, але може розрізати слова. Рішення: overlap -- перекриття між чанками.

2. За структурою (Structure-based)

Ділимо по заголовках, абзацах, секціях. Ідеально для Markdown/HTML, але потребує гарантованої структури документа.

3. За семантикою (Semantic-based)

Використовуємо NLP для групування пов'язаних речень. Найточніший, але найскладніший метод.

Тепер, коли документи розрізані на чанки, потрібно навчити комп'ютер "розуміти" їх зміст. Ось тут на сцену виходять ембедінги.

Text Embeddings

Ембедінг -- це як GPS-координати для тексту. Кожен текст отримує "адресу" у математичному просторі -- список чисел (від -1 до +1). Тексти про схожі теми мають близькі "адреси", навіть якщо використовують різні слова. "Собака грає у парку" і "Пес біжить по газону" матимуть схожі ембедінги, хоча не мають жодного спільного слова.

# Anthropic рекомендує Voyage AI для ембедінгів from voyageai import Client as VoyageClient voyage = VoyageClient() # Один текст embedding = voyage.embed(["Привіт, як справи?"], model="voyage-3") # Список чанків chunks = ["Розділ 1: Вступ...", "Розділ 2: Методологія...", "Розділ 3: Результати..."] embeddings = voyage.embed(chunks, model="voyage-3")

Cosine Similarity

Міра схожості між двома ембедінгами. Значення від -1 до 1, де 1 = ідентичні. Cosine distance = 1 - similarity (ближче до 0 = більш схожі).

5.3 Повний RAG-пайплайн

Модуль 5 · RAG

Цілі уроку

Реалізувати повний RAG-пайплайн крок за кроком
Зрозуміти BM25 лексичний пошук як доповнення
Порівняти семантичний та лексичний підходи

Ви вже знаєте окремі компоненти: чанкінг та ембедінги. Тепер час зібрати їх у працюючий механізм -- від завантаження документа до фінальної відповіді Claude.

Метафора: Збирання LEGO

У попередніх уроках ви вивчили окремі деталі LEGO: "цеглинки" чанкінгу та "колеса" ембедінгів. Тепер час зібрати з них працюючу машину. Кожен крок RAG-пайплайну -- це одна інструкція в інструкції зі збирання. Пропустити крок -- і машина не поїде.

7 кроків RAG

Цей код -- повний робочий пайплайн. Кожен крок прокоментований. Скопіюйте, підставте свої дані -- і ви отримаєте працюючий RAG за 15 хвилин.

# Крок 1: Чанкінг chunks = chunk_by_section(document_text) # Крок 2: Ембедінги embeddings = [generate_embedding(chunk) for chunk in chunks] # Крок 3-4: Збереження у векторну БД vector_store = VectorIndex() for chunk, emb in zip(chunks, embeddings): vector_store.add_vector(emb, {"content": chunk}) # Крок 5: Ембедінг запиту query = "Що зробив відділ розробки минулого року?" query_embedding = generate_embedding(query) # Крок 6: Пошук схожих (top-2) results = vector_store.search(query_embedding, k=2) # Крок 7: Промпт з контекстом context = "\n\n".join([r["content"] for r in results]) response = client.messages.create( model=MODEL, max_tokens=2048, messages=[{"role": "user", "content": f"""На основі цього контексту: <context>{context}</context> Дай відповідь: {query}"""}] )

Але семантичний пошук не ідеальний. Що якщо користувач шукає конкретний термін -- "RFC-7231" або "артикул XJ-5500"? Ембедінги можуть промахнутись. Ось тут на допомогу приходить старий добрий лексичний пошук.

BM25: лексичний пошук

Навіщо BM25?

Семантичний пошук може пропустити точні збіги термінів. BM25 (Best Match 25) ранжує документи за частотою входження конкретних слів. Рідкісні терміни отримують вищий вага, загальні -- нижчий.

	Семантичний пошук	BM25
Як працює	Порівнює "значення" ембедінгів	Рахує частоту слів
Добре	Синоніми, парафрази	Точні терміни, назви
Погано	Може пропустити точні збіги	Не розуміє контекст

5.4 Просунутий RAG

Модуль 5 · RAG

Цілі уроку

Побудувати multi-index pipeline (Vector + BM25)
Реалізувати reranking через LLM
Зрозуміти contextual retrieval

Ваш базовий RAG працює, але точність -- 75%. Клієнт хоче 90%+. Три просунуті техніки допоможуть досягти цього: об'єднання семантичного та лексичного пошуку (RRF), розумне переранжування результатів (reranking), та додавання контексту до чанків (contextual retrieval). Кожна техніка підвищує точність на 5-10%.

Reciprocal Rank Fusion (RRF)

Метафора: Два детективи

Уявіть двох детективів, що шукають улику. Один (Vector) шукає за "духом" питання -- розуміє контекст і синоніми. Інший (BM25) -- за конкретними словами, як слідчий з лупою, що шукає точний відбиток пальця. RRF -- це їхній спільний звіт, де знахідки обох ранжуються за важливістю.

RRF об'єднує результати з різних індексів в один рейтинг. Формула проста:

RRF_score(doc) = sum( 1 / (rank + 1) ) для кожного індексу # Приклад: # Vector: [doc2, doc7, doc6] → doc2: 1/1, doc7: 1/2, doc6: 1/3 # BM25: [doc6, doc2, doc7] → doc6: 1/1, doc2: 1/2, doc7: 1/3 # RRF: doc2 = 1/1 + 1/2 = 1.5 # doc6 = 1/3 + 1/1 = 1.33 # doc7 = 1/2 + 1/3 = 0.83 # Результат: [doc2, doc6, doc7]

Але навіть RRF може залишити не найрелевантніший документ на першому місці. Ось тут на сцену виходить "суддя" -- LLM-reranker.

Reranking через LLM

Після пошуку відправте знайдені документи Claude для переранжування за релевантністю. Це як фінальний раунд відбору -- з 10 кандидатів обрати ТОП-3 найрелевантніших.

rerank_prompt = f"""Ранжуй документи за релевантністю до запиту. Запит: {query} Документи: {documents_with_ids} Поверни JSON з відсортованими ID у порядку зменшення релевантності."""

Contextual Retrieval

Додавання контексту до чанків

Проблема: чанки втрачають контекст з оригіналу. Рішення: перед ембедінгом, попросіть Claude додати контекст до кожного чанка.

def add_context(chunk, full_document): context = client.messages.create( model=MODEL, max_tokens=200, messages=[{"role": "user", "content": f""" Ось повний документ: <doc>{full_document}</doc> Ось фрагмент: <chunk>{chunk}</chunk> Напиши 1-2 речення контексту для цього фрагменту."""}] ).content[0].text return f"{context}\n\n{chunk}" # Контекстуалізований чанк

Перевірка знань: Урок 5.4

1. Що робить Reciprocal Rank Fusion?

Шукає документи в одному індексі

Об'єднує результати з кількох індексів

Видаляє дублікати з результатів

2. Навіщо потрібен contextual retrieval?

Для прискорення пошуку

Для зменшення кількості чанків

Щоб чанки зберігали зв'язок з оригінальним документом

6.1 Extended Thinking

Модуль 6 · Можливості Claude

Цілі уроку

Зрозуміти, що таке Extended Thinking та коли використовувати
Реалізувати thinking з budget_tokens
Зрозуміти структуру відповіді з thinking блоками

Ви попросили Claude розв'язати складну задачу з оптимізації логістики -- і він помилився. Ви переписали промпт тричі -- результат покращився, але все ще неточний. Проблема не в промпті, а в тому, що Claude "відповідає з ходу", не маючи часу подумати. Extended Thinking дає Claude "чернетку" -- простір для поетапних міркувань перед фінальною відповіддю.

Що таке Extended Thinking?

Метафора: Чернетка на іспиті

Уявіть студента на складному іспиті. Без Extended Thinking він відразу починає писати відповідь -- як на швидкісному тесті. З Extended Thinking він отримує аркуш для чернетки: спочатку записує формули, малює схеми, перевіряє розрахунки, і тільки потім переносить чисту відповідь. Ви можете заглянути в чернетку (thinking block), але оцінюється лише фінальний аркуш (text block).

Реалізація

Увімкнути Extended Thinking -- це один додатковий параметр. Але він може перетворити помилкову відповідь на ідеальну для складних задач.

response = client.messages.create( model=MODEL, max_tokens=16000, thinking={ "type": "enabled", "budget_tokens": 10000 # Мінімум 1024 }, messages=[{"role": "user", "content": "Розв'яжи цю задачу з оптимізації..."}] ) # Відповідь містить два блоки: for block in response.content: if block.type == "thinking": print("Думки:", block.thinking) # Процес міркування elif block.type == "text": print("Відповідь:", block.text) # Фінальна відповідь

Обмеження

budget_tokens -- мінімум 1024 токенів для thinking
max_tokens має бути БІЛЬШЕ за budget_tokens (наприклад, budget 10000 -- max_tokens 16000)
Thinking токени тарифікуються -- це додаткова вартість
Використовуйте тільки коли промпт-оптимізація не дає потрібної точності

Коли використовувати?

Складні математичні задачі
Багатокрокове планування
Аналіз коду з пошуком вразливостей
Задачі, де звичайний промпт дає недостатню точність

Реальний сценарій: Аудит безпеки коду

Компанія просить Claude проаналізувати 500-рядковий модуль авторизації на вразливості. Без Extended Thinking Claude знаходить 3 з 7 вразливостей. З budget_tokens=10000 -- знаходить 6 з 7: thinking block показує, як Claude поетапно перевіряє SQL injection, XSS, CSRF, брутфорс, session fixation. Додаткова вартість thinking-токенів -- мінімальна порівняно з вартістю пропущеної вразливості.

6.2 Робота з зображеннями та PDF

Модуль 6 · Можливості Claude

Цілі уроку

Надсилати зображення через base64 або URL
Обробляти PDF-документи
Засвоїти правила ефективного промптингу для візуального контенту

Claude не обмежений текстом -- він "бачить" зображення та "читає" PDF-документи. Уявіть: користувач завантажує фото чека, і ваш додаток автоматично витягує суму, дату та назву магазину. Або клієнт надсилає 50-сторінковий контракт у PDF, і Claude створює короткий огляд ключових умов за секунди. Давайте навчимося це робити.

Метафора: Всебачне око

Додавання зображень та PDF до запиту -- це як дати Claude "очі" на додачу до "вух" (тексту). Тепер він може аналізувати графіки, читати сканові документи, оцінювати дизайн-макети та навіть описувати фотографії. Один запит може містити і текст, і зображення -- як повідомлення в месенджері з вкладенням.

Зображення в API

Зображення можна передавати двома способами: як base64-рядок (для локальних файлів) або як URL (для зображень з інтернету). Ось як працює base64-підхід.

import base64 # Спосіб 1: Base64 with open("photo.png", "rb") as f: image_data = base64.standard_b64encode(f.read()).decode("utf-8") response = client.messages.create( model=MODEL, max_tokens=1024, messages=[{ "role": "user", "content": [ {"type": "image", "source": {"type": "base64", "media_type": "image/png", "data": image_data}}, {"type": "text", "text": "Опиши, що зображено на фото. Зверни увагу на кольори та композицію."} ] }] )

PDF-документи

PDF обробляються аналогічно -- але замість image використовується document. Claude розуміє структуру сторінок і може посилатися на конкретні місця в документі.

with open("report.pdf", "rb") as f: pdf_data = base64.standard_b64encode(f.read()).decode("utf-8") response = client.messages.create( model=MODEL, max_tokens=4096, messages=[{ "role": "user", "content": [ {"type": "document", "source": {"type": "base64", "media_type": "application/pdf", "data": pdf_data}}, {"type": "text", "text": "Створи резюме цього звіту з ключовими висновками."} ] }] )

Обмеження

Максимум 100 зображень на запит
Зображення споживають токени (розрахунок на основі пікселів)
Якість аналізу залежить від якості промпта, а не тільки від якості зображення

Реальний сценарій: Обробка рахунків-фактур

Бухгалтерія отримує 200 сканованих рахунків на день. Раніше оператор вручну вносив дані: постачальник, сума, дата, номер рахунку. Тепер: фото рахунку завантажується через API, Claude витягує всі поля в JSON. Час обробки одного рахунку: з 3 хвилин до 5 секунд. Точність: 97% (людина перевіряє тільки помилки).

Техніки промптингу для зображень

Давайте покрокові інструкції: "Спочатку опиши об'єкти, потім їх розташування, потім кольори"
Використовуйте few-shot з парами зображення+текст
Вказуйте конкретні критерії аналізу

6.3 Цитування (Citations)

Модуль 6 · Можливості Claude

Цілі уроку

Увімкнути citations для прозорості джерел
Зрозуміти типи цитувань (page, char)
Інтегрувати цитати в UI

Ваш юридичний асистент каже: "Згідно з договором, штрафні санкції складають 5%." Клієнт питає: "А де саме це написано?" Без цитувань -- нікуди показати. З цитуваннями -- можна вказати: "сторінка 12, параграф 3.2". Це перетворює AI з "чорної скриньки" на прозорого помічника, якому можна довіряти.

Навіщо цитування?

Метафора: Виноски у підручнику

Citations -- це як виноски в науковому підручнику. Кожне твердження посилається на конкретне джерело. Читач (користувач) може будь-коли перевірити джерело і переконатися, що інформація точна. Без виносок -- це просто "хтось так сказав". З виносками -- це верифікована інформація.

Citations дозволяють користувачу перевірити, звідки Claude взяв інформацію. Замість "Claude сказав X" ви отримуєте "Claude сказав X, посилаючись на сторінку 5 документа Y".

Реалізація

response = client.messages.create( model=MODEL, max_tokens=4096, citations={"enabled": True}, # Увімкнути цитати! messages=[{ "role": "user", "content": [ {"type": "document", "source": {"type": "base64", "media_type": "application/pdf", "data": pdf_data}, "title": "Фінансовий звіт 2024"}, {"type": "text", "text": "Яка була виручка компанії?"} ] }] ) # Відповідь містить text блоки з масивами citations for block in response.content: if hasattr(block, 'citations') and block.citations: for cite in block.citations: print(f"Джерело: {cite.document_title}, стор. {cite.start_page}")

Типи цитувань

citation_page_location -- для PDF: індекс документа, назва, номери сторінок, цитований текст
citation_char_location -- для тексту: позиція символу в текстовому блоці

6.4 Prompt Caching

Модуль 6 · Можливості Claude

Цілі уроку

Зрозуміти механізм кешування промптів
Навчитися розміщувати cache breakpoints
Оптимізувати вартість через кешування

У вашому чат-боті кожен запит надсилає один і той самий system prompt на 2000 токенів + ті самі 10 tool schemas на 3000 токенів + динамічне повідомлення користувача на 50 токенів. 5000 токенів -- це 98% промпту -- ідентичні кожного разу. Чому б не "запам'ятати" їх? Prompt Caching саме це і робить -- і може зекономити до 90% вартості.

Як працює кешування?

Метафора: Конспект лекції

Без кешування Claude перечитує весь підручник для кожного питання -- як студент, що щоразу починає читати з першої сторінки. З кешуванням він робить конспект після першого читання і потім використовує його. Конспект зберігається 1 годину. Якщо ви змінили хоч одне слово в підручнику -- конспект стає недійсним і доведеться перечитувати заново.

Зрозумівши принцип, давайте подивимось, як розставити "мітки кешування" в коді.

Cache Breakpoints

Cache breakpoint -- це позначка cache_control, яку ви ставите на елементі промпту. Все ДО цієї позначки буде закешовано. Ось два найпоширеніших сценарії.

# Кешування system prompt response = client.messages.create( model=MODEL, max_tokens=1024, system=[{ "type": "text", "text": "Ти -- експерт з фінансового аналізу...", "cache_control": {"type": "ephemeral"} # Кешувати! }], messages=[{"role": "user", "content": "Проаналізуй звіт"}] ) # Кешування tool schemas tools_with_cache = list(tools) tools_with_cache[-1] = {**tools[-1], "cache_control": {"type": "ephemeral"}}

Правила кешування

Правило	Деталі
Тривалість кешу	Максимум 1 година
Мінімальний розмір	1024 токенів для кешування
Максимум breakpoints	4 на запит
Порядок кешування	tools → system → messages
Інвалідація	Будь-яка зміна ДО breakpoint інвалідує весь кеш

Токени у відповіді

cache_creation_input_tokens -- токени, записані в кеш (перший раз)
cache_read_input_tokens -- токени, прочитані з кешу (наступні рази)

7.1 Code Execution

Модуль 7 · Code Execution & Files

Цілі уроку

Зрозуміти серверне виконання коду в Docker-контейнерах
Побачити use cases для code execution
Навчитися інтегрувати з Files API

Клієнт завантажує CSV з 10 000 рядків даних продажів і питає: "Покажи тренд за останні 6 місяців з графіком." Claude може проаналізувати текст, але побудувати графік з даних -- це вже інша справа. Code Execution дозволяє Claude не просто говорити про дані, а написати Python-код, виконати його і повернути результат -- графік, таблицю, обчислення.

Що таке Code Execution?

Метафора: Пісочниця

Code Execution -- це ізольована пісочниця (Docker-контейнер), де Claude може писати та запускати Python-код. Контейнер не має доступу до мережі -- вхідні та вихідні дані передаються через Files API.

Як працює

Найкраще в Code Execution -- це те, що вам НЕ потрібно реалізовувати виконання коду самостійно. Claude сам пише код, сам запускає його, сам аналізує результат. Ваш код -- мінімальний.

# Code Execution -- вбудований tool, не потребує реалізації # Claude автоматично пише код, запускає, аналізує результати response = client.messages.create( model=MODEL, max_tokens=4096, tools=[{"type": "code_execution_20250522", "name": "code_execution"}], messages=[{ "role": "user", "content": "Проаналізуй цей CSV та побудуй графік продажів по місяцях" }] ) # Claude напише pandas + matplotlib код, виконає його, поверне результат

Use Cases

Аналіз даних з CSV/Excel
Генерація графіків та звітів
Математичні обчислення з перевіркою
Автоматизована обробка файлів

7.2 Files API

Модуль 7 · Code Execution & Files

Цілі уроку

Завантажувати файли через Files API
Посилатися на файли за ID замість base64
Комбінувати Files API з Code Execution

До цього моменту ви передавали файли через base64 -- кодували їх прямо в запит. Це працює для одного-двох файлів, але уявіть: ви аналізуєте один і той самий CSV у 10 різних запитах. Кожного разу кодуєте 5 МБ файлу в base64? Files API дозволяє завантажити файл один раз і далі посилатися на нього за ID -- як прикріплення в Google Drive.

Метафора: Хмарне сховище

Files API -- це як Google Drive для Claude. Замість того, щоб кожного разу вкладати файл в email (base64 в запиті), ви завантажуєте його в хмару і даєте посилання (file ID). Файл зберігається на сервері Anthropic, і Claude може звертатися до нього будь-коли.

Workflow Files API

Два кроки: завантажити файл, потім використати його ID у запиті. Простіше не буває.

# Крок 1: Завантажити файл file = client.files.create( file=open("data.csv", "rb"), purpose="user_upload" ) file_id = file.id # "file-abc123" # Крок 2: Використати файл у запиті з Code Execution response = client.messages.create( model=MODEL, max_tokens=4096, tools=[{"type": "code_execution_20250522", "name": "code_execution"}], messages=[{ "role": "user", "content": [ {"type": "container_upload", "file_id": file_id}, {"type": "text", "text": "Проаналізуй дані та створи візуалізацію"} ] }] )

Переваги Files API

Завантаження один раз, використання багато разів за ID
Не потрібно кожен раз кодувати в base64
Claude може генерувати файли (графіки, звіти) і повертати їх

Перевірка знань: Модулі 6-7

1. Яке мінімальне значення budget_tokens для Extended Thinking?

256

1024

4096

2. Скільки зберігається кеш Prompt Caching?

1 годину

24 години

Назавжди

3. Де виконується код у Code Execution?

На вашому сервері

У браузері

В ізольованому Docker-контейнері

8.1 Введення в MCP

Модуль 8 · MCP

Цілі уроку

Зрозуміти, що таке Model Context Protocol
Побачити архітектуру: Client ↔ Server
Зрозуміти різницю між MCP та звичайним Tool Use

Ви побудували інтеграцію Claude з вашою базою даних. Потім з GitHub. Потім з Slack. Кожна інтеграція -- це окрема робота: написати tool schemas, реалізувати функції, обробити помилки. А що якщо б усі ці інтеграції вже були готові, і вам достатньо "підключити" їх, як USB-пристрій до комп'ютера? Саме цю проблему вирішує MCP -- Model Context Protocol.

Що таке MCP?

Метафора: USB-C для штучного інтелекту

Пам'ятаєте часи, коли кожен телефон мав свій зарядний роз'єм? Nokia, Samsung, Apple -- всі різні. USB-C вирішив цю проблему одним стандартом. MCP -- це "USB-C для AI". Один протокол для підключення будь-якого сервісу: GitHub, Slack, бази даних, хмарні сховища. Хтось вже написав усі інструменти за вас -- ви просто підключаєте готовий MCP-сервер, як флешку у порт.

Тепер давайте подивимось, як це працює "під капотом".

Архітектура

Ваш додаток (MCP Client) | ↕ (stdio / HTTP / WebSocket) | MCP Server ├── Tools (інструменти для дій) ├── Resources (дані для читання) └── Prompts (шаблони промптів)

MCP vs Tool Use

	Tool Use	MCP
Хто пише schemas?	Ви	Автор MCP-сервера
Хто пише функції?	Ви	Автор MCP-сервера
Масштабованість	Кожна інтеграція -- окрема робота	Підключив сервер -- готово

Хто створює MCP-сервери?

Будь-хто! Часто самі сервіс-провайдери (AWS, Stripe). Також є open-source спільнота. І ви можете написати свій -- для внутрішніх систем компанії.

Реальний сценарій: Стартап з 5 інтеграціями

Стартап будує AI-асистента, що має працювати з GitHub (коміти), Slack (повідомлення), Jira (тікети), Confluence (документація) і PostgreSQL (бізнес-дані). Без MCP: 5 окремих інтеграцій, 5 наборів tool schemas, 5 обробників помилок. З MCP: 5 готових серверів підключаються за 5 хвилин кожен. Час інтеграції: з 2 тижнів до 1 дня.

8.2 Створення MCP сервера

Модуль 8 · MCP

Цілі уроку

Створити MCP-сервер на Python з декораторами
Визначити інструменти через @mcp.tool
Тестувати через MCP Inspector

У попередньому уроці ви дізнались, що MCP-сервери вже існують для GitHub, Slack, AWS. Але що робити, якщо у вашої компанії є власна внутрішня система -- CRM, ERP, база знань? Для них готових серверів немає. Час написати свій! І це простіше, ніж здається -- завдяки декораторам Python.

Метафора: Побудова розетки

Створення MCP-сервера -- це як встановлення електричної розетки у стіну. Ви визначаєте "гнізда" (інструменти), до яких будь-який "пристрій" (Claude через MCP-клієнт) може під'єднатися. SDK автоматично генерує JSON Schema з типів Python -- вам не потрібно писати схеми вручну!

Визначення інструментів через декоратори

Кожна функція з декоратором @mcp.tool автоматично стає інструментом, доступним через MCP. Зверніть увагу на Field(description=...) -- ці описи Claude побачить і використає для правильного виклику.

from mcp.server import Server from pydantic import Field mcp = Server("document-server") @mcp.tool(name="read_doc", description="Читає вміст документа за ID") async def read_doc(doc_id: str = Field(description="ID документа")): if doc_id not in docs: raise ValueError(f"Документ {doc_id} не знайдено") return docs[doc_id] @mcp.tool(name="edit_document", description="Редагує документ: замінює текст") async def edit_document( doc_id: str = Field(description="ID документа"), old_string: str = Field(description="Текст для заміни"), new_string: str = Field(description="Новий текст") ): if doc_id not in docs: raise ValueError(f"Документ {doc_id} не знайдено") docs[doc_id] = docs[doc_id].replace(old_string, new_string) return f"Оновлено: {doc_id}"

Перевага: автоматичні JSON Schema

SDK автоматично генерує JSON Schema з типів Python-функції та декораторів Field(). Вам не потрібно писати схеми вручну!

MCP Inspector

# Запуск дебагера mcp dev server.py # Відкрийте URL у браузері -- інтерактивне тестування інструментів

8.3 Реалізація MCP клієнта

Модуль 8 · MCP

Цілі уроку

Реалізувати MCP-клієнт для підключення до сервера
Отримувати список інструментів та викликати їх
Інтегрувати з Claude через tool use

Ви побудували MCP-сервер з інструментами. Тепер потрібна "інша сторона" -- клієнт, який під'єднається до сервера, дізнається про доступні інструменти і передасть їх Claude. Це як побудувати "міст" між Claude і вашим MCP-сервером.

Метафора: Перекладач-посередник

MCP-клієнт -- це як перекладач між Claude і MCP-сервером. Claude "говорить" tool_use блоками, MCP-сервер "говорить" своїм протоколом. Клієнт перекладає в обидва боки: бере список інструментів від сервера, передає Claude, а коли Claude хоче щось виконати -- перекладає запит назад серверу.

MCP Client клас

Клієнт -- мінімалістичний. Три методи: підключитись, дізнатись про інструменти, викликати інструмент. Вся складність -- на стороні SDK.

from mcp import ClientSession class MCPClient: def __init__(self): self.session = None async def connect(self, server_command): # Підключення до MCP-сервера через stdio self.session = await ClientSession.connect(server_command) async def list_tools(self): result = await self.session.list_tools() return result.tools async def call_tool(self, tool_name, tool_input): result = await self.session.call_tool(tool_name, tool_input) return result async def close(self): await self.session.close()

Інтеграція з Claude

Ось де все з'єднується воєдино. Три кроки -- і Claude використовує інструменти з вашого MCP-сервера, навіть не знаючи, що вони "живуть" в іншому процесі.

# 1. Отримати інструменти від MCP-сервера tools = await mcp_client.list_tools() # 2. Відправити Claude запит з інструментами response = client.messages.create( model=MODEL, max_tokens=4096, tools=tools, # Інструменти від MCP! messages=[{"role": "user", "content": "Прочитай документ report-2024"}] ) # 3. Коли Claude хоче tool_use -- викликаємо через MCP for block in response.content: if block.type == "tool_use": result = await mcp_client.call_tool(block.name, block.input) # Надсилаємо результат назад Claude

8.4 Ресурси та промпти в MCP

Модуль 8 · MCP

Цілі уроку

Визначати та читати MCP Resources
Створювати MCP Prompts як шаблони
Зрозуміти повну екосистему: Tools + Resources + Prompts

Метафора: Ресторан

MCP-сервер -- це ресторан. Tools -- це кухня: місце, де відбуваються дії (готуються страви, обробляються замовлення). Resources -- це меню: дані для перегляду, які клієнт запитує проактивно ("Покажіть, що є"). Prompts -- це рекомендації шефа: перевірені "рецепти" промптів від автора сервера. Разом -- повний досвід.

MCP -- це не тільки інструменти (tools). Протокол надає ще два потужних примітиви: Resources (дані) та Prompts (шаблони). Якщо tools -- це "руки" Claude, то resources -- це "бібліотека", а prompts -- "рецепти". Разом вони створюють повну екосистему для будь-якої інтеграції.

Resources: проактивні дані

Resources -- це дані, які клієнт може запросити за URI-адресою. Подумайте про них як про "сторінки довідника" -- вони доступні для читання у будь-який момент.

@mcp.resource("docs://documents", mime_type="application/json") async def list_documents(): return json.dumps(list(docs.keys())) @mcp.resource("docs://documents/{doc_id}", mime_type="text/plain") async def get_document(doc_id: str): return docs.get(doc_id, "Документ не знайдено")

Resources vs Tools

Resources -- проактивні дані: клієнт запитує ресурс (наприклад, при @ mention). Tools -- реактивні дії: Claude вирішує, коли їх викликати. Ресурси для читання, інструменти для дій.

Останній примітив -- Prompts. Автор MCP-сервера може "вкласти" перевірені промпти, як шаблони документів в офісі.

Prompts: шаблони від експерта

@mcp.prompt(name="format_doc", description="Форматує документ у Markdown") async def format_document(doc_id: str): return [ { "role": "user", "content": f"Прочитай документ {doc_id}, переформатуй його у красивий Markdown і збережи зміни." } ] # Клієнт: messages = await mcp_client.get_prompt("format_doc", {"doc_id": "report-2024"})

Повна картина MCP

Tools: дії, що їх Claude може виконати (CRUD, API-виклики)
Resources: дані, доступні за URI (документи, конфігурації)
Prompts: перевірені шаблони промптів від автора сервера

Перевірка знань: Модуль 8

1. Хто зазвичай створює MCP-сервери?

Тільки Anthropic

Тільки кінцеві розробники

Будь-хто: провайдери сервісів, open-source спільнота, внутрішні команди

2. Чим Resources відрізняються від Tools?

Resources -- для читання даних, Tools -- для виконання дій

Resources швидші за Tools

Нічим, це синоніми

9.1 Claude Code

Модуль 9 · Anthropic Apps

Цілі уроку

Зрозуміти Claude Code як приклад агентної архітектури
Побачити ефективні стратегії промптингу
Навчитися розширювати через MCP-сервери

Все, що ви вивчили у цьому курсі -- API, Tool Use, MCP -- зібрано в одному продукті: Claude Code. Це не абстрактна теорія, а реальний інструмент, яким розробники по всьому світу пишуть код, рефакторять проєкти і виправляють баги. Він показує, як виглядає агентна архітектура "в бою".

Claude Code = MCP Client + Agent

Метафора: Досвідчений розробник з терміналом

Уявіть досвідченого розробника, який сидить за терміналом. Він може читати файли (Read), редагувати код (Edit), запускати команди (Bash), шукати по кодовій базі (Grep). Claude Code -- це саме такий "розробник": Claude з набором інструментів для роботи з файловою системою. А через MCP-сервери можна додати йому ще інструменти -- як плагіни в IDE.

Claude Code -- це термінальний асистент, що поєднує інструменти (Read, Edit, Bash, Grep) з вбудованим MCP-клієнтом. Він демонструє, як будувати агентні системи на практиці.

Ефективні стратегії

Метод 1: Три кроки

Покажіть Claude релевантні файли, попросіть проаналізувати
Опишіть фічу, попросіть спланувати рішення (без коду)
Попросіть реалізувати план

Метод 2: TDD

Надайте контекст
Попросіть Claude запропонувати тести
Оберіть та реалізуйте тести
Попросіть Claude написати код, поки тести не пройдуть

Розширення через MCP

# Додати MCP-сервер до Claude Code: claude mcp add doc-reader -- uv run main.py # Тепер Claude Code може використовувати інструменти # з вашого MCP-сервера (наприклад, конвертація PDF в текст)

9.2 Паралельна робота Claude Code

Модуль 9 · Anthropic Apps

Цілі уроку

Паралелізувати Claude через Git worktrees
Зрозуміти автоматизований дебагінг

У вас дедлайн: три фічі за один день. Один інстанс Claude Code працює над авторизацією, другий -- над пошуком, третій -- над дашбордом. Все одночасно. Але як уникнути конфліктів, коли три "розробники" редагують один і той самий проєкт?

Git Worktrees для паралелізації

Метафора: Окремі робочі столи

Git worktrees -- це як три окремих робочих столи для трьох співробітників. Кожен працює зі своєю копією проєкту у своїй гілці. Жодних конфліктів під час роботи -- мерж відбувається лише коли всі закінчили.

Кілька інстансів Claude, що працюють над одними файлами = конфлікти. Рішення: Git worktrees -- ізольовані копії проєкту з окремими гілками.

# Створити worktree для задачі git worktree add ../feature-auth feature/auth # Запустити Claude в ізольованій копії cd ../feature-auth && claude # Після завершення -- мержити назад git merge feature/auth

Але паралельна робота -- це не тільки про швидкість розробки. Це ще й про автоматизацію рутини.

Автоматизований дебагінг

Реальний сценарій: GitHub Actions + CloudWatch + Claude

GitHub Action щодня перевіряє CloudWatch логи
Claude аналізує помилки, дедуплікує
Claude генерує фікси та створює PR

Ловить помилки, що існують тільки в production (конфігурація, API ключі, інша інфраструктура).

9.3 Computer Use

Модуль 9 · Anthropic Apps

Цілі уроку

Зрозуміти, як Claude взаємодіє з комп'ютером
Побачити архітектуру: Tool Use + Docker
Оцінити use cases для QA та автоматизації

Що якщо Claude міг би не тільки писати код і аналізувати тексти, а й користуватися комп'ютером як людина -- клікати по кнопках, заповнювати форми, перевіряти інтерфейси? Саме це робить Computer Use. І за лаштунками -- все той самий Tool Use, який ви вже знаєте.

Як працює Computer Use?

Метафора: Віддалений робочий стіл

Computer Use -- це як TeamViewer для AI. Claude "бачить" екран через скріншоти і "діє" через програмні натискання клавіш і кліки мишею. Все це відбувається в ізольованому Docker-контейнері.

Під капотом Computer Use -- це серія tool_use запитів. Claude "бачить" через скріншоти і "діє" через кліки та натискання клавіш. Ось як виглядає типовий потік.

# Computer Use = спеціальний tool schema # Claude надсилає tool_use запити: screenshot, click, type, move # Ваш Docker контейнер виконує дії та повертає результат # Потік: # 1. Claude: {"action": "screenshot"} # 2. Docker: робить скріншот, повертає зображення # 3. Claude: аналізує, {"action": "click", "x": 150, "y": 300} # 4. Docker: клікає на координатах # 5. Claude: {"action": "screenshot"} -- перевіряє результат

Реальний сценарій: Автоматизоване QA

Ваш QA-відділ тестує веб-додаток перед релізом. Замість мануальних тестів, Claude з Computer Use: 1) відкриває браузер, 2) заповнює форму реєстрації різними даними, 3) перевіряє, чи з'являються правильні повідомлення про помилки, 4) робить скріншот кожного кроку, 5) генерує звіт з знайденими багами. Нічних тестувань, нічних QA-інженерів.

Use Cases

Автоматизоване QA-тестування веб-додатків
Тестування UI в різних сценаріях
Автоматизація повторюваних задач в GUI
Виявлення багів через систематичне тестування

9.4 Огляд Anthropic Apps

Модуль 9 · Anthropic Apps

Цілі уроку

Побачити повну екосистему Anthropic
Зрозуміти, як Apps демонструють агентні концепції

Ви вивчили API, Tool Use, MCP, Claude Code, Computer Use. Тепер давайте подивимось на всю екосистему Anthropic з висоти пташиного польоту -- і зрозуміємо, як ці елементи складаються у цілісну картину. Кожен продукт Anthropic -- це не просто утиліта, а демонстрація агентних патернів, які ви можете використати у своїх проєктах.

Екосистема Anthropic

Метафора: Оркестр

Екосистема Anthropic -- це оркестр. Claude API -- це нотний стан (базова мова). Claude.ai -- це концерт для глядачів (кінцевих користувачів). Claude Code -- це диригент (агент з інструментами). Computer Use -- це музикант, що грає "на слух" (взаємодіє з GUI через зір). MCP -- це стандарт нотації, що дозволяє будь-якому інструменту грати в оркестрі.

Продукт	Тип	Призначення
Claude API	API	Базовий доступ до моделей
Claude.ai	Web App	Чат-інтерфейс для кінцевих користувачів
Claude Code	CLI Agent	Термінальний кодинг-асистент
Computer Use	Tool System	Взаємодія з GUI через скріншоти
MCP	Protocol	Стандарт для підключення зовнішніх сервісів

Головний висновок

Claude Code та Computer Use -- це не просто продукти. Це демонстрації агентних патернів: Claude Code показує, як будувати текстового агента з інструментами; Computer Use показує, як будувати візуального агента. Обидва використовують Tool Use та MCP -- ті самі концепції, що ви вже вивчили.

10.1 Введення в агенти та воркфлоу

Модуль 10 · Агенти та Воркфлоу

Цілі уроку

Зрозуміти різницю між агентами та воркфлоу
Навчитися обирати правильний підхід
Побачити патерн evaluator-optimizer

Фінальний модуль. Ви вже знаєте всі "цеглинки": API-запити, промпти, інструменти, RAG, MCP. Тепер -- як з цих цеглинок побудувати систему, що автономно вирішує складні задачі? Два фундаментальних підходи -- workflows (передбачуваний конвеєр) та agents (автономний вирішувач) -- і знання, коли який обрати, відрізняє досвідченого архітектора від новачка.

Воркфлоу vs Агенти

Метафора: GPS-навігація vs Автопілот

Workflow -- це GPS-навігація з ручним керуванням: маршрут прокладено заздалегідь, ви просто крутите кермо по інструкціях. "Поверніть ліворуч, потім 500 метрів прямо." Передбачувано, надійно. Agent -- це повний автопілот: ви кажете "їдемо в аеропорт", а система сама обирає маршрут, об'їжджає затори, паркується. Гнучко, але менш передбачувано.

	Workflows	Agents
Кроки	Визначені заздалегідь	Визначаються динамічно
Тестування	Легко (відомий шлях)	Складно (непередбачуваний шлях)
Надійність	Висока	Нижча
Гнучкість	Низька	Висока
Коли?	Знаєте точні кроки	Не знаєте, як вирішити

Реальний сценарій: Обробка email

Компанія отримує 500 email на день. Workflow підхід: Крок 1: Claude класифікує email (скарга/запитання/замовлення). Крок 2: Для кожної категорії -- свій промпт генерує відповідь. Крок 3: Людина перевіряє і відправляє. Кожен крок визначений, результат передбачуваний. Agent підхід був би: "Розберися з цим email" -- Claude сам вирішує, що робити. Для 80% email це працювало б, але для 20% -- непередбачувані результати. Для бізнесу workflow надійніший.

Правило: спочатку workflows, потім agents

Пріоритезуйте workflows для надійності. Використовуйте agents тільки коли гнучкість дійсно необхідна. Користувачі хочуть 100% працюючий продукт, а не красивого агента з 80% успіхом.

10.2 Паралелізація

Модуль 10 · Агенти та Воркфлоу

Цілі уроку

Зрозуміти патерн fan-out/fan-in
Побачити реальний приклад паралелізації

Перший патерн workflow -- паралелізація. Уявіть ситуацію: вам потрібно оцінити чотири матеріали для виробництва деталі. Замість послідовного аналізу кожного (4 хвилини), ви запускаєте 4 паралельних аналізи одночасно (1 хвилина + агрегація). Це як найняти 4 експертів замість одного.

Метафора: Комісія експертів

Паралелізація -- це як комісія з оцінки проєктів. Замість того, щоб один експерт послідовно оцінював всі аспекти, ви збираєте комісію: один оцінює фінанси, другий -- технічну частину, третій -- ризики, четвертий -- відповідність стандартам. Потім модератор збирає висновки у фінальний звіт.

Патерн: Input → Паралельні підзадачі → Агрегатор

Задача: "Обери матеріал для деталі" | ┌─────┼─────┐─────┐ ↓ ↓ ↓ ↓ Метал Полімер Кераміка Композит (Claude) (Claude) (Claude) (Claude) ↓ ↓ ↓ ↓ └─────┼─────┘─────┘ ↓ Агрегатор (Claude) ↓ Фінальне рішення

Переваги паралелізації

Фокус: кожна підзадача фокусується на одному аспекті
Модульність: промпти можна покращувати незалежно
Масштабованість: легко додати нову підзадачу
Якість: менше плутанини від надто складних промптів

import asyncio async def evaluate_material(material, requirements): response = client.messages.create( model=MODEL, max_tokens=2048, messages=[{"role": "user", "content": f"Оціни {material} для: {requirements}"}] ) return {"material": material, "analysis": response.content[0].text} async def parallel_evaluation(requirements): materials = ["метал", "полімер", "кераміка", "композит"] tasks = [evaluate_material(m, requirements) for m in materials] results = await asyncio.gather(*tasks) # Агрегатор summary = client.messages.create( model=MODEL, max_tokens=2048, messages=[{"role": "user", "content": f"Порівняй результати: {results}. Обери найкращий."}] ) return summary.content[0].text

10.3 Ланцюжки (Chaining)

Модуль 10 · Агенти та Воркфлоу

Цілі уроку

Зрозуміти послідовні ланцюжки обробки
Побачити, коли chaining краще за один великий промпт

Другий патерн workflow -- ланцюжки. Якщо паралелізація -- це "кілька експертів одночасно", то chaining -- це "конвеєр": результат першого кроку стає входом для другого, потім для третього. Як збирання автомобіля: спочатку каркас, потім двигун, потім фарбування -- кожен крок залежить від попереднього.

Навіщо ланцюжки?

Метафора: Редактор газети

У газеті журналіст пише статтю, потім редактор перевіряє факти, потім коректор виправляє граматику, потім верстальник форматує. Кожен фокусується на своєму. Якби журналіст намагався робити все одночасно -- якість статті була б нижчою. Те ж саме з Claude: коли промпт містить багато обмежень ("не згадуй AI", "без emoji", "професійний тон", "3 абзаци"), Claude часто порушує деякі з них. Рішення: розбити на кроки.

# Замість одного складного промпту: # Крок 1: Генерація контенту draft = chat([{"role": "user", "content": "Напиши пост про Python"}]) # Крок 2: Перевірка та виправлення final = chat([{"role": "user", "content": f"""Перевір цей текст: <draft>{draft}</draft> Виправ: - Видали будь-які emoji - Переконайся, що тон професійний - Не більше 3 абзаців"""}])

Коли використовувати Chaining?

Claude ігнорує обмеження у довгих промптах
Задача природно розбивається на послідовні кроки
Вивід одного кроку потрібен як вхід для наступного

10.4 Маршрутизація (Routing)

Модуль 10 · Агенти та Воркфлоу

Цілі уроку

Зрозуміти патерн routing
Побачити, як категоризація визначає обробку

Третій патерн workflow -- маршрутизація. Уявіть приймальне відділення лікарні: пацієнт приходить, медсестра оцінює стан і направляє: легке нездужання -- до терапевта, перелом -- до хірурга, біль у грудях -- до кардіолога. Різні проблеми -- різні спеціалісти. Routing працює так само: спочатку класифікуємо запит, потім обробляємо спеціалізованим промптом.

Метафора: Телефонна станція

Routing -- це як IVR (автовідповідач) у колл-центрі. "Натисніть 1 для підтримки, 2 для продажів, 3 для бухгалтерії." Кожна "лінія" веде до спеціаліста з правильним контекстом і знаннями. Один промпт для всіх -- це як один оператор, що знає все і нічого водночас.

Патерн: Класифікація → Спеціалізована обробка

Запит користувача ↓ [Класифікатор] (Claude: "Яка це категорія?") ↓ ┌────┼────┐ ↓ ↓ ↓ Навч. Розв. Тех. промпт промпт промпт ↓ ↓ ↓ Відповідь

# Крок 1: Класифікація category = chat([{"role": "user", "content": f""" Класифікуй тему "{topic}" в одну з категорій: - educational - entertainment - technical Поверни тільки назву категорії."""}]) # Крок 2: Спеціалізований промпт prompts = { "educational": "Створи навчальний контент з визначеннями та прикладами...", "entertainment": "Створи захоплюючий контент з гумором та трендами...", "technical": "Створи технічний матеріал з кодом та діаграмами..." } result = chat([{"role": "user", "content": prompts[category]}])

Переваги маршрутизації

Різні теми потребують різного тону, структури та глибини. Routing гарантує, що кожна категорія отримує оптимальну обробку замість "одного розміру для всіх".

10.5 Агенти та інструменти

Модуль 10 · Агенти та Воркфлоу

Цілі уроку

Зрозуміти принцип абстрактних інструментів
Побачити важливість інспекції середовища
Порівняти workflows vs agents для прийняття рішень

Останній урок курсу -- і найфілософічніший. Ви навчились будувати workflows (паралелізація, ланцюжки, маршрутизація). Тепер -- як побудувати справжнього агента? Три принципи: правильні інструменти, інспекція середовища і знання, коли агент краще за workflow.

Принцип абстракції інструментів

Метафора: Набір інструментів

Дайте агенту молоток, пилку та викрутку (bash, web_fetch, file_write) -- і він побудує що завгодно. Не давайте йому "інструмент-для-побудови-стільця" -- це занадто спеціалізовано. Абстрактні інструменти = більша гнучкість.

# Claude Code використовує абстрактні інструменти: # bash, web_fetch, file_write, file_read # НЕ: refactor_code, install_deps, run_tests # Агент може комбінувати інструменти креативно: # get_current_datetime + add_duration + set_reminder # = вирішити будь-яку задачу зі часом

Але навіть з ідеальними інструментами, агент може "зламатися", якщо не перевіряє результати своїх дій. Це другий фундаментальний принцип.

Інспекція середовища

Зворотний зв'язок після дій

Після кожної дії агент повинен перевірити результат:

Computer Use: скріншот після кожного кліку
Code editing: прочитати файл перед редагуванням
API виклик: перевірити відповідь перед наступним кроком

Тепер, маючи повну картину, давайте зведемо все воєдино. Ось ваш "шпаргалка" для вибору правильного патерну.

Фінальне порівняння

Патерн	Коли використовувати	Приклад
Паралелізація	Незалежні підзадачі	Аналіз кількох матеріалів
Ланцюжки	Послідовні кроки	Генерація → Перевірка → Публікація
Маршрутизація	Різні типи = різна обробка	Класифікація теми → Спеціалізований промпт
Агенти	Невідомі кроки	Claude Code (будь-яка задача розробки)

Вітаємо!

Курс Building with Claude API завершено!

Ви пройшли шлях від першого API-запиту до побудови агентних систем. Тепер ви знаєте: моделі, промпт-інженерію, Tool Use, RAG, MCP, Code Execution, Extended Thinking, Computer Use, та патерни агентів і воркфлоу.

Тепер будуйте!

Починайте з простого: один API-запит, один інструмент, один RAG-пайплайн. Поступово нарощуйте складність. Пам'ятайте: workflows перед agents, eval перед deploy.

Фінальний квіз: Агенти та Воркфлоу

1. Який підхід надійніший для продакшену?

Agents -- бо вони гнучкіші

Workflows -- бо кроки передбачувані

Однаково надійні

2. Який принцип дизайну інструментів для агентів?

Створювати спеціалізовані інструменти для кожної задачі

Не давати інструментів взагалі

Давати абстрактні, комбіновані інструменти

3. Навіщо агент робить скріншот після кожної дії?

Для інспекції середовища та перевірки результату

Для збереження в базу даних

Для звіту користувачу