Агент заполняет 80% окна контекста. Срабатывает сжатие и удаляет самые старые ходы. Через десять минут он повторно читает уже прочитанный файл и снова задаёт вопрос, на который уже получил ответ.
Порог знал, что место закончилось. Он ничего не знал о том, что безопасно потерять.
Это третья заметка из серии о проектировании агентов для длительных задач, появившейся после внимательного изучения BEACON (Чжэцзянский университет, arXiv:2605.06078). Первая была об обнаружении застоя, вторая — о проектировании контрольных точек.
Начнём с нашей реализации
Orkas — настольный клиент с несколькими агентами. Длительные задачи здесь обычны, поэтому сжатие требуется ежедневно. Наша реализация срабатывает по порогу токенов: контекст сжимается примерно при заполнении 80% окна. Пока мы не начали писать эту заметку, никто из нас не видел в этом проблемы.
На практике распространены примерно три варианта границы: доля окна, число ходов или сводка старого содержимого, написанная моделью. Наш вариант — первый.
Первые два вообще не смотрят на содержимое. Третий смотрит, но полностью отдаёт вопрос о важности на откуп модели.
Все три отвечают на вопрос когда мне придётся что-то выбросить. А настоящий вопрос — что можно безопасно выбросить. Отсечение по порогу удаляет самое старое содержимое, а не наименее важное.
Граница по контрольным точкам и лежащее в её основе допущение
Контрольные точки из предыдущей заметки могли бы дать лучшую границу, чем любой из трёх вариантов. Но здесь есть ловушка, которую предыдущая заметка описала слишком гладко.
В BEACON есть допущение под названием «марковское свойство контрольных точек». Проще говоря, после достижения контрольной точки дальнейшее зависит только от оставшихся подцелей, а не от того, как вы сюда пришли. Когда ключ у вас, важно, какую дверь вы откроете, а не как вы его нашли.
Это звучит как разрешение сжать контекст: после контрольной точки предшествующий отрезок можно свернуть.
Но это допущение, а не факт. В статье стоит ≈, а не =, и авторы обсуждают случаи его нарушения.
Достаточно для обучения, недостаточно для сжатия
Одно допущение, два применения и разница в строгости на порядок.
При обучении достаточно, чтобы оно выполнялось статистически. Если несколько десятков из нескольких тысяч траекторий его нарушают, смещение усредняется. При обучении также используется страховочный сигнал на уровне всей траектории; если убрать этот слой в абляционном эксперименте, результат ALFWorld падает с 91,4 до 23,4 — намного ниже, чем вообще без вмешательства.
При сжатии оно должно выполняться в каждом отдельном случае, для конкретного запуска перед вами. Достаточно один раз удалить не то — и задача провалена. Усреднять не по чему.
Поэтому опора статьи на это допущение не означает, что его можно перенести в сжатие. Два применения предъявляют к нему разные требования.
Четыре случая, в которых оно нарушается
Мы используем их как контрольный список при оценке политики сжатия.
1. Неявные знания, накопленные по пути. В одном из ранних шагов выясняется, что конкретный API возвращает временные метки в UTC. Этот факт не относится ни к одной контрольной точке, но нужен каждому последующему шагу.
2. Уже израсходованные ресурсы. Бюджет токенов, квота вызовов, оставшееся время. Контрольная точка не записывает я потратил 60% бюджета, но именно это число определяет, можно ли ещё позволить себе повторную попытку.
3. Побочные эффекты, зависящие от пройденного пути. Контрольная точка гласит: рефакторинг завершён. Как только начинается отладка, нужно знать, какие пять файлов фактически изменены.
4. Сама контрольная точка описана недостаточно точно. Это худший из четырёх случаев. В статье контрольная точка — полное состояние среды: ключ у вас есть или его нет, без двусмысленности. Шаг плана — одно предложение на естественном языке. «Завершить очистку данных» и близко не описывает всё, что произошло на этом отрезке.
Что сохранять вместо этого
Не сохраняйте только сводку. Её пишет модель и на глаз решает, что было важно.
Сохраняйте фиксированный набор полей, выбранных человеком. Как минимум четыре:
- Текущее состояние рабочей папки — какие файлы изменены и к какому состоянию приведены.
- Оставшийся бюджет — токены, квота вызовов, время.
- Установленные факты — факт про UTC и всё подобное, что повлияет на дальнейшие решения.
- Нерешённые вопросы — то, что однажды заблокировало работу, было обойдено и может возникнуть снова.
Сопоставьте их с четырьмя случаями сбоев выше: они соответствуют друг другу один к одному. Это соответствие — простейший способ оценить достаточность политики сжатия.
Половина этого почти бесплатна. Как описано в предыдущей заметке, приложение уже записывает детерминированные факты после каждого вызова инструмента: действительно ли переписан файл, действительно ли выполнена команда. Эти данные собирались для проверки контрольных точек, но они и есть снимок рабочей папки, поэтому при сжатии их можно перенести напрямую, не прося модель снова их обобщать.
Сложнее с двумя другими пунктами. Установленные факты и нерешённые вопросы сейчас существуют лишь тогда, когда модель их записывает, поэтому они и становятся первыми жертвами сжатия.
Это можно измерить, а не обсуждать
Если после сжатия агент повторно читает файл, сведения о котором были удалены, или снова задаёт уже отвеченный вопрос, допущение нарушилось на этой задаче — и доказательство перед вами.
Измерение простое: найдите пересечение путей файлов, прочитанных после точки сжатия, с теми, что были записаны до неё.
С этим числом вопрос, какие типы задач можно сжимать агрессивно, а какие нельзя, превращается в запрос к данным, а не спор об архитектуре. Это тот же подход, что в первой заметке серии: сначала измерить, затем менять.
Где нужны оговорки
Ничего из этого ещё не выпущено. Мы на этапе проектирования и добавления измерений.
Какие поля сохранять и с какой детализацией, должны показать данные о том, что действительно приходится получать повторно. Решить сейчас — хороший способ решить неверно.
И это лишь один из нескольких подходов. Граница сжатия и определение полей в продукте другого типа могут выглядеть совершенно иначе. Список из четырёх случаев переносим; конкретный ответ — нет.
Следующая, заключительная заметка серии посвящена самоанализу: почему извлечённые агентом уроки раз за разом оказываются общими фразами вроде «быть осторожнее» и что действительно удивляет в том, какие данные входят и не входят в его входные материалы.