Представляємо розширене використання інструментів на платформі Claude Developer Platform

Майбутнє агентів штучного інтелекту — це те, де моделі безперебійно працюватимуть із сотнями чи тисячами інструментів.Помічник IDE, який інтегрує операції git, маніпуляції з файлами, менеджери пакетів, інфраструктури тестування та конвеєри розгортання.Операційний координатор, який одночасно з’єднує Slack, GitHub, Google Drive, Jira, бази даних компанії та десятки серверів MCP.

Щоб створювати ефективні агенти, їм потрібно працювати з необмеженими бібліотеками інструментів, не вставляючи кожне визначення в контекст заздалегідь.У нашій статті в блозі про використання коду за допомогою MCP обговорювалося, як результати інструментів і визначення іноді можуть споживати понад 50 000 токенів, перш ніж агент прочитає запит.Агенти повинні знаходити та завантажувати інструменти на вимогу, зберігаючи лише те, що стосується поточного завдання.

Агентам також потрібна можливість викликати інструменти з коду.Під час використання інструментів виклику природної мови для кожного виклику потрібен повний перехід висновку, а проміжні результати накопичуються в контексті незалежно від того, корисні вони чи ні.Код природно підходить для логіки оркестровки, такої як цикли, умови та перетворення даних.Агентам потрібна гнучкість для вибору між виконанням коду та висновком на основі поставленого завдання.

Агентам також необхідно навчитися правильному використанню інструментів на прикладах, а не лише на визначеннях схем.Схеми JSON визначають, що є структурно дійсним, але не можуть виражати шаблони використання: коли включати додаткові параметри, які комбінації мають сенс або які умовності очікує ваш API.

Сьогодні ми випускаємо три функції, які роблять це можливим:

- Інструмент пошуку інструментів, який дозволяє Клоду використовувати інструменти пошуку для доступу до тисяч інструментів, не споживаючи контекстне вікно

- Programmatic Tool Calling , що дозволяє Клоду викликати інструменти в середовищі виконання коду, зменшуючи вплив на контекстне вікно моделі

- Приклади використання інструментів, які надають універсальний стандарт для демонстрації того, як ефективно використовувати певний інструмент

Під час внутрішнього тестування ми виявили, що ці функції допомогли нам створювати речі, які були б неможливі за стандартних моделей використання інструментів.Наприклад, Claude для Excel використовує Programmatic Tool Calling, щоб читати та змінювати електронні таблиці з тисячами рядків, не перевантажуючи контекстне вікно моделі.

Виходячи з нашого досвіду, ми вважаємо, що ці функції відкривають нові можливості для того, що ви можете створити з Claude.

Інструмент пошуку інструментів

Виклик

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

- GitHub: 35 інструментів (~26 тис. токенів)

- Slack: 11 інструментів (~21 тис. токенів)

- Вартовий: 5 інструментів (~3K жетонів)

- Grafana: 5 інструментів (~3K жетонів)

- Splunk: 2 інструменти (~2K жетонів)

Це 58 інструментів, які споживають приблизно 55 тисяч токенів ще до початку розмови.Додайте більше серверів, таких як Jira (який використовує ~17 тисяч токенів), і ви швидко наблизитеся до понад 100 тисяч токенів.У Anthropic ми бачили, що визначення інструментів споживають 134 тисячі токенів до оптимізації.

Але вартість жетонів — не єдина проблема.Найпоширенішими помилками є неправильний вибір інструменту та неправильні параметри, особливо коли інструменти мають схожі назви, як-от notification-send-user або notification-send-channel.

Наше рішення

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

Традиційний підхід:

- Усі визначення інструментів завантажуються заздалегідь (~72K маркерів для 50+ інструментів MCP)

- Історія розмов і системна підказка змагаються за місце, що залишилося

- Загальне споживання контексту: ~77 тисяч токенів до початку будь-якої роботи

За допомогою інструменту пошуку інструментів:

- Тільки інструмент пошуку інструментів завантажується заздалегідь (~500 токенів)

