Programmatic Tool Calling на Amazon Bedrock: снижаем latency при многошаговых вызовах инструментов

Когда туда-сюда убивает отзывчивость

Ты собрал агента на Bedrock, который вызывает пять инструментов подряд: проверить баланс, найти рейс, забронировать, отправить уведомление. Что происходит? Каждый вызов - отдельный round-trip к LLM. Модель возвращает JSON с именем функции и аргументами, твой код исполняет функцию, отдает результат обратно, модель снова думает. И так пять раз. Латенси растет как снежный ком: от 2-3 секунд на простой запрос до 15-20 на многошаговый.

В 2025 году AWS наконец-то выкатили Programmatic Tool Calling (PTC) для агентов Bedrock. Это не эволюция - это слом парадигмы. Вместо того чтобы возвращать JSON с одним вызовом, модель генерирует Python-скрипт, который сам зовет все нужные инструменты внутри себя. А ты просто дергаешь этот скрипт в изолированной песочнице и получаешь финальный ответ.

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

Под капотом: генерация кода и песочница

В обычном режиме (ReAct) схема такая:

• Пользователь: "Забронируй билет на 25 июня"
• Модель: думает, выдает JSON: {"tool": "searchFlights", "params": {"date": "2026-06-25"}}
• Агент: выполняет searchFlights, возвращает результат
• Модель: думает снова, JSON: {"tool": "bookTicket", "params": {"flight": "SU123"}}
• Агент: бронирует, возвращает статус
• Модель: формирует ответ пользователю

Пять шагов, четыре обращения к LLM, минимум 8-12 секунд чистой работы модели (без учета времени на сами API). А теперь PTC:

1. Пользователь: "Забронируй билет на 25 июня"
2. Модель: генерирует Python-код, который вызывает searchFlights, bookTicket, sendEmail внутри одного скрипта
3. Агент: передает код в sandbox-среду (изолированный Docker-контейнер), выполняет, получает финальный результат
4. Модель: один раз до-формулирует ответ на основе результата выполнения

Время сокращается до 2-4 секунд. Разница в 3-5 раз. И это еще не все: PTC экономит токены, потому что модель не генерирует повторные цепочки вызовов. Одно длинное рассуждение вместо нескольких коротких.

Как это выглядит в коде (без кода, но с логикой)

Допустим, у тебя агент для финопс-задач. Ты хочешь: получить текущий расход по сервису EC2, умножить на прогнозируемый рост, сравнить с бюджетом. В обычном режиме - три вызова. В PTC модель сгенерирует скрипт:

import boto3, json
from utils import get_bedrock_cost, get_budget

# 1. Получаем данные
cost_data = get_bedrock_cost(service='ec2', period='MTD')
budget_data = get_budget(name='Production')

# 2. Расчет
current_spend = cost_data['total']
forecast = current_spend * 1.15
alert = forecast - budget_data['limit']

# 3. Вывод
result = {
    'current': current_spend,
    'forecast': forecast,
    'over_budget': alert > 0,
    'difference': alert
}
print(json.dumps(result))

Агент берет этот код, запускает в песочнице Bedrock Sandbox (изолированная среда с ограниченными правами), и возвращает финальный JSON. Никаких промежуточных шагов. Одна генерация, один запуск, один ответ.

Когда PTC дает максимальный профит

Выигрыш заметен не всегда. Если у тебя агент делает один вызов - смысла нет (оверхед на генерацию кода может даже увеличить latency). Но если в workflow больше двух последовательных вызовов, особенно с ветвлениями или циклами - PTC незаменим.

Цифры экспериментальные, сняты на Claude 4.5 Opus (последняя версия на май 2026). Результат зависит от сложности задачи и размера промпта. Но тренд очевиден: чем длиннее цепочка, тем выгоднее PTC.

Практический гайд: включаем PTC в Bedrock Agent

Все действия делаются через AWS Console или SDK (boto3). Покажу настройку на Python, потому что в консоли все тривиально.

1 Создай инструменты с правильным типом

Для PTC инструменты должны быть описаны как JSON Schema, а не как лямбды. Песочница будет вызывать их прямо из кода через функцию call_tool(name, args). Вот пример для boto3:

import boto3
from typing import Dict, Any

client = boto3.client('bedrock-agent')

# Агент с PTC включенным
response = client.create_agent(
    agentName='ptc-assistant',
    foundationModel='anthropic.claude-4-5-opus-20260524',
    instruction='Ты - агент с PTC. Генерируй Python-код для выполнения задач.',
    actionGroups=[
        {
            'actionGroupName': 'tools',
            'description': 'Инструменты для работы',
            'actionGroupExecutor': {
                'customControl': 'RETURN_CONTROL'  # критично!
            },
            'functionSchema': {
                'functions': [
                    {
                        'name': 'get_usage',
                        'description': 'Получить использование сервиса',
                        'parameters': {
                            'service': {'type': 'string'},
                            'period': {'type': 'string', 'enum': ['MTD', 'YTD']}
                        }
                    },
                    {
                        'name': 'send_notification',
                        'description': 'Отправить уведомление',
                        'parameters': {
                            'message': {'type': 'string'},
                            'channel': {'type': 'string'}
                        }
                    }
                ]
            }
        }
    ],
    codeInterpreterEnabled=True  # включает PTC
)

