Длинная сессия агента деградирует не в момент переполнения окна. Сначала падает точность извлечения: инструкции, факты и ограничения тонут в середине истории. Затем растут KV-cache, задержка и стоимость каждого следующего шага. Лимит в 128k токенов — не архитектура памяти, а дорогой буфер. Рабочая схема: короткое оперативное окно, журнал решений, иерархические summary-checkpoint’ы и адресный retrieval по идентификаторам задач. Для каждого фрагмента нужны TTL, приоритет, источник и причина попадания в контекст. Метрики контроля: доля использованных фактов, token-to-action ratio, latency p95, размер KV-cache и число повторно загружаемых токенов. Экономика проста: стоимость шага = входные токены + выходные токены + память под KV-cache + время GPU. В облаке длинная история превращается в постоянную оплату чужой VRAM и скрытую зависимость от тарифов. На собственном сервере можно зафиксировать модель, tokenizer и runtime, а затем считать предельную стоимость токена по ваттам и амортизации железа. Контекст также является носителем PII и служебных полномочий. Санитизация, редактирование и контроль доступа должны происходить до сборки prompt, а не после аварии. Проектируем память агента как управляемый ресурс, а не как бесконечную строку: https://run-as-daemon.dev/? utm_source=telegram&utm_medium=smm&utm_campaign=rad_ru&utm_content=upravlenie-kontekstnym-oknom-v-dlin
