Von „Chatsitzungen“ zu „dauerhaften digitalen Mitarbeitern“: 5 wichtige Veränderungen in der openJiuwen Hyper-Agent-Architektur

Anmerkung des Autors: Dieser Artikel erklärt die Architektur der dauerhaft aktiven Agenten von openJiuwen Hyper-Agent und hilft Teams, die Workflows erstellen, einzuschätzen, ob sich dieses Modell für sie eignet.

Die von Huawei unterstützte Open-Source-Agenten-Community openJiuwen hat die Schwarmarchitektur Hyper-Agent vorgestellt. Sie löst Agenten aus einzelnen Chat-Sitzungen und bringt sie als „dauerhaft aktive digitale Mitarbeiter“ in reale Arbeitsgruppen. Pandaily berichtete am 5. November 2026 unter Berufung auf einen bei IT之家 veröffentlichten Community-Beitrag, dass die Funktionen in openJiuwen WorkSwarm verfügbar sind. Der Code ist unter dem Namen JiuwenSwarm auf GitHub quelloffen verfügbar.

Es geht nicht darum, einem Gruppenchat einfach einen weiteren Frage-Antwort-Bot hinzuzufügen. Die eigentliche Veränderung liegt darin, dass sich das Verhältnis zwischen Agent und Sitzung umkehrt: Die Sitzung ist nicht mehr der Container für den Agenten, sondern eine Ressource, die das System steuern kann.

Das Wichtigste auf einen Blick: Dieser Artikel ordnet einzelne Funktionen aus architektonischer Sicht ein. Er zeigt, was openJiuwen Hyper-Agent verändert und was Teams vor dem Einsatz prüfen sollten.

openJiuwen Hyper-Agent: Das Wichtigste im Überblick

Die Fakten in diesem Artikel beruhen auf einer Sekundärquelle zu einem Community-Beitrag. Der Bericht nennt weder die zugrunde liegenden Modelle noch Anforderungen an die Bereitstellung, Lizenz oder Produktionsreife. Diese Angaben sollten anhand des GitHub-Repositories und der offiziellen Dokumentation überprüft werden.

Wie openJiuwen Hyper-Agent Sitzungen zu Ressourcen macht

Viele Agentenanwendungen arbeiten nach dem Muster „eine Sitzung, ein Agent“: Der Nutzer öffnet einen Chat, und der Agent nimmt seine Arbeit auf. Identität, Kontext und Aufgabenfortschritt sind dabei an diesen Chat gebunden. Wer die Gruppe oder das Fenster wechselt, muss die Zusammenarbeit oft von vorn beginnen.

Hyper-Agent geht den umgekehrten Weg. Ein Persistent Agent besitzt eine unabhängige Identität und einen eigenen Zustand und kann fortlaufend Aufgaben entgegennehmen. Sitzungen werden zu Ressourcen auf einer niedrigeren Ebene: Das System weist sie zu, koordiniert ihre parallele Nutzung und stellt bei der Wiederaufnahme den Kontext bereit. Laut Community baut dieses Design auf der früheren Arbeit an Persistent Session auf. Dadurch kann ein Agent gleichzeitig mehrere Aufgaben in verschiedenen Gruppenchats von Drittanbietern betreuen.

Zur Grafik: Links ist der Zustand an die Sitzung gebunden, rechts an den Agenten. Wer den Kontext-Overhead mit eigenen geschäftlichen Dialogen vergleichen möchte, kann über die einheitliche Schnittstelle von APIYI apiyi.com Versuche im kleinen Rahmen durchführen.

Die 5 Schlüsselkomponenten der openJiuwen-Hyper-Agent-Architektur

Den Berichten zufolge lässt sich das System in fünf Bereiche unterteilen: Anbindung, Steuerung, Identitätsverwaltung, Zusammenarbeit und Beobachtung. Die folgende Tabelle fasst die Architektur nach Zuständigkeiten zusammen; es handelt sich nicht um eine offizielle Schichteneinteilung.

Hyper-Agent-Mitarbeiterzentrum und Kontextübergabe

