De la « session de chat » à l’« employé numérique permanent » : 5 changements clés dans l’architecture Hyper-Agent d’openJiuwen

Note de l’auteur : cet article décrypte l’architecture d’agents permanents d’openJiuwen Hyper-Agent pour aider les concepteurs de workflows à déterminer si cette approche convient à leur équipe.

La communauté open source d’agents openJiuwen, soutenue par Huawei, a dévoilé l’architecture en essaim Hyper-Agent, qui permet aux agents de dépasser le cadre d’une conversation ponctuelle pour rejoindre de vrais groupes de travail en tant que « collaborateurs numériques permanents ». Le 5 novembre 2026, Pandaily a rapporté cette annonce en citant un article de la communauté publié par IT之家. Ces fonctionnalités sont disponibles dans openJiuwen WorkSwarm et le code est publié en open source sur GitHub sous le nom JiuwenSwarm.

Il ne s’agit pas simplement d’ajouter un robot de questions-réponses à une discussion de groupe. Le véritable changement, c’est l’inversion du rapport entre l’agent et la conversation : celle-ci n’est plus un conteneur pour l’agent, mais une ressource que le système peut mobiliser.

L’essentiel : cet article rassemble les différentes fonctionnalités sous l’angle de l’architecture, pour vous aider à comprendre ce que change openJiuwen Hyper-Agent et ce qu’une équipe devrait vérifier avant de l’adopter.

openJiuwen Hyper-Agent : l’essentiel en bref

Les faits présentés ici proviennent d’un article secondaire basé sur une publication de la communauté. Cet article ne précise ni la liste des modèles sous-jacents, ni les exigences de déploiement, la licence ou le niveau de maturité en production. Ces points restent à vérifier dans le dépôt GitHub et la documentation officielle.

Comment openJiuwen Hyper-Agent transforme les sessions en ressources

La plupart des applications d’agents reposent sur le principe « une session, un agent » : l’utilisateur ouvre une conversation et l’agent se met au travail. Son identité, son contexte et l’avancement de ses tâches restent liés à cette conversation. Dès qu’on change de groupe ou de fenêtre, la collaboration doit souvent repartir de zéro.

Hyper-Agent adopte l’approche inverse. Un Persistent Agent possède sa propre identité et son propre état, et peut recevoir du travail en continu. Les sessions deviennent des ressources sous-jacentes que le système attribue, planifie en parallèle et reprend avec leur contexte. Selon la communauté, cette conception s’appuie sur les travaux précédents autour de Persistent Session et permet à un agent de suivre simultanément plusieurs tâches dans différents groupes de discussion tiers.

À propos du schéma : à gauche, l’état est lié à la session ; à droite, il est lié à l’agent. Pour comparer le coût en contexte avec vos propres conversations professionnelles, vous pouvez mener une expérience à petite échelle via l’interface unifiée d’APIYI apiyi.com.

Les 5 composants clés de l’architecture openJiuwen Hyper-Agent

D’après les descriptions disponibles, le système peut être décomposé en cinq couches : accès, orchestration, gestion des identités, collaboration et observation. Le tableau ci-dessous regroupe les composants selon leur rôle architectural ; il ne s’agit pas d’une classification officielle.

Centre des employés Hyper-Agent et transfert de contexte

Dans le centre des employés, les utilisateurs peuvent configurer les responsabilités, le style de travail, les exigences de livraison, les compétences, les connecteurs, les sources de connaissances et même une adresse courriel dédiée. C’est comme si la configuration de l’invite devenait une véritable « fiche de poste » : les limites des capacités de l’agent et son identité auprès des interlocuteurs externes y sont définies.

Un fonctionnement de longue durée finit forcément par atteindre la limite de la fenêtre de contexte. WorkSwarm passe alors à une nouvelle fenêtre en y ajoutant un résumé de transfert qui contient les objectifs, l’avancement et les prochaines étapes. Si des détails sont nécessaires, le système les recherche dans l’historique archivé. Le travail peut ainsi se poursuivre sans avoir à faire tenir tout l’historique dans la fenêtre active.

Modes passif et adaptatif de Hyper-Agent

Faut-il qu’un agent intervienne dans un groupe de travail ? C’est une question incontournable lorsqu’il y est présent en permanence. WorkSwarm propose deux modes de réponse, qui se distinguent surtout par la prévisibilité de leur comportement.

L’article ne précise ni le mécanisme de décision du mode adaptatif ni son taux de précision. Pour mieux comprendre la difficulté de ce type de décision, une équipe peut commencer par une expérience simplifiée. Le code ci-dessous est une démonstration de notre part, et non une implémentation 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:
    """Résume les notes de travail en objectifs, avancement et prochaines étapes pour simuler une passation de contexte."""
    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))

Conseil pour l’expérience : vous pouvez commencer par obtenir un crédit de test gratuit via APIYI apiyi.com, puis comparer les décisions de différents modèles sur des extraits de conversations de groupe anonymisés. Cette étape permet de vérifier la logique de décision ; elle ne signifie pas que WorkSwarm prend déjà en charge cette API.

Collaboration entre groupes et en local avec openJiuwen Hyper-Agent