- Інструменти, виявлені за потребою (3-5 відповідних інструментів, ~3K маркерів)

- Загальне споживання контексту: ~8,7 тис. токенів, зберігаючи 95% вікна контексту

Це означає зменшення використання маркерів на 85%, зберігаючи доступ до повної бібліотеки інструментів.Внутрішнє тестування показало значне підвищення точності оцінок MCP під час роботи з великими бібліотеками інструментів.Opus 4 покращився з 49% до 74%, а Opus 4.5 покращився з 79,5% до 88,1% з увімкненим інструментом пошуку інструментів.

Як працює інструмент пошуку інструментів Інструмент пошуку інструментів дозволяє Клоду динамічно знаходити інструменти замість того, щоб завантажувати всі визначення заздалегідь.Ви надаєте всі свої визначення інструментів API, але позначаєте інструменти за допомогою defer_loading: true, щоб зробити їх доступними за запитом.Відкладені інструменти спочатку не завантажуються в контекст Клода.Клод бачить лише сам інструмент пошуку інструментів, а також будь-які інструменти з defer_loading: false (ваші найважливіші інструменти, які часто використовуються).

Коли Клоду потрібні певні можливості, він шукає відповідні інструменти.Інструмент пошуку інструментів повертає посилання на відповідні інструменти, які розширюються до повних визначень у контексті Клода.

Наприклад, якщо Клоду потрібно взаємодіяти з GitHub, він шукає «github», і завантажуються лише github.createPullRequest і github.listIssues, а не інші понад 50 ваших інструментів із Slack, Jira та Google Drive.

Таким чином, Клод отримує доступ до вашої повної бібліотеки інструментів, сплачуючи лише символічну вартість інструментів, які йому дійсно потрібні.

Примітка щодо кешування підказок: Інструмент пошуку інструментів не порушує кешування підказок, оскільки відкладені інструменти повністю виключаються з початкової підказки.Вони додаються до контексту лише після того, як Клод їх шукає, тому ваші системні підказки та визначення основних інструментів залишаються кешованими.

Реалізація:

```

{

"інструменти": [

// Включаємо інструмент пошуку інструментів (регулярний вираз, BM25 або спеціальний)

{"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"},

// Позначити інструменти для виявлення на вимогу

{

"ім'я": "github.createPullRequest",

"description": "Створити запит на отримання",

"вхідна_схема": {...},

"defer_loading": правда

}

// ... ще сотні відкладених інструментів із defer_loading: true

]

}

```

Для серверів MCP ви можете відкласти завантаження цілих серверів, залишаючи завантаженими певні інструменти, які часто використовуються:

```

{

"тип": "mcp_toolset",

"mcp_server_name": "google-диск",

"default_config": {"defer_loading": true}, # відкласти завантаження всього сервера

"конфігурації": {

"пошук_файлів": {

"defer_loading": false

} // Тримайте завантаженим інструмент, який найчастіше використовується

}

}

```

Платформа Claude Developer Platform надає інструменти пошуку на основі регулярних виразів і BM25 із коробки, але ви також можете реалізувати спеціальні інструменти пошуку за допомогою вбудовування або інших стратегій.

Коли використовувати інструмент пошуку інструментів

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

Використовуйте його, коли:

- Визначення інструментів, що споживають >10K токенів

- Проблеми з точністю вибору інструменту

- Створення систем на базі MCP з кількома серверами

- доступні 10+ інструментів

Менш корисно, коли:

- Невелика бібліотека інструментів (<10 інструментів)

- Усі інструменти, які часто використовуються під час кожного сеансу

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

Програмний виклик інструментів

Виклик

Традиційний виклик інструментів створює дві фундаментальні проблеми, оскільки робочі процеси стають складнішими:

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

