Как API агентов OpenAI меняет экономику работы с ИИ

API Agents от OpenAI предназначена для запуска облачных агентов в течение длительных сессий, оснащенных инструментами, средами тестирования, файлами, механизмами обработки контекста и субагентами, работающими параллельно. Агент может изучить проблему, запустить код, передать задачу другим, сохранить промежуточные результаты и продолжать работу до завершения задания.

Это меняет не только способ создания агентов разработчиками, но и то, как компании должны оценивать их стоимость.

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

Запрос больше не является единицей работы

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

API Agents предназначен для иного типа работы. Агент получает задачу и сам решает, как ее выполнить. Например, вы можете попросить его изучить рост количества ошибок типа 5xx:

Выясните, почему за последние 30 минут у service-api наблюдается необычный рост ошибок, и предложите безопасные способы их устранения.

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

Пользователь видит один запрос. Система выполнила весь рабочий процесс.

Практическое руководство OpenAI по созданию агентов называет это «запуском»: цикл, который продолжается до тех пор, пока агент не завершит задачу, не выдаст окончательный результат, не столкнётся с ошибкой или не достигнет установленного лимита. Стоимость накапливается внутри этого цикла.

Во время выполнения скрывается дополнительная стоимость

Токены являются частью счёта. Это просто та часть, которую легче всего увидеть.

Вернёмся к инциденту в производстве. Сначала агент загружает последние показатели ошибок из инструмента мониторинга, затем читает историю развертывания, после чего ищет записи в журналах. Каждый из этих запросов имеет свою цену, время задержки, набор разрешений и собственные способы сбоя.

Затем инструмент для логирования возвращает 500 записей. Это кажется полезным, пока вы не узнаете, что происходит дальше. Эти записи необходимо переместить, обработать и включить в контекст модели. Большинство из них несущественны, и модель тратит время на обработку лишней информации, прежде чем находит пять событий, объясняющих инцидент.

Следовательно, проектирование инструмента — это проектирование затрат. Инструмент поиска, возвращающий краткое структурированное резюме, может быть дешевле и надежнее того, который показывает все соответствующие записи. Ответ API — это поиск инструментов в сочетании с программным вызовом инструментов, что позволяет отображать определения инструментов только по мере необходимости и фильтровать или объединять результаты перед их передачей модели.

Та же логика применяется и к выполнению в среде песочницы. Диагностический скрипт потребляет процессорные ресурсы, память, место на диске, время установки пакетов, а также, возможно, сетевой трафик. Если он генерирует отчет или набор доказательств, эти файлы необходимо хранить, индексировать, анализировать или сохранять.

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

Небольшой пример SDK агента показывает, где проходит граница выполнения:

from agents import Agent, Runner, function_tool
@function_tool
def get_error_rate(service: str, minutes: int = 30) -> str:
    """Return the recent error rate for a service."""
    return f"{service}: 8.4% errors over {minutes} minutes"
investigator = Agent(
    name="Incident investigator",
    instructions=(
        "Investigate the incident, use evidence, and recommend "
        "the safest next action. Do not change production state."
    ),
    tools=[get_error_rate],
)
result = Runner.run_sync(
    investigator,
    "Investigate the elevated 5xx rate in service-api."
)

Сама функция крайне проста. Однако экономические аспекты здесь гораздо сложнее. Всё это зависит от агента: будет ли он вызван, вызван во второй раз, как будут считываться его результаты, и потребуется ли дополнительный инструмент или одобрение человека.

Надежность, контроль и приемлемость определяют успех

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

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

Для пользователя кажется, что агент завершил задачу. С экономической точки зрения задача также включала неудачные попытки, дополнительные обработки модели, больше вызовов инструментов и больше времени, затраченного на её выполнение.

Повторные попытки не всегда являются пустой тратой времени. Повторная попытка, позволяющая преодолеть временную неисправность, может стать тем фактором, который делает агента надежным. Проблема возникает при суммировании всех этих попыток в один общий показатель успеха.

