De la «conversación de chat» al «empleado digital permanente»: 5 cambios clave en la arquitectura Hyper-Agent de openJiuwen

Nota del autor: Este artículo analiza la arquitectura de agentes permanentes de openJiuwen Hyper-Agent y ayuda a quienes diseñan flujos de trabajo a decidir si este modelo encaja con su equipo.

openJiuwen, la comunidad de agentes de código abierto respaldada por Huawei, presentó la arquitectura de enjambre Hyper-Agent, que permite a los agentes salir de una sesión de chat individual e incorporarse a grupos de trabajo reales como «empleados digitales permanentes». El 5 de noviembre de 2026, Pandaily informó sobre estas capacidades, citando una publicación de la comunidad difundida por IT Home. Ya están disponibles en openJiuwen WorkSwarm y su código se publicó en GitHub bajo el nombre JiuwenSwarm.

No se trata simplemente de añadir otro bot de preguntas y respuestas al chat grupal. El cambio de fondo es que se invierte la relación entre el agente y la sesión: la sesión deja de ser el contenedor del agente y pasa a ser un recurso que el sistema puede gestionar.

Valor principal: Este artículo reúne funciones dispersas bajo una perspectiva arquitectónica para ayudarte a entender qué cambia con openJiuwen Hyper-Agent y qué conviene verificar antes de adoptarlo en tu equipo.

Datos clave de openJiuwen Hyper-Agent

Cabe aclarar que este artículo se basa en una información de segunda mano procedente de un texto de la comunidad. La noticia no detalla la lista de modelos subyacentes, los requisitos de despliegue, la licencia ni el grado de madurez para producción. Estos datos deben contrastarse con el repositorio de GitHub y la documentación oficial.

Cómo convierte openJiuwen Hyper-Agent las sesiones en recursos

La mayoría de las aplicaciones de agentes siguen el modelo de «un agente por sesión»: el usuario abre una conversación y el agente comienza a trabajar, con su identidad, contexto y progreso de las tareas ligados a esa conversación. Si se cambia de grupo o de ventana, la colaboración suele tener que empezar de nuevo.

Hyper-Agent funciona al revés. Persistent Agent tiene una identidad y un estado independientes, y puede recibir trabajo de forma continua. Las sesiones pasan a ser recursos subyacentes que el sistema asigna y gestiona de forma concurrente, conservando el contexto al retomarlas. Según la comunidad, este diseño se basa en el trabajo previo de Persistent Session y permite que un agente siga varias tareas a la vez en distintos chats grupales de terceros.

Sobre el gráfico: a la izquierda, el estado está ligado a la sesión; a la derecha, al agente. Si quieres comparar el consumo de contexto con conversaciones de tu propio negocio, puedes hacer pruebas a pequeña escala mediante la interfaz unificada de APIYI apiyi.com.

Los 5 componentes clave de la arquitectura Hyper-Agent de openJiuwen

Según las descripciones publicadas, el sistema puede dividirse en cinco capas: acceso, coordinación, gestión de identidad, colaboración y observabilidad. La siguiente tabla resume los componentes según su función arquitectónica; no se trata de una clasificación oficial.

Centro de empleados de Hyper-Agent y traspaso de contexto

En el centro de empleados, los usuarios pueden configurar responsabilidades, estilo de trabajo, requisitos de entrega, habilidades, conectores, fuentes de conocimiento e incluso un correo electrónico propio. Es como ampliar la configuración de la indicación hasta convertirla en una «descripción del puesto»: ahí se definen tanto el alcance de las capacidades del agente como su identidad de cara al exterior.

En tareas de larga duración, tarde o temprano se alcanza el límite de la ventana de contexto. WorkSwarm lo resuelve pasando a una ventana nueva cuando la actual está cerca de su límite, junto con un resumen de traspaso que incluye los objetivos, el progreso y los próximos pasos. Si necesita más detalles, consulta el historial archivado. Así puede continuar el trabajo sin tener que incluir todo el historial en la ventana actual.

Modos pasivo y adaptativo de Hyper-Agent

Decidir si un agente debe intervenir en un grupo de trabajo es una cuestión inevitable cuando permanece activo de forma continua. WorkSwarm ofrece dos modos de respuesta, cuya principal diferencia está en lo predecible que resulta su comportamiento.

La noticia no explica el mecanismo concreto de decisión del modo adaptativo ni su tasa de acierto. Los equipos pueden probar primero un experimento sencillo para entender la dificultad de este tipo de decisiones. El siguiente código es solo una demostración nuestra, no la implementación de WorkSwarm:

import openai

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

message = "接口今天下午还没联调通，明天的发布可能有风险。"
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "你是项目助理。只输出 ignore、respond 或 intervene。"},
        {"role": "user", "content": message}
    ]
)
print(response.choices[0].message.content)

import json
import openai

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

def create_handoff_summary(history: list[str], model: str = "gpt-4o-mini") -> dict:
    """Resume los registros de trabajo en objetivos, progreso y próximos pasos para simular un traspaso de contexto."""
    prompt = (
        "请根据工作记录输出 JSON，字段为 goals、progress、next_steps。"
        "不要输出 JSON 以外的内容。\n\n" + "\n".join(history)
    )
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"}
    )
    return json.loads(response.choices[0].message.content)

records = [
    "产品经理：周五前完成客户周报。",
    "智能体：已汇总销售数据，等待客服数据。",
    "客服主管：今天下班前提供工单统计。"
]
print(create_handoff_summary(records))

