Coding-Agents

Ein Coding-Agent ist eine KI, die für dich an einem deiner Addon-Repositories arbeitet. Du beschreibst die Änderung, und der Agent bearbeitet den Code, probiert ihn in einem Odoo aus und pusht ihn für einen Pull Request, den du prüfst und mergst. Du verfolgst die Sitzung mit, beantwortest seine Fragen und legst fest, was er ohne Rückfrage tun darf.

So funktioniert es #

• Der Agent arbeitet immer in einem Odoo: in einer Agent-Kopie, einer frischen neutralisierten Kopie, die für die Sitzung erstellt wird, oder, im Early Access, direkt in einem Test-, Demo- oder Kopie-Odoo deines Teams. In beiden Fällen belegt die Sitzung dieses Odoo, bis es jemand zurückgibt. Von selbst passiert das nie. Beim Zurückgeben wird eine Agent-Kopie gelöscht, und ein Odoo, in dem der Agent direkt gearbeitet hat, bekommt seine eigenen Addons zurück. Siehe Wo der Agent arbeitet.
• Wo du startest, bestimmt die Art. In einem Formular wählst du sie nie. Siehe Eine Sitzung starten.
• Eine Agent-Kopie wird auf dem Server für Kopien des Odoo erstellt, von dem aus du startest, oder auf seinem eigenen Server, wenn keiner festgelegt ist. Agent-Kopien zählen nicht zum Kopienlimit deines Plans, belegen aber Serverressourcen, bis du sie entfernst.
• Der Agent läuft neben seinem Odoo auf deinem Server. Sein Checkout, seine Unterhaltung und die Odoo-Daten bleiben auf deinem Server. Was der Agent aus dem Odoo liest, geht allerdings an deinen KI-Anbieter: Setze in einer Agent-Kopie beim Start der Sitzung den Haken bei Obfuscate personal data, damit ihre personenbezogenen Daten vorher verschlüsselt werden (siehe Personenbezogene Daten verschleiern).
• Der Agent läuft mit deinem eigenen Schlüssel eines KI-Anbieters und über deine Rechnung bei diesem Anbieter. Die im Panel angezeigten Kosten sind eine Schätzung.
• Jeder git push fragt nach deiner Freigabe, in jedem Berechtigungsmodus außer Full access (Vollzugriff). Mit Vollzugriff pusht der Agent ohne Rückfrage, und in einem Odoo, in dem er direkt arbeitet, startet er auch das Odoo neu, aktualisiert Module und führt SQL aus, ohne zu fragen. Siehe Vollzugriff.

Bevor du anfängst #

API-Schlüssel hinzufügen #

Ein Team-Owner oder Admin trägt den Schlüssel einmalig ein:

1. Öffne das Teammenü und wähle Team profile.
2. Wähle unter AI / Coding agents den Provider:
   • Anthropic betreibt Claude mit deinem Anthropic-Schlüssel.
   • OpenRouter und Requesty betreiben Claude und andere Modelle, etwa GLM, Kimi oder DeepSeek, mit deinem Schlüssel bei ihnen. Wähle bei Requesty die Region EU oder Global.
3. Füge den Schlüssel ein und wähle optional ein Default model, mit dem jede neue Sitzung startet.
4. Speichere.

Ein gespeicherter Schlüssel wird nie wieder angezeigt. Füge einen neuen ein, um ihn zu ersetzen, oder entferne ihn mit dem Schalter unter dem Feld.

Repository vorbereiten #

Der Agent arbeitet an einem Repository, das über die calmo.cloud-GitHub-App an das Odoo angebunden ist und dessen Addons für die Version des Odoo synchronisiert sind. Der Pull Request geht an dieses Repository.

Ein Agent, der direkt in einem Odoo arbeitet, kommt auch ohne Repository aus. Dann richtet er dieses Odoo ein, statt Code zu ändern: Er installiert Apps, nimmt Einstellungen vor und erfasst Daten, etwa deine Firmendaten, Benutzer oder eine Vertriebspipeline. Siehe Ohne Repository.

Eine Sitzung starten #

Es gibt drei Wege. Jeder startet eine Art von Sitzung:

Die REST-API und KI-Assistenten wählen die Art stattdessen mit einem Flag.

Was du ausfüllst #

Jeder Weg fragt dasselbe ab:

Unter More options, zugeklappt, weil die meisten Sitzungen sie so lassen, wie sie sind:

Das Odoo bereitzustellen dauert einige Minuten, eine Agent-Kopie am längsten, weil sie erst kopiert und geladen wird. Du landest auf der Sitzungsseite, die zeigt, wie weit es ist (siehe Wenn eine Sitzung endet), und danach die Unterhaltung live.

Aus dem Dialog Create Copy #

Klicke an einem Odoo auf Create Copy, auf seiner Seite, in der Liste der Odoos oder in seinem Tab Copies, und schalte Start a coding agent in this copy ein. Der Schalter erscheint für Teams mit Coding-Agents, die sie auf diesem Odoo starten dürfen, nicht aber, wenn du eine Kopie aus einem Backup erstellst.

Mit eingeschaltetem Schalter wird der Dialog zum Start einer Sitzung:

• Seine Überschrift sagt, dass du das Odoo kopierst und einen Agenten startest, und sein Button heißt Create copy and start agent.
• Neutralize sensitive data ist eingeschaltet und gesperrt: Eine Agent-Kopie ist immer neutralisiert. Obfuscate personal data bleibt deine Wahl.
• Server und Share the copy with entfallen: Eine Agent-Kopie wird für die Sitzung erstellt, auf dem Server für Kopien des Odoo.
• Die Felder von oben erscheinen.

Der Schalter ist ausgegraut, mit dem Grund darunter, wenn dein Team keinen API-Schlüssel für seinen Modellanbieter hat oder das Odoo kein Repository hat, in das der Agent pushen kann.

Eine Agent-Kopie zählt nicht zum Kopienlimit deines Plans und wartet nicht auf eine Kopie, die noch erstellt wird. Lässt sich keine normale Kopie erstellen, weil dein Plan keinen Platz für eine weitere hat, bereits eine Kopie des Odoo entsteht oder normale Kopien dir auf diesem Odoo nicht offenstehen, öffnet sich der Dialog trotzdem für einen Agenten: Der Schalter ist eingeschaltet und gesperrt, und ein Hinweis sagt, warum nur eine Agent-Kopie möglich ist.

Aus der Sitzungsliste #

Öffne Agent Sessions unter Developer und klicke auf Start session. Der Dialog Start agent in a copy fragt zuerst nach dem Odoo und dann nach den Feldern von oben. Sein Button heißt Create copy and start agent.

Direkt in einem Odoo #

Öffne die Seite eines Test-, Demo- oder Kopie-Odoo, öffne das Menü ⋮ am Ende der Kopfzeile und klicke auf Start agent in this Odoo. Siehe Direkt in einem Odoo arbeiten.

Wo der Agent arbeitet #

Der Agent arbeitet immer in einem Odoo, und die Sitzung belegt es, bis es jemand zurückgibt. Jeder Unterschied zwischen den beiden Arten folgt aus einer Tatsache: Eine Agent-Kopie benutzt sonst niemand, ein Odoo, in dem der Agent direkt arbeitet, benutzen dagegen andere Menschen.

In beiden Fällen meldet sich der Agent mit einem Administrator-Konto an, das nur für diese Sitzung erstellt wurde. Deine Benutzer und der Admin-Login des Odoo bleiben unberührt, und die Admin-Zugangsdaten einer Agent-Kopie sind nicht die des Agenten.

Beginne mit einer Agent-Kopie, außer die Änderung muss dort ausprobiert werden, wo dein Team ohnehin testet, mit den Daten, den übrigen Addons und den Benutzern dieses Odoo, und eine frische Kopie wäre nicht dasselbe.

Direkt in einem Odoo arbeiten #

Statt in einer Agent-Kopie kann der Agent direkt in einem Test-, Demo- oder Kopie-System arbeiten, zum Beispiel in dem Testsystem, auf dem dein Team Änderungen ohnehin ausprobiert. Öffne dieses Odoo, öffne das Menü ⋮ am Ende der Kopfzeile und klicke auf Start agent in this Odoo. Der Eintrag erscheint nur auf Test-, Demo- und Kopie-Odoos, nie auf einem Live-System, einer Vorschau oder einer Agent-Kopie, und nur für Personen, die Coding-Agents auf diesem Odoo starten dürfen.

