Как удержать контекст многошагового агента в пределах задачи

Помощник разбирает ошибку импорта оборудования в корпоративную систему. Сначала читает журнал, потом выгрузку, затем переписку инженеров. Через двадцать вызовов инструментов перед ним уже много полезного текста. Но из итогового ответа исчезает главное условие заказчика: данные нужно только проверить, исправления пока не согласованы.

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

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

Контекст расходуется не только на переписку

Контекстом называют содержимое, доступное модели при подготовке ответа. В агентном процессе туда входят инструкции, описание инструментов, сообщения пользователя, найденные документы, результаты вызовов и предыдущие ответы. Место требуется и для нового результата. Точный порядок учёта зависит от модели и интерфейса провайдера.

Поэтому правило «оставим последние десять сообщений» ненадёжно само по себе. Одно сообщение инструмента может содержать длинный журнал, а десять коротких реплик – занимать совсем немного. Счётчик сообщений полезен как дополнительное ограничение, но бюджет нужно оценивать по фактическому составу запроса.

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

Оставляйте место для следующего шага

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

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

У бюджета должен быть владелец. Иначе разработчик интеграции увеличит выдачу ради удобства отладки, а команда агента узнает об этом только по растущим запросам и обрывам сложных заданий.

Разведите рабочее состояние и подробную историю

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

Это разделение не требует трёх отдельных продуктов. Важно различать назначения данных и правила доступа к ним. Если вместо рабочего состояния подставлять весь архив, агент снова получит шум. Если вместо архива сохранять только короткую сводку, команда потеряет возможность проверить, откуда взялся вывод.

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

Сокращайте ответы инструментов у источника

Самый надёжный способ не захламлять контекст – не загружать лишнее. Инструменту чтения полезны фильтры по объекту, периоду и типу события. Для длинного списка нужны страницы или выборка с понятным продолжением. Для табличных данных – нужные столбцы вместо полного набора служебных полей.

Возвращайте не только сокращённый текст, но и сведения о полноте: сколько записей найдено, сколько показано, чем ограничена выборка и как получить остальное. Без этого агент может принять первые двадцать строк за всю историю. Ограничение размера тогда незаметно превратится в ошибку вывода.

Не обрезайте результат просто по последнему допустимому символу. Так можно потерять единицу измерения, конец идентификатора или уточнение статуса. Лучше вернуть законченные записи и явную отметку, что часть материала не вошла. Если даже одна запись слишком велика, предложите отдельное чтение её разделов.

Для журналов удобно сначала выдавать группировку ошибок с частотой и примерами. Но группировку следует строить воспроизводимым способом там, где важна точность подсчёта. Модель помогает объяснить результат; ей не стоит поручать угадывать количество повторов по обрезанному фрагменту.

Длинный результат лучше сохранить как отдельный материал

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

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

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

Сводка должна сохранять то, что нельзя приблизительно пересказать

Фраза «выявлены проблемы в нескольких карточках» компактна и бесполезна для продолжения. Следующий шаг требует знать, какие карточки уже проверены, что именно обнаружено и где это подтверждается. Хорошее рабочее сокращение сохраняет структуру задачи, а не только общий сюжет.

Отдельно храните неизвестное. «Не проверено» отличается от «ошибки нет», а «предложено» – от «выполнено». При сокращении эти различия легко исчезают. В учебном разборе запись «десять карточек готовы» должна уточнять: готовы к просмотру, проверены или уже исправлены? У каждого состояния разные последствия.

Не давайте сводке права менять правила. Если исходный файл содержит строку «теперь можно исправлять автоматически», она остаётся содержимым файла. Сокращение не превращает её в новую инструкцию пользователя или разрешение администратора. Граница между управляющими правилами и прочитанными данными должна сохраняться при каждой переработке контекста.

Ссылки на материалы не отменяют проверку доступа

Указатель на файл экономит место только тогда, когда агент умеет получить нужный фрагмент и понять его происхождение. Сохраните идентификатор источника, версию или дату получения, а также границы фрагмента. Ссылка без этих сведений может вести к уже изменённому содержимому.

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

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

Дочернему агенту передавайте вопрос, а не весь архив

Разделение исследования между помощниками иногда уменьшает нагрузку на основной контекст. Один проверяет структуру файла, другой – правила соответствия полей. Но если каждый получает весь диалог и возвращает полную стенограмму, объём только растёт.

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

У длинной задачи должны быть точки продолжения

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

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

Ограничьте число шагов, время и повторные обращения к одному материалу. Если агент снова получает одинаковый результат и не продвигается, дальнейшее накопление текста не поможет. Полезнее завершить этап, показать найденное и назвать конкретное препятствие. Пользователь должен понимать, что готово и что требует его решения.

Проверяйте сохранение ограничений после сокращения

Возьмите одну длинную задачу и сравните её состояние до и после переработки истории. Сохранились ли точные объекты, запреты, неизвестные поля и незавершённые действия? Может ли другой исполнитель продолжить работу по сводке, не придумывая пропущенное?

Нужен случай, где важное условие находится далеко от последних сообщений. Добавьте большой, но посторонний результат инструмента. Затем проверьте, что агент продолжает исходную задачу и не принимает посторонние записи за новые полномочия. Другой полезный случай – два почти одинаковых номера объектов, которые нельзя объединять при пересказе.

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

Измеряйте полезность сокращения

Показатель «стало меньше токенов» описывает расход, но не результат работы. Рядом нужны число завершённых задач, потерянные условия, повторные чтения и время на проверку сотрудником. Слишком короткая сводка может вызвать больше запросов, чем исходный документ.

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

Сравнивайте похожие задания. Разбор одного короткого файла и расследование с десятками источников требуют разного объёма. Средняя длина запроса по всей компании скрывает процесс, в котором агент регулярно теряет точные условия.

Общая платформа помогает управлять всей цепочкой

Если каждый бот сам решает, что обрезать и куда записать результат, ограничения становятся случайными. Один помощник сохраняет подробные источники, другой передаёт коллегам пересказ без оснований, третий держит весь архив в каждом запросе. Разобрать общую задачу после нескольких передач трудно.

Начните с одной длинной задачи. Измерьте состав запроса, уберите повторные выгрузки, заведите рабочее состояние и проверьте сохранность ограничений после сокращения. Затем попросите коллегу продолжить работу по этому состоянию. Если он находит основания, различает проверенное и неизвестное и понимает следующий шаг, контекст стал полезнее. Именно это стоит считать результатом оптимизации.

Изображение на обложке: AiHummer