Cómo los agentes de larga duración superan la ventana de contexto: 3 cuestiones de diseño del patrón de resumen de transferencia + recuperación de información archivada

Nota del autor: analizamos el mecanismo de cambio de contexto de openJiuwen WorkSwarm para explicar el patrón de «resumen de traspaso + consulta del archivo» y las opciones de diseño disponibles cuando un agente de larga duración se acerca al límite de su ventana de contexto.

La comunidad de agentes de código abierto openJiuwen, respaldada por Huawei, presentó recientemente la arquitectura de clúster Hyper-Agent. Hay un detalle que merece la atención de los desarrolladores: cuando la ventana de contexto de un agente se acerca a su límite, este pasa a una nueva ventana con un resumen de traspaso que incluye el objetivo, el progreso y los próximos pasos; si necesita más detalles, consulta el historial archivado. El mecanismo se explica en una sola frase, pero detrás hay un problema de ingeniería al que se enfrentan todos los agentes de larga duración.

No es un rumor. Esta funcionalidad ya se ha publicado con openJiuwen WorkSwarm y su código está disponible como proyecto de código abierto en GitHub bajo el nombre JiuwenSwarm. En este artículo usamos el mecanismo como ejemplo para abordar tres cuestiones de diseño: qué debe incluir el resumen de traspaso, cuándo activar el cambio de ventana y cuándo consultar el archivo. También comparamos las ventajas y desventajas de dos enfoques: «depender de un contexto más largo» y «resumen de traspaso + consulta».

Qué te aporta: al terminar de leer, podrás revisar las opciones disponibles para gestionar el límite de la ventana de contexto en tu propia aplicación de agentes y los riesgos de cada una.

Resumen de traspaso y búsqueda en el archivo: lo esencial

Primero, repasemos los hechos que se pueden confirmar en las fuentes y después veamos qué significan para los desarrolladores. La información de la tabla procede de publicaciones de acceso público; los detalles de implementación que no se han confirmado se señalan por separado más adelante.

Por qué los agentes persistentes necesitan resolver el límite de la ventana de contexto

WorkSwarm está diseñado para que los agentes funcionen más allá de una única sesión de chat y permanezcan a largo plazo como «empleados digitales» en grupos de trabajo de Feishu, DingTalk y otras plataformas. Un mismo agente puede dar seguimiento a varias tareas en distintos chats grupales: recibe una solicitud en un canal y entrega el resultado en otro. Una puerta de enlace conecta las aplicaciones de mensajería instantánea y la interfaz web, mientras que AgentServer gestiona los agentes y las sesiones de trabajo.

En este escenario, alcanzar el límite de la ventana de contexto deja de ser un problema ocasional: es algo inevitable. Un chatbot que solo responde a preguntas individuales rara vez llena la ventana, pero un agente que da seguimiento a un proyecto durante varios días acumula conversaciones, resultados de llamadas a herramientas y contenido de archivos. Las publicaciones también mencionan que el panel de actividad de WorkSwarm muestra el consumo de tokens de cada agente, lo que indica que el uso del contexto es una métrica operativa que estos sistemas deben vigilar de forma continua.

Las sesiones como recurso: la base del resumen de traspaso

La clave para entender el mecanismo de traspaso es que WorkSwarm separa el «agente» de la «sesión». La identidad y el estado del agente persisten; las sesiones son recursos que el sistema asigna, gestiona de forma concurrente y puede reanudar con su contexto. Si una sesión se puede reemplazar, «abrir una ventana nueva cuando la actual se llena» se convierte en una decisión de diseño natural.

El resumen de traspaso transmite entre la sesión anterior y la nueva el estado de trabajo mínimo necesario para continuar. El historial archivado, por su parte, permite que los detalles de la sesión anterior no se pierdan: dejan de estar siempre presentes y pasan a consultarse solo cuando hacen falta.