Der Dialog beginnt mit einem Infokasten, der vor dem Start drei Punkte nennt: was mit den Data geschieht, mit Others, die das Odoo benutzen, und Afterwards. Ist das Odoo gestoppt, ergänzt er, dass die Ankunft des Agenten es startet, und hat es Konfigurationsänderungen, die noch nicht deployt sind, dass sie mit dem Agenten deployt werden. Ist das Odoo nicht neutralisiert, musst du außerdem bestätigen, dass du verstanden hast, dass seine E-Mails und Integrationen live sein können. Danach kommen die Felder von oben, und der Button heißt Start agent.

Ein Odoo nimmt jeweils einen Agenten auf. Solange es ein anderer Agent belegt, ist Start agent in this Odoo im Menü ⋮ ausgegraut, und sein Tooltip nennt die Sitzung, die das Odoo belegt, wenn sie zu deinem Team gehört, und sagt sonst nur, dass dort der Agent eines anderen Teams arbeitet. Außerdem sagt er dir, dass du das Odoo zuerst über die Agent-Karte auf seiner Seite zurückgeben musst, oder, wenn dein Team das nicht kann, das Team bitten sollst, das es hostet, es zurückzugeben. Kommt ein Agent an, während dein Dialog offen ist, lehnt Start agent mit Another agent works in this Odoo ab, und der Dialog bleibt offen.

Was sich am Odoo ändert #

• Das Odoo wird mit dem Agenten daneben neu deployt, startet also neu, wenn der Agent ankommt. Mit einem Repository führt das Odoo bis zum Gehen des Agenten dessen Checkout des Repositorys aus statt der eigenen deployten Version, für alle, die es benutzen. Aktualisierungen der Addons dieses Repositorys auf dem Odoo wirken erst, wenn der Agent geht und ein laufendes Odoo noch einmal neu startet.
• Für die Sitzung wird nichts kopiert oder neutralisiert: Der Agent sieht die Daten des Odoo, wie sie sind, und was er liest, geht an deinen KI-Anbieter. Ist das Odoo nicht neutralisiert, können seine ausgehenden E-Mails und geplanten Aktionen live sein. Der Agent wird darauf hingewiesen und gebeten, sie nicht auszulösen, außer du verlangst es. Ein Mail Catcher auf dem Odoo ändert daran nichts: Er fängt nur E-Mails ab, die das Odoo ohne eigenen Mailserver versendet.
• Ein Odoo nimmt jeweils einen Agenten auf. Eine Sitzung, die dort bereits einen anderen Agenten vorfindet, wartet nicht: Sie endet als Failed und blockiert das Odoo nicht. Siehe Wenn der Start scheitert.
• Automatische Redeploys warten, solange der Agent im Odoo arbeitet. Was sich in der Zwischenzeit geändert hat, wird deployt, wenn der Agent geht.
• Das Stoppen, Neustarten oder Neu-Deployen des Odoo unterbricht den Agenten. Die Bestätigung sagt es dir. Löschst du das Odoo, endet die Sitzung, als Failed, wenn sie noch lief, und sie belegt das Odoo nicht mehr.

Ohne Repository #

Lass Repository bei Start agent in this Odoo leer, und der Agent arbeitet am Odoo selbst statt an Code. Er sieht sich zuerst an, was installiert und eingerichtet ist, installiert die Apps, die die Aufgabe braucht, in einem Durchgang und richtet Einstellungen und Daten über Odoo selbst ein, zum Beispiel:

• Verkauf, CRM und die deutsche Buchhaltungslokalisierung installieren
• deine Firmendaten erfassen und drei Benutzer mit den passenden Zugriffsrechten anlegen
• eine Vertriebspipeline mit ihren Stufen einrichten

Ohne Repository hat der Agent keinen Checkout: Er schreibt keine Module, pusht nichts und öffnet keinen Pull Request, und die Sitzungsseite zeigt kein Changes-Badge. Braucht eine Aufgabe eigenen Code, sagt der Agent es dir; starte dafür eine Sitzung mit Repository. Alles, was er einrichtet, steht in der Datenbank des Odoo und bleibt, wenn der Agent geht. Einem Benutzer, den er anlegt, gibt der Agent nur dann ein Passwort, wenn du ihn darum bittest, und nennt es dir dann. Passwörter und Logins deiner bestehenden Benutzer ändert er nie.

Eine Agent-Kopie braucht immer ein Repository, denn ihre Arbeit verlässt die Kopie nur über einen Push.

Freigaben #