Sugerencia para el experimento: puedes obtener crédito gratuito de prueba en APIYI apiyi.com y comparar las decisiones de distintos modelos con muestras anonimizadas de conversaciones grupales. Esta prueba valida la lógica de decisión, pero no significa que WorkSwarm ya sea compatible con esa API.

Colaboración entre grupos y en dispositivos locales con Hyper-Agent de openJiuwen

Un mismo agente puede trabajar en aplicaciones como Feishu y DingTalk: por ejemplo, puede recibir una solicitud en un canal y entregar el resultado en otro. El intercambio entre grupos no está permitido por defecto: el usuario debe comprobar el grupo de origen, el destinatario y el contenido antes de conceder un permiso de un solo uso o permanente. También puede revocarlo después.

Los miembros del equipo también pueden ejecutar WorkSwarm en sus propios dispositivos. Los agentes de servidores en la nube y los de computadoras personales pueden colaborar en un mismo grupo y utilizar archivos y herramientas locales que ya tengan autorizados. Así, la nube se encarga de mantener el servicio disponible de forma continua, mientras que los dispositivos locales aportan datos y herramientas del entorno personal.

Para tareas más grandes, los chats grupales de SwarmEngine pueden reunir en un mismo espacio a usuarios, Persistent Agent, expertos individuales y equipos de expertos. En cada equipo, un responsable recibe las tareas, informa sobre el progreso y organiza las entregas, mientras los demás miembros trabajan en segundo plano. Los expertos también pueden ser agentes de terceros, como Codex o Claude Code, y formar equipos mixtos con empleados digitales creados internamente.

Análisis del impacto de openJiuwen Hyper-Agent

Impacto en desarrolladores y creadores de flujos de trabajo

• Cambio en el enfoque de diseño: se pasa de diseñar conversaciones individuales a definir la identidad, el estado, los permisos y los mecanismos de traspaso de los agentes.
• Mayores exigencias operativas: los agentes permanentes necesitan supervisión, auditoría y gestión, igual que cualquier servicio en producción.
• Integraciones más amplias: la mensajería instantánea, las bases de conocimiento, el correo electrónico y las herramientas locales pueden formar parte de una misma cadena de tareas.

Impacto en la colaboración entre equipos

• Los agentes pasan de ser herramientas a colaboradores: pueden dar seguimiento a tareas a largo plazo, en lugar de limitarse a responder preguntas puntuales.
• La gobernanza se aborda desde el principio: hay que acordar de antemano quién puede compartir datos, cuándo intervienen los agentes y quién responde por los resultados.
• La orquestación híbrida se vuelve clave en la evaluación: el reparto de tareas entre empleados creados internamente y agentes de terceros influye en la calidad de las entregas y en la asignación de responsabilidades.

Aspectos clave para evaluar Hyper-Agent en un equipo

Preguntas frecuentes sobre openJiuwen Hyper-Agent

openJiuwen Hyper-Agent: puntos clave

• Arquitectura: el agente mantiene su identidad y estado, mientras que las sesiones pasan a ser recursos programables.
• Componentes principales: Gateway gestiona el acceso y AgentServer coordina los agentes y las sesiones.
• Funcionamiento continuo: usa resúmenes de transferencia para cambiar de contexto y consulta el historial archivado cuando hace falta.
• Estrategia de respuesta: el modo pasivo ofrece más control; el adaptativo es más proactivo, pero requiere validación.
• Diseño de permisos: compartir contenido entre grupos requiere aprobación. La autorización puede ser puntual o permanente y se puede revocar.
• Colaboración híbrida: la nube, los dispositivos locales, los equipos de expertos y los agentes de terceros pueden compartir un mismo espacio de colaboración.
• Validación: primero, verifica la documentación del proyecto; después, prueba los modelos con APIYI apiyi.com.

Conclusión: qué nos enseña la arquitectura de openJiuwen Hyper-Agent

Lo interesante de openJiuwen Hyper-Agent no es solo que los agentes lleguen a Feishu o DingTalk, sino que lleva al diseño del sistema la idea de «convertir la sesión de contenedor en recurso»:

1. Identidad persistente: Persistent Agent mantiene la continuidad del trabajo aunque termine una sesión.
2. La coordinación es clave: AgentServer se encarga de coordinar los agentes y varias sesiones de trabajo.
3. La gobernanza determina su adopción: la aprobación de permisos, el control de las intervenciones y la observación del uso determinan si puede incorporarse a equipos reales.

Si tu trabajo depende de la colaboración entre varios grupos, el seguimiento a largo plazo y las entregas a través de distintos canales, vale la pena explorar este enfoque. Si los procesos implican datos sensibles o requisitos estrictos de cumplimiento, conviene empezar con una prueba piloto aislada, en modo pasivo y con permisos mínimos. Para evaluar las decisiones relacionadas con los modelos, puedes usar APIYI apiyi.com y comparar varios modelos con una misma interfaz, acumulando datos para elegir la tecnología más adelante.

📚 Referencias

1. Pandaily – openJiuwen’s Hyper-Agent Swarm Puts Persistent AI Agents Into Work Chats as Digital Employees: fuente principal de los datos de este artículo
2. Enlace: pandaily.com/openjiuwen-hyper-agent-swarm-architecture-persistent-agents-workswarm-digital-employees
3. Descripción: presenta la arquitectura de Hyper-Agent, las funciones de WorkSwarm y los planes futuros de la comunidad. Es una fuente secundaria basada en un texto de la comunidad.

Autor: Equipo técnico de APIYI
Contacto técnico: Puedes contactarnos desde la página de inicio de APIYI. Para más información, visita el centro de documentación en docs.apiyi.com.