Как долго работающие агенты преодолевают ограничения контекстного окна: 3 вопроса проектирования схемы «сводка при передаче управления + поиск в архиве»

Примечание автора: на примере механизма переключения контекста в openJiuwen WorkSwarm разбираем подход «итоговая сводка + поиск в архиве», а также варианты и компромиссы для долго работающих агентов, приближающихся к пределу контекстного окна.

Сообщество разработчиков openJiuwen, которое при поддержке Huawei развивает агентов с открытым исходным кодом, недавно представило кластерную архитектуру Hyper-Agent. Одна деталь заслуживает внимания разработчиков: когда контекстное окно агента приближается к пределу, он переключается на новое окно, передавая в него сводку с целью, прогрессом и следующими шагами, а при необходимости ищет детали в архиве истории. Механизм можно описать одним предложением, но за ним стоит инженерная задача, с которой сталкиваются все долго работающие агенты.

Это не слухи. Соответствующая функциональность уже выпущена в составе openJiuwen WorkSwarm, а её код открыт на GitHub под названием JiuwenSwarm. На примере этого механизма мы разберём три вопроса: что включать в сводку, когда переключать окно и когда обращаться к архиву. А ещё сравним компромиссы двух подходов: «полагаться на более длинный контекст» и «передавать сводку и искать в архиве».

Главная польза: после прочтения вы сможете применить эти идеи к своему агенту и разобраться, какие есть способы работы с пределом контекстного окна и какие риски связаны с каждым из них.

Краткий обзор: сводка передачи и поиск по архиву

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

Почему постоянному агенту нужно решать проблему предела контекстного окна

Идея WorkSwarm — вывести агента за рамки отдельной чат-сессии, чтобы он мог постоянно работать как «цифровой сотрудник» в рабочих группах Feishu, DingTalk и других мессенджеров. Один и тот же агент может вести несколько задач в разных групповых чатах: получать запрос в одном канале, а передавать результат в другом. Шлюз соединяет приложения для обмена сообщениями и веб-интерфейс с системой, а AgentServer управляет агентами и рабочими сессиями.

В таком сценарии достижение предела контекстного окна — не случайность, а неизбежное событие. Чат-бот, который отвечает на отдельные вопросы, редко заполняет окно целиком. Но у агента, который несколько дней ведёт проект, постоянно накапливаются история диалога, результаты вызовов инструментов и содержимое файлов. В публикации также отмечается, что панель активности WorkSwarm показывает расход токенов каждого агента. Это значит, что за расходом контекста в таких системах нужно следить постоянно.

Сессия как ресурс: основа сводки передачи

Чтобы понять механизм сводки передачи, важно учесть, что WorkSwarm разделяет понятия «агент» и «сессия». Идентичность и состояние агента сохраняются постоянно, а сессия — лишь ресурс, который система выделяет, использует для параллельной работы и может восстановить вместе с контекстом. Если сессию можно заменить, то и решение «окно заполнено — переключаемся на новое» выглядит вполне естественно.

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

Первый вопрос при создании сводки для передачи: что в неё включить

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

«Ограничения» и «индекс» — два пункта, которые мы добавили. Ограничения важны, потому что предпочтения, высказанные пользователем в разных частях длинного диалога (например, «отчёт не должен превышать одной страницы»), проще всего потерять при сжатии сводки. Индекс связывает сводку для передачи с поиском по архиву: чем короче сводка, тем важнее подсказать новому окну, где искать подробности.

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

Второй вопрос о сводке для передачи контекста: когда переключать контекст

В публикации сказано лишь, что переключение происходит «при приближении к лимиту». Конкретный порог и способ создания сводки — моделью или по правилам — в открытых материалах не раскрыты. Чтобы это выяснить, нужно изучить исходный код или документацию JiuwenSwarm. С инженерной точки зрения момент переключения можно выбирать несколькими способами.

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

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

Как реализовать сводку для передачи работы и поиск по архиву: минимальный прототип

Ниже — минимальный прототип, демонстрирующий эту идею. Он не является реализацией JiuwenSwarm. Когда расчётное количество токенов приближается к порогу, прототип просит модель составить сводку для передачи работы и сохраняет старые сообщения в архив.

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # OpenAI-совместимый интерфейс APIYI
)

HANDOFF_PROMPT = "请将以上工作记录整理为交接摘要，包含：目标、进展、下一步、约束、关键信息索引。"

def make_handoff(messages, model="gpt-4o-mini"):
    resp = client.chat.completions.create(
        model=model,
        messages=messages + [{"role": "user", "content": HANDOFF_PROMPT}]
    )
    return resp.choices[0].message.content

import openai
from typing import List, Dict

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

MODEL = "gpt-4o-mini"
CONTEXT_LIMIT = 100_000      # Примерное значение; настройте под фактическое окно модели
SWITCH_RATIO = 0.7           # Оставляем место для создания сводки
HANDOFF_PROMPT = (
    "请将以上工作记录整理为交接摘要，分为五部分："
    "1.目标 2.进展（含关键决策及理由）3.下一步 4.用户约束 5.关键信息索引（关键词列表）"
)