Weil andere Menschen das Odoo benutzen, fragen die Werkzeuge des Agenten zum Neustarten des Odoo, zum Aktualisieren von Modulen, zum Ausführen von SQL und zum Ausführen von odoo shell-Skripten dort in jedem Berechtigungsmodus außer Full access nach deiner Freigabe, auch bei Auto. Alles andere folgt wie gewohnt dem Berechtigungsmodus, und ein Push fragt wie in einer Agent-Kopie.

Im Modus Full access fragen auch diese Werkzeuge nicht: Der Agent startet das Odoo neu, aktualisiert Module und führt SQL und odoo shell aus, ohne vorher zu fragen, für alle, die das Odoo benutzen. Siehe Vollzugriff.

Eine Modulaktualisierung stoppt das Odoo, solange sie läuft, und startet es danach wieder, das Odoo beantwortet während der Aktualisierung also keine Anfragen. Ein Neustart oder eine Aktualisierung trennt alle, die das Odoo benutzen.

Sehen, wer in einem Odoo arbeitet #

Ein Odoo nimmt höchstens einen Agenten auf, deshalb zeigt seine Seite oben eine einzige Agent-Karte und nie eine Liste von Sitzungen. Die Karte erscheint, sobald der Agent unterwegs ist, und bleibt, bis das Odoo zurückgegeben ist.

• Ein Agent arbeitet direkt im Odoo. Die Karte heißt A coding agent works in this Odoo. Sie nennt, wessen Agent es ist und welche Addons welches Repositorys sein Checkout ersetzt, oder bei einem Agenten ohne Repository, dass er das Odoo selbst ändert. Ist die Sitzung beendet, sagt sie, dass der Agent das Odoo behält, mit seinem Checkout, wenn er einen hat, bis du es zurückgibst. Ihre Buttons sind View session und Release Odoo.
• Das Odoo ist eine Agent-Kopie. Die Karte heißt This copy was made for a coding agent. Sie nennt, wessen Agent es ist, wie weit er ist und, sobald die Sitzung beendet ist, dass die Kopie bleibt, bis du sie entfernst. Ihre Buttons sind View session und, sobald die Sitzung beendet ist, Remove copy. Entfernst du die Kopie, kommst du zurück zur Liste der Odoos, denn die Seite gibt es dann nicht mehr.
• Die Sitzung konnte nicht starten. Das Team, das sie gestartet hat, sieht den Grund auf der Karte als Last error.

Nur das Team, das eine Sitzung gestartet hat, sieht ihren Titel und kann sie öffnen. Jedem anderen Team, etwa dem Hosting-Team eines geteilten Odoo, zeigt die Karte zum Beispiel An agent of Acme GmbH, ohne Titel, Link und Fehlertext.

An weiteren Stellen im Panel:

• Die Spalte Agent in der Liste der Odoos zeigt ein Sparkles-Symbol, solange ein Agent ein Odoo vorbereitet oder darin arbeitet, in einer Agent-Kopie ebenso wie direkt. Fahre mit der Maus darüber, um zu sehen, wessen Agent es ist.
• Der Tab Copies eines Odoo listet seine Agent-Kopien zusammen mit seinen übrigen Kopien. Die Spalte Type sagt Agent copy, und die Spalte Agent verlinkt auf die Sitzung deines eigenen Teams.
• Die Bestätigung beim Löschen eines Odoo, in dem ein Agent arbeitet, oder einer Agent-Kopie, die ihre Sitzung noch belegt, sagt, dass die Sitzung endet und alles verloren geht, was der Agent nicht gepusht hat.
• ⋮ > Agent sessions auf der Seite des Odoo öffnet den Verlauf der Sitzungen, die von diesem Odoo aus gestartet wurden, mit ausgewähltem All sessions. Den Eintrag sehen Personen, die Coding-Agents auf dem Odoo starten dürfen. Auf einer Agent-Kopie gibt es ihn nicht, denn ihre Sitzungen wurden von dem Odoo aus gestartet, aus dem sie gemacht wurde, und auf einer Kopie erscheint er, sobald dein Team von ihr aus eine Sitzung gestartet hat.

Wenn eine Sitzung endet #

