Ein Benutzer lädt eine Rechnung als PDF hoch und fragt:
"Extrahieren Sie die Positionen, berechnen Sie den Gesamtbetrag und erstellen Sie einen formatierten Excel-Bericht."
Ein modernes LLM kann die Rechnung verstehen und die benötigten Informationen ermitteln. Aber das ist nur die halbe Lösung. Ihre Anwendung muss dieses Verständnis immer noch in eine echte, formatierte .xlsx-Datei mit der geforderten Dokumentstruktur verwandeln.
Genau hier liegt die Lücke zwischen dem Verstehen eines Dokuments und dem Bearbeiten eines Dokuments. Eine reine LLM-API bietet Sprach- und Denkfähigkeiten, aber für sich genommen keinen vollständigen Workflow zur Bearbeitung von Office-Dokumenten. Ein Dokument-KI-Agent verbindet das LLM mit einem deterministischen SDK zur Dokumentverarbeitung, sodass das LLM bestimmt, was passieren soll, und die Dokumentebene die Dateioperationen ausführt.
Schnellnavigation
- Das Problem: Rohe LLM-APIs und Dokumentdateien
- Was ein Dokument-KI-Agent bietet
- Vergleich Seite an Seite
- Wann welcher Ansatz verwendet werden sollte
- Ein Minimalbeispiel in C#
- Warum Spire.Agent.Office für .NET-Teams
- FAQ
1. Das Problem: Rohe LLM-APIs und Dokumentdateien
Wenn Sie gpt-4 oder claude direkt mit der Anweisung „Verarbeiten Sie dieses Dokument“ aufrufen, scheitert das auf drei Arten, die in der Produktion eine Rolle spielen. Diese Punkte werden wichtig, sobald ein Dokument-Workflow über die einfache Textextraktion hinausgeht und zuverlässige Dateibearbeitung, Validierung und Formatierung erfordert.
1.1 LLMs können Office-Dateien nicht zuverlässig lesen oder schreiben
Große Sprachmodelle können Dokumentinhalte verstehen, wenn Modell und API den entsprechenden Dateityp oder multimodale Eingaben unterstützen – ein deterministisches Bearbeiten von Dokumenten ist damit jedoch nicht gegeben. Ein Modell kann den Text, die Tabellen oder die visuellen Inhalte einer PDF analysieren, aber das bedeutet nicht, dass es über die LLM-API selbst eine Arbeitsmappe deterministisch ändern, jede Office-spezifische Eigenschaft bewahren und das Ergebnis als produktionsreife .xlsx-Datei speichern kann. Wird eine Office-Datei an eine reine LLM-API übergeben, erhält das Modell möglicherweise extrahierte oder transformierte Inhalte statt eines nativen, bearbeitbaren Arbeitsmappenobjekts. Selbst wenn das Modell den Inhalt der Arbeitsmappe verstehen kann, bietet die API für sich genommen keine deterministischen Operationen zum Erhalten und Ändern der nativen Arbeitsmappenstruktur (Blätter, benannte Bereiche, Formeln, bedingte Formatierung, verbundene Zellen, Zahlenformate).
Die Dokumentanalyse durch ein direktes LLM kann nützliche semantische Informationen extrahieren, aber semantische Analyse ist etwas anderes als das Erhalten und Bearbeiten der nativen Dokumentstruktur.
Beim Schreiben tritt das gleiche Problem umgekehrt auf. Eine reine LLM-API stellt für sich genommen keine deterministische Office-Dokumentverarbeitungsebene bereit. Ein LLM kann beschreiben, was ein Bericht enthalten soll, aber um eine gültige .docx- oder .xlsx-Datei zu erzeugen, ist zusätzliche Werkzeugsoftware erforderlich. Um aus einer reinen LLM-API echte Office-Ausgabe zu erzeugen, müssen Sie eine Rekonstruktionspipeline aufbauen: Textantwort des Modells parsen, Felder auf Zellen oder Absätze abbilden, Formatierung anwenden und die Datei selbst schreiben. Diese Pipeline ist nicht trivial – und sie ist der Teil, der in der Produktion bricht.
1.2 Formatierung ist nicht garantiert
Dokument-Workflows tragen Formatierungen, die wichtig sind: Spaltenüberschriften in einem Rechnungsbericht, Zahlenformate in einer Finanztabelle, bedingte Füllungen, die Abweichungen markieren, Tabellenstile in einem Managementbericht. Eine reine LLM-API liefert modellgenerierte Inhalte wie Text, JSON oder Tool-Aufrufe; sie liefert nicht von sich aus ein formatiertes Office-Dokument als Ausgabe. Die Formatierung kann schwer zu erhalten sein, wenn die Antwort des Modells zu einer Office-Datei rekonstruiert werden muss – ein Excel-Blatt ohne Zahlenformate ist ein Blatt, das jemand von Hand korrigieren muss, bevor es an die Buchhaltung gehen kann.
Selbst wenn das LLM strukturierte Ausgaben erzeugt (JSON, Markdown-Tabellen), ist strukturierte Ausgabe keine strukturierte Dokumentausgabe. JSON liefert strukturierte Daten, kein strukturiertes Office-Dokument. Eine JSON-Antwort kann Zellen, Absätze, Tabellen oder Formatieranweisungen beschreiben, aber es ist weiterhin eine zusätzliche Dokumentverarbeitungsebene erforderlich, um diese Anweisungen auf eine echte .xlsx-, .docx-, .pptx- oder .pdf-Datei anzuwenden. Sie pflegen dann einen Formatierer, einen Feld-Mapper und einen Stil-Anwender – bei keinem davon hilft Ihnen das LLM.
1.3 Sie implementieren die gesamte Orchestrierung neu
Eine Pipeline mit reiner LLM-API ist nicht nur ein API-Aufruf. Sie ist ein Stapel:
- Prompt-Design – vorlagenbasierte Prompts, die brechen, wenn sich das Dokumentlayout ändert
- Extraktion – zusätzliche Dokumentverarbeitungswerkzeuge können erforderlich sein, um strukturierte Inhalte aus PDF-, Word- und Excel-Dateien zu extrahieren, bevor das LLM sie sieht
- Parsen – JSON-Parsing-Logik, um die Antwort des LLM in strukturierte Daten umzuwandeln
- Wiederholungslogik – Umgang mit halluzinierten Ausgaben, Ratenlimits und Ablehnungen durch Inhaltsfilter
- Datei-E/A – Lesen von Eingaben, Schreiben von Ausgaben, Verwalten temporärer Dateien
- Ausgabevalidierung – Prüfung, dass die erzeugte Datei gültig und wohlgeformt ist, bevor sie an den Benutzer zurückgegeben wird
An diesem Punkt bauen Sie eine Lösung zur Dokumentverarbeitung – mit einem LLM als Komponente, nicht als Lösung selbst. Jeder neue Dokumenttyp, jede Schemaänderung oder jedes neue Ausgabeformat bedeutet, Prompts neu abzustimmen und modellspezifische Eigenheiten erneut zu testen. Der Wartungsaufwand wächst linear mit der Anzahl der unterstützten Dokumenttypen.
2. Was ein Dokument-KI-Agent bietet
Ein Dokument-KI-Agent löst die drei oben genannten Probleme, indem er das LLM mit einer deterministischen Dokumentverarbeitungsebene kombiniert. Die Aufgabenteilung ist klar:
- Das LLM übernimmt das Verstehen. Es liest die natürlichsprachliche Anweisung, entscheidet, was extrahiert oder erzeugt werden soll, und bestimmt die Struktur der Ausgabe.
- Die Dokumentebene übernimmt die Ausführung. Sie liest und schreibt echte Office- und PDF-Dateien, erhält Formatierungen, wendet Stile an und nutzt deterministische Dokumentoperationen, um eine strukturell gültige Datei zu erzeugen.
Anstatt das LLM zu bitten, die Dokumentstruktur „herauszufinden“, ruft der Agent deterministische Dokumentoperationen auf. Das Modell muss das Office-Dateiformat nicht selbst konstruieren; es erzeugt die Absicht, und die Dokumentebene führt die entsprechenden Dateioperationen aus.
Die beiden Architekturen im Vergleich:
So sieht das in der Praxis aus
| Problem mit reinem LLM | Wie der Agent es löst |
|---|---|
Keine native .xlsx-Bearbeitung |
Die Dokumentebene liest und bearbeitet die Arbeitsmappe nativ |
| Keine deterministische Office-Dateigenerierung | Die Dokumentebene erstellt die Ausgabedatei |
| Formatierung kann bei der Rekonstruktion verloren gehen | Die Dokumentebene übernimmt Stile und Zahlenformate |
| Modellgenerierte Struktur kann inkonsistent sein | Dokumentoperationen sind deterministisch |
| Sie bauen die umgebende Pipeline | Das Agent-SDK bietet den Dokumentverarbeitungs-Workflow |
Der Kernpunkt: Das LLM ist das Gehirn, die Dokumentebene sind die Hände. Eine reine LLM-API gibt Ihnen das Gehirn und erwartet, dass Sie die Hände bauen. Ein Dokument-KI-Agent bietet Ihnen beides integriert in einem einzigen SDK-Aufruf.
Ein Dokument-SDK allein kann Dateien bearbeiten, versteht aber keine natürlichsprachliche Absicht. Ein KI-Agent kombiniert diese deterministische Dokumentebene mit einem LLM, sodass Benutzer den gewünschten Workflow beschreiben können, anstatt jede Dokumentoperation manuell zu implementieren. Der Wert liegt nicht in „Dokument-SDK + KI“, sondern in der Pipeline: natürlichsprachliche Anweisung → LLM-Schlussfolgerung → deterministische Dokumentoperationen.
Empfohlene Lektüre: KI-Agent für die Dokumentverarbeitung: Was es ist und wie es funktioniert – das Konzept des Dokument-KI-Agenten erklärt.
3. Vergleich Seite an Seite
| Dimension | Rohe LLM-API | Dokument-KI-Agent |
|---|---|---|
| Dateiverständnis | Hängt vom Modell/der API und dem Dateityp ab | Die Dokumentebene bietet nativen Dokumentzugriff |
| Dateibearbeitung | Erfordert Tools oder zusätzliche Dokumentbibliotheken | In der Dokumentverarbeitungsebene integriert |
| Formattreue | Hängt von der Rekonstruktionslogik ab | Wird durch deterministische Dokument-APIs sichergestellt |
| Ausgabeverarbeitung | Die LLM-Antwort muss geparst und in eine Datei konvertiert werden | Die Dokumentebene führt die deterministische Dateierstellung durch |
| Codeumfang | Mehr anwendungsseitige Orchestrierung | Natürlichsprachliche Anweisung + SDK-Einrichtung |
| Wartung | Prompts, Parser, Zuordnungen und Dateilogik | Mehr Workflow-Verhalten kann über Anweisungen ausgedrückt werden |
| Mehrformatverarbeitung | Erfordert formatspezifische Unterstützung | Einheitlicher Dokumentverarbeitungs-Workflow |
| Semantische Genauigkeit | Hängt vom Modell und Prompt ab | Hängt weiterhin vom Modell und der Anweisung ab |
| Dateivalidierung | Verantwortung der Anwendung | Das SDK meldet Verarbeitungserfolg/-fehlschlag |
| .NET-Integration | .NET-SDK- oder HTTP-Integration, bei Bedarf plus Dokumentverarbeitungsbibliotheken | Natives C#-SDK mit Dokumentverarbeitung |
| Am besten geeignet für | Textorientierte KI-Aufgaben | KI-gesteuerte Dokument-Workflows |
4. Wann welcher Ansatz verwendet werden sollte
Der Vergleich bedeutet nicht, dass der Agent immer besser ist. Rohe LLM-APIs und Dokument-KI-Agenten verfolgen unterschiedliche Ziele, und die Wahl des richtigen Werkzeugs hängt davon ab, was der Workflow erzeugen soll.
Verwenden Sie eine reine LLM-API, wenn:
- Die Ausgabe Text und keine Datei ist. Zusammenfassen, Fragenbeantwortung, Klassifikation und Entwürfe sind Text-in-Text-Aufgaben. Es ist keine Dokumentebene erforderlich.
- Sie bereits einen LLM-Stack haben. Wenn Ihr Team in Prompt-Engineering, RAG und Orchestrierungsinfrastruktur investiert hat, ist ein zusätzliches Dokument-SDK für reine Text-Workflows möglicherweise unnötig.
-
Die Eingabe reiner Text oder Markdown ist. Wenn das Ausgangsmaterial bereits Text ist – nicht
.pdfoder.xlsx– entfällt das Extraktionsproblem, und ein direkter LLM-Aufruf ist der einfachste Weg.
Verwenden Sie einen Dokument-KI-Agenten, wenn:
-
Die Ausgabe eine echte Office- oder PDF-Datei sein muss. Wenn das Ergebnis eine
.xlsx-Arbeitsmappe für die Buchhaltung, ein.docx-Bericht für das Management oder eine.pdf-Datei zur Verteilung sein soll, wird eine Dokumentverarbeitungsebene wichtig, wenn der Workflow zuverlässig eine gültige, formatierte Office-Datei erzeugen muss. - Die Eingabe mehrere Formate umfasst. PDFs, Word-Dokumente, Excel-Dateien und gescannte Bilder treffen im selben Workflow ein. Ein reines LLM benötigt pro Format eine separate Extraktionsbibliothek; ein Agent verarbeitet alle in einer Anweisung.
- Formatierung wichtig ist. Spaltenüberschriften, Zahlenformate, bedingte Füllungen, Tabellenstile, Schriftarten – wenn das Unternehmen Wert darauf legt, wie die Datei aussieht, ist die Dokumentebene der Teil, der diese Formate erhält.
- Sie in .NET arbeiten. Ein natives C#-SDK, das KI-Orchestrierung mit Dokumentverarbeitung kombiniert, kann den anwendungsseitigen Integrationsaufwand gegenüber der Kombination eines LLM-SDK mit separaten Dokumentverarbeitungsbibliotheken reduzieren.
- Der Workflow sich häufig ändert. Neue Lieferanten, neue Berichtslayouts, neue Validierungsregeln – wenn das Umkodieren bei jeder Änderung der Engpass ist, ist das Bearbeiten einer Anweisung schneller und günstiger.
Entscheidungshilfe
| Frage | Rohe LLM-API | Dokument-KI-Agent |
|---|---|---|
| Ist die Ausgabe eine echte Datei (Excel, Word, PDF)? | Erfordert zusätzliche Werkzeuge | Ja |
| Muss die Formatierung erhalten bleiben? | Hängt von Ihrer Rekonstruktionspipeline ab | Wird von der Dokumentebene übernommen |
| Sind Eingaben in mehreren Office-Formaten vorhanden? | Erfordert formatspezifische Extraktion | Ja |
| Handelt es sich um eine reine Textaufgabe (Zusammenfassen, Fragen & Antworten)? | Ja | Möglich, aber unnötig |
| Benötigen Sie native Dokumentbearbeitung in .NET? | Erfordert eine zusätzliche Dokumentbibliothek | In den Workflow integriert |
| Ändern sich die Workflow-Regeln häufig? | Prompts und Parser müssen neu abgestimmt werden | Verhalten durch Bearbeiten der Anweisung ändern |
5. Ein Minimalbeispiel in C#
Der Unterschied zeigt sich am deutlichsten im Code. Im Folgenden wird dieselbe Aufgabe – Daten aus einer PDF-Rechnung extrahieren und einen formatierten Excel-Bericht erzeugen – auf beide Arten implementiert.
Ansatz mit reiner LLM-API
// Simplified raw LLM pipeline — illustrative architecture, not production code.
// 1. Obtain document content using a document-processing tool
// (This example uses extracted text to illustrate one common raw-LLM architecture;
// some modern LLM APIs can also accept PDFs directly.)
string documentText = ExtractTextFromPdf(@"C:\invoices\supplier-a.pdf");
// 2. Send the extracted content to the LLM
string json = await CallLlmAsync(
"Extract vendor, invoice date, line items, and total as JSON.",
documentText);
// 3. Deserialize and validate the model response
InvoiceData data = JsonSerializer.Deserialize<InvoiceData>(json)
?? throw new InvalidOperationException("Invalid LLM response.");
// 4. Create the Excel file using a document library
using var workbook = new Workbook();
var sheet = workbook.AddWorksheet("Invoice");
// ... map data to cells and apply formatting
workbook.SaveToFile(@"C:\output\report.xlsx");
Illustrative Pipeline: API- und Dokumentbibliotheks-Aufrufe sind vereinfacht, um den Fokus auf die Architektur zu legen und nicht auf ein bestimmtes Anbieter-SDK.
Ansatz mit Dokument-KI-Agent
// Document AI agent: one instruction, real file output
using Spire.Agent.Office.AI;
using Spire.Agent.Office.Extensions;
using Spire.Xls;
string? spireToken = Environment.GetEnvironmentVariable("SPIRE_TOKEN");
if (string.IsNullOrEmpty(spireToken))
throw new InvalidOperationException("SPIRE_TOKEN is not set.");
AIOptions agentOptions = new AIOptions();
agentOptions.WorkDir = @"C:\output";
agentOptions.SpireToken = spireToken;
string instruction =
"Read the attached invoice PDF, extract vendor name, invoice date, " +
"line items (description, quantity, unit price, amount), and total. " +
"Create a workbook with formatted headers, number formats for currency " +
"columns, and a summary row. Save as a .xlsx file.";
string[] attachments = { @"C:\invoices\supplier-a.pdf" };
using (Workbook wb = new Workbook())
{
AIResult result = wb.AI(agentOptions).ExecuteInstruction(
wb,
instruction,
@"C:\output\report.xlsx",
attachments);
if (result == null || !result.Success)
throw new InvalidOperationException(
$"Processing failed: {result?.ErrorMessage}");
}
Der Agent liest die PDF-Rechnung und erzeugt einen formatierten Excel-Bericht:
Wichtige API-Aufrufe
-
Workbook.AI(agentOptions)– fügt einer Arbeitsmappe den KI-Dokumentprozessor hinzu -
ExecuteInstruction(doc, instruction, savePath, attachments)– führt die Anweisung aus und schreibt die Ausgabedatei -
AIResult.Success/AIResult.ErrorMessage– prüft das Ergebnis und meldet Fehler
Der Ansatz mit reiner LLM-API besteht aus vier getrennten Problemen (Extraktion, Prompting, Parsen, Dateischreiben), die zusammengefügt werden. Der Agent-Ansatz besteht aus einer Anweisung und einer Ergebnischeckung. Beide Ansätze können letztlich eine .xlsx-Datei erzeugen, aber der Ansatz mit reiner LLM-API erfordert, dass Sie die Dokumentgenerierungsebene selbst bauen und pflegen. Der Agent integriert diese Dokumentverarbeitungsebene in den Workflow, sodass sich das LLM auf die Interpretation der Anweisung konzentrieren kann, während das SDK die Dokumentoperationen übernimmt.
Das könnte Ihnen auch gefallen: Rechnungsverarbeitung mit einem KI-Agenten in .NET automatisieren – ein vollständiger Workflow für Extraktion, Validierung und Berichterstellung.
6. Warum Spire.Agent.Office für .NET-Teams
Der obige Vergleich ist bewusst produktneutral; dieselbe Architektur (LLM + Dokumentebene) funktioniert mit jedem leistungsfähigen Modell und jedem Dokument-SDK. Wo sich Spire.Agent.Office für .NET-Teams auszeichnet, sind drei konkrete Bereiche:
-
Native Verarbeitung mehrerer Formate. PDFs, Word-Dokumente, Excel-Dateien und bildbasierte Dokument-Workflows können in den Agent-Workflow integriert werden. Der Agent liest, extrahiert und generiert diese Formate in einer einzigen Anweisung – keine formatspezifische Extraktionsbibliothek, kein formatspezifischer Ausgabe-Formatierer.
-
Dokumentformatierung kann durch deterministische Dokumentoperationen erhalten bleiben. Die Dokumentebene hält Spaltenüberschriften, Zahlenformate, bedingte Füllungen, Tabellenstile und Schriftarten intakt. Wenn Sie mit einer vorhandenen Vorlage arbeiten, weisen Sie den Agenten ausdrücklich an, das ursprüngliche Layout und die Formatierung beizubehalten, und die Ausgabe bleibt ohne zusätzlichen Code der Vorlage treu.
-
Native .NET-Integration. Es ist ein C#-SDK, das sich in eine bestehende .NET-Anwendung integrieren lässt. Kein separater Dokumentverarbeitungsdienst, der gebaut oder gewartet werden muss, keine dienstübergreifende Verkabelung, keine HTTP-Orchestrierungsebene. Das obige Beispiel zeigt den wesentlichen Integrationsumfang: SDK-Einrichtung, eine Anweisung und eine Ergebnischeckung.
Wenn Sie bereits Spire.Office für die Dokumentverarbeitung nutzen, ist der Agent die natürliche nächste Ebene: Dasselbe Workbook-Objekt erhält einen AI()-Prozessor, der Anweisungen in ausgeführte Workflows umwandelt. Das deterministische SDK, das Sie bereits kennen, wird zur Dokumentebene, die der Agent aufruft.
7. FAQ
Kann ich die PDF nicht einfach direkt an die LLM-API senden?
Das können Sie. Moderne LLM-APIs können einige Dokumenttypen direkt verarbeiten, einschließlich PDFs. Der wichtige Unterschied besteht darin, dass die Dateieingabe dem Modell Zugriff auf den Dokumentinhalt verschafft; das gibt Ihrer Anwendung nicht automatisch eine deterministische API zum Ändern der ursprünglichen Office-Struktur und zum Speichern einer produktionsreifen Ausgabedatei. Beispielsweise kann ein Modell Rechnungstabellen in einer PDF korrekt erkennen, aber um dieses Verständnis in eine formatierte .xlsx-Datei zu verwandeln, ist weiterhin Dokumenterzeugungslogik erforderlich.
Was genau ist eine „Dokumentebene“?
Eine Dokumentebene ist ein deterministisches SDK, das Office- und PDF-Dateien liest und schreibt und dabei mit deren nativen Dokumentstrukturen arbeitet. Sie übernimmt die Operationen, die ein LLM nicht ausführen kann: eine .xlsx-Datei öffnen und ihre Blätter und Formeln erhalten, eine .docx-Datei mit korrekten Stilen und Kopfzeilen schreiben, Zellen zusammenführen, bedingte Formatierung anwenden und strukturell gültige Office-/PDF-Ausgaben mithilfe deterministischer Dokument-APIs erzeugen. In Spire.Agent.Office ist die Dokumentebene das Spire.Office-SDK; das LLM entscheidet, was zu tun ist, und die Dokumentebene führt es aus.
Ist das nur RAG mit zusätzlichen Schritten?
Nein. RAG (Retrieval-Augmented Generation, abrufgestützte Generierung) konzentriert sich in erster Linie darauf, relevante Informationen abzurufen, um Modellantworten zu fundieren. Ein Dokument-KI-Agent übernimmt eine weitere Verantwortung: das Ausführen von Dokumentoperationen und das Erzeugen oder Ändern tatsächlicher Dateien. Ein Dokument-Agent liest und schreibt echte Dateien, erhält Formatierungen und erzeugt eine strukturierte Ausgabe, die ein gültiges Office-Dokument ist, keine Textantwort.
Welche KI-Modelle unterstützt Spire.Agent.Office?
Spire.Agent.Office verbindet sich über einen SpireToken-Schlüssel mit einem großen Sprachmodell und unterstützt gehostete Modell-APIs sowie benutzerdefinierte Modell-Endpunkte. Bei Fragen dazu, welche Anbieter und Modellprotokolle in Ihrer Bereitstellung unterstützt werden, kontaktieren Sie den Vertrieb.
Bleiben meine Daten in meiner Umgebung?
Das SDK, die Vorlagen und die Dokumentverarbeitung laufen in Ihrer Anwendung – Dateien werden nicht zur Speicherung oder Konvertierung an einen externen Dokumentdienst hochgeladen. Zur Analyse von Inhalten benötigt die KI den relevanten Text, und dieser wird zur Verarbeitung an das Modell gesendet. Wenn der Modell-Endpunkt in Ihrem eigenen Netzwerk bereitgestellt wird und Ihre Konfiguration keine Dokumentinhalte nach außen sendet, können Dokumentinhalte in Ihrer Infrastruktur bleiben. Wenn Sie über eine gehostete Modell-API wie OpenAI oder Azure OpenAI Verbindung herstellen, werden die relevanten Inhalte gemäß Ihrer Konfiguration an diesen Anbieter übertragen.
Wann ist eine reine LLM-API die richtige Wahl?
Für reine Textaufgaben, bei denen keine Datei als Ausgabe benötigt wird: ein Dokument zusammenfassen, Fragen zu seinem Inhalt beantworten, es in eine Kategorie einordnen oder einen E-Mail-Entwurf erstellen. Wenn die Eingabe bereits reiner Text ist und die Ausgabe reiner Text ist, fügt eine Dokumentebene Komplexität ohne Mehrwert hinzu. Der Agent ist dann die richtige Wahl, wenn der Workflow echte Dateien erzeugt, die gültig und formatiert sein müssen.
Bereit, Ihren LLM-Workflows eine Dokumentebene hinzuzufügen?
Wenn Ihre Anwendung Rechnungen, Verträge, Berichte oder andere Office-Dokument-Workflows verarbeitet, verwandelt ein Dokument-KI-Agent eine natürliche Sprachangabe in eine echte, formatierte Datei – ohne eine Extraktions- und Rekonstruktionspipeline zu bauen. Folgen Sie dem Tutorial Erste Schritte, um Ihren ersten Workflow in .NET auszuführen.
Weiterführende Lektüre
- Word-Dokumente aus Excel-Daten in C# generieren – datengetriebene Dokumentgenerierung mit dem deterministischen SDK
- Erstellen Sie einen KI-gestützten Excel-Berichtsassistenten in C# – automatisierte Berichtserstellung und -analyse
- Produktübersicht zu Spire.Agent.Office – KI-Agent-SDKs für jedes Office-Dokumentformat