Tool calls: построй устойчивый цикл tool calling

Построй цикл tool calling production-уровня вокруг любой чат-модели с tool use (Claude или OpenAI-совместимый function-calling API). Он должен исполнять многошаговую задачу против минимум трёх tools — включая один мутирующий, гейтящийся авторизацией tool — и оставаться корректным, ограниченным и осознающим стоимость, когда tools возвращают галлюцинированные аргументы, виснут или падают.

• Определи минимум три tools со строгим input_schema на JSON schema: один читающий (например find_order), один мутирующий и гейтящийся авторизацией (например cancel_order, скоупленный на вызывающего/тенанта) и один независимый читающий, который может идти параллельно с первым (например get_shipping_status). Используй required-поля, enum и реальные description.
• Реализуй цикл round-trip, управляемый stop_reason: шли tools + messages, исполняй tool_use-блоки, добавляй tool_result-блоки, повторяй пока stop_reason равен tool_use, и чисто выходи на end_turn / max_tokens / refusal.
• Добавь жёсткий cap итераций (for step in range(MAX_STEPS), например 10) плюс repeat-detection: если модель зовёт тот же tool с идентичными аргументами дважды подряд, прерви или впрысни сообщение, что вызов уже упал. Никогда не используй while True.
• Загейть каждый tool за пайплайном валидации: провалидируй аргументы по схеме (Pydantic/jsonschema), затем для мутирующего tool сделай authorize и existence-check сущности (существует И принадлежит этому вызывающему) до исполнения.
• Возвращай каждый сбой — ошибку валидации, отказ авторизации, timeout, исключение tool — как tool_result с выставленным is_error, а не как исключение, ломающее цикл, чтобы модель могла прочесть его и само-исправиться.
• Оберни исполнение каждого tool в timeout и ограниченную политику ретраев: ретраь только идемпотентные чтения при временном сбое (с capом и backoff); никогда не авто-ретраь мутирующий tool на плохом/галлюцинированном аргументе.
• Гоняй независимые tool_use-блоки конкурентно (asyncio.gather или пул потоков), сопоставляя каждый tool_result его block id, и возвращай их в одном последующем запросе. Продемонстрируй выигрыш по латентности от параллелизма против последовательного.
• Кэшируй или иначе учитывай статичный блок tools, чтобы контролировать потокеновую стоимость раунда, и логируй потокеновый расход за ход и число вызовов модели.

• Тест, где модели скармливают (или провоцируют на) галлюцинированный order_id: цикл отвергает его на проверке авторизации/существования, возвращает tool_result с ошибкой, и модель восстанавливается — мутирующий эндпоинт ни разу не срабатывает на плохом id. Покажи логи.
• Тест, где один tool виснет: per-tool timeout срабатывает, возвращает tool_result с ошибкой, и цикл продолжается или изящно выходит — ход никогда не стопорится бесконечно.
• Тест, где модель застревает, повторяя один падающий вызов: cap итераций и/или repeat-detection останавливает её в пределах MAX_STEPS и возвращает изящный отказ пользователю — зафиксированная стоимость остаётся ограниченной.
• Измерение латентности до/после для двух независимых вызовов, показывающее, что параллельный путь быстрее последовательного, с корректно сопоставленными id у tool_result.
• Короткий разбор: три слоя валидации, где живёт каждый guard, политика ретраев (и почему мутирующий tool исключён), и потокеновые числа/число вызовов за ход.