Der Status der Sitzung sagt, was der Agent tut. Die Phase ihres Odoo sagt, was das Odoo durchläuft, und das ist nicht dasselbe: Eine Sitzung, die abgeschlossen wurde, fehlgeschlagen ist oder gestoppt wurde, belegt ihr Odoo weiter, bis es jemand zurückgibt. Die Sitzungsseite zeigt die Phase jeder Sitzung, welcher Art auch immer, unter Works in, mit Namen und Typ ihres Odoo. Unter Started nennt sie unter dem Datum das Odoo, von dem aus die Sitzung gestartet wurde, und verlinkt darauf, solange du es öffnen kannst. Der Eintrag bleibt, wenn eine Agent-Kopie weg ist, und fehlt, wenn der Agent direkt in diesem Odoo arbeitet.

Nichts wird von selbst zurückgegeben #

Eine beendete Sitzung belegt ihr Odoo, bis es jemand zurückgibt. Kein Datum läuft ab, und nichts löscht nach einigen Tagen eine Agent-Kopie oder gibt ein Odoo zurück.

• Eine Agent-Kopie bleibt, samt Datenbank und Checkout des Agenten, bis du sie entfernst. Sie zählt nicht zum Kopienlimit deines Plans, belegt aber weiter Serverressourcen. Entferne deshalb die, mit denen du fertig bist.
• Ein Odoo, in dem der Agent direkt gearbeitet hat, bleibt beim Agenten, mit seinem Checkout, wenn er einen hat, für alle, die es benutzen, bis du es zurückgibst.

Beim Zurückgeben geht Arbeit verloren, die nie gepusht wurde. Bitte den Agenten deshalb vorher, sie zu pushen. Siehe Zurückgeben.

Eine Sitzung fortsetzen #

• Eine Sitzung ist Completed, wenn der Agent fertig und inaktiv ist. Sende eine weitere Nachricht, um sie mit derselben Unterhaltung und demselben Checkout fortzusetzen. Das geht, solange die Sitzung ihr Odoo belegt, ohne Frist.
• Eine Sitzung, die Failed ist, etwa weil der Agent unerwartet gestoppt hat, lässt sich ebenfalls mit einer Nachricht fortsetzen, solange sie ihr Odoo noch belegt.
• Eine Sitzung, die du gestoppt hast oder die nicht starten konnte, lässt sich nicht fortsetzen. Starte eine neue.
• Ist ihr Odoo zurückgegeben, lässt sich eine Sitzung nicht mehr fortsetzen, auf welchem Weg auch immer es dazu kam. Die Unterhaltung bleibt lesbar.

Die Liste Agent Sessions zeigt standardmäßig Active & unfinished: Sitzungen, die noch laufen oder auf dich warten, solche, die noch ein Test-, Demo- oder Kopie-Odoo belegen, in dem sie direkt arbeiten, solche, deren Agent-Kopie noch nie gepushte Arbeit enthält, und solche, deren Arbeit noch keinen gemergten Pull Request erreicht hat. Wechsle zu All sessions für den gesamten Verlauf. Die Sitzungen sind nach Odoo gruppiert, mit geschätzten Kosten pro Gruppe.

Zurückgeben #

Ein Odoo zurückzugeben heißt, dass die Sitzung es loslässt:

• Eine Agent-Kopie wird gelöscht, samt Datenbank, Checkout des Agenten, seinem Gesprächsverlauf und den Dateien der Sitzung.
• Ein Odoo, in dem der Agent direkt gearbeitet hat, bleibt. Der Agent verlässt es: Sein Checkout, sein Gesprächsverlauf und sein Login werden aus dem Odoo entfernt, und das Odoo bekommt seine eigenen Addons zurück. Ein laufendes Odoo startet dafür neu; ein gestopptes bleibt gestoppt, und nur seine Konfiguration wird neu geschrieben. Was der Agent in der Datenbank geändert hat, bleibt, etwa Module, die er installiert oder aktualisiert hat, und Datensätze, die er geändert hat. Aktualisiere deshalb die Addons des Odoo, wenn sein eigener Code älter ist als das, was der Agent aktualisiert hat.

Arbeit im Checkout des Agenten, die nie gepusht wurde, geht verloren, und die Sitzung lässt sich nicht mehr fortsetzen. Bitte den Agenten deshalb, vorher zu pushen. Die Unterhaltung bleibt lesbar. Das Aktivitätsprotokoll eines Odoo, in dem ein Agent direkt gearbeitet hat, hält fest, wann ein Agent ankam und wann er ging.

Ein Odoo wird nur zurückgegeben, wenn:

• du auf Remove copy oder Release Odoo klickst, an der Sitzungsseite, sobald die Sitzung beendet ist. Der Button heißt Remove copy bei einer Agent-Kopie und Release Odoo bei einem Odoo, in dem der Agent direkt gearbeitet hat. Die Bestätigung warnt dich, wenn der Checkout ungepushte Arbeit enthält. Eine laufende Sitzung musst du vorher stoppen.
• du die Sitzung stoppst, bei einem Agenten, der direkt in einem Odoo arbeitet. Stop session gibt das Odoo sofort zurück, was der Agent auch gerade tut, und die Bestätigung warnt dich vor ungepushter Arbeit. Das Stoppen über die API oder einen KI-Assistenten tut dasselbe. Stoppst du eine Sitzung mit Agent-Kopie, bleibt die Kopie, wie sie ist, bis sie zurückgegeben wird.
• ein Kollege an der Agent-Karte des Odoo auf Release Odoo oder Remove copy klickt. Das kann das Hosting-Team und das Team, das die Sitzung gestartet hat, sofern sie das Odoo neu deployen dürfen; ein Kollege muss also nicht auf die Person warten, die die Sitzung gestartet hat. Ein Partnerteam kann nie den Agenten des Hosting-Teams oder eines anderen Partners zurückgeben.
• das Odoo gelöscht wird. Die Sitzung belegt es dann nicht mehr, und alles, was der Agent nicht gepusht hat, geht verloren.
• das Team den Zugriff verliert. Wird ein Partnerteam von einem geteilten Odoo entfernt oder verlässt es, werden seine Agenten aus diesem Odoo und aus allen seinen Kopien zurückgegeben, und die Agent-Kopien, die seine Sitzungen daraus gemacht haben, werden ebenfalls gelöscht. Wird seine Rolle auf Viewer oder Operator gesenkt, die keine Coding-Agent-Sitzungen starten können, geschieht das Gleiche für dieses Odoo, aber nicht für seine Kopien, denn dort behält das Team seine eigene Rolle.
• du es über die API oder einen KI-Assistenten entfernst oder zurückgibst. Siehe Webhooks und die API.

Wenn der Start scheitert #

Eine Sitzung, die das Odoo, in dem sie arbeiten sollte, nicht bekommt, endet mit dem Grund als Failed, egal welcher Art sie ist. Sie bleibt nicht auf „pending“ und blockiert nichts. Wer sie gestartet hat, wird benachrichtigt, und die Sitzung lässt sich nicht fortsetzen: Starte eine neue. Die Gründe sind:

• Bei einer Agent-Kopie: Das Odoo, von dem aus sie gestartet wurde, existiert nicht mehr oder hat keinen Server, dein Team darf dort keine Coding-Agents mehr starten, oder die Kopie für den Agenten ließ sich nicht erstellen.
• Bei einem Agenten, der direkt in einem Odoo arbeitet: Das Odoo belegt bereits eine andere Sitzung, dein Team hat keinen Zugriff mehr darauf, es hat keinen Server, oder der Login des Agenten ließ sich darin nicht anlegen. Starte die neue Sitzung in einer Agent-Kopie oder erst, wenn die andere das Odoo zurückgegeben hat.

Ist das Odoo bereit, ließ sich der Agent aber nicht darin starten, bleibt die Sitzung mit dem Grund auf der Sitzungsseite auf „pending“. Stoppe sie und starte eine neue. Fehlt der API-Schlüssel deines Teams, sobald der Agent startet, schlägt die Sitzung stattdessen mit diesem Grund fehl. Trage den Schlüssel ein und sende eine Nachricht, um sie fortzusetzen.

Die Startdialoge lehnen ab, bevor etwas erstellt wird, mit einer Meldung und offen bleibendem Dialog: wenn dein Team keinen API-Schlüssel für seinen Modellanbieter hat (die Meldung verlinkt auf die Teameinstellungen, wenn du sie öffnen darfst), wenn in dem Odoo, in dem du einen Agenten direkt startest, bereits ein anderer Agent arbeitet, oder wenn dein Team auf dem Odoo keine Coding-Agents starten darf.

Was der Agent kann #

In seinem Odoo kann der Agent die Dateien des Repositorys lesen und ändern, Befehle ausführen und committen, wenn die Sitzung ein Repository hat. Außerdem kann er:

