Вайбкодинг · 9 октября 2026 г.
agent-friendly APIs: как масштабировать API для AI‑агентов
The New Stack объясняет, почему сессионные реализации теряют контекст при росте нагрузки и предлагает разделить стек на gateway, memory и tools, а данные хранить в Oracle AI Database Free для транзакционной согласованности.
Почему сессионный подход не масштабируется
The New Stack объясняет, почему agent‑friendly APIs (API, дружелюбные к агентам) теряют контекст при росте нагрузки: классическая сессионная реализация держит состояние в памяти процесса, и это работает до тех пор, пока все обращения одного диалога попадают на одну реплику.
Авторы выделяют четыре свойства агентного трафика, которые создают проблему: разговоры длинные и stateful, но каждое обращение — отдельный HTTP‑запрос; вызовы инструментов фан-аутятся непредсказуемо; обвязка агента часто повторяет запросы; нагрузка — machine‑paced и взрывная из‑за отсутствия «think time». При распределении по репликам локальная сессия теряется, а API может продолжать возвращать HTTP 200, но отвечать без нужного контекста.
Решение и результаты POC
В POC предложили декомпозировать стек по доменам отказа и вынести данные в общее хранилище. Четыре компонента — gateway (OpenAI‑совместимый шлюз, не хранящий историю), memory (хранение сессии и аудит вызовов), tools (выполнение инструментов отдельно, со своими бюджетами) и общий слой данных на Oracle AI Database Free — дают возможность задавать отдельные бюджеты конкурентности и таймауты для разных путей запросов.
В тесте прогоняли 200 разговоров по 4 хода (800 обращений). В «монолитной» развёртке на трёх машинах при равномерном распределении реплик потеря контекста составила 75% (600 случаев). В декомпозированной архитектуре при тех же нагрузках потерь не зафиксировали. Для контроля доступа к ресурсам используют семафоры: примерные конфиgurации — общий пул 32 слота, разделённый на 24 для обычного чата и 8 для запросов с инструментами.
Авторы объясняют выбор единой базы данных: хранение истории, аудита, эмбеддингов и леджера идемпотентности в одном движке позволяет делать связанные записи в одной транзакции и сериализовать конкурентные обновления (SELECT … FOR UPDATE, версия строки), вместо сложной координации между Postgres, векторным стором и Redis.
Подробности архитектуры, примеры кода и результаты POC — в оригинальной статье The New Stack: https://thenewstack.io/building-agent-friendly-apis/