Im Mitarbeiterzentrum können Benutzer Zuständigkeiten, Arbeitsstil, Anforderungen an die Ergebnisse, Fähigkeiten, Konnektoren, Wissensquellen und sogar eine eigene E-Mail-Adresse konfigurieren. Damit wird die Konfiguration der Eingabeaufforderung zu einer Art „Stellenbeschreibung“ erweitert: Hier werden sowohl die Grenzen der Fähigkeiten des Agenten als auch seine Identität nach außen definiert.

Bei länger laufenden Aufgaben wird zwangsläufig die Grenze des Kontextfensters erreicht. WorkSwarm wechselt daher zu einem neuen Fenster, wenn sich das bisherige dem Limit nähert. Dabei übernimmt es eine Übergabezusammenfassung mit Zielen, Fortschritt und den nächsten geplanten Schritten. Werden Details benötigt, durchsucht es den archivierten Verlauf. So lässt sich die Arbeit fortsetzen, ohne den gesamten Verlauf in das aktuelle Fenster packen zu müssen.

Passiver und adaptiver Modus von Hyper-Agent

Ob ein Agent in einem Arbeitsgruppen-Chat mitreden sollte, ist eine zentrale Frage beim dauerhaften Einsatz. WorkSwarm bietet zwei Antwortmodi, die sich vor allem darin unterscheiden, wie vorhersehbar ihr Verhalten ist.

Der Bericht nennt weder den konkreten Entscheidungsmechanismus noch die Trefferquote des adaptiven Modus. Teams können mit einem vereinfachten Experiment zunächst ein Gefühl für die Schwierigkeiten solcher Entscheidungen bekommen. Der folgende Code dient lediglich zur Veranschaulichung und ist keine Implementierung von 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:
    """Verdichtet Arbeitsprotokolle zu Zielen, Fortschritt und nächsten Schritten, um eine Kontextübergabe zu simulieren."""
    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))

Experimentier-Tipp: Über APIYI auf apiyi.com können Sie zunächst kostenloses Testguthaben erhalten und mit anonymisierten Gruppenchat-Beispielen die Entscheidungen verschiedener Modelle vergleichen. Damit prüfen Sie die Entscheidungslogik – es bedeutet nicht, dass WorkSwarm diese Schnittstelle bereits unterstützt.

Zusammenarbeit des openJiuwen Hyper-Agent über Gruppen und lokale Geräte hinweg

Ein und derselbe Agent kann in verschiedenen Office-Anwendungen wie Feishu und DingTalk arbeiten – etwa Anfragen über einen Kanal entgegennehmen und die Ergebnisse über einen anderen liefern. Das Teilen zwischen Gruppen ist nicht standardmässig freigegeben: Nutzer müssen die Quellgruppe, die Empfänger und den Inhalt prüfen und anschliessend eine einmalige oder dauerhafte Berechtigung erteilen. Diese lässt sich später auch wieder widerrufen.

Teammitglieder können WorkSwarm auch auf ihren eigenen Geräten ausführen. Agenten auf Cloud-Servern und PCs können in derselben Gruppe zusammenarbeiten und lokal freigegebene Dateien und Tools nutzen. So bleibt der Cloud-Agent dauerhaft online, während lokale Geräte Daten und Tools aus der persönlichen Arbeitsumgebung bereitstellen.

Bei grösseren Aufgaben kann ein SwarmEngine-Gruppenchat Nutzer, Persistent Agents, einzelne Experten und Expertenteams in einem gemeinsamen Raum zusammenbringen. In einem Expertenteam nimmt die verantwortliche Person Aufgaben entgegen, berichtet über den Fortschritt und organisiert die Auslieferung, während die Mitglieder im Hintergrund arbeiten. Experten können auch aus Drittanbieter-Agenten wie Codex und Claude Code stammen und mit selbst entwickelten digitalen Mitarbeitern zusammenarbeiten.

Auswirkungen von openJiuwen Hyper-Agent

Auswirkungen auf Entwickler und Workflow-Builder

• Verschiebung des Designschwerpunkts: Statt einzelner Dialoge stehen Identität, Status, Berechtigungen und Übergabemechanismen von Agenten im Mittelpunkt.
• Höhere Betriebsanforderungen: Dauerhaft aktive Agenten müssen wie produktive Dienste überwacht, auditiert und verwaltet werden.
• Umfangreichere Integration: Messenger, Wissensdatenbanken, E-Mail und lokale Tools können Teil derselben Aufgabenkette werden.