Un même agent peut travailler sur plusieurs applications professionnelles, comme Feishu et DingTalk : il peut par exemple recevoir une demande sur un canal et livrer le résultat sur un autre. Le partage entre groupes n’est pas autorisé par défaut : l’utilisateur doit vérifier le groupe source, le destinataire et le contenu, puis accorder une autorisation ponctuelle ou permanente. Il peut aussi la révoquer par la suite.

Les membres de l’équipe peuvent également exécuter WorkSwarm sur leurs propres appareils. Les agents hébergés sur un serveur cloud et ceux installés sur des ordinateurs personnels peuvent collaborer dans un même groupe et utiliser les fichiers et outils locaux autorisés. Le cloud assure ainsi une disponibilité continue, tandis que les appareils locaux donnent accès aux données et aux outils de l’environnement personnel.

Pour les tâches plus importantes, les conversations de groupe SwarmEngine peuvent réunir dans un même espace l’utilisateur, un agent persistant, des experts individuels et des équipes d’experts. Le responsable d’une équipe reçoit les tâches, rend compte de l’avancement et organise la livraison, tandis que les membres travaillent en arrière-plan. Les experts peuvent aussi être issus d’agents tiers comme Codex ou Claude Code et travailler aux côtés d’employés numériques développés en interne.

Analyse de l’impact d’openJiuwen Hyper-Agent

Impact sur les développeurs et les concepteurs de workflows

• Changement des priorités de conception : il ne s’agit plus seulement de concevoir une conversation ponctuelle, mais aussi l’identité, l’état, les autorisations et les mécanismes de transfert de l’agent.
• Exigences d’exploitation accrues : les agents permanents doivent être supervisés, audités et gérés comme des services en production.
• Périmètre d’intégration élargi : messagerie instantanée, bases de connaissances, courriels et outils locaux peuvent tous intervenir dans une même chaîne de tâches.

Impact sur la collaboration en équipe

• L’agent passe du statut d’outil à celui de collaborateur : il peut suivre une tâche dans la durée, au lieu de simplement répondre à une question ponctuelle.
• La gouvernance doit être anticipée : il faut définir à l’avance qui peut partager des données, quand l’agent peut intervenir et qui est responsable des résultats.
• L’orchestration hybride devient un critère clé : la répartition du travail entre les employés virtuels créés en interne et les agents tiers influe sur la qualité des livrables et le partage des responsabilités.

Points à examiner pour évaluer Hyper-Agent en équipe

FAQ sur openJiuwen Hyper-Agent

openJiuwen Hyper-Agent : points clés

• Architecture : l’agent conserve son identité et son état, tandis que la session devient une ressource planifiable.
• Composants principaux : Gateway gère les accès, AgentServer orchestre les agents et les sessions.
• Fonctionnement continu : des résumés de passation permettent de changer de contexte, et l’historique archivé peut être consulté au besoin.
• Stratégie de réponse : le mode passif offre davantage de contrôle ; le mode adaptatif est plus proactif, mais demande à être vérifié.
• Gestion des permissions : le partage entre groupes nécessite une approbation. L’autorisation peut être ponctuelle ou permanente, et reste révocable.
• Collaboration hybride : cloud, appareils locaux, équipes d’experts et agents tiers peuvent se retrouver dans un même espace de collaboration.
• Démarche de validation : vérifiez d’abord la documentation du projet, puis testez les étapes faisant intervenir les modèles avec APIYI apiyi.com.

Conclusion : les enseignements architecturaux d’openJiuwen Hyper-Agent

L’intérêt d’openJiuwen Hyper-Agent ne se limite pas à l’arrivée des agents dans Feishu ou DingTalk. Le projet concrétise dans sa conception une idée plus large : faire passer la session du statut de conteneur à celui de ressource.

1. Une identité persistante : le Persistent Agent conserve la continuité de son travail au-delà d’une seule session.
2. L’orchestration au centre : AgentServer coordonne les agents et plusieurs sessions de travail.
3. La gouvernance conditionne le déploiement : l’approbation des permissions, le contrôle des prises de parole et le suivi de l’utilisation déterminent si le système peut être adopté par de vraies équipes.

Si votre travail repose sur la collaboration entre plusieurs groupes, le suivi à long terme et les livrables sur plusieurs canaux, ce modèle mérite d’être étudié. Si vos processus impliquent des données sensibles ou des exigences strictes de conformité, mieux vaut commencer par un pilote isolé, en mode passif et avec des permissions minimales. Pour les décisions faisant intervenir des modèles, APIYI apiyi.com permet de comparer plusieurs modèles avec une même interface et de recueillir des données pour vos futurs choix techniques.

📚 Références

1. Pandaily – openJiuwen’s Hyper-Agent Swarm Puts Persistent AI Agents Into Work Chats as Digital Employees : principale source factuelle de cet article
2. Lien : pandaily.com/openjiuwen-hyper-agent-swarm-architecture-persistent-agents-workswarm-digital-employees
3. Description : présentation de l’architecture Hyper-Agent, des fonctionnalités de WorkSwarm et des projets à venir de la communauté. Il s’agit d’un article de seconde main fondé sur un texte de la communauté.

Auteur : équipe technique APIYI
Échanges techniques : contactez-nous depuis la page d’accueil du site APIYI. Pour plus de ressources, consultez le centre de documentation docs.apiyi.com.