Primera cuestión de diseño del resumen de traspaso: qué debe incluir

El reportaje señala tres elementos: objetivo, avances y próximos pasos. La estructura es sencilla, pero, al llevarla a la práctica, conviene desglosar cada uno. La siguiente tabla amplía esos tres elementos como referencia de diseño y ofrece recomendaciones de ingeniería; no describe una implementación confirmada de JiuwenSwarm.

Hemos añadido dos elementos: «restricciones» e «índice». Las restricciones son importantes porque las preferencias que el usuario expresa de forma dispersa durante una conversación larga —por ejemplo, «que el informe no supere una página»— son especialmente fáciles de perder al comprimir el resumen. El índice, por su parte, conecta el resumen de traspaso con la búsqueda en el archivo: cuanto más breve sea el resumen, más importante es indicarle a la nueva ventana «dónde están los detalles».

En el caso de WorkSwarm, también hay que tener en cuenta la complejidad de trabajar con varios grupos y canales. Según el reportaje, compartir información entre grupos requiere la aprobación del usuario. Este puede conceder permisos de una sola vez o permanentes, y también revocarlos. Si el estado de esas autorizaciones no figura en el resumen de traspaso, el agente de la nueva ventana podría interpretarlo de forma incorrecta. Es preferible guardar esta información en campos estructurados, no como texto libre.

Segundo problema de diseño del resumen de traspaso: cuándo activar el cambio de contexto

La información publicada solo indica que el cambio se produce «al acercarse al límite». No se han dado a conocer el umbral exacto ni si el resumen lo genera un modelo o se crea mediante reglas; para confirmarlo, habría que consultar el código fuente o la documentación de JiuwenSwarm. Desde el punto de vista de la ingeniería, hay varias opciones habituales para decidir cuándo activar el cambio.

Es importante tener en cuenta que generar el resumen de traspaso también consume espacio de contexto. Si se espera a que la ventana esté completamente llena, es posible que el modelo ya no tenga espacio para leer todo el historial y redactar un resumen de calidad. Por eso, sea cual sea la estrategia elegida, conviene reservar un margen para generar el resumen.

En cuanto a la forma de generarlo, un resumen creado por el modelo es más flexible y puede comprender la semántica de la tarea. Uno generado mediante reglas —por ejemplo, extrayendo directamente los campos de estado de la lista de tareas— es más estable, pero le cuesta captar las decisiones implícitas en la conversación. En la práctica, es habitual combinar ambos enfoques: el programa mantiene el estado estructurado y el modelo solo añade una explicación del progreso en lenguaje natural.

Cómo implementar resúmenes de traspaso y búsqueda en archivos: un prototipo mínimo

Este prototipo mínimo ilustra la idea, pero no es una implementación de JiuwenSwarm. Cuando el consumo estimado de tokens se acerca al umbral, pide al modelo que genere un resumen de traspaso y guarda los mensajes antiguos en un archivo.

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # Interfaz compatible con OpenAI de 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      # Valor de ejemplo; ajustar a la ventana real del modelo utilizado
SWITCH_RATIO = 0.7           # Reservar espacio para generar el resumen
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] = []   # Historial archivado; en producción se puede usar una base de datos o una base vectorial

    def estimate_tokens(self) -> int:
        # Estimación aproximada; en producción se debe usar el tokenizador del modelo correspondiente
        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:])      # Guardar la sesión anterior en el archivo
        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("请记录：本周报告不要超过一页。"))

La búsqueda en archivos de este prototipo se limita a buscar coincidencias de palabras clave. La información publicada no indica si JiuwenSwarm utiliza búsqueda vectorial u otro método. En un proyecto real, puedes elegir entre búsqueda de texto completo, búsqueda vectorial o una combinación de ambas según el tamaño del archivo. También puedes registrar search_archive como herramienta para que el modelo decida cuándo invocarla.