- Накладні витрати на логічний висновок і ручний синтез: для кожного виклику інструмента потрібен повний проход логічного висновку моделі.Отримавши результати, Клод повинен «оглядати» дані, щоб отримати релевантну інформацію, міркувати про те, як частини поєднуються разом, і вирішити, що робити далі — і все це за допомогою обробки природної мови.Робочий процес із п’ятьма інструментами означає п’ять проходів висновків плюс Клод аналізує кожен результат, порівнює значення та синтезує висновки.Це повільно і схильне до помилок.

Наше рішення

Програмний виклик інструментів дає змогу Клоду оркеструвати інструменти за допомогою коду, а не за допомогою окремих двосторонніх звернень API.Замість того, щоб Клод запитував інструменти по одному, повертаючи кожен результат до свого контексту, Клод пише код, який викликає кілька інструментів, обробляє їхні виходи та контролює, яка інформація фактично надходить у контекстне вікно. Клод чудово вміє писати код, і дозволяючи йому виражати логіку оркестровки в Python, а не через виклики інструментів природною мовою, ви отримуєте більш надійний і точний потік керування.Цикли, умови, перетворення даних і обробка помилок — усе це явно виражено в коді, а не приховано в міркуваннях Клода.

Приклад: перевірка відповідності бюджету

Розглянемо звичайне бізнес-завдання: «Хто з членів команди перевищив свій бюджет на відрядження за 3-й квартал?»

У вас є три інструменти:

- get_team_members(department) - Повертає список членів команди з ідентифікаторами та рівнями

- get_expenses(user_id, quarter) - Повертає позиції витрат для користувача

- get_budget_by_level(level) - Повертає обмеження бюджету для рівня співробітника

Традиційний підхід:

- Зберіть членів команди 20 осіб

- Для кожної особи отримайте її витрати за 3 квартал 20 викликів інструментів, кожен повертає 50-100 рядків (авіаквитки, готелі, харчування, квитанції)

- Отримайте обмеження бюджету за рівнем співробітника

- Усе це входить у контекст Клода: понад 2000 статей витрат (50 КБ+)

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

- Більше поворотів до моделі, значне споживання контексту

З програмним викликом інструменту:

Замість того, щоб кожен результат інструменту повертався до Клода, Клод пише сценарій Python, який організовує весь робочий процес.Сценарій виконується в інструменті виконання коду (ізольоване середовище), призупиняючись, коли потрібні результати ваших інструментів.Коли ви повертаєте результати інструменту через API, вони обробляються сценарієм, а не споживаються моделлю.Сценарій продовжує виконуватися, і Клод бачить лише кінцевий результат.

Ось як виглядає оркестровий код Клода для завдання відповідності бюджету:

```

team = await get_team_members("розробка")

# Отримати бюджети для кожного унікального рівня

levels = list(set(m["level"] for m in team))

budget_results = await asyncio.gather(*[

get_budget_by_level(level) для рівня в рівнях

])

# Створіть пошуковий словник: {"молодший": бюджет1, "старший": бюджет2, ...}

бюджети = {рівень: бюджет для рівня, бюджет у zip(рівні, бюджет_результати)}

# Отримати всі витрати паралельно

витрати = очікувати asyncio.gather(*[

get_expenses(m["id"], "Q3") для m у команді

])

# Знайдіть співробітників, які перевищили свій бюджет на відрядження

перевищено = []

для члена, досвіду в zip(команда, витрати):

бюджет = бюджети[учасник["рівень"]]

total = sum(e["amount"] for e in exp)

if total > budget["travel_limit"]:

перевищено.append({

"ім'я": учасник["ім'я"],

"витрачено": всього,

"limit": бюджет["travel_limit"]

})

print(json.dumps(exceeded))

```

Контекст Клода отримує лише кінцевий результат: двоє-троє людей, які перевищили свій бюджет.Понад 2000 рядків-позицій, проміжні суми та пошук бюджету не впливають на контекст Клода, зменшуючи споживання з 200 КБ необроблених даних про витрати до лише 1 КБ результатів.

Підвищення ефективності є значним:

- Економія токенів: зберігаючи проміжні результати поза контекстом Клода, PTC значно зменшує споживання токенів.Середнє використання впало з 43 588 до 27 297 токенів, що на 37% менше для складних дослідницьких завдань.

