Як 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 пропонує механізми контролю для вхідних та вихідних даних, а також інструментів, причому його документація розділяє перевірки на рівні агента та на рівні інструментів: у сценаріях використання делегованих спеціалістів можуть знадобитися перевірки окремих функцій-інструментів та операцій 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 під час підготовки до ролей у сфері штучного інтелекту.