🚀 Inicio rápido: Al crear este tipo de prototipo, puedes usar modelos distintos para generar el resumen y resolver la tarea principal. Por ejemplo, un modelo ligero para el resumen y otro más potente para la tarea principal. Con una sola clave API de APIYI apiyi.com puedes invocar modelos de OpenAI, Claude, Gemini y otros, lo que facilita alternar entre ellos y compararlos en el mismo código. Los usuarios nuevos disponen de crédito gratuito para pruebas.

Tercer problema al diseñar el resumen de traspaso: cuándo consultar el historial archivado

La búsqueda en archivos aborda un problema fundamental: todo resumen pierde información. Cualquier compresión implica pérdidas; la clave está en poder recuperar lo que se ha omitido. Hay tres enfoques principales para decidir cuándo consultar el archivo:

• Invocación autónoma del modelo: se pone la búsqueda a disposición del modelo como herramienta, y este consulta el archivo cuando detecta que le falta información. Es flexible, pero depende de que el modelo sepa reconocer lo que desconoce.
• Activación mediante reglas: cuando el usuario menciona una entidad, un nombre de archivo o un momento que no aparece en el resumen, el programa busca automáticamente e incorpora los resultados. Ofrece mucho control, pero las reglas tienen una cobertura limitada.
• Consulta guiada por índices: el resumen de traspaso conserva un índice de la información clave. Cuando surge un tema relacionado en la nueva ventana, se usa el índice para recuperar los datos precisos. Su eficacia depende de la calidad del índice creado durante la elaboración del resumen.

Creemos que el mayor riesgo es «no saber qué se ha omitido». Si el resumen deja fuera una preferencia del usuario y en la nueva ventana tampoco hay ninguna pista de que existe, al modelo no se le ocurrirá buscarla. Por eso recomendamos antes incluir campos de «restricciones» e «índices» en el resumen: sirven como puntos de entrada para consultar el archivo.

Depender de un contexto más largo vs. resúmenes de traspaso: análisis de impacto

Ante el límite de la ventana de contexto, otra opción es cambiar directamente a un modelo con una ventana más larga. Ambas estrategias pueden combinarse, pero son adecuadas para situaciones distintas. La siguiente tabla presenta un análisis cualitativo, sin datos de rendimiento.

💡 Recomendación: si la tarea suele poder completarse en una sola ventana larga, cambiar a un modelo con más contexto es la opción más sencilla. Si el agente necesita permanecer activo a largo plazo, como los empleados digitales de WorkSwarm, el resumen de traspaso es casi imprescindible. Puedes ejecutar primero la misma tarea con modelos de distintos tamaños de contexto en APIYI apiyi.com y, tras observar el uso real, decidir si vale la pena desarrollar un mecanismo de resumen.

Impacto para los desarrolladores

• La gestión del contexto se convierte en una cuestión de arquitectura: WorkSwarm trata las sesiones como recursos que se pueden planificar. Esto significa que el cambio de contexto forma parte del diseño del sistema, en lugar de ser una medida correctiva tras un error.
• El estado debe modelarse de forma explícita: la calidad del resumen de traspaso depende de que el agente haya registrado con claridad los objetivos, las decisiones y las tareas pendientes. Esto exige que los desarrolladores planifiquen la estructura del estado desde la fase de diseño.
• La observabilidad cobra más importancia: WorkSwarm muestra el uso de tokens y el tiempo de respuesta en su panel de actividad. Los agentes de larga duración también necesitan monitorear la frecuencia de los cambios de ventana y los resultados de las búsquedas.

Impacto en la industria

• De agentes basados en sesiones a agentes permanentes: los agentes pasan de responder preguntas individuales a trabajar de forma continua en grupos. La capacidad de mantener el contexto entre ventanas se convertirá en infraestructura básica para este tipo de productos.
• Una implementación de código abierto como referencia: con la publicación de JiuwenSwarm como código abierto, los desarrolladores pueden estudiar directamente sus umbrales de cambio, la generación de resúmenes y la implementación de búsquedas, sin tener que empezar de cero.