- Зменшена затримка: для кожного зворотного проходження API потрібне визначення моделі (від сотень мілісекунд до секунд).Коли Клод організовує понад 20 викликів інструментів в одному блоці коду, ви виключаєте 19+ проходів висновку.API обробляє виконання інструменту, не повертаючись кожного разу до моделі.

- Покращена точність: створюючи чітку логіку оркестровки, Клод робить менше помилок, ніж під час жонглювання результатами кількох інструментів природною мовою.Внутрішній пошук знань покращився з 25,6% до 28,5%;Орієнтовні показники GIA з 46,5% до 51,2%.

Виробничі робочі процеси містять безладні дані, умовну логіку та операції, які потребують масштабування.Programmatic Tool Calling дозволяє Claude впоратися з цією складністю програмним шляхом, зосереджуючись на ефективних результатах, а не на обробці необроблених даних.

Як працює Programmatic Tool Calling

1. Позначте інструменти як викликані з коду

Додайте code_execution до інструментів і встановіть allowed_callers для підключення інструментів для програмного виконання: ```

{

"інструменти": [

{

"type": "code_execution_20250825",

"ім'я": "виконання_коду"

},

{

"name": "get_team_members",

"description": "Отримати всіх членів відділу...",

"вхідна_схема": {...},

"allowed_callers": ["code_execution_20250825"] # підключення до програмного виклику інструменту

},

{

"name": "get_expenses",

...

},

{

"name": "get_budget_by_level",

...

}

]

}

```

API перетворює ці визначення інструментів у функції Python, які може викликати Клод.

2. Клод пише код оркестровки

Замість того, щоб запитувати інструменти по одному, Клод генерує код Python:

```

{

"type": "server_tool_use",

"id": "srvtoolu_abc",

"ім'я": "виконання_коду",

"вхід": {

"code": "team = get_team_members('engineering')\n..." # приклад коду вище

}

}

```

3. Інструменти виконуються, не зачіпаючи контекст Клода

Коли код викликає get_expenses(), ви отримуєте запит інструменту з полем виклику:

```

{

"type": "tool_use",

"id": "toolu_xyz",

"name": "get_expenses",

"input": {"user_id": "emp_123", "quarter": "Q3"},

"дзвінок": {

"type": "code_execution_20250825",

"tool_id": "srvtoolu_abc"

}

}

```

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

4. Лише остаточний результат входить у контекст

Коли код завершує роботу, Клоду повертаються лише результати коду:

```

{

"type": "code_execution_tool_result",

"tool_use_id": "srvtoolu_abc",

"вміст": {

"stdout": "[{\"ім'я\": \"Аліса\", \"витрачено\": 12500, \"ліміт\": 10000}...]"

}

}

```

Це все, що бачить Клод, а не понад 2000 статей витрат, оброблених на цьому шляху.

Коли використовувати Programmatic Tool Calling

Programmatic Tool Calling додає крок виконання коду до вашого робочого процесу.Ці додаткові накладні витрати окупаються, коли економія маркерів, покращення затримки та підвищення точності є значними.

Найбільш корисно, коли:

- Обробка великих наборів даних, де вам потрібні лише агрегати або підсумки

- Запуск багатоетапних робочих процесів із трьома або більше залежними викликами інструментів

- Фільтрування, сортування або трансформація результатів інструментів до того, як їх побачить Клод

- Виконання завдань, де проміжні дані не повинні впливати на міркування Клода

- Виконання паралельних операцій з багатьма елементами (перевірка 50 кінцевих точок, наприклад)

Менш корисно, коли:

— Виконання простих викликів одним інструментом

- Робота над завданнями, де Клод повинен бачити та міркувати про всі проміжні результати

- Запуск швидкого пошуку з невеликими відповідями

Приклади використання інструментів

Виклик

Схема JSON відмінно справляється з визначенням структурних типів, обов’язкових полів, дозволених переліків, але вона не може виражати шаблони використання: коли включати додаткові параметри, які комбінації мають сенс або які умовності очікує ваш API.

