Das Unternehmen hat in den letzten zwei Jahren zahlreiche KI‑Tools angeschafft: Chat‑Assistenten, Schreib‑Plugins, Kundenservice‑Bots sowie interne Wissensfragen‑ und Antwortsysteme. Doch wirklich nachhaltige Kompetenzen sind nur wenige entstanden. Die Prompt‑Texte liegen noch auf dem persönlichen Computer, die Geschäftsprozesse sind in den Ecken der Dokumente verstreut, nach dem Go‑Live der intelligenten Agenten fehlen Feedback und Anpassungen, und die Schlüsselmitarbeiter werden weiterhin von denselben Arten von Beratungsanfragen über Stunden hinweg belastet. Das Problem liegt oft nicht darin, dass die Modelle nicht klug genug sind, sondern…Das System hat „Arbeit verrichten“ nicht als verwaltbare Kompetenz für Stellen konzipiert.。
Zunächst klären wir: Warum kann das Chat-Fenster nicht als Position fungieren?
Der Chatbot beendet die Konversation nach einer einzigen Frage. Eine Stelle muss die Arbeit kontinuierlich übernehmen: Informationen sammeln, Regeln prüfen, Systeme aufrufen, Status zurückschreiben und bei Ausnahmen weiterleiten. Die Reisekostenabrechnung ist ein typisches Beispiel – der Nutzer sagt zunächst „Bitte erstelle meine Reisekostenabrechnung“, fragt zwischendurch „Wie viel Budget bleibt für diesen Monat noch übrig?“ und fügt anschließend eine weitere Rechnung hinzu. Würde das System jeden Dialog als neue Sitzung behandeln, würde der Prozess unterbrochen, der Kontext verloren gehen und im Nachhinein wäre nicht mehr nachvollziehbar, ob ein Fehler in den Regeln oder in der Schnittstelle vorlag.
In der Branche gibt es bereits Ansätze, Agenten als „digitale Mitarbeiter“ zu konzipieren: Man weist ihnen eine Stelle, eine Personalnummer, klare Kompetenzgrenzen und Arbeitsprotokolle zu und ergänzt dies mit anpassbaren SOPs, einer Wissensdatenbank, entsprechenden Tools sowie einem nachvollziehbaren Ausführungsverlauf. Im Open-Source‑Bereich stellt etwa StaffDeck, veröffentlicht von Organisationen wie OpenBMB, den Agenten als betreibbare Ressourcenkomposition dar – und nicht als bloßen Prompt. Für unternehmenseigene Entwicklungen oder maßgeschneiderte Lösungen sind weniger die Produktbezeichnungen als vielmehr dieses Objektmodell von Nutzen.
Geschäftslogik: Das System muss mindestens sieben Arten von Objekten enthalten.
Bei der Entwicklung eines digitalen Mitarbeitersystems werden zunächst die Geschäftsbereiche in die Spezifikationen eingearbeitet, bevor über die Auswahl des Modells entschieden wird.
- Stellenprofil: Name oder Rollenname, Mitarbeiternummer, Verantwortungsbereich, Online-Status, Dienstleistungsempfänger. Ohne Akte sind Berechtigungen und Leistungsbeurteilungen nicht zuordnenbar.
- Fähigkeitsgrenze: Welche Dokumente können gelesen, welche Felder können geschrieben und was kann nicht zugesagt werden. Die Grenzen müssen vom Administrator änderbar sein und dürfen nicht fest im Prompt verankert sein.
- SOP / Prozessbezogene Fähigkeiten: Zerlegen Sie komplexe Prozesse in einzelne Knoten und unterstützen Sie bedingte Verzweigungen, Tool-Aufrufe, Wissenssuche sowie die Weiterleitung an einen menschlichen Mitarbeiter.
- Wissensontologie: Themen, Regeln, Quellen und Handbücher werden separat gespeichert; die Antworten müssen sich eindeutig auf die jeweiligen Quellen beziehen, und die Recherche muss anpassbar sein.
- Tool-Integration: HTTP‑Schnittstelle oder MCP, um Kreditlimits abzufragen, Dokumente zu erstellen und Statusänderungen vorzunehmen, statt lediglich einen Text zu generieren.
- Zeitgesteuerte Aufgaben: Tagesberichte, Fristüberziehungs‑Nachverfolgung und Bestandsinspektionen sind wiederkehrende Aufgaben, die nicht darauf warten können, dass der Nutzer zuerst das Wort ergreift.
- Spur und Rückmeldung: Protokollierung von Routen, Schritten, Tools, Wissen und Antworten; Likes, Dislikes sowie die manuelle Übernahme gehen in die nächste Überarbeitungsphase.
Eine echte Anfrage umfasst häufig mehrere Aufgaben. Digitale Mitarbeiter müssen zunächst in den SOP für die Abrechnung einsteigen, alle erforderlichen Felder sammeln und entsprechende Regeln prüfen, bevor sie zum SOP zur Kreditlimitabfrage wechseln, um dort eine Schnittstelle aufzurufen. Wenn der Nutzer zwischendurch Fragen zur Richtlinie stellt, sollte der aktuelle Knoten gespeichert und nach Beantwortung der Frage wieder zum ursprünglichen Ablauf zurückgekehrt werden. Bei Fragen, die über die festgelegten Regeln hinausgehen, ist der Kontext an den Ersteller oder den diensthabenden Mitarbeiter weiterzugeben; eine unbegründete, kategorische Antwort ist zu unterlassen.
Designlogik: Rollen, Zustandsmaschine, Wissenshierarchie
Wie wird die Rolle geändert?
Mindestens vier Kategorien von Menschen:Ersteller(Die Erfahrungen in die Mitarbeiter verankern),Administrator(Verwaltung von Berechtigungen, Veröffentlichung, Quoten),Benutzer(Aufgaben an digitale Mitarbeiter verteilen),Diensthabender(Weiterhin Ausnahme). Der Ersteller sollte nicht standardmäßig über die Berechtigung verfügen, den Bestand oder die Preise zu ändern; der Nutzer sollte weder die vollständigen Hinweiswörter noch den Schlüssel einsehen können. Auch die offenen Schnittstellen sind zu hierarchisieren: Ein Schlüssel auf Kontoebene kann die Ressourcenkonfiguration steuern, während ein Schlüssel auf Mitarbeiterebene lediglich Sitzungen erstellen und die eigenen Aktivitäten einsehen darf.
SOP verwendet einen Zustandsautomaten, nicht nur Dialogspeicher.
Natürliche Sprache kann einen ersten Entwurf generieren; die Ausführung muss über einen Zustandsautomaten ablaufen: aktueller Knoten, bereits gesammelte Slots, aufrufbare Tools, Fehlerversuche und manuelle Knoten. Nach einer Unterbrechung des Auftrags muss der Kontext serialisiert werden, damit an den ursprünglichen Knoten zurückgekehrt und fortgesetzt werden kann. Mehrere SOPs ermöglichen einen Echtzeitwechsel, wobei beim Wechsel jedoch „Woher kommt es und welche bestätigten Informationen wurden mitgeführt“ festgehalten werden müssen, um zu vermeiden, dass Nutzer Formulare erneut ausfüllen müssen. Versionen und Branches müssen rückgängig gemacht werden können; selbst wenn vor Ort ein einziger Hinweiswort‑Text geändert wird, tritt die Änderung sofort in Kraft, und im Nachhinein kann keine Haftung mehr geltend gemacht werden.
Wissen sollte nicht zu einem Sammelsurium an Suchergebnissen werden.
Erstellen Sie ein navigierbares Indexsystem nach Dokumenten, Kapiteln, Seiten und Zusammenfassungen; zunächst wird ermittelt, in welcher Kategorie die Information vermutlich zu finden ist, anschließend erfolgt die Lokalisierung des Originaltextes. Wissensaufteilung in Behälter: Regelwerke, Produktbeschreibungen, After-Sales‑Redewendungen und Ausnahmefälle werden getrennt gehalten; eine zielgerichtete Suche ist stabiler als eine umfassende Stichwortsuche. Jede Antwort ist mit Quelle, Regeln und Geschäftsthema verknüpft; im Testumfeld muss ersichtlich sein, „warum genau dieser Abschnitt ausgelöst wurde“. Oft lassen sich Probleme besser durch Such‑Debugging lösen als durch den Einsatz eines noch größeren Modells.
Entwicklung und Implementierung: Schnittstellen, Isolierung, Überwachung, Abnahme
Zur Laufzeit wird empfohlen, einen einheitlichen Einstiegspunkt zu verwenden, um zu vermeiden, dass jede Fähigkeit einen eigenen Pfad durchläuft und dadurch zu Statusdrift führt. Die Erkennung von Fähigkeiten, deren isolierte Ausführung, die Integrität der Artefakte sowie die Quotenabrechnung sollten zur Laufzeit erfolgen und nicht auf Vereinbarungen basieren. Vor der Veröffentlichung einer Fähigkeit im internen Marktplatz ist eine Berechtigungsprüfung durchzuführen: Authentifizierungskopfzeilen, Umgebungsvariablen und Verbindungszugangsdaten dürfen in normalen Lese‑APIs nicht vorkommen.
- Ausführungschannel: Der synchrone Streaming‑Modus eignet sich für Dialoge; der asynchrone Run‑ plus‑Event‑Stream ist für die Wiederaufnahme nach Unterbrechungen und für Aufgabenwarteschlangen geeignet. Beide nutzen denselben Kern.
- Kanalidentität: WeChat, WeCom, Feishu und DingTalk können als Zugangspunkte dienen, doch die Mitarbeiteridentitäten, Konversationen und Traces müssen einheitlich sein; es ist untersagt, auf den einzelnen Kanälen jeweils eine eigene Datenspeicherung einzurichten.
- Sicherheit: Die Modellkonfiguration verweist nur auf bereits vorhandene Konfigurationsnummern und gibt den Anbieter‑Schlüssel nicht zurück; bei der Übermittlung der Tool‑Ergebnisse in Trace werden diese anonymisiert.
- Künstliche Absicherung: Bei Zeitüberschreitung, geringer Zuverlässigkeit, Berechtigungsverletzung sowie bei einer vom Nutzer initiierten Überleitung zum Kundendienst muss der gesamte Kontext vollständig übergeben werden.
Bei der Abnahme darf nicht nur geprüft werden, ob „gechattet werden kann“. Legen Sie eine Reihe wiederholbarer Testskripte fest: normale Closed-Loop‑Abwicklung, Unterbrechung durch Zwischenfragen, unzureichendes Kontingent, Schnittstellen‑Timeout, unrechtmäßige Schreibvorgänge und Antworten ohne Quelle. Für jedes Skript ist zu überprüfen: Ob die Knoten wiederhergestellt sind, ob die Dokumente korrekt geschrieben wurden, ob der Trace vollständig ist und ob Ausnahmen an die zuständigen Personen weitergeleitet werden. Die Quote der bestandenen Stichproben, die Rate der Timeout‑Behandlungen sowie die Anzahl der Antworten ohne sachliche Grundlage eignen sich besser als die Zufriedenheitssterne als Zugangskriterien für die Inbetriebnahme.
Online-Schaltreihenfolge: Zuerst eine Phase mit wiederholter Arbeit
Beginnen Sie nicht gleich damit, einen Allround‑Assistenten zu entwickeln. Wählen Sie zunächst eine Aufgabe aus, die im Verkaufs‑Follow‑Up‑Protokoll, bei der Genehmigungs‑Nachverfolgung, in den System‑Fragen und -Antworten oder bei der Kosten‑Vorabprüfung täglich mehr als eine halbe Stunde lang wiederholt wird; formulieren Sie Eingaben, Ausgaben, Berechtigungen und Ausnahmen in vier Sätzen und ergänzen Sie dies mit einem SOP sowie zwei bis drei schreibgeschützten oder eingeschränkt schreibbaren Schnittstellen. Wenn die Stammdaten ungenau sind oder die Genehmigungsknoten nicht klar definiert sind, sollten Sie zuerst die betroffenen Objekte und Status nachtragen und erst dann die intelligente Ausführung einbinden – sobald die Datenqualität automatisiert verbessert wurde, verbreiten sich die Informationen im gesamten Unternehmen noch schneller.
Wie lässt sich feststellen, ob das Design richtig umgesetzt wurde: Die frühere Phase, in der man auf Gruppennachverfolgung und Tabelleneintragungen angewiesen war, gehört nicht mehr zum Hauptprozess; Protokolle, Nachverfolgungen und Zusammenfassungen können anhand von Belegen stichprobenartig überprüft werden; bei unklaren Fällen gibt es ein Eskalationsobjekt; sensible Vorgänge werden geprüft, und die Protokolle sind einsehbar. Um zu beurteilen, ob die Entwicklung den Anforderungen entspricht, gilt es zu prüfen…Kann derselbe SOP nach einer Unterbrechung wieder aufgenommen werden?、Antwort: Kann auf die Quelle verwiesen werden?、Können Grenzfälle in die nächste Überarbeitungsrunde übergehen?. Wenn diese drei Punkte erfüllt sind, kann man die Stellen weiter ausbauen; das ist stabiler, als zuerst zahlreiche Chat‑Einstiegspunkte einzuführen.
Die technische Schwierigkeit des Digital‑Employee‑Systems liegt nicht in der Dialoggenerierung, sondern darin, Stellen, Prozesse, Wissen, Werkzeuge und Abläufe in versionierbare Softwareobjekte zu überführen. Prompte können zwar zehnmal pro Woche angepasst werden; doch sobald das Objektmodell auseinanderfällt, müsste jeder nachfolgende Skill jeweils eine eigene Implementierung erhalten. Zunächst müssen diese sieben Kategorien von Objekten sowie die Zustandsmaschine gründlich zum Laufen gebracht werden; erst dann lässt sich das Modell problemlos aktualisieren. Andernfalls würde jeder Modellwechsel zu einem neuen Projekt – statt zu einer reinen Konfigurationsänderung – führen.