Разработчик вынес агента из OpenWebUI после запроса на 1,67 млн токенов

Если ваш агент читает большой файл, его содержимое может отправляться модели снова при каждом следующем сообщении. Именно так внутренний ассистент небольшой команды на OpenWebUI дошёл до запроса на 1 674 813 токенов и отказа API. Автор опубликованного на Habr разбора сначала чистил историю фильтром, а затем вынес выполнение задач в отдельный сервис. Практический урок: прежде чем увеличивать контекстное окно, выясните, какие данные повторно уходят модели и какой компонент хранит состояние разговора.

Один файл остаётся в разговоре надолго

По данным автора, один вызов read_file вернул 66 871 символ. Одиннадцать вызовов инструментов дали почти 130 тысяч символов — примерно 32 тысячи токенов по его оценке. Эти результаты продолжали ездить вместе с историей. Агент запрашивал новые проверки, контекст рос, пользователь в итоге отменял задачу.

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

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

Синтетический тест выглядел убедительно: примерный объём сократился с 3637 до 103 токенов. Однако суточные логи показали другую картину: за 128 срабатываний фильтр удалил всего два сообщения с ролью tool. Значительная часть мусора сохранялась внутри обычного текста ответов assistant, включая блоки отображения инструментов. Пришлось чистить и их.

Память агента переехала в отдельный сервис

Суммаризация тоже упёрлась в размер входа. По отчёту автора, запросы на сжатие достигали 161–170 тысяч токенов при лимите выбранной модели в 128 тысяч. Механизм отказывал на самых длинных разговорах, где был особенно нужен.

Был и таймаут при обращении из фильтра к собственному API OpenWebUI в конфигурации с одним воркером. Автор связал его с обработкой вложенного запроса и заменил этот путь прямым обращением к шлюзу. Это наблюдение конкретной установки; переносить объяснение на любую одноворкерную конфигурацию без диагностики не стоит.

К июлю автор изменил архитектуру. OpenWebUI сохранила пользователей, загрузку файлов и отображение ответов. Pipe-функция стала передавать последнее сообщение, системные правила и вложения во внешний Agent Runtime. Состояние разговора теперь хранит сам исполнитель, использующий Agents SDK или Codex SDK.

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

Потоковый ответ пришлось проверять по событиям

При переходе на Responses API обнаружилась ещё одна ловушка. В промежуточных событиях потока вызов инструмента присутствовал, а в финальном объекте output оказывался пустым. Установленная версия SDK брала результат хода из финального объекта, и агент повторял вызовы до исчерпания лимита шагов.

Отдельный пробник, собиравший завершённые элементы из потока, позволил продолжить сценарий. Но место потери данных автор не установил: сравнения потока до и после прокси не было. Приписывать проблему самому API по этому кейсу нельзя.

После обновления зависимостей автор сообщил о шести успешных API-сценариях без скрытого отката на Chat Completions. При этом браузерная проверка, длительная параллельная нагрузка и часть сценариев восстановления состояния остались за пределами приёмки.

Для своей системы стоит повторить три проверки: разобрать реальную историю запросов, испытать суммаризатор на максимальном входе и подтвердить по логам фактический протокол. Этот кейс показывает, сколько ошибок скрывается за формально успешным ответом агента.