Odoo-KI-Agenten testen: gespeicherte Aktivitäten prüfen

Zurück

Kevin Riedl

12 Min. Lesezeit · 5. November 2026
Zuletzt geprüft 5. November 2026

Weiter

Ein Agent meldet, die Nachverfolgung sei geplant. Eine neue Aktivität existiert, der richtige Vertriebsmitarbeiter ist zuständig und die Frist stimmt. Doch die Aktivität hängt an einer anderen Verkaufschance. Ein Test, der nur die Erstellung irgendeiner Aktivität prüft, würde das falsche Ergebnis akzeptieren.

Teste einen Odoo-KI-Agenten gegen schriftlich vereinbarte Anforderungen an den Geschäftszustand. Lege fest, welche Aktivität er anlegen darf, welche Datensätze unverändert bleiben müssen und wann er nachfragen soll. Prüfe die Ergebnisprüfung zuerst mit absichtlich falschen Beobachtungen, bevor sie kontrollierte Läufe in der tatsächlichen Installation bewertet.

Recherche geprüft: 5. November 2026. Produktangaben beruhen auf offizieller Odoo-20-Dokumentation und Quellcode. Wir haben dreizehn konstruierte JSON-Beobachtungen durch eine Python-Prüfung ausgeführt. Odoo, ein KI-Modell und ein Mailserver wurden dabei nicht betrieben. Das native Abnahmepaket enthält vorgeschlagene Prüfungen, sämtlich mit NOT_RUN markiert.

Was muss ein Test für einen Odoo-KI-Agenten belegen?

Der Test muss innerhalb des vereinbarten Beobachtungsumfangs belegen, dass das erlaubte Geschäftsergebnis entstanden ist. Die angeforderte Änderung muss stimmen, geschützte bestehende Datensätze müssen unverändert bleiben und untersagte Auswirkungen dürfen in den Nachweisen nicht vorkommen. Ein erfolgreiches Gespräch oder eine Werkzeugantwort allein kann diese Bedingungen nicht bestätigen.

Die Ergebnisprüfung, auch Testorakel genannt, vergleicht beobachtete Nachweise mit dem vereinbarten Sollzustand. Halte diese Regel außerhalb der eigenen Erklärung des Agenten. Wählt der Agent das Ziel und beurteilt anschließend selbst seine Wahl, kann dasselbe Missverständnis beide Schritte passieren.

Die Dokumentation zu Odoo-KI-Serveraktionen ordnet die Durchsetzung der Geschäftsregeln dem Werkzeugcode zu; die KI-Aktion wählt Werkzeug und Argumente. Die Abnahme muss trotzdem den resultierenden Geschäftszustand prüfen.

Trenne diese Aufgabenabnahme von der Architektur. Der Leitfaden zu Agent Harness Engineering erklärt die umgebenden Ausführungskontrollen. Hier ist die Frage enger: Welche Nachweise reichen für die Abnahme einer geplanten CRM-Nachverfolgung?

Wie definierst du eine einzelne CRM-Aktivität?

Definiere die Aktivität mit eindeutiger Verkaufschancenreferenz, freigegebener zuständiger Person und absolutem Fälligkeitsdatum. Lege danach fest, welche vorhandenen Felder unverändert bleiben. Unser fiktiver Vertrag erlaubt genau eine Anrufaktivität für OPP-42 in Unternehmen A, zugewiesen an Benutzer 7 und fällig am 12. November 2026. Externe E-Mails sind untersagt.

Die Odoo-Anleitung zur Aktivitätsplanung enthält Zuständigkeit und Fälligkeitsdatum. Das sind eigenständige Abnahmebedingungen: Ein korrektes Datum gleicht die Zuordnung an den falschen Kollegen nicht aus.

Der Datensatz enthält zusätzlich OPP-43 in Unternehmen A und OPP-99 in Unternehmen B. Die vorhandene Aktivität ACT-OLD gehört zu OPP-43, ist Benutzer 8 zugewiesen und am 10. November fällig. Diese benachbarten Datensätze machen falsche Zuordnungen und unbeabsichtigte Änderungen sichtbar.

Der Download verwendet normalisierte Schlüssel wie record_ref und assigned_user. Das ist kein Odoo-API-Payload. Im geprüften Odoo-20-Aktivitätsquellcode erfolgt die Dokumentverknüpfung über Modell- und Referenzfelder; Zuständigkeit und Frist verwenden user_id und date_deadline. Eine native Beobachtung muss das installierte Schema in die vereinbarte Datensicht übersetzen.

Das Unternehmen stammt hier aus der verknüpften Verkaufschance. Die Prüfung folgt dieser Beziehung und erfindet kein Unternehmensfeld auf der Aktivität. Technische Verwaltungsdaten wie Chatdatensätze sind ebenfalls nicht Teil der Datensicht. Entscheide ausdrücklich, welche weiteren Geschäftsfelder und Benachrichtigungswirkungen deine Installation beobachten muss.

