KI-Agenten Fachwissen beibringen: Knowledge Base und Skills

Ihre Antworten klingen fachlich plausibel, führen aber bei Sonderfällen zu falschen Abläufen oder riskanten Tool-Aufrufen.

Die schnellste belastbare Lösung ist ein Vier-Schichten-Modell: Die Knowledge Base liefert belegbares Wissen, Agent Skills beschreiben stabile Arbeitsabläufe, Tools führen kontrollierte Aktionen aus und ein Evaluationsset prüft, ob der Agent tatsächlich zuverlässig arbeitet.

Wer nur RAG ergänzt oder nur ein langes Skill-Dokument schreibt, erhält noch keinen fachkundigen Agenten. Sie brauchen klare Zuständigkeiten zwischen Wissen, Prozess, Ausführung und Qualitätsprüfung.

Dieser Beitrag richtet sich an:

• AI-Ingenieure, die einen Agenten für Softwareentwicklung, Betrieb, Design oder Support bauen,
• Plattformteams, die interne SOPs und dynamische Informationen zusammenführen müssen,
• Projektverantwortliche, die einen Domänen-Agenten in einer dauerhaft laufenden Umgebung abnehmen wollen.

1. Trennen Sie Wissen, Ablauf, Aktion und Nachweis

Der häufigste Architekturfehler besteht darin, alle Informationen in einen System-Prompt oder in eine einzige Dokumentensammlung zu legen. Dadurch ist später kaum noch feststellbar, ob ein Fehler aus einer veralteten Quelle, einer unklaren Prozessbeschreibung, einem zu mächtigen Tool oder einer fehlenden Prüfung entstanden ist.

Die vier Schichten haben deshalb unterschiedliche Aufgaben:

Diese Trennung ist kein theoretisches Modell. Dokumentationssysteme für Retrieval unterstützen beispielsweise Text-, Vektor- und multimodale Suche, während moderne Agenten-SDKs Tools, Guardrails, Sitzungen und Nachverfolgung als getrennte Laufzeitbausteine behandeln. Die offizielle Dokumentation zu Retrieval-Systemen und die Dokumentation zu Agent-Laufzeit, Tools und Guardrails beschreiben diese Verantwortlichkeiten ebenfalls getrennt.

Knowledge Base und Agent Skills haben also nicht dieselbe Aufgabe. Die Wissensbasis beantwortet fachliche Fragen anhand versionierter Quellen. Ein Skill legt dagegen fest, wie der Agent eine wiederkehrende Aufgabe bearbeitet. Ein Skill kann auf die Knowledge Base verweisen, sollte sie aber nicht vollständig duplizieren.

2. Bauen Sie zuerst eine rückverfolgbare Knowledge Base

Eine Knowledge Base ist nur dann nützlich, wenn Sie die Herkunft einer Aussage prüfen können. Ein Textabschnitt ohne Quelle, Gültigkeitsbereich und Versionsstand ist für einen Produktions-Agenten nicht verlässlicher als eine zufällige Modellantwort.

Beginnen Sie deshalb nicht mit dem Embedding-Modell, sondern mit einem Quellenregister. Für jedes Dokument sollten Sie mindestens folgende Metadaten verwalten:

• fachlicher Eigentümer,
• Dokumenttyp und Gültigkeitsbereich,
• Version oder Änderungskennung,
• Erstellungs- und Aktualisierungsdatum,
• Freigabestatus,
• Zugriffsgruppe,
• Quelle und Originalpfad,
• Ablauf- oder Prüfdatum.

Besonders wichtig ist die Unterscheidung zwischen statischem Fachwissen und dynamischen Fakten. Eine Erklärung zum internen Code-Review-Prozess kann als stabiler Wissensbestandteil gelten. Der aktuelle Bereitschaftsplan, ein laufender Incident oder die Belegung einer Rechenressource darf dagegen nicht als dauerhafte Skill-Regel gespeichert werden. Solche Daten gehören in eine aktuelle Quelle oder in ein Tool.

Beim Chunking sollten Sie die fachliche Bedeutung erhalten. Ein Abschnitt mit einer Ausnahmebedingung darf nicht so zerschnitten werden, dass die Bedingung vom eigentlichen Verfahren getrennt im Index landet. Für technische Dokumente sind Überschrift, Versionsnummer, Produktbereich und Gültigkeit oft wichtigere Metadaten als eine möglichst kleine Textlänge.

