Dokumentation / Code und Addons
Coding-Agents
Lass einen KI-Coding-Agent deine Addons in einer Sandbox-Kopie deines Odoo ändern und prüfe anschließend seinen Pull Request.
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 einer Sandbox-Kopie deines Odoo aus und öffnet einen Pull Request, sobald du seinen Push freigibst. Du verfolgst die Sitzung mit, beantwortest seine Fragen und legst fest, was er tun darf.
Coding-Agents sind im Early Access und werden Team für Team freigeschaltet. Wenn du im Panel-Menü unter Developer keine Agent Sessions siehst, sind sie für dein Team noch nicht aktiviert. Melde dich bei uns, dann schalten wir sie frei.
So funktioniert es #
- Jede Sitzung bekommt eine Sandbox: eine neutralisierte Kopie des Odoo, von dem aus du sie gestartet hast. Sie wird auf dem Server für Kopien dieses Odoo erstellt, oder auf seinem eigenen Server, wenn keiner festgelegt ist. Sandboxes zählen nicht zum Kopienlimit deines Plans.
- Der Agent läuft neben der Sandbox auf deinem Server. Sein Checkout, seine Unterhaltung und die Odoo-Daten bleiben auf deinem Server.
- 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.
- Ohne dich verlässt nichts die Sandbox: Jeder
git pushfragt nach deiner Freigabe, in welchem Berechtigungsmodus die Sitzung auch läuft.
Bevor du anfängst #
API-Schlüssel hinzufügen #
Ein Team-Owner oder Admin trägt den Schlüssel einmalig ein:
- Öffne das Teammenü und wähle Team profile.
- 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.
- Füge den Schlüssel ein und wähle optional ein Default model, mit dem jede neue Sitzung startet.
- 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.
Eine Sitzung starten #
Öffne das Odoo und seinen Tab Agent Sessions, oder öffne Agent Sessions im Menü und klicke auf Start session. Fülle dann aus:
| Feld | Wofür es ist |
|---|---|
| Title | Ein Name für die Sitzung. Er wird auch der Titel des Pull Requests. |
| Service | Nur beim Start aus der Liste: das Odoo, von dem die Sandbox kopiert wird. Kopien und Vorschauen lassen sich nicht auswählen. |
| Repository | Das Repository, an dem der Agent arbeitet. |
| Prompt | Was der Agent tun soll, bis zu 10.000 Zeichen. |
| Attachments | Bis zu 8 Dateien pro Nachricht, etwa Screenshots oder Beispieldaten, je 25 MB. |
| Model | Wähle aus der Liste deines Anbieters oder gib eine beliebige Modell-ID ein. |
| Reasoning effort | Von Low (am schnellsten) bis Max (tiefstes Nachdenken). Stufen, die ein Modell nicht unterstützt, werden automatisch gesenkt. |
| Permission mode | Wie oft der Agent nachfragt, bevor er handelt. Siehe unten. |
| Branch | Optional. Der Branch, von dem der Agent ausgeht und auf den der Pull Request zielt. Standard ist der Branch des Repositorys für die Version des Odoo. |
Die Sandbox einzurichten dauert einige Minuten. Danach zeigt die Sitzungsseite die Unterhaltung live.
Was der Agent kann #
In seiner Sandbox kann der Agent die Dateien des Repositorys lesen und ändern, Befehle ausführen und committen. Außerdem kann er:
- das Sandbox-Odoo neu starten und seine Logs lesen
- Module installieren und aktualisieren und dabei optional ihre Tests ausführen
- SQL und
odoo shellgegen die Sandbox-Datenbank ausführen - die Sandbox in einem Browser öffnen, angemeldet mit einem eigenen Admin-Konto; deine Benutzer und ihre Passwörter bleiben unberührt
- die E-Mails lesen, die die Sandbox 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
Berechtigungen und Fragen #
Der Permission mode legt fest, wann der Agent anhält und nachfragt:
| Modus | Verhalten |
|---|---|
| Ask every time | Der Agent fragt vor jeder Aktion, die etwas verändert. Der Standard. |
| Auto-accept edits | Dateiänderungen gehen durch. Andere Aktionen fragen weiterhin nach. |
| Auto | Der Agent entscheidet selbst, was sicher auszuführen ist. |
| Plan mode | Der Agent liest und plant nur, ohne etwas zu ändern. |
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.
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. Klicke dann 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 sandbox, um die Änderung selbst auszuprobieren, bevor du mergst.
Beenden, fortsetzen und aufräumen #
- Eine Sitzung ist Completed, wenn der Agent fertig und inaktiv ist. Sende eine weitere Nachricht, um sie mit derselben Unterhaltung und demselben Checkout fortzusetzen.
- Eine Sitzung, die Failed ist, etwa weil der Agent unerwartet gestoppt hat, lässt sich ebenfalls mit einer Nachricht fortsetzen, solange ihre Sandbox existiert.
- Stop session bricht die Sitzung endgültig ab: Offene Freigaben werden abgelehnt und die Sandbox wird heruntergefahren.
- Die Sandbox einer beendeten Sitzung wird nach sieben Tagen gelöscht. Remove sandbox löscht sie früher. Die Unterhaltung bleibt lesbar, aber die Sitzung lässt sich nicht mehr fortsetzen. Das Panel warnt dich, wenn die Sandbox noch ungepushte Arbeit enthält.
Die Liste Agent Sessions zeigt standardmäßig Active & unfinished: Sitzungen, die noch laufen oder auf dich warten, 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.
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.
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. Beides erfordert den Agency-Plan; im Panel funktionieren Coding-Agents in jedem Plan.