Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Агент теперь может сохранять промежуточные результаты, продолжать работу после сбоя и уточнять API по ходу многошаговой задачи. В препринте UC Berkeley, который не рецензирован и содержит замеры самих авторов, I-PTC чаще решал сложные задачи и тратил меньше токенов, чем последовательные вызовы инструментов и одноразовые программы. Для продуктовой команды это означает, что состояние стоит хранить не только в контексте модели, но и в отдельной исполняемой среде.
Почему одноразовая программа теряет результаты
При обычном вызове инструментов модель выбирает одну функцию, получает ответ в контекст и решает, что делать дальше. Такой цикл подходит для короткой операции, но длинная цепочка раздувает контекст: в него попадают результаты поиска, записи из баз, параметры следующих вызовов и повторяющиеся описания API.
Программный вызов инструментов (PTC) переносит часть работы в код. Модель пишет цикл, фильтрует записи, объединяет ответы нескольких API и возвращает только итог. Проблема возникает, когда программа выполняется в новой изолированной среде при каждом запуске. Если агент неверно угадал формат ответа или столкнулся со сбоем, он теряет переменные и часто повторяет уже сделанные запросы.
I-PTC заменяет одноразовый запуск средой в стиле Jupyter Notebook. Модель отправляет небольшие ячейки кода, видит результаты и продолжает работу в том же пространстве имён. Переменные, импорты и функции остаются доступны следующим ячейкам. Если ошибка возникает посередине ячейки, среда сохраняет результаты успешно выполненных строк, поэтому агент исправляет только сломанный участок.
Состояние не приходится превращать в текст и снова передавать модели. Например, список свободных временных интервалов остаётся переменной в среде, а при следующем сообщении пользователя агент меняет фильтр вместо повторного чтения всех календарей.
API тоже становится частью состояния
I-PTC хранит не только данные конкретной задачи. Агент может запросить описание нужного метода API непосредственно перед вызовом. В исходный контекст попадают только названия доступных сервисов, а полные схемы загружаются по запросу. Это сокращает расходы на большие каталоги инструментов, где для одной задачи нужна лишь малая часть методов.
Ошибки API превращаются в поправки к документации. После группы задач отдельный агент разбирает трассировки и добавляет к описанию метода короткое уточнение: допустимый формат аргумента, особенность возвращаемого объекта или условие вызова. Следующие запуски получают эту поправку без изменения весов модели.
Так появляются два уровня памяти. Внутри задачи исполнитель хранит вычисления и частичные результаты. Между задачами реестр инструментов накапливает сведения о фактическом поведении API. Их важно разделять: пользовательские данные относятся к одному запуску, а поправка к интерфейсу может применяться ко всем последующим.
Состояние помогает на длинных цепочках, но требует подходящей модели
Метод проверяли на PTC-Bench из 240 задач с локальными имитациями API и детерминированной проверкой результата. Сценарии охватывали расписания, покупки, поездки, анализ записей, финансы и поддержку. В 51% основных задач требовалось не менее 50 вызовов API, поэтому тест измерял работу с длинными зависимыми цепочками, а не только выбор правильной функции.
Сравнение охватило открытые и закрытые модели, обычные вызовы инструментов, одноразовый PTC и I-PTC. Для Gemini 3.1 Pro I-PTC выполнил 82,9% задач против 75,4% у исполнения кода через Gemini CLI. На MCP-Universe и MCP-Bench подход также проверяли, но главный вывод опирается на искусственную среду PTC-Bench, поэтому перенос на рабочий набор API стоит измерять отдельно.
Само наличие интерпретатора рядом с моделью не даёт тот же эффект. Если код не может напрямую вызывать инструменты, ответы API всё равно проходят через контекст по одному. Нужна среда, где программа обращается к API сама, а её состояние сохраняется между обращениями модели.
Встроенные среды поставщиков в этих опытах расходовали в 2,5–7,5 раза больше общего объёма токенов, чем I-PTC. Разница возникала из-за повторной передачи служебного контекста и запуска новой среды, а не из-за самих вычислений. Поэтому при выборе платформы нужно проверять не наличие исполнения кода, а сохранение пространства имён, доступ к инструментам из кода и объём повторно отправляемого контекста.
Подход зависит и от способности модели писать многошаговый код. В семействе Qwen3.5 программные интерфейсы начали превосходить обычные вызовы с модели на 4 млрд параметров; меньшие варианты чаще ошибались в программе. Это не универсальная граница, но она показывает, что I-PTC не компенсирует слабое следование инструкциям.
Менять архитектуру имеет смысл для процессов с повторными выборками, объединением данных, продолжениями диалога и временными сбоями. Практическая схема состоит из модели-планировщика, изолированного исполнителя с состоянием и реестра API, который загружает схемы по запросу и хранит проверенные поправки. Для коротких независимых операций обычный вызов функции остаётся проще, а выигрыш I-PTC раскрывается там, где потеря промежуточного состояния уже заставляет агента повторять работу.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