• das Odoo neu starten und seine Logs lesen
• Module installieren und aktualisieren und dabei optional ihre Tests ausführen
• SQL und odoo shell gegen die Datenbank ausführen
• das Odoo in einem Browser öffnen, angemeldet mit dem Administrator-Konto, das für die Sitzung erstellt wurde; deine Benutzer und ihre Passwörter bleiben unberührt
• die E-Mails lesen, die das Odoo verschickt hat, einschließlich der Anhänge, um zu prüfen, ob eine Änderung die richtigen Personen anschreibt. Dafür braucht der Server den Mail Catcher.
• Dateien mit dir teilen, etwa Screenshots oder Exporte

In einem Odoo, in dem er direkt arbeitet, fragen seine Werkzeuge zum Neustarten des Odoo, zum Aktualisieren von Modulen, zum Ausführen von SQL und der Odoo-Shell in jedem Modus außer Full access nach deiner Freigabe; siehe Freigaben.

Berechtigungen und Fragen #

Der Permission mode legt fest, wann der Agent anhält und nachfragt:

In jedem Modus außer Full access fragt ein Push nach deiner Freigabe, und in einem Odoo, in dem der Agent direkt arbeitet, ebenso seine Werkzeuge zum Neustarten des Odoo, zum Aktualisieren von Modulen, zum Ausführen von SQL und der Odoo-Shell; siehe Freigaben.

Eine Anfrage erscheint in der Unterhaltung als Permission requested mit Approve und Deny. Braucht der Agent eine Eingabe, stellt er eine Frage mit Antwortoptionen oder Platz für deine eigene Antwort und wartet, bis du antwortest. Modell, Reasoning effort und Permission mode kannst du ändern, während die Sitzung läuft.

Wer eine Sitzung gestartet hat, bekommt eine Benachrichtigung in der App, wenn der Agent eine Entscheidung oder eine Antwort braucht und wenn die Sitzung fehlschlägt oder nicht starten kann.

Vollzugriff #

Im Modus Full access fragt der Agent nach keiner Freigabe. Jede Aktion geht durch, sobald der Agent sie ausführt: Dateiänderungen, Befehle, Pushes und, in einem Odoo, in dem er direkt arbeitet, die Werkzeuge, die dort in jedem anderen Modus fragen (siehe Freigaben). In der Unterhaltung erscheint kein Permission requested.

• Fragen warten weiter auf dich. Eine Frage ist keine Freigabe: Braucht der Agent eine Eingabe, fragt er und wartet auf deine Antwort, wie in jedem anderen Modus.
• Schütze die Branches, aus denen deine Odoos bereitstellen. Der Agent ist angewiesen, nur seinen eigenen Work-Branch zu pushen und das Mergen dir zu überlassen, aber mit Vollzugriff prüft niemand einen Push, bevor er bei GitHub ankommt. Sollen Änderungen diese Branches nur über einen Pull Request erreichen, den du prüfst, schütze sie auf GitHub mit einer Branch-Protection-Regel oder einem Ruleset. Fügst du Module mit Add Module hinzu, nimm die GitHub-App von calmo.cloud von dieser Regel aus, denn sie committet direkt in den Branch.
• Eine Anfrage, die schon wartet, wartet weiter. Wechselst du zu Full access, wird sie dadurch nicht freigegeben. Gib sie also wie gewohnt frei oder lehne sie ab; ohne Rückfrage geht erst durch, was der Agent nach dem Wechsel tut. Wechselst du in einen anderen Modus, fragt der Agent wieder so, wie es dieser Modus vorsieht.
• Dafür brauchst du keine zusätzliche Berechtigung. Wer den Berechtigungsmodus wählen darf, darf auch Full access wählen, beim Start einer Sitzung oder während sie läuft, im Panel, über die REST-API (fullAccess) oder über einen KI-Assistenten. Der Agent selbst kann nicht in diesen Modus wechseln.

Die Änderungen übernehmen #

Das Badge im Sitzungskopf zeigt, wo die Änderungen stehen: No changes, Unpushed, Pushed, PR open, Merged oder PR closed. Hat der Agent ungepushte Commits, klicke auf Request push und gib den Push frei. Im Modus Full access pusht der Agent ohne Rückfrage, es gibt also nichts freizugeben. Klicke anschließend auf Open pull request. Gibt es für den Branch bereits einen Pull Request, übernimmt die Sitzung ihn. Sein Status folgt ab dann GitHub.

Klicke auf Open Odoo, um die Änderung selbst auszuprobieren, bevor du mergst.

Geteilte Odoos #