Розглянемо API квитка підтримки:

```

{

"name": "create_ticket",

"вхідна_схема": {

"властивості": {

"title": {"type": "string"},

"priority": {"enum": ["низький", "середній", "високий", "критичний"]},

"labels": {"type": "array", "items": {"type": "string"}},

"репортер": {

"type": "об'єкт",

"властивості": {

"id": {"type": "string"},

"name": {"type": "string"},

"контакт": {

"type": "об'єкт",

"властивості": {

"email": {"type": "string"},

"телефон": {"тип": "рядок"}

}

}

}

},

"due_date": {"type": "string"},

"ескалація": {

"type": "об'єкт",

"властивості": {

"level": {"type": "integer"},

"notify_manager": {"type": "boolean"},

"sla_hours": {"type": "integer"}

}

}

},

"обов'язково": ["назва"]

}

}

```

Схема визначає, що є дійсним, але залишає критичні запитання без відповіді:

- Неоднозначність формату: чи має термін_виконання використовувати "2024-11-06", "Nov 6, 2024" або "2024-11-06T00:00:00Z"?

- Умовні позначення ідентифікаторів: reporter.id є UUID, "USR-12345" чи просто "12345"?

- Використання вкладеної структури: коли Клод повинен заповнити reporter.contact ?

- Кореляції параметрів: як escalation.level і escalation.sla_hours пов’язані з пріоритетом?

Ці неоднозначності можуть призвести до неправильно сформованих викликів інструментів і непослідовного використання параметрів.

Наше рішення

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

{

"name": "create_ticket",

"input_schema": { /* та сама схема, що й вище */ },

"input_examples": [

{

"title": "Сторінка входу повертає помилку 500",

"priority": "критичний",

"labels": ["bug", "authentication", "production"],

"репортер": {

"id": "USR-12345",

"name": "Джейн Сміт",

"контакт": {

"електронна пошта": "jane@acme.com",

"телефон": "+1-555-0123"

}

},

"due_date": "2024-11-06",

"ескалація": {

"рівень": 2,

"notify_manager": правда,

"sla_hours": 4

}

},

{

"title": "Додати підтримку темного режиму",

"labels": ["feature-request", "ui"],

"репортер": {

"id": "USR-67890",

"ім'я": "Алекс Чен"

}

},

{

"title": "Оновити документацію API"

}

]

}

```

З цих трьох прикладів Клод дізнається:

- Умовні позначення формату: у датах використовується РРРР-ММ-ДД, в ідентифікаторах користувачів – USR-XXXXX, у мітках – kebab-case.

- Шаблони вкладеної структури: як побудувати об’єкт звіту з його вкладеним об’єктом контакту

- Необов'язкові кореляції параметрів: критичні помилки мають повну контактну інформацію + ескалацію з жорсткими SLA;запити на функції мають репортера, але не мають контакту/ескалації;внутрішні завдання мають лише назву

Під час нашого власного внутрішнього тестування приклади використання інструментів підвищили точність обробки складних параметрів із 72% до 90%.

Коли використовувати інструмент. Приклади використання

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

Найбільш корисно, коли:

- Складні вкладені структури, де дійсний JSON не передбачає правильного використання

- Інструменти з багатьма необов'язковими параметрами та шаблонами включення мають значення

- API із специфічними для домену угодами, які не враховані в схемах

- Подібні інструменти, де приклади пояснюють, який з них використовувати (наприклад, create_ticket проти create_incident )

Менш корисно, коли:

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

- Стандартні формати, як-от URL-адреси чи електронні листи, які Клод уже розуміє

- Питання перевірки краще обробляються обмеженнями схеми JSON

Кращі практики

Створення агентів, які виконують дії в реальному світі, означає водночас керування масштабом, складністю та точністю.Ці три функції працюють разом, щоб вирішити різні вузькі місця в робочих процесах використання інструментів.Ось як їх ефективно поєднати.

Шар має стратегічні особливості

Не кожен агент повинен використовувати всі три функції для певного завдання.Почніть із найбільшого вузького місця:

— Роздутість контексту з визначень інструментів Інструмент пошуку

- Великі проміжні результати, що забруднюють контекст Програмний виклик інструменту

- Помилки параметрів і некоректні виклики інструментів. Приклади використання

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

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

Налаштуйте інструмент пошуку інструментів для кращого пошуку

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

```