Warum muss die Ergebnisprüfung zuerst getestet werden?

Die Ergebnisprüfung braucht negative Beispiele, weil eine schwache Regel einen falschen Workflow zuverlässig erscheinen lassen kann. Lege die erwartete Klassifikation vor der Ausführung fest. Nimm Fälle auf, in denen die angeforderte Aktivität korrekt ist, aber ein anderer geschützter Datensatz verändert wird. Damit prüfst du die Bedeutung der Abnahmeregel über einen Erfolgsfall hinaus.

Die erwarteten Kennzeichnungen im Beispieldatensatz stehen getrennt von der Prüffunktion. Diese liest Anforderungen sowie Vorher-Nachher-Datensichten und liefert PASS, FAIL oder UNKNOWN mit Begründung. Assistententext und gemeldeter Werkzeugstatus gelten nicht als Nachweis einer tatsächlich gespeicherten Änderung.

Eine reine Zählprüfung könnte zwei Aktivitäten akzeptieren, wenn sie nur „mindestens eine“ verlangt. Eine Feldprüfung, die nur die neue Zielzeile sucht, könnte eine veränderte vorhandene Aktivität übersehen. Deshalb vergleicht die Abnahmeregel auch den geschützten Ausgangszustand.

Diese Unabhängigkeit hat Grenzen. Jemand muss die Anforderungen freigeben und den Beobachter validieren, der die Datensicht erzeugt. Eine Prüfung erkennt kein ausgelassenes Feld und kann nicht bestätigen, dass eine als „vollständig“ bezeichnete Datei alle relevanten Auswirkungen enthält. Ihr Umfang muss in den Freigabenachweisen sichtbar sein.

Was zeigten die dreizehn Beispielprüfungen?

Alle dreizehn konstruierten Beobachtungen erhielten im lokalen Lauf die erwartete Klassifikation: zweimal PASS, zehnmal FAIL und einmal UNKNOWN. Das belegt das Verhalten der mitgelieferten Python-Demonstration für diese Eingaben. Es misst keine Erfolgsquote eines Odoo-Agenten, denn kein Agent hat diese Beobachtungen erzeugt.

Lade Prüfskript und Falldatei in dasselbe Verzeichnis. Die Python-Standardbibliothek genügt:

python3 state-oracle.py

Vergleiche die Ausgabe mit den aufgezeichneten Ergebnissen. Der Prozess endet erfolgreich, wenn alle erwarteten Klassifikationen stimmen, einschließlich der absichtlichen FAIL-Fälle. Ein erfolgreicher Skriptabschluss bedeutet, dass die Prüfung die Beispiele richtig eingeordnet hat. Er bedeutet nicht, dass dreizehn Geschäftsaufgaben bestanden haben.

Der Rückfragezweig nutzt die beispielhafte Kennzeichnung reviewed_disposition. Im echten Test muss ein Prüfer oder separat validierter Adapter feststellen, dass nach der fehlenden Verkaufschancenreferenz gefragt wurde. Das Skript versteht die Qualität einer natürlichsprachlichen Frage nicht; diese Kennzeichnung ist kein dokumentiertes Odoo-Antwortfeld.

Wann ist UNKNOWN das richtige Ergebnis?

UNKNOWN ist richtig, wenn die Beobachtung den erforderlichen Endzustand nicht feststellen kann. Ein unzugänglicher Datensatz, unvollständige Nachweise zu Nebenwirkungen oder ein offenes Beobachtungsfenster lassen die Abnahme ungeklärt. Bewahre Bekanntes auf und untersuche die Beobachtungslücke vor einer Wiederherstellung. Eine fehlgeschlagene Leseoperation beweist nicht, dass kein Schreibzugriff stattfand.

Die synthetische Liste outbound_events ist nur ein Platzhalter für externe Wirkungsnachweise. Eine leere Liste setzt kein E-Mail-Verbot durch. Leite Nachrichten beim nativen Probelauf an ein freigegebenes Testziel und prüfe passende Transportnachweise. Widersprechen Zuweisungsbenachrichtigungen der Vorgabe „keine E-Mail“, kläre das Verhalten vor der Abnahme.

Wähle ein Beobachtungsfenster, das den tatsächlichen Aufgabenabschluss umfasst. Eine Warteschlange, die am Stichtag noch arbeitet, ist ungeklärt; sie gilt weder automatisch als erfolgreich noch dauerhaft fehlgeschlagen. Dokumentiere Abfrageumfang und Endzeit, damit die Prüfung verspätete von fehlender Arbeit unterscheiden kann.

Wiederhole einen ungewissen Schreibzugriff nicht, nur um eine freundlichere Rückmeldung zu erhalten. Das Odoo-Beispiel zur Wiederherstellung nach Schreibzugriffen erklärt Duplikatrisiko und Wiederherstellungsentscheidung separat.