agent_id = response['agent']['agentId']

2 Настрой инструкцию для генерации кода

Промпт агента должен явно просить генерировать код. Пример:

Ты - агент с Programmatic Tool Calling. Когда получаешь запрос:
1. Разбей задачу на шаги.
2. Напиши Python-код, который использует функцию call_tool(name, args) для вызова инструментов.
3. Код должен работать в изолированной среде без доступа к сети.
4. Возвращай только код в тегах ```python ... ```.
5. Не используй сторонние библиотеки кроме json, math, datetime.
6. Обрабатывай ошибки инструментов через try-except.

Я настоятельно рекомендую запретить генерацию кода с бесконечными циклами - добавь в промпт что-то вроде "не используй while True, ставь ограничение на 100 итераций". Иначе получишь таймаут в 30 секунд и пустой ответ.

3 Выполни и проверь результат

После отправки запроса, агент вернет объект response, в котором будет поле intermediateSteps. В этом поле найдешь сгенерированный код и результат его выполнения. Если возникла ошибка - в логах будет traceback.

response = client.invoke_agent(
    agentId=agent_id,
    agentAliasId='TSTALIAS_ID',
    sessionId='test-session',
    inputText='Покажи текущие расходы на EC2 и если они превышают 1000$, отправь уведомление'
)

# Читаем поток ответа
for event in response['completion']:
    if 'chunk' in event:
        text = event['chunk']['bytes'].decode()
        print(text)
    if 'trace' in event:
        trace = event['trace']
        # Здесь будет код и результат выполнения
        print(trace)

Шесть граблей, на которые я наступил

Первый месяц работы с PTC - чистый ад. Но потом стало кайфово. Вот что может пойти не так:

1. Модель генерирует синтаксически невалидный код. Особенно часто с Claude 3.5 Sonnet - он любит забывать закрывающие скобки. Переход на Claude 4.5 Opus эту проблему почти убил, но не до конца. Решение: включи автоматический ретрай с повторной генерацией кода.
2. Таймаут песочницы. По умолчанию 30 секунд. Если агент зациклится или полезет в датасет из 1000 строк - получишь таймаут. Ставь лимит на размер вывода (maxTokens) и время выполнения через codeInterpreterTimeoutSeconds.
3. Инструменты с побочными эффектами. В коде может быть вызван deleteResource() случайно. PTC не защищает от глупых вызовов - только от злонамеренных. Поэтому перед запуском в продакшн обязательно тестируй все возможные сценарии.
4. Размер кода. Модель может сгенерировать километровый скрипт. Песочница ограничена 8192 символами на код. Если больше - упадет с ошибкой.
5. Смешение data и function calling. Если в инструментах есть и query, и mutation, модель может вызвать их в неправильном порядке. В явном виде пропиши порядок в инструкции.
6. Отсутствие мониторинга. PTC генерирует код динамически - стандартные метрики вызовов инструментов перестают работать. Используй новые CloudWatch метрики TimeToFirstToken и EstimatedTPMQuotaUsage для отслеживания задержек. Без этого ты ослепнешь при росте нагрузки.

Когда PTC не нужен (честно)

Бывают кейсы, где PTC только мешает:

• Задачи с одним инструментом. Например, просто перевести текст. JSON-вызов быстрее и дешевле.
• Взаимодействие с реальным временем. Если нужны стриминговые данные (цены акций) - код в песочнице не может держать открытое соединение.
• Высокая частота ошибок в инструментах. Если API часто падает, лучше обрабатывать ошибки по одному, а не внутри сгенерированного кода. PTC предполагает, что инструменты надежные.

FAQ по PTC

Прогноз: через год все будут так делать

Сейчас PTC - опция, которую включают фанаты скорости. Но посмотри на тренды: AWS инвестирует в песочницу, модели лучше кодируют, а сложность агентов растет. Уже к концу 2026 года PTC станет режимом по умолчанию для всех multi-tool агентов.

Почему? Потому что это не просто оптимизация - это смена парадигмы. Вместо того чтобы учить LLM быть "дирижером" оркестра вызовов, мы говорим ей "напиши партитуру и отдай роботу". Робот (песочница) сыграет быстрее и точнее. А LLM останется только оценить результат.

Совет на будущее: если ты строишь агента с более чем двумя последовательными вызовами - сразу переходи на PTC. Да, первые две недели будешь материть кривой код. Но когда наладишь - срежешь latency вдвое. А в мире AI-агентов скорость - это валюта.

И да, если думаешь, что географическая маршрутизация может еще ускорить - почитай как это сделали в Bedrock Окленда. Комбинируя PTC с умным роутингом, можно получить агента, который отвечает быстрее, чем ты моргаешь.

Подписаться на канал