Auswirkungen auf die Zusammenarbeit im Team

• Vom Werkzeug zum Teammitglied: Ein Agent kann Aufgaben langfristig begleiten, statt nur auf einzelne Fragen zu reagieren.
• Governance frühzeitig klären: Wer Daten teilen darf, wann sich der Agent zu Wort meldet und wer für Ergebnisse verantwortlich ist, muss im Voraus festgelegt werden.
• Hybride Orchestrierung wird zum Bewertungsschwerpunkt: Wie sich selbst erstellte Mitarbeiter und Agenten von Drittanbietern die Arbeit teilen, beeinflusst die Qualität der Ergebnisse und die Verteilung der Verantwortung.

Wichtige Kriterien für die Bewertung von Hyper-Agent im Team

Häufige Fragen zu openJiuwen Hyper-Agent

openJiuwen Hyper-Agent: Die wichtigsten Punkte

• Architekturprinzip: Der Agent behält seine Identität und seinen Zustand; Sitzungen werden zu planbaren Ressourcen.
• Kernkomponenten: Das Gateway übernimmt die Anbindung, der AgentServer die Koordination von Agenten und Sitzungen.
• Langfristiger Betrieb: Übergabezusammenfassungen ermöglichen Kontextwechsel; archivierte Verläufe werden bei Bedarf abgerufen.
• Antwortstrategie: Der passive Modus ist besser kontrollierbar, der adaptive Modus proaktiver, muss aber überprüft werden.
• Berechtigungen: Das Teilen zwischen Gruppen erfordert eine Genehmigung. Berechtigungen können einmalig oder dauerhaft erteilt und widerrufen werden.
• Hybride Zusammenarbeit: Cloud, lokale Geräte, Expertenteams und Drittanbieter-Agenten können im selben Arbeitsbereich zusammenarbeiten.
• Validierung: Zuerst die Projektdokumentation prüfen, anschließend die Modellkomponenten mit APIYI apiyi.com testen.

Fazit: Architekturimpulse durch openJiuwen Hyper-Agent

openJiuwen Hyper-Agent ist nicht nur deshalb interessant, weil Agenten in Feishu oder DingTalk eingebunden werden. Entscheidend ist, dass das System eine Sitzung nicht mehr als Container, sondern als Ressource behandelt:

1. Dauerhafte Identität: Ein Persistent Agent verliert seine Arbeitskontinuität nicht mehr, wenn eine einzelne Sitzung endet.
2. Koordination als Kernaufgabe: Der AgentServer koordiniert Agenten und mehrere Arbeitssitzungen.
3. Governance entscheidet über den Einsatz: Berechtigungsgenehmigungen, Kontrolle der Beiträge und Nutzungsüberwachung bestimmen, ob sich das System in echten Teams einsetzen lässt.

Wenn Ihre Arbeit die Zusammenarbeit über mehrere Gruppen, langfristige Nachverfolgung und kanalübergreifende Bereitstellung erfordert, lohnt sich ein genauerer Blick auf dieses Modell. Bei sensiblen Daten oder strengen Compliance-Anforderungen empfiehlt sich zunächst ein isoliertes Pilotprojekt im passiven Modus und mit minimalen Berechtigungen. Für die modellgestützten Entscheidungen können Sie über APIYI apiyi.com mehrere Modelle über dieselbe Schnittstelle vergleichen und so Daten für die spätere Technologieauswahl sammeln.

📚 Quellen

1. Pandaily – openJiuwen’s Hyper-Agent Swarm Puts Persistent AI Agents Into Work Chats as Digital Employees: wichtigste Faktenquelle dieses Artikels
2. Link: pandaily.com/openjiuwen-hyper-agent-swarm-architecture-persistent-agents-workswarm-digital-employees
3. Hinweis: Der Beitrag beschreibt die Architektur von Hyper-Agent, die Funktionen von WorkSwarm und die weiteren Pläne der Community. Es handelt sich um eine Sekundärquelle, die auf einem Community-Beitrag basiert.

Autor: APIYI-Technikteam
Technischer Austausch: Kontaktieren Sie uns über die Startseite von APIYI. Weitere Informationen finden Sie im Dokumentationszentrum unter docs.apiyi.com.