Параллельные агенты меняют время на затраты

API может распределять сложные задачи между субагентами, работающими одновременно. При расследовании инцидента одному специалисту могут передаваться данные о истории развертывания, второму — информация об ошибках приложения, а третьему — изменениях в зависимостях, причем координатор объединяет полученные результаты.

Время выполнения может сократиться, поскольку все операции происходят одновременно. Однако общая стоимость может увеличиться, так как теперь придется оплачивать несколько отдельных контекстов моделей, множество цепочек вызовов инструментов, процесс координации, этап синтеза, а также, возможно, двукратное обработание одних и тех же данных.

Вот почему многопроцессорные системы напоминают распределённые системы с языковыми моделями в их составе. Координатор выполняет функции планировщика, специалисты — рабочих процессов, внешние инструменты — сервисов, а файлы и базы данных становятся общим состоянием. Появляются характерные проблемы: частичные сбои, повторные попытки, несогласованность состояния, дублирование работы, ограничения на одновременность выполнения задач и неясность при распределении затрат. Увеличение количества агентов автоматически не приводит к улучшению качества принятия решений. Параллелизм должен быть оправдан структурой задачи и ценностью времени.

Принятие результата — это финишная черта

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

cost per accepted task =
    total execution cost / tasks accepted without rework

Если агент отвечает за десять секунд, а человек затем тратит десять минут на решение проблемы, то ответ за десять секунд не является самым экономичным решением. Это лишь самая дешевая попытка.

То, что человек проверяет результат, не означает, что автоматизация провалилась. Для работ с высоким уровнем риска именно утверждение человеком может сделать автоматизацию вообще приемлемой. Вам нужны минимальные усилия со стороны человека, при которых сохраняется реальный человеческий контроль.

SDK предоставляет механизмы контроля для ввода данных, вывода результатов и работы с инструментами, причем его документация разделяет проверки на уровне агента и на уровне инструментов: в сценариях использования деlegeированных специалистов могут потребоваться проверки отдельных функций инструментов и операций MCP. Механизмы контроля требуют усилий и иногда дополнительных вызовов моделей. Они также помогают избежать гораздо более серьезных последствий в виде неправильных действий, утечки данных, нарушений политик или проблем с регулированием. Результат работы считается завершенной только после проверки качества и соответствующего уровня человеческого контроля.

От отслеживания до бизнес-ценности

Каждый новый инструмент расширяет возможности агента. Он также увеличивает объем прав доступа системы, задержки в работе, возможные сценарии сбоев и потребности в управлении.

API поддерживает пользовательские функции, встроенные инструменты и серверы MCP. Стандарт MCP унифицирует способ подключения приложений ИИ к внешним инструментам, ресурсам и запросам. Это снижает сложность интеграции, но не делает удаленные инструменты автоматически надежными. В спецификации MCP предупреждается, что описания инструментов и аннотации от ненадежных серверов не следует автоматически считать достоверными, и рекомендуется видимое вызов инструментов и утверждение операций человеком. Удаленная авторизация порождает дополнительные проблемы, такие как проверка аудитории токена, безопасное хранение токенов, использование PKCE и предотвращение атак типа confused-deputy. Каждая добавляемая функциональность создает новые границы в области авторизации, аудита и управления.

Логи являются учетными данными

Итоговый ответ почти ничего не говорит о том, как к нему было придумано путь. Невозможно узнать, какие инструменты использовались, сколько из них сработало, не вышел ли из строя какой-либо подагент, или что побудило вовлечь определённого человека.