// Добре

{

"name": "search_customer_orders",

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

}

// Погано

{

"name": "query_db_orders",

"description": "Виконати запит замовлення"

}

```

Додайте системні підказки, щоб Клод знав, що доступно:

```

Ви маєте доступ до інструментів для обміну повідомленнями Slack, керування файлами Google Drive,

Відстеження квитків Jira та операції зі сховищем GitHub.Скористайтеся інструментом пошуку

щоб знайти конкретні можливості.

```

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

Налаштуйте Programmatic Tool Calling для правильного виконання

Оскільки Клод пише код для аналізу вихідних даних інструменту, чіткі формати повернення документа.Це допомагає Клоду написати правильну логіку аналізу: ```

{

"name": "get_orders",

"description": "Отримати замовлення для клієнта.

Повернення:

Список об'єктів замовлення, кожен з яких містить:

- id (str): ідентифікатор замовлення

- total (float): загальна сума замовлення в доларах США

- статус (str): один із «очікує», «відправлено», «доставлено»

- елементи (список): масив {sku, quantity, price}

- created_at (str): мітка часу ISO 8601"

}

```

Нижче наведено інструменти підключення, які виграють від програмної оркестровки:

- Інструменти, які можуть працювати паралельно (незалежні операції)

- Операції, безпечні для повторної спроби (ідемпотентні)

Налаштуйте приклади використання інструменту для точності параметрів

Приклади ремесел для ясності поведінки:

- Використовуйте реалістичні дані (справжні назви міст, правдоподібні ціни, а не "рядок" або "значення")

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

- Будьте лаконічними: 1-5 прикладів на інструмент

- Зосередьтеся на двозначності (лише додайте приклади, у яких правильне використання не є очевидним зі схеми)

Початок роботи

Ці функції доступні в бета-версії.Щоб увімкнути їх, додайте бета-заголовок і включіть необхідні інструменти:

```

client.beta.messages.create(

betas=["advanced-tool-use-2025-11-20"],

model="claude-sonnet-4-5-20250929",

max_tokens=4096,

інструменти=[

{"type": "tool_search_tool_regex_20251119", "name": "tool_search_tool_regex"},

{"type": "code_execution_20250825", "name": "code_execution"},

# Ваші інструменти з defer_loading, allowed_callers і input_examples

]

)

```

Детальну документацію API і приклади SDK див.

- Д окументація та кулінарна книга для Інструменту пошуку інструментів

- Документація та кулінарна книга для Programmatic Tool Calling

- Документація для прикладів використання інструментів

Ці функції переміщують використання інструментів від простого виклику функції до інтелектуальної оркестровки.Оскільки агенти вирішують складніші робочі процеси, що охоплюють десятки інструментів і великі набори даних, динамічне виявлення, ефективне виконання та надійний виклик стають основоположними.

Ми раді бачити, що ви створюєте.

Подяки

Написав Бін Ву за участі Адама Джонса, Артура Рено, Генрі Тея, Джейка Нобла, Натана МакКендліша, Ноа Пікарда, Сема Цзяна та команди Claude Developer Platform.Ця робота базується на фундаментальних дослідженнях Кріса Горголевскі, Деніела Цзяна, Джеремі Фокса та Майка Ламберта.Ми також черпали натхнення в екосистемі штучного інтелекту, включаючи LLMVM Джоела Побара, режим коду Cloudflare і виконання коду як MCP.Особлива подяка Енді Шумайстеру, Хемішу Керру, Кіру Бредвеллу, Метту Блейферу та Моллі Форверк за підтримку.