Як вижити під час компактації: драбина для довготривалих сеансів агентів та процесу компактації.
Як довго сеанси агентів залишаються доступними та послідовними: кеш-хвіст як оренда, п’ять рівнів перед компактацією, делегування як межа пам’яті, витрати на відновлення.
Альпіністи не несуть усе обладнання експедиції на гору; вони залишають його там. Довге підйомне шлях розділяється на табори, кожен з яких заповнюється тим, що потрібно на наступному етапі. Усе, що не потрібне, залишається внизу — у наявності на випадок, якщо групі доведеться повернутися, але ніколи не піднімається вище. Те, що досягає вершини, — це те, що пережило рішення кожного табору щодо того, що залишити позаду.
Вікно контексту поводиться так само. Його ємність фіксована, а маршрут — ні, тож рано чи пізно доводиться щось залишити позаду.
Зберігання запитів вже дає одне правило для пристроїв агентів: ніколи не скасовувати кеш. Зберігайте стабільну частину в актуальному стані та вносіть зміни в кінці. Однак це правило ставиться до сеансу як до статичної фотографії, тоді як сеанси мають часовий вимір. Кожен сеанс з часом старіє. Розмова розширюється, поки вікно не заповниться, і тоді його доводиться скласти.
Згинання скорочує вікно; ця частина є механічною. Ціна є менш очевидною, оскільки процес згинання змушує кеш стати недійсним. За це платять один раз, все, що залишається, переписується, і сесія продовжується. Проте недійсність кешу — це другорядна проблема. Справжньою проблемою є вибір того, що має пройти. Хороша компактизація — це не просто видалення: вона стискає історію у форму, з якої агент може продовжувати роботу. А довга сесія згинається не лише один раз. Вона згинається, працює, згинається знову, і рано чи пізно згинається ще раз.
Це змінює формулювання питання планування. Запитання про те, коли проводити стиснення, менш важливе, ніж запитання про те, що залишається після кількох циклів складання та що вже було втрачено. Час є фактором витрат, оскільки кожне скасування оплачується. Якість стиснення є фактором ідентичності, адже вона визначає, чи залишається сеанс таким самим, як на початку. З обох причин стиснення має бути на вершині ієрархії, а не внизу.
Де накопичується рахунок
Кожен запит ділиться на дві зони оплати. Одна — це префікс, який зберігається з одного циклу в інший. Інша — це хвіст, який постійно зростає.
Префікс містить системні команди, визначення інструментів, контекст стабільного репозиторію та файли правил. Він записується один раз, зберігається в кеші, а потім читається знову за незначну частину початкової ціни. Його розмір залишається незмінним.
Хвіст — це все, що йде далі: діалоги, виклики інструментів, їхні результати, блоки міркувань та відмінності. Він лише розширюється.
Проте саме розширення не є проблемою. Проблемою є багаторазове заряджання. Нове повідомлення не надсилається окремо. Система пересилає відповідний префікс, оплачує штраф за читання з кешу та додаткову плату за запис нового матеріалу, і весь цей хвіст передається під час кожного такого читання. Тож 150 000 токенів хвоста — це не нерухомий обсяг, який просто знаходиться у вікні; за нього знову стягується плата при кожному кроці, незалежно від того, чи потрібен моделі цей обсяг для наступного запитання. Стара історія фактично здається в оренду на весь період сесії.
У вікні обсягом 200 000 токенів більша частина простору вже зайнята. Залежно від системи та кількох інших факторів, кількість справді вільних токенів для роботи може скоротитися до приблизно 7 500–15 000 токенів.
Кеші також закінчують свою дію. Активність оновлює термін їхньої дієздатності, що означає, що перерва може зробити наступну операцію запису «холодною». Час, який людина витрачає на роздуми, є прихованою витратою кешу, про яку ніхто не повідомляє.
Якщо дивитися з цієї точки зору, стиснення накопичених даних також є операцією над кешем. Одноразова оплата за анулювання даних компенсує припинення їхнього подальшого використання. У цьому й полягає вся угода, і існують дешевші способи дії перед тим, як її використовувати.
Драбина з п’яти кроків
Існує п’ять способів протидії зростанню обсягу накопичених даних. Це менше варіантів, ніж сходинки: чим вище підйом, тим більше існуюча історія пошкоджується.
Перший крок: ніколи не генерувати його. Обмежте обсяг вихідних даних інструментом. Інструмент текстового редагування Anthropic підтримує параметр max_characters, а його функція веб-пошуку — параметр max_uses. Codex за замовчуванням обмежує обсяг вихідних даних окремих інструментів приблизно від 10 000 до 16 000 токенів ще до того, як вони потрапляють у розрахунок стиснення. Більш дисциплінованим підходом є видалення середньої частини: залишають початок та кінець, видаляючи середину, оскільки вважається, що те, як почалася команда та де вона закінчилася, має більше значення, ніж те, що було між ними. Недоліком є обрізання перед тим, як з’ясувати, що є важливим, а відсутність відповідного етапу у стек-трейсі гірша, ніж його відсутність зовсім.
Другий крок: збережіть дані. Якщо вся інформація не є необхідною, не зберігайте її. Коли результат роботи інструменту перевищує певний поріг розміру, система записує його на диск та залишає посилання. Повний об’єкт даних зберігається, тоді як актуальний контекст — ні. Це відрізняється від обрізання, оскільки нічого не викидається. Журнал збірки з 500 тисяч рядків може залишатися на диску, тоді як контекст містить лише його шлях, метадані чи індекс для пошуку, а інструмент пошуку чи читання згодом отримує лише необхідну частину даних. Зберігайте об’єкт даних, видаліть спостереження. Це чітко розділяє зберігання від контексту, тож інформація залишається стабільною, не створюючи додаткового навантаження пізніше.
Проблема полягає у тому, що харнес має забезпечувати засоби для його подальшого знаходження. Виведення даних у файл має сенс лише тоді, коли агент може шукати те, що було збережено, читати це та розуміти його зміст; без цього переповнення контексту перетворюється на файлову систему з недоступними даними.
Схожість між різними харнесами є помітною. Claude Code зберігає на диску будь-який результат інструменту, розмір якого перевищує приблизно 100 кбайт, та повертає попередній перегляд та шлях до файлу, а Hermes застосовує таку саму межу у 100 кбайт на результат. Обидва передбачають однакове виняток для інструменту читання, оскільки виведення даних у файл під час читання дає шлях, який агент буде читати знову та знову, без кінця. У такі петлі легко потрапити. Єдиний інструмент, метою якого є повернення контенту, — це той, який ніколи не повинен виводити дані у файл.
Третій етап: не дозволяти доступу ззовні. Передайте завдання підагенту. Озброєний вбудованими інструментами, він може читати файли, аналізувати журнали та оглядати репозиторій, створюючи великий приватний контекст, причому жодна з цих інформацій не потрапляє до записів головного агента. Після виконання завдання його тимчасовий простір видаляється, і лише значення повернення передається далі. Виробники Harness зробили цю функцію однією з найпоширеніших у цьому році.
Існує певний ліміт, адже дослідження є безпечнішим, ніж зміни. Робот, який читає неправильні файли, лише змушує все перезапустити. Робот, який редагує неправильні файли, залишає пошкодження після того, як його контекст зникає, тому важливо, якій моделі довіряють внесення змін. Стародавні армії це ілюструють: розвідники були швидкими, замінними людьми, яких посилали вперед, адже спостереження коштують недорого, а звіт можна перевірити, тоді як справжні рішучі дії доручалися найкращим командирам, оскільки їх неможливо скасувати. Такий самий поділ застосовується і тут. Доручіть розвідку дешевому, замінному контексту, залиште найсильнішу модель для кроку, який змінює світ, та нехай батьківський елемент бере участь у перевірці. Батьківський елемент оплачує відповідь, а не розслідування.
Четвертий етап: замініть його на посилання. Якщо контент вже зберігається надійно — чи то у вигляді файлу, об’єкта, створеного звіту чи результату обробки — розмові потрібен лише посилання на нього. Повторне переглядання означає переход до місця, де знаходиться матеріал, а не його постійне носіння з собою. Інструмент пам’яті Anthropic робить саме це, а OpenAI підтримує подібну функціональність через виклик функцій. Дорогий стан розмови перетворюється на дешеве посилання на надійний стан. Існує одне застереження: економія триває лише тоді, коли базовий контент залишається поза межами „вікна“. Як тільки його знову прочитають, він знову стає активним та негайно починає спричиняти додаткові витрати.
П’ятий етап: видаліть його пізніше. Очистити, стиснути або згорнути. Лише цей етап скасовує те, що вже зберігається у кеші. Одна ітерація витрачається на заміну накопиченої історії на щось менше, з надією, що наступна ітерація зможе розпочатися з цього. Повний запис може залишитися на диску, проте поточний контекст буде іншим.
З цього моменту економіка перетворюється на ставку. Чи перевищує економія на оренді протягом решти сесії вартість переписування історії зараз? Раннє стиснення призводить до втрати корисного кешу, який міг би слугувати для сотень дешевих ітерацій. Пізнє стиснення означає, що оренда вже сплачена за велику кількість історії, протягом якої модель може вже погіршити свою здатність її використовувати. Більшість обговорень щодо довгих сесій починаються з цього питання, але цього робити не варто. П’ять етапів у порядку:
- Ніколи не створювати його: зупиніть зростання даних на початковому етапі.
- Розкрийте це: вийміть об’ємні спостереження та залиште артефакт.
- Залиште його зовні: перенесіть розслідування в інший контекст.
- Вкажіть на нього: залиште дешеву посилання у розмові.
- Видаліть пізніше: стисніть або згорніть, та живіть із втратою.
Найдешевший контекст — це не стиснутий контекст. Це контекст, який ніколи не мав бути там.
Набори інструментів як ставка на те, де оплачувати
Важливо, де знаходиться визначення інструменту. Визначення займають префікс — фіксовану плату, яка записується один раз та зберігається в кеші. Результати займають тил — змінну плату, яку потрібно оплачувати постійно. Тож вибір набору інструментів — це ставка на те, яка зони має покрити витрати на інформацію. Кілька інструментів означають невеликий префікс, але більше необроблених спостережень у тилі; багато інструментів означають додаткові токени префіксу, витрачені для отримання меншої кількості більш структурованих спостережень.
Terminus 2 — це крайній приклад мінімалізму: один безголовий термінал, створений на основі уніксівського принципу, згідно з яким один загальний інструмент може бути складений без обмежень. Codex часто об’єднують з ним, що є лише частково справедливим. Його вбудований префікс зовсім не мініатюрний — там постійно присутні близько 20 інструментів, набір багатоагентних засобів та версії v1/v2. Він уникає надмірностей завдяки відкладенню завантаження: інструменти MCP та конектори індексуються в пошуковій системі та завантажуються лише тоді, коли це необхідно. Codex справді робить ставку на мінімізацію у частині „хвоста“. apply_patch ілюструє це, адже короткий різницевий файл замінює тисячі токенів переписаного файлу, а обмеження на кількість даних, які виводить кожен інструмент, запобігають накопиченню необроблених даних. Обидва підходи призводять до схожих результатів різними шляхами: Terminus 2 зберігає префікс мінімальним, а Codex — частину „хвоста“.
Claude Code та Hermes витрачають більше ресурсів на спеціалізовані інструменти, які повертають структуровані дані замість сирих. Кількість інструментів у каталозі Claude Code перевищує 40, якщо врахувати LSP, режим планування, робочі дерева та cron, а у Hermes — близько 55; вони поділені на набори інструментів для терміналу, файлів, пам’яті, навичок, делегування тощо. Типовим прикладом є використання Grep для пошуку відповідностей замість повернення цілого файлу: це дозволяє заощадити деякі ресурси, уникаючи тисяч токенів непотрібного тексту.
Отже, порівняння має стосуватися не кількості інструментів, а того, чи дозволяє додаткове використання префіксу усунути достатню кількість „хвостового“ росту, щоб відстрочити процес згортання. Це та сама дилема між швидкістю та оптимізацією, але на вищому рівні. Anthropic чітко формулює концепцію відкладеного завантаження: визначення інструментів можна знаходити лише тоді, коли це необхідно, а не включати їх з кожним запитом. Claude Code реалізує це за допомогою механізму ToolSearch, який залишає назви відкладених інструментів видимими та приховує повні схеми до моменту запиту моделі; він автоматично активується, коли визначення інструментів MCP становлять близько 10% вікна контексту. Навіть порядок відсортування обирається для захисту префікса, адже алфавітне сортування зберігає блок визначень ідентичним за розміром між запитами, тому його можна кешувати. Префікс розроблений так, щоб залишатися активним, незалежно від свого розміру.
Ось зберігає свою корисність, але змінюється її роль. Вона не вирішує, чи слід компактувати інформацію. Вона визначає, скільки історії спочатку накопичується. І ця історія не є однорідною. Результати пошуку часто можна переобчислити, але рішення — ні. Шлях до файлу можна відновити, тоді як причина відхилення певного підходу — ні. Чим довше триває сеанс, тим дорожче коштує плутати ці два типи пам’яті.
Делегування як межа пам’яті
Делегування вирізняється тим, що воно позбавляється історії, залишаючи кеш батьківського об’єкта недоторканим, і це має більшу цінність, ніж знижка на виконання завдань. Підагент має власне вікно контексту. Воно може утворити величезний „хвіст“, заповнити вікно, внутрішньо компактуватися, а потім зникнути, при цьому не переписуючи жодного слова з історії батьківського об’єкта.
Необхідно скоригувати поширене припущення. Привабливо уявляти собі розгалуження за однаковою моделлю, при якому дитина успадковує накопичений батьком „хвіст“ разом із його „теплим“ префіксом. Однак більшість перевірених реалізацій не роблять цього. Claude Code, OpenCode, Codex та Hermes кожен створюють окремі контексти робітників, а не копію всього „хвоста“ батька. Деякі з них можуть використовувати робітника з іншої моделі: Codex дозволяє змінити модель під час створення, а Claude Code дає кожному підагенту можливість вибрати між sonnet, opus чи haiku. Це не є універсальним правилом, а у Hermes механізм делегування не має прямого способу зміни моделі. Те, що передається між системами, — це окремий контекст, а не вибір моделі.
Це вказує на щось більше, ніж просте розділення завдань. „Хвіст“ дитинчати можна викинути: він може прочитати сорок файлів, проаналізувати журнали та визначити правила найменування, а весь контекст зникає, коли повертається абзац. Делегування виступає як межа пам’яті. Батьківський елемент призначає завдання та вказує, що йому потрібно, що еквівалентно попередній компресії, адже працівник знає, хто буде читати його результат та яке рішення цей результат має підтримати. Коли підагент повертається, батьківський елемент зазвичай перевіряє результат. Це вимагає кількох кроків, але є розумним рішенням.
Компактування відбувається у зворотному напрямку, після завершення процесу. Воно має узагальнювати інформацію для читача, якого ще немає, щоб уникнути будь-яких запитань, які можуть виникнути далі. Передчасне стиснення має перевагу у вигляді наявності відомого читача. Це призводить до принципу бюджетування: потрібно бюджетувати на те, що повернеться, а не на сам процес. Робот може витратити сотні тисяч токенів, і жоден з них не стане частиною батьківської пам’яті. Однак повернений текст стає частиною пам’яті. Чотириста токенів відповіді потрапляють у „хвіст“ батьківської структури та оплачуються при кожному наступному кроці, тож протягом тривалої сесії необроблена різниця може коштувати більше, ніж дорогий робот, який повертає одне корисне речення. Дослідження є тимчасовим, а відповідь — це історія, і ця відповідь у свою чергу мусить вижити після процедури згортання.
Що надають платформи
Платформа моделі визначає, скільки з цього обладнання має створити сама система.
Anthropic пропонує два типи допомоги, спрямовані на різні проблеми. Перший, clear_tool_uses_20250919, є точним у своїй дії. Коли запит перевищує певний поріг (за замовчуванням 100 тис. токенів вхідного тексту, при цьому зберігаються три останні використання інструментів), він видаляє старі результати роботи інструментів на сервері та замінює їх місцями замінниками. Опція clear_at_least дозволяє розподілити витрати на скасування, вимагаючи очищення мінімальної кількості даних. Другий тип, compact_20260112, є більш ресурсоємним: він здійснює повне узагальнення на стороні сервера, що створює нову версію розмови, а не просто скорочує існуючу.
Claude Code є гарним прикладом для дослідження, адже навіть засіб керування, створений компанією, яка постачає ці примітиви, здається, самостійно координує свій більш важкий варіант /compact на своїй стороні. Підтримка цього функціоналу походить від зусиль спільноти з зворотної інженерії, які сягають одного публічного джерела на GitHub, а не з публічної документації Anthropic. Очищення даних відбувається на сервері, тоді як крок, який визначає, який стан розмови залишиться, координується клієнтом.
OpenAI зосереджується на стисненні даних. Його кінцева точка /v1/responses/compact повертає зашифрований непрозорий блок даних, який клієнт передає назад, не дивлячись усередину, частково для блокування способу введення команд, коли підроблений огляд міг би вплинути на подальші кроки. Тут немає нічого, що відповідало б точному очищенню даних, тому Codex мусить самостійно керувати розміром результату роботи інструменту, а під обома цими шляхами є примітивний варіант виходу з ситуації: якщо вікно все одно переповнюється, Codex видаляє найстаріший елемент історії та пробує знову.
DeepSeek пропонує значно менші можливості для керування контекстом. Його кешування префіксів на стороні сервера знижує витрати, але не вирішує проблеми фіксованого вікна, тому будь-який інструмент, що використовує його, повинен мати повний цикл стиснення. Офіційний інструмент DeepSeek створює такий цикл, не пошкоджуючи при цьому жодних даних: події, які були зафіксовані, залишаються в журналі та доступні для використання. Одна з інтерфейсів сторонніх терміналів, яку було перевірено, пропускає цей етап та ніколи не здійснює проактивного стиснення.
Важливо не якість окремого кінцевого пункту стиснення API, а те, хто відповідає за прийняття рішення про те, що залишити. Hermes є показовим прикладом крайнього випадку, оскільки він використовує кількох постачальників та не може припускати, що хтось із них пропонує потрібні інструменти. Тому він використовує власний компресор з боку клієнта як базовий варіант, застосовуючи два пороги: 50% згідно з власним підрахунком токенів та 85% за результатами більш грубої перевірки на рівні шлюзу, яка виявляє сеанси, що зростають між операціями без спостереження. Як тільки активний постачальник пропонує кращий варіант, він відкладає використання власного компресора.
Це правильний загальний підхід до проектування. За замовчуванням інструмент має контролювати процес стиснення, оскільки він має інформацію, яку сервер може ніколи не побачити, та передавати її платформі, коли це стає можливим. Незалежно від того, хто виконує процедуру стиснення, питання залишається тим самим: що можна допустити до видалення?
Повернення до табору
Усе вищесказане передбачало, що сесія ніколи не припиняється. Але сесії все ж припиняються: ноутбуки закриваються, процеси завершуються, завдання CI закінчуються, і хтось вводить /resume, сподіваючись продовжити з того місця, де все залишилося.
Це найпростіша команда, яка забезпечує найдорожче відновлення сесії. Вона складається з семи символів, включаючи слеш, схожа на /help або /clear, без аргументів, без підтвердження та без жодних перешкод. У ній немає нічого, що б вказувало на її вартість, а інтерфейс налаштований так, щоб повернення здавалося безкоштовним.
Розмову можна відновити, але кеш — ні. Відновлена сесія — це не процес, який було призупинено. Система переграє запис з диска та відновлює історію повідомлень, тож діалог повертається зі зберігання, тоді як інші дані — ні. Це призводить до двох різних витрат на відновлення.
Перше — це гроші. Буфер префіксів Anthropic за замовчуванням зберігається протягом п’яти хвилин, або години, якщо було придбано більший об’єм зберігання, і його оновлює лише активність. Стан «відпочинку» — це крайній випадок бездіяльності, коли зовсім немає жодних процесів. Префікс, який раніше коштував дешево, повертається у стан повної недієздатності, і наступний раз доводиться платити повну ціну за його відновлення. Найдорожчим варіантом є відновлення сесії, яка тривала кілька днів, що є вагомою причиною для обережного керування сесіями.
Другим фактором є інформація. Коли обсяг транскрипту перевищує розмір доступного вікна, системі може знадобитися його скласти перед тим, як відбудеться будь-яка нова дія. Це особливо ризиковане складання, оскільки стиснення відбувається ще до того, як хтось зможе знову визначити, що є важливим. Обмеження, яке пояснює повернення на попередній варіант, може бути присутнім у транскрипті, але відсутнім у стиснутій версії. Агент продовжує роботу з меншим вікном та правдоподібною історією, яка не обов’язково є тією самою, що робила попередні рішення обґрунтованими.
Усе, що виживає після згортання, виживає також після відновлення, і саме це є підставою для стійкого стану. Правила кореня проєкту можна знову завантажити з диска, файли можна перечитати, список справ можна відновити, а створений журнал збірки можна зберегти та посилатися на нього. Рішення, яке існує лише в рамках розмови, не має зовнішнього джерела. Якщо воно існувало лише тому, що його записано, його потрібно знову створювати під час повернення, а якщо згортання його видало, воно може назавжди зникнути.
Отже, ранжування стосується як стійкості, так і вартості. Від найстійкіших до найбільш крихких: стан, який можна відновити, стійкий зовнішній стан, актуальний стан розмови, а потім тимчасові спостереження. Чим нижче позиція елемента, тим більше він схильний до згортання.
Два способи, якими згортання може зазнати невдачі
Процес згортання може зазнати невдачі двома способами. Очевидний варіант легко помітити: процес стиснення працює, потім величезний об’єм даних миттєво заповнює вікно, пристрій знову стискає дані, з’являється той самий об’єм даних, і цикл повторюється, наче намагання вичерпати воду з човна, поки в ньому свердлять отвір. Claude Code припиняє спроби замість того, щоб безкінечно використовувати ресурси, маючи вбудовану логіку для виявлення того, що він застряг і не просувається вперед. Це правильна поведінка, але сам цикл є сигналом того, що використовується неправильний підхід. Ідеально, якби агент відступив та спробував інший метод замість того, щоб знову використовувати той самий інструмент. Якщо один великий за розміром файл постійно змушує виконувати процес стиснення, зниження порогового значення не є рішенням. Рішенням буде читання обмеженого діапазону рядків, пошук у вузьких межах, спрямування даних на стійкий формат виводу чи передача файлу підагенту, чиє вікно можна втратити. Щоразу, коли починається налаштування стиснення, запитайте, чи полягає рішення на рівні, вищому на три етапи, чи у зовсім іншому підході.
Повільна несправність є більш тонкою. Під час стиснення втрачається інформація, а тривалі сеанси ніколи не стискаються лише один раз. Вони стискаються, працюють, знову стискаються, працюють, ще раз стискаються: підсумки на підсумках.
Повторні стиснення
Перший етап аналізу може бути відмінним, але все одно призвести до поганого результату на третьому етапі. Другий агент-узагальнювач ніколи не бачить початкову інформацію, лише представлення, обране першим агентом. Третій агент не бачить нічого з цього, лише висновок другого агента щодо висновку першого. Подивіться, як це впливає на факти та причини. Перший етап міг би зберегти інформацію про те, що «було обрано підхід B». Другий етап міг би зберегти інформацію про те, що «B — це поточна реалізація». Третій етап міг би зберегти інформацію про те, що «реалізація використовує B». Кожен з цих тверджень є правдивим, але причина відхилення підходу A зникає. Система не втратила рішення, але втратила те, що робило це рішення зрозумілим, і саме це є наслідком багаторазового аналізу.
Що має залишитися
У різних системах структуровані узагальнення збігаються приблизно з однаковими категоріями:
- Мета: що саме потрібно досягти?
- Стан: що було дізнано або змінено?
- Робота та завдання: що вже зроблено та що залишилося?
- Відкриті питання: які запитання все ще залишаються нерозв’язаними, обмеженими або перебувають на розгляді?
Мітки відрізняються у різних інструментах, але структура залишається однаковою, що свідчить про те, що це найменший практичний стан, який сесія повинна зберігати. Деякі інструменти також додають кроки відновлення файлів, щоб можна було знову завантажити набір даних після збереження.
Пов’язана література
- Sandboxing a Coding Agent and Keeping Its Context Window Lean — Додайте сандбокс у вигляді ременя безпеки або пухирчастої плівки до агента та керуйте контекстом за допомогою файлів-заповнювачів, шаблонів, компактування та ін’єкції даних у кінці процесу, що сприяє ефективному використанню пам’яті.