class LongRunningAgent:
    def __init__(self, system_prompt: str):
        self.system_prompt = system_prompt
        self.messages: List[Dict] = [{"role": "system", "content": system_prompt}]
        self.archive: List[Dict] = []   # Архив истории; в продакшене можно заменить базой данных или векторной базой

    def estimate_tokens(self) -> int:
        # Приблизительная оценка; в продакшене следует использовать токенизатор соответствующей модели
        return sum(len(m["content"]) for m in self.messages)

    def maybe_switch(self):
        if self.estimate_tokens() < CONTEXT_LIMIT * SWITCH_RATIO:
            return
        resp = client.chat.completions.create(
            model=MODEL,
            messages=self.messages + [{"role": "user", "content": HANDOFF_PROMPT}]
        )
        summary = resp.choices[0].message.content
        self.archive.extend(self.messages[1:])      # Сохраняем старый диалог в архив
        self.messages = [
            {"role": "system", "content": self.system_prompt},
            {"role": "system", "content": f"【交接摘要】\n{summary}"}
        ]

    def search_archive(self, keyword: str, top_k: int = 5) -> str:
        hits = [m["content"] for m in self.archive if keyword in m["content"]]
        return "\n---\n".join(hits[-top_k:]) or "归档中未找到相关记录"

    def chat(self, user_input: str) -> str:
        self.maybe_switch()
        self.messages.append({"role": "user", "content": user_input})
        resp = client.chat.completions.create(model=MODEL, messages=self.messages)
        answer = resp.choices[0].message.content
        self.messages.append({"role": "assistant", "content": answer})
        return answer

agent = LongRunningAgent("你是负责跟进项目周报的数字员工。")
print(agent.chat("请记录：本周报告不要超过一页。"))

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

🚀 Быстрый старт: при создании такого прототипа для подготовки резюме и выполнения основной задачи можно использовать разные модели — например, лёгкую модель для резюме и более мощную для основной задачи. С APIYI apiyi.com достаточно одного API-ключа для вызова моделей OpenAI, Claude, Gemini и других. Это позволяет переключать и сравнивать модели в одном и том же коде. Новым пользователям доступен бесплатный лимит для тестирования.

Третий вопрос при разработке резюме для передачи контекста: когда обращаться к архиву

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

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

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

Длинный контекст или сводка для передачи состояния: анализ подходов

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

💡 Как выбрать: если задача обычно укладывается в одно длинное окно, проще перейти на модель с большим контекстом. Если же агент должен работать постоянно, как цифровой сотрудник WorkSwarm, сводка для передачи состояния почти наверняка необходима. Можно сначала выполнить одну и ту же задачу на APIYI apiyi.com с моделями, у которых разный размер контекстного окна, оценить фактический расход и затем решить, стоит ли разрабатывать механизм создания сводок.

Что это значит для разработчиков

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

Что это значит для отрасли

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

Частые вопросы FAQ

Ключевые выводы: передача состояния и контекстное окно

• Основной механизм: когда окно почти заполнено, агент переходит в новое окно с резюме, содержащим цель, текущий прогресс и следующие шаги.
• Необходимое условие: идентичность агента отделена от сессии, а сессия становится ресурсом, которым можно управлять и который можно восстанавливать.
• Содержание резюме: помимо трёх основных элементов стоит добавить ограничения пользователя и индекс архива, чтобы снизить риск потери информации.
• Момент переключения: оставляйте место для создания резюме и по возможности переключайтесь на границах задач.
• Поиск в архиве: резюме неизбежно теряет часть информации, поэтому возможность найти детали зависит от доступа к архиву.
• Выбор подхода: для задач средней длительности можно перейти на модель с длинным контекстом; для долгосрочной работы агента важнее передача состояния через резюме.
• Быстрая проверка: создать и сравнить прототипы можно через единый интерфейс APIYI apiyi.com для работы с несколькими моделями.

Итоги

Механизм переключения контекста в openJiuwen WorkSwarm — наглядный пример организации работы долго функционирующих агентов:

1. Резюме передаёт рабочее состояние: цель, прогресс и следующие шаги — необходимый минимум; ограничения и индекс архива — полезные дополнения.
2. Для переключения нужен запас: создание резюме само расходует контекст, поэтому нельзя ждать, пока окно заполнится полностью.
3. Поиск в архиве помогает восстановить утраченную информацию: задача резюме — запомнить главное, а детали можно найти по мере необходимости.

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

📚 Источники

1. Публикация Pandaily: кластерная архитектура openJiuwen Hyper-Agent и цифровые сотрудники WorkSwarm
2. Ссылка: pandaily.com/openjiuwen-hyper-agent-swarm-architecture-persistent-agents-workswarm-digital-employees

3. Описание: англоязычная статья о постоянных агентах, переключении контекста и механизме передачи кратких сводок

4. Исходный код JiuwenSwarm: открытая реализация openJiuwen WorkSwarm

5. Ссылка: github.com (поиск по запросу JiuwenSwarm)
6. Описание: реализация порогов переключения, генерации сводок и поиска в архиве

Автор: техническая команда APIYI
Технические вопросы: свяжитесь с нами через главную страницу APIYI apiyi.com. Дополнительные материалы доступны в документации на docs.apiyi.com

Читайте также

• Один человек может следить максимум за 5 сессиями? Разбираем пять ключевых модулей суперагента DeepSeek: Разбор статьи команды DeepSeek Harness об архитектуре суперагента (Super-agent): пять основных модулей, условия и данные экспериментов, четыре открытых вопроса, план внедрения для небольшой команды, подбор моделей для Router и Worker и оценка затрат.
• Создаём агента для формирования сводок мониторинга по расписанию: 4 компонента и руководство по выбору интерфейсов: Разберите 4 компонента агента для создания сводок мониторинга по расписанию, объясните, как слой вызова модели отделяется от конкретного SDK с помощью OpenAI-совместимого интерфейса, и приведите рабочий пример на Python.