SDK поставляется с системой отслеживания, охватывающей генерации, вызовы инструментов, передачу задач, ограничения и пользовательские события. Отслеживание обычно используется в качестве средства отладки, но оно также является системой учёта. С помощью отслеживания можно выяснить, что именно один инструмент вызывает большую задержку, что рабочий процесс постоянно повторяет один и тот же поиск, или что определённый выбор модели приводит к более высокому уровню принятия решений при меньшем количестве попыток. Без отслеживания команды оптимизируют средние показатели; с его помощью они могут оптимизировать отдельные этапы рабочего процесса.

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

Стратегическое решение

Организации не должны начинать с вопроса о том, как сделать агента дешевле за один вызов. Сначала следует задать более сложный вопрос:

Способен ли этот агент надежно справляться с таким типом работы так, чтобы общая стоимость оказалась ниже, чем стоимость текущего процесса?

Для этого необходима честная база для оценки текущего процесса, включающая время работы сотрудников, ожидание в очередях, многократную передачу задач, инфраструктуру, ошибки и необходимость их исправления, упущенные возможности и усилия по соблюдению требований. Агент, стоимость которого составляет 2 доллара за принятую задачу, может стать отличной инвестицией, если существующий процесс обходится в 20 долларов. Агент, стоимость которого составляет 0,10 доллара за попытку, может оказаться неэффективным, если только половина его результатов принимается, а каждая неудача требует ручного устранения.

Разумный план оптимизации начинается с самой простой системы, способной выполнить задачу. Используйте более простые модели для маршрутизации, фильтрации или простой верификации, а переходите к более мощным моделям тогда, когда требуется более глубокое анализирование. Обеспечивайте, чтобы инструменты возвращали компактные, структурированные результаты. Параллелизуйте только независимые задачи. Проверяйте последующие действия. Сохраняйте достаточно доказательств для анализа и восстановления ситуации.

SDK оправдывает себя тогда, когда сама среда выполнения должна обрабатывать очереди действий, инструменты, сессии, передачу контроля, ограничения и координацию между агентами. API Responses остается подходящим вариантом, когда команда предпочитает самостоятельно управлять циклом выполнения и обработкой состояния. Этот выбор имеет архитектурные последствия, а также финансовые.

Оценивайте работу, а не слова

API Agents облегчает создание агентов, которые могут работать с различными инструментами, средами, сессиями и подагентами, в то время как SDK предоставляет примитивы на уровне приложения для их координации, защиты с помощью ограничений и анализа через трейсы. Вместе они указывают на иной подход к рассмотрению экономики искусственного интеллекта.

Полученная заявка является лишь точкой входа, а не единицей учета. Единицей учета является завершенная задача, которую можно считать правильно выполненной, восстановить в случае ошибки, проверить после завершения и обосновать затраты на нее. Ценообразование по токенам по-прежнему удобно как отдельная статья расходов. Все остальное — инструменты, вычислительные ресурсы, хранилище, попытки повторной обработки, задержки, безопасность и участие человека — указывается в других разделах счета-фактуры.

Лучшие системы агентов — это не те, которые генерируют наименьшее количество токенов. Это те, которые выполняют наиболее ценную работу при разумной общей стоимости.

Связанные материалы

• Создание систем RAG, способных работать в производственных условиях: от ввода данных до возможности наблюдения за их работой — от разбиения данных на чанки и гибридного поиска до переранжирования результатов, контроля доступа, использования наборов для оценки и отслеживания действий: слои, отделяющие демо-версию системы RAG от полноценной производственной системы.
• Расчеты на основе иерархической структуры документов вместо поиска векторов — PageIndex создает иерархический индекс, позволяющий большой языковой модели навигировать по нему, избегая необходимости разбиения данных на чанки и использования векторных представлений. Принцип работы, результаты тестирования на FinanceBench и ситуации, когда его следует применять.

GPT-6 Astra для разработчиков: использование на компьютере, ценообразование и изменения в API — что может делать GPT-6 Astra помимо чатов, как вызовы инструментов влияют на код API и как он сравнивается с Claude и Gemini при подготовке к работе в сфере искусственного интеллекта.