Preguntas frecuentes FAQ

Puntos clave sobre el resumen de traspaso y la ventana de contexto

• Mecanismo principal: cuando la ventana está casi llena, se cambia a una nueva y se lleva un resumen de traspaso con el objetivo, el progreso y los siguientes pasos.
• Requisito previo: la identidad del agente se separa de la sesión, que pasa a ser un recurso que puede programarse y recuperarse.
• Diseño del resumen: además de los tres elementos básicos, conviene incluir las restricciones del usuario y un índice del archivo para reducir el riesgo de omisiones.
• Momento del cambio: hay que reservar espacio para generar el resumen y, de ser posible, cambiar entre tareas.
• Consulta del archivo: los resúmenes siempre pierden información; la forma de acceder al archivo determina si se pueden recuperar los detalles.
• Elección de estrategia: para tareas de duración media puede bastar con un modelo de contexto largo; las tareas de larga duración necesitan más el traspaso mediante resúmenes.
• Validación rápida: se pueden crear prototipos y compararlos mediante la interfaz unificada multimodelo de APIYI apiyi.com.

Conclusión

El mecanismo de cambio de contexto de openJiuwen WorkSwarm ofrece un modelo claro de referencia para agentes que funcionan durante largos periodos:

1. El resumen de traspaso conserva el estado del trabajo: el objetivo, el progreso y los siguientes pasos son el conjunto mínimo; las restricciones y los índices son complementos útiles.
2. Hay que dejar margen para el cambio: generar el resumen también consume contexto, así que no conviene esperar a que la ventana esté completamente llena.
3. La búsqueda en el archivo compensa la pérdida de información: el resumen se encarga de «recordar lo esencial» y los detalles se recuperan cuando hacen falta.

Si tu agente está pasando de trabajar en una sola sesión a funcionar de forma continua, conviene primero definir la estructura de su estado y después decidir si cambiar a un modelo de contexto largo o introducir resúmenes de traspaso. Puedes usar APIYI apiyi.com para crear un prototipo rápidamente y comparar la calidad de los resúmenes y el consumo de contexto entre varios modelos.

📚 Referencias

1. Artículo de Pandaily: arquitectura de clústeres openJiuwen Hyper-Agent y empleados digitales WorkSwarm
2. Enlace: pandaily.com/openjiuwen-hyper-agent-swarm-architecture-persistent-agents-workswarm-digital-employees

3. Descripción: artículo en inglés sobre agentes persistentes, cambio de contexto y mecanismos de resumen para el traspaso de tareas

4. Código abierto de JiuwenSwarm: implementación de código abierto de openJiuwen WorkSwarm

5. Enlace: github.com（busca JiuwenSwarm）
6. Descripción: consulta la implementación de los umbrales de cambio, la generación de resúmenes y la recuperación de archivos

Autor: Equipo técnico de APIYI
Consultas técnicas: Puedes contactarnos desde la página principal de APIYI apiyi.com. Encontrarás más información en el centro de documentación docs.apiyi.com

Artículos relacionados

• ¿Una persona puede supervisar como máximo 5 sesiones? Análisis de los cinco módulos del superagente de DeepSeek: Análisis del artículo del equipo DeepSeek Harness sobre la arquitectura del superagente (Super-agent): cinco módulos, condiciones y datos experimentales, cuatro preguntas abiertas, lista de implementación para equipos pequeños y combinación de modelos y estimación de costes para Router y Worker.
• Crea un agente de resúmenes de monitoreo programado: 4 componentes y guía para elegir interfaces: Desglosa los 4 componentes de un agente de resúmenes de monitoreo programado, explica cómo la capa de invocación del modelo se desacopla de SDK específicos mediante una interfaz compatible con OpenAI y proporciona un ejemplo ejecutable en Python.