Die Antwort des Retrieval-Schritts sollte deshalb nicht nur Text liefern, sondern strukturierte Belege:

{
  "source_id": "runbook-incident-042",
  "title": "Incident-Prozess Datenbank",
  "version": "2026-07",
  "valid_from": "2026-07-01",
  "owner": "Plattformbetrieb",
  "access_scope": "betrieb-intern",
  "evidence": "Bei hoher Fehlerquote zuerst den Read-only-Status prüfen.",
  "source_url": "interner-originalpfad"
}

Damit kann der Agent Quellen vergleichen, den Gültigkeitsbereich beachten und eine Antwort verweigern, wenn keine aktuelle Grundlage vorhanden ist. Retrieval-gestützte Systeme können zusätzlich Berechtigungsmetadaten aus dem Speichersystem übernehmen; diese Funktion muss aber in Ihrer konkreten Umgebung geprüft und getestet werden, statt sie automatisch vorauszusetzen. Die technische Übersicht zu RAG und Berechtigungsmetadaten beschreibt dieses Prinzip.

3. Entscheiden Sie, ob Wissen in RAG, Skill oder Tool gehört

Soll Domänenwissen in RAG oder in einen Skill? Die Antwort hängt davon ab, ob sich der Inhalt häufig ändert und ob der Agent ihn zitieren oder als Handlungsregel verwenden muss.

Nutzen Sie die Knowledge Base beziehungsweise RAG für:

• umfangreiche Dokumentbestände,
• Richtlinien mit Versions- und Zugriffsregeln,
• wechselnde Produkt- oder Betriebsinformationen,
• Fallwissen, das nur bei bestimmten Fragen benötigt wird,
• Aussagen, die auf eine Originalquelle zurückgeführt werden müssen.

Nutzen Sie Agent Skills für:

• stabile Schrittfolgen,
• Entscheidungsbäume,
• verpflichtende Prüfpunkte,
• definierte Ausgabeformate,
• Regeln dafür, wann ein Tool aufgerufen oder eine Aufgabe abgelehnt wird.

Nutzen Sie Tools für:

• aktuelle Statusabfragen,
• Berechnungen und Validierungen,
• das Lesen oder Ändern von Tickets,
• Dateioperationen,
• Deployments, Neustarts oder andere externe Aktionen.

Eine einfache Entscheidungsregel lautet: Wenn sich eine Information ändern kann, ohne dass der Arbeitsablauf selbst geändert wird, gehört sie in die Knowledge Base. Wenn der Ablauf stabil bleibt, aber seine Quellen wechseln, bleibt der Ablauf im Skill und die Quelle im Retrieval-System. Wenn eine Handlung einen externen Zustand verändert, muss sie als Tool mit eigenen Rechten und Prüfungen behandelt werden.

Ein Skill sollte daher nicht das gesamte Handbuch enthalten. Offizielle Dokumentation zu Agent Skills beschreibt Skills als wiederverwendbare, dateibasierte Ressourcen mit Anweisungen, Metadaten und optionalen Hilfsdateien. Die Inhalte werden schrittweise geladen, wenn sie für eine Aufgabe relevant sind. Die Übersicht zur Skill-Struktur und zum progressiven Laden erläutert dieses Muster.

4. Schreiben Sie Agent Skills als ausführbare SOP

Ein gutes Agent Skill ist keine Sammlung allgemeiner Ratschläge wie „arbeiten Sie sorgfältig“. Es muss eine Aufgabe so beschreiben, dass ein anderer Ingenieur daraus einen prüfbaren Ablauf ableiten könnte.

Strukturieren Sie jedes Skill-Dokument mindestens in diese Bereiche:

1. Auslöser: Woran erkennt der Agent, dass das Skill passt?
2. Voraussetzungen: Welche Informationen, Quellen oder Berechtigungen müssen vorhanden sein?
3. Schritte: In welcher Reihenfolge wird gearbeitet?
4. Bedingungen: Wann wird ein alternativer Pfad gewählt?
5. Abbruchregeln: Wann muss der Agent stoppen oder einen Menschen fragen?
6. Ausgabeformat: Welche Felder, Nachweise und Quellen sind verpflichtend?
7. Prüfung: Woran erkennt der Agent, dass die Aufgabe erfolgreich beendet ist?

Ein vereinfachtes Beispiel für ein Skill zur Incident-Zusammenfassung könnte so aussehen:

Name: incident-summary
Auslöser: Wenn ein Incident-Bericht aus Logs und Tickets erstellt werden soll.

Voraussetzungen:
- Incident-ID ist vorhanden.
- Zugriff auf die freigegebenen Log- und Ticketquellen ist möglich.
- Quellen müssen innerhalb des gültigen Zeitfensters liegen.

Ablauf:
1. Incident-Metadaten lesen.
2. Relevante Ereignisse nach Zeit und Dienst filtern.
3. Aussagen mit mindestens einer Quelle belegen.
4. Widersprüche markieren, nicht eigenständig auflösen.
5. Entwurf als Zusammenfassung ausgeben.

Abbruch:
- Keine aktuelle Quelle verfügbar.
- Zugriffsschutz verhindert die Prüfung.
- Ein Schreibvorgang wäre erforderlich.

Ausgabe:
- Zeitraum
- betroffene Komponente
- beobachtete Symptome
- belegte Ursache
- offene Unsicherheiten
- Quellen

Die Beschreibung muss außerdem klar sagen, wann das Skill nicht verwendet werden darf. Das verhindert, dass der Agent ein Verfahren auf ähnliche, aber ungeeignete Aufgaben überträgt. Für größere Skill-Sammlungen sollten Sie Namen, Versionen und Änderungsnotizen verwalten. Skills beanspruchen denselben Kontext wie die eigentliche Anfrage; unnötige Wiederholungen vergrößern daher den Prompt und erschweren die Pflege. Die Empfehlungen für robuste Skill-Autorenschaft liefern dafür konkrete Leitlinien.

5. Begrenzen Sie Tool-Aufrufe nach Risiko und Zuständigkeit

Ein Agent kann fachlich korrekt antworten und trotzdem gefährlich handeln, wenn seine Tools zu weitreichende Rechte besitzen. Die entscheidende Frage lautet nicht nur, ob ein Tool verfügbar ist, sondern unter welchen Bedingungen es aufgerufen werden darf.

Teilen Sie Tools mindestens in vier Klassen:

• Lesen: Status, Dokumente, Logs oder Tickets abfragen.
• Validieren: Eingaben prüfen, Konfigurationen vergleichen oder Simulationen ausführen.
• Schreiben: Kommentare, Tickets, Dateien oder Konfigurationen ändern.
• Ausführen: Deployments, Neustarts, Löschungen oder produktive Änderungen anstoßen.

Für jede Funktion sollten Sie Eingabeschema, Identitätskontext, erlaubte Zielobjekte, Zeitüberschreitung, Protokollierung und Fehlerformat definieren. Ein Tool darf nicht einfach „Deployment durchführen“ heißen. Es sollte beispielsweise eine Zielumgebung, eine Versionskennung, eine Begründung und eine Freigabereferenz verlangen.

Das Ergebnis muss strukturiert zurückkommen:

{
  "status": "rejected",
  "reason_code": "approval_missing",
  "next_action": "human_review",
  "changed_objects": [],
  "audit_id": "audit-event-id"
}

Der Agent muss dadurch zwischen Erfolg, fachlicher Ablehnung, technischer Störung und notwendiger Freigabe unterscheiden können. Moderne Agent-Laufzeiten unterstützen dafür unter anderem strukturierte Tool-Eingaben, Fehlerbehandlung, Tool-Gruppen und menschliche Freigaben. Die offizielle Übersicht zu Tool-Aufrufen, Namespaces und Freigabegates zeigt diese Muster.

Für sensible interne Prozesse gehören außerdem DSGVO-Anforderungen, Geheimnisverwaltung und Mandantentrennung in die Architektur. Zugangsdaten dürfen weder in Knowledge-Base-Dokumenten noch in Skill-Dateien stehen. Protokolle sollten nur die Daten enthalten, die für Nachvollziehbarkeit und Fehleranalyse erforderlich sind. Prüfen Sie dazu auch die Hinweise von ZavCloud zum Datenschutz, bevor Sie sensible Dokumente oder Betriebsdaten in eine laufende Umgebung übertragen.

6. Prüfen Sie echte Fachkompetenz mit einem Evaluationsset

Wie lässt sich feststellen, ob ein Agent Fachwissen wirklich beherrscht? Nicht mit einer einzigen gelungenen Demo, sondern mit einem festen Evaluationsset, das normale Aufgaben und Fehlersituationen abdeckt.

Ein brauchbares Set enthält mindestens:

• direkte Wissensfragen mit erwarteten Quellen,
• mehrstufige Prozessaufgaben,
• Fälle mit fehlenden Eingaben,
• veraltete oder widersprüchliche Dokumente,
• Aufgaben außerhalb des Zuständigkeitsbereichs,
• fehlgeschlagene Tool-Aufrufe,
• Aktionen, die eine menschliche Freigabe benötigen,
• Wiederholungen desselben Falls mit leicht veränderter Formulierung.

Bewerten Sie nicht nur die Textqualität. Messen Sie getrennt:

1. Quellenrichtigkeit: Wird die richtige und aktuelle Quelle verwendet?
2. Prozessrichtigkeit: Werden die Schritte in korrekter Reihenfolge ausgeführt?
3. Berechtigungsrichtigkeit: Wird eine unzulässige Aktion abgelehnt?
4. Fehlerverhalten: Erkennt der Agent Tool-Fehler und versucht er keine unbegründete Ersatzaktion?
5. Ausgabequalität: Sind Pflichtfelder, Unsicherheiten und Nachweise vorhanden?

Legen Sie vor jeder Änderung eine Baseline ab. Wenn Sie Retrieval, Skill oder Tool-Schema aktualisieren, führen Sie dasselbe Set erneut aus. Eine Verbesserung bei Wissensfragen kann gleichzeitig eine Verschlechterung bei Grenzfällen verursachen. Genau deshalb benötigen Sie getrennte Teilwerte statt einer einzigen Gesamtbewertung.

Ein sinnvoller Testfall ist beispielsweise: „Die Richtlinie vom letzten Quartal sagt A, das neuere freigegebene Dokument sagt B.“ Der Agent sollte nicht einfach die längere Passage auswählen, sondern Version, Gültigkeit und verantwortliche Stelle prüfen. Bei einem Tool-Fehler sollte er den Fehler offen melden und den nächsten zulässigen Schritt nennen, statt einen Erfolg zu behaupten.

7. Organisieren Sie Aktualisierung, Konflikte und Versionen

Wie aktualisiert ein professioneller Agent veraltetes Wissen? Nicht durch stilles Überschreiben und auch nicht dadurch, dass der Agent selbst entscheidet, welches Dokument „wahrscheinlich“ richtig ist.

Definieren Sie für jedes Fachgebiet:

• eine verantwortliche Person oder Gruppe,
• eine Prüfung bei relevanten Änderungen,
• eine Regel für widersprüchliche Quellen,
• einen Prozess für Zurückziehung und Archivierung,
• eine Versionierung für Knowledge Base und Skills,
• eine Pflicht zur erneuten Evaluation nach Änderungen.

Die Reihenfolge sollte dabei immer gleich bleiben:

1. Neue oder korrigierte Quelle aufnehmen.
2. Metadaten und Zugriffsrechte prüfen.
3. Alte Quelle als ersetzt, abgelaufen oder weiterhin gültig markieren.
4. Retrieval-Tests mit betroffenen Fragen ausführen.
5. Prüfen, ob ein Skill auf die alte Regel verweist.
6. Falls nötig, Skill und Tool-Gates ändern.
7. Betroffene Evaluationsfälle erneut ausführen.
8. Erst danach die neue Version freigeben.

Wenn sich nur ein Parameter ändert, muss nicht automatisch der ganze Skill neu geschrieben werden. Wenn sich dagegen eine Pflichtfreigabe oder ein Sicherheitsgrenzwert ändert, ist neben dem Skill auch das Tool-Schema und die Abnahme zu aktualisieren.

8. Nehmen Sie den Agenten erst nach der Laufzeitprüfung ab

Vor dem produktiven Einsatz muss Ihre Abnahme mehr prüfen als die Frage, ob die Antwort verständlich klingt. Entscheidend sind Isolation, Identität, Protokollierung und Wiederherstellung.

Checkliste für die technische Abnahme

• [ ] Jede Knowledge-Base-Quelle besitzt Eigentümer, Version und Gültigkeitsstatus.
• [ ] Der Agent kann veraltete oder widersprüchliche Quellen ausdrücklich melden.
• [ ] Skills enthalten Auslöser, Ablauf, Abbruchregeln und Ausgabeformat.
• [ ] Dynamische Fakten werden nicht dauerhaft in Skill-Anweisungen kopiert.
• [ ] Lese-, Schreib- und Ausführungs-Tools sind getrennt.
• [ ] Produktive Änderungen benötigen eine passende Freigabe.
• [ ] Tool-Ergebnisse unterscheiden Erfolg, Ablehnung und technische Fehler.
• [ ] Zugangsdaten liegen außerhalb von Prompts, Dokumenten und Skill-Dateien.
• [ ] Jede relevante Aktion besitzt eine nachvollziehbare Audit-Spur.
• [ ] Unterbrochene Läufe können sicher beendet oder wiederaufgenommen werden.
• [ ] Parallelität, Zeitüberschreitungen und Wiederholungen sind begrenzt.
• [ ] Das Evaluationsset wurde vor und nach der letzten Änderung ausgeführt.
• [ ] Der Agent kann bei fehlender Evidenz auf eine menschliche Prüfung verweisen.
• [ ] Interne Dokumente werden nur in freigegebenen und isolierten Umgebungen verarbeitet.

Für einen risikoarmen internen Rechercheassistenten können Sie den Zugriff schrittweise erweitern: zuerst nur Lesen, danach strukturierte Entwürfe und erst später begrenzte Schreibaktionen. Für externe Aktionen, produktive Systeme oder personenbezogene Daten sollte die Schwelle deutlich höher liegen. Eine isolierte Laufzeitumgebung ist dabei nicht automatisch sicher; Sie müssen Netzwerkzugriff, Dateisystem, Geheimnisse und Wiederanlaufverhalten separat prüfen. Informationen zu verfügbaren Betriebs- und Hilfemöglichkeiten finden Sie im Hilfe-Zentrum von ZavCloud.

9. Wählen Sie die passende Betriebsumgebung

Für die Entwicklung eines Domänen-Agenten reicht ein lokales Notebook oft aus. Für wiederholbare Evaluationen, parallele Testläufe, isolierte Skill-Versionen oder dauerhaft laufende interne Prozesse brauchen Sie jedoch eine Umgebung, deren Zustand, Zugriffe und Protokolle kontrollierbar sind.

Eine eigene lokale Umgebung passt besser, wenn Sie:

• direkt auf physische Geräte oder lokale Entwicklungswerkzeuge zugreifen müssen,
• langfristig eine konstante hohe Auslastung haben,
• sämtliche Daten innerhalb Ihrer eigenen Infrastruktur halten müssen,
• spezielle Netzwerk- oder Hardwareanforderungen besitzen.

Eine gemietete Mac-Umgebung kann sinnvoller sein, wenn Sie kurzfristig eine reproduzierbare Testumgebung, zusätzliche Apple-Hardware oder eine getrennte Agent-Laufzeit benötigen, ohne sofort Hardware zu kaufen und dauerhaft zu verwalten. Dabei sollten Sie vorab klären, wie Zugriff, Datenlöschung, Protokollierung, Laufzeit und Wiederherstellung geregelt sind. Für die ersten Informationen zu verfügbaren Mac-Optionen können Sie die Mac-Mietangebote von ZavCloud prüfen; bei sensiblen Unternehmensdaten gehört die Datenschutzprüfung vor die technische Einrichtung.

Wenn Ihre aktuelle Lösung auf einem gemeinsam genutzten Rechner, einer unkontrollierten Entwicklerumgebung oder einem ständig erweiterten Cloud-Sandbox-Prozess basiert, entstehen häufig drei konkrete Nachteile: Zustände sind schwer reproduzierbar, Berechtigungen wachsen unbemerkt und Fehler lassen sich wegen fehlender Laufzeitprotokolle nur unvollständig zurückverfolgen. Eine gemietete Mac-Umgebung ist deshalb nicht für jedes Team automatisch die beste Wahl, kann aber für zeitlich begrenzte Entwicklung, Abnahmetests und getrennte Agent-Läufe die praktischere Option sein.

Der entscheidende Schritt ist nicht, möglichst viele Dokumente oder Tools anzuschließen. Sie sollten zuerst die vier Zuständigkeiten festlegen, anschließend ein kleines Fachgebiet auswählen und den Agenten mit veralteten Quellen, falschen Prozesswegen und fehlgeschlagenen Tool-Aufrufen testen. Erst wenn Knowledge Base, Agent Skills, Tool-Aufrufe und Evaluationsset gemeinsam bestehen, können Sie begründet sagen, dass Ihr KI-Agent ein Fachgebiet nicht nur sprachlich nachahmt, sondern kontrolliert darin arbeitet.