Welche Tests brauchen noch die tatsächliche Odoo-Installation?

Die native Abnahme muss den konfigurierten Agenten mit seinen verfügbaren Werkzeugen auf dem konkret geprüften Odoo-Build ausführen. Nutze freigegebene Testidentitäten und vergleiche den Beobachtungsadapter mit bekannten Datensätzen. Prüfe dann die Ergebnisse gegen die Anforderungen. Der erfolgreiche Selbsttest der Ergebnisprüfung bleibt von der Aufgabenleistung des Agenten getrennt.

Das native Abnahmepaket enthält zunächst sechzehn vorgeschlagene Fälle. Ausführungsstatus ist NOT_RUN, Abnahmestatus PENDING; tatsächliche Werte sind leer. Passe die Fälle an installierte Module und Aufgabe an, bevor du Ergebnisse erfasst.

Die QA-Checkliste vor dem Start behandelt die umfassendere Freigabe. Dieses Aufgabenpaket betrifft den Aktivitätsablauf und seine Beobachtungsnachweise.

Der Beobachter braucht berechtigten Zugriff auf die Testdaten. Eine gegebenenfalls größere Sicht für den Abgleich darf nicht mit den Betriebsrechten des Agenten verwechselt werden. Die Odoo-20-Tests für Unternehmenszugriffe behandeln diese native Berechtigungsmatrix separat.

Erfasse Modell- oder Anbieterinformationen, wenn die geprüfte Verbindung sie offenlegt; kennzeichne fehlende Angaben als nicht verfügbar. Werkzeugkonfiguration und Promptrevision bleiben zu dokumentieren, auch bei unbekannter Modellidentität. Der Testbericht beschreibt die beobachtete Konfiguration und markiert unbestätigte Servicedetails.

Wie wertest du wiederholte Agentenläufe aus?

Prüfe jeden Lauf einzeln, bevor du Ergebnisse zusammenfasst. Jeder Eintrag braucht Ausgangsdatensatz, genaue Anfrage und beobachtetes Ergebnis sowie Gründe für FAIL oder UNKNOWN. Vereinbare Wiederholungen und akzeptable Streuung passend zu den Folgen der Aufgabe vorab. Die dreizehn Skriptbeispiele liefern keinen statistisch begründeten Grenzwert für den Produktivbetrieb.

Starte Wiederholungen mit einem gleichwertigen Ausgangszustand, außer der Fall prüft ausdrücklich bereits vorhandene Arbeit. Sonst findet der zweite Lauf möglicherweise die Aktivität von gestern und untersucht eine andere Frage. Bei wiederholter Zustellung musst du festlegen, ob eine bestehende Aktivität wiederverwendet, eine Bestätigung verlangt oder eine weitere angelegt werden soll.

Trenne die Korrektheit der Geschäftsdaten von der Kommunikationsqualität. Ein Agent kann den richtigen Datensatz hinterlassen und den Nutzer schlecht informieren. Eine überzeugende Erklärung gleicht wiederum die falsche Zuständigkeit nicht aus. Beide Aspekte sind wichtig; ein einziger Gesamteindruck erschwert die Fehlerdiagnose.

Eine untersagte externe Änderung bleibt als eigene verletzte Bedingung sichtbar. Sie darf nicht im Durchschnitt leichter Aufgaben verschwinden. Für vertragliche Kennzahlen und Reaktionsverantwortung hilft die Agenten-SLA-Vorlage. Dieser Beitrag liefert Nachweise für eine klar begrenzte Aufgabe.

Was würden wir für den Betrieb freigeben?

Wir würden nur die begrenzte Aktivitätsaufgabe freigeben, deren Sollzustand, Beobachtungsumfang und native Nachweise der zuständige Verantwortliche abgenommen hat. Die Beispielprüfung ist nützliche Vorbereitung, weil sie schwache Abnahmeregeln mit wenig Aufwand sichtbar macht. Zum Freigabenachweis wird sie erst zusammen mit erfolgreicher Beobachtung des real konfigurierten Ablaufs und seiner erforderlichen Fehlerbehandlung.

Beginne mit der regulären Aktivität und dem Gegenbeispiel einer falschen Zielzuordnung. Ergänze den Fall, in dem die neue Zeile korrekt ist, aber eine bestehende Aktivität verändert wird. Damit muss das Team sowohl erlaubte Aktionen als auch den geschützten Zustand benennen.

Für eine unabhängige Freigabeentscheidung kann Wavects Software-Qualitätssicherung die Nachweise mit dir definieren und prüfen. Bring Aufgabenanforderungen, installierte Konfiguration und offene Fälle mit. Eine grüne Demonstration ist dann hilfreich, wenn der Prüfer genau erklären kann, was sie belegt.