Auf einem Odoo, das mit deinem Team geteilt ist, brauchst du zum Starten von Sitzungen die Rolle Developer. Sitzungen gehören dem Team, das sie gestartet hat: Das Hosting-Team sieht die Sitzungen eines Partnerteams nicht und umgekehrt. Ein Partnerteam startet eine Agent-Kopie eines geteilten Odoo wie jedes andere Team über den Dialog Create Copy, und die Kopie ist nur mit diesem Partnerteam geteilt.

Auch der Agent eines Partnerteams kann direkt in einem geteilten Test-, Demo- oder Kopie-Odoo arbeiten. Das Hosting-Team sieht ihn auf der Seite des Odoo, wo die Agent-Karte das Partnerteam nennt statt der Sitzung. Die Sitzung öffnen kann es nicht, aber es kann den Agenten mit Release Odoo zurückgeben, wenn es das Odoo neu deployen darf. Das Partnerteam kann seine eigenen Agenten auf dieselbe Weise zurückgeben, nie aber die des Hosting-Teams oder eines anderen Partners. Im geteilten Odoo gilt ebenso der Berechtigungsmodus der Sitzung des Partnerteams: Mit Full access startet sein Agent das Odoo dort neu, aktualisiert Module und führt SQL aus, ohne jemanden zu fragen, auch nicht das Hosting-Team.

Wird ein Partnerteam vom Odoo entfernt oder verlässt es, werden seine Agenten aus dem Odoo und aus allen seinen Kopien zurückgegeben, und die Agent-Kopien, die seine Sitzungen daraus gemacht haben, werden gelöscht. Wird seine Rolle auf Viewer oder Operator gesenkt, die keine Coding-Agent-Sitzungen starten können, geschieht das Gleiche für das Odoo selbst, aber nicht für seine Kopien, denn dort behält das Team seine eigene Rolle.

Webhooks und die API #

• Webhooks melden deinem System, wenn eine Sitzung ihren Status ändert, eine Entscheidung braucht, einen Pull Request öffnet oder Dateien teilt. Der Button Webhooks in der Sitzungsliste führt Team-Admins dorthin.
• Die REST-API und KI-Assistenten über MCP können Sitzungen starten, ihnen antworten und ihre Anfragen beantworten. Für ein Team, für das Coding-Agents nicht aktiviert sind, antworten die Agent-Aufrufe der REST-API mit 403, und KI-Assistenten bekommen die Agent-Werkzeuge nicht; der Team-Endpunkt zeigt es als early_access.coding_agents. Eine so gestartete Sitzung arbeitet in einer Agent-Kopie. Sobald das direkte Arbeiten in einem Odoo für dein Team aktiviert ist, übergib attached: true, damit der Agent direkt in einem Test-, Demo- oder Kopie-System arbeitet; der Team-Endpunkt zeigt es als early_access.coding_agents_attach. Mit attached: true ist das Repository optional: Lass repository_uuid weg für einen Agenten, der das Odoo einrichtet, und mit ihm auch branch. Beides erfordert den Agency-Plan; im Panel funktionieren Coding-Agents in jedem Plan.
• Die Agent-Kopie einer beendeten Sitzung über die API oder MCP zu entfernen, tut dasselbe wie der Button: Eine Agent-Kopie wird gelöscht, und ein Odoo, in dem der Agent direkt gearbeitet hat, wird zurückgegeben. Ein KI-Assistent muss dafür den Work-Branch der Sitzung wiederholen.
• Wer eine Sitzung, die direkt in einem Odoo arbeitet, über die API oder MCP abbricht, gibt das Odoo genauso zurück wie mit Stop session und verwirft Arbeit, die nie gepusht wurde. Ein KI-Assistent muss dafür den Work-Branch der Sitzung wiederholen. Eine Sitzung mit Agent-Kopie abzubrechen lässt die Kopie, wie sie ist.
• Eine Sitzung, deren Odoo zurückgegeben wurde, meldet resumable: false.
• Eine Sitzung meldet ended_at, wann sie zuletzt geendet hat, und service_stage (preparing, starting, working, holding, released oder not_used), egal welcher Art sie ist. Ein Odoo meldet is_neutralized und, wenn es einzeln abgerufen wird, coding_agent_working.
• Eine Sitzung, die das Odoo, in dem sie arbeiten sollte, nicht bekommen hat, endet bei beiden Arten als failed; ihr Webhook status_changed trägt die Ursache start_failed und den Grund.