Automatisierung

Console-Bots

Entwerfen Sie im Chat abgegrenzte Archibot-Bot-Arbeit, prüfen Sie das Aufgabenpaket und führen Sie es nur aus, wenn Kundenrichtlinie, Profil und Blueprint-Schranken es zulassen.

KundenadministratorenPlattformbetreiber

Zuletzt aktualisiert 18. Juni 2026

Wofür Bots gedacht sind

Console-Bots verwandeln eine abgegrenzte, gut beschriebene Änderung in Archibot-Arbeit, die in einem Console-Merge-Ereignis, einer Prüfung, QA und menschlicher Freigabe endet. Eine Bot-Aufgabe erfasst das Repository und den Branch, von dem aus gearbeitet wird, den Pfadbereich, in dem geblieben werden soll, und die QA-Notizen, die der spätere QA-Schritt ausführen soll.

Das Speichern einer Aufgabe merged keinen Code. Solange ein Konto im reinen Einrichtungsmodus ist, zeigt die Oberfläche ein Banner Nur Einrichtung an und Sie erfassen lediglich prüfbare Aufgabendatensätze. Wenn die Ausführung aktiviert ist, prüft die Console weiterhin die Bot-Richtlinie, das ausgewählte Profil, das zulässige Blueprint, das Limit gleichzeitiger Läufe und das Monatsbudget, bevor ein Workspace startet.

Wer Bots nutzen kann

Kundenadministratoren können Bot-Arbeit für ihr eigenes Konto entwerfen und verwalten. Plattformbetreiber können dasselbe für ein ausgewähltes Kundenkonto tun, und sie verwalten die Richtlinie, die Profile und die Blueprint-Einstellungen, die die Ausführung steuern.

Kundenmitglieder können die Bots-Seite nicht öffnen. Wenn ein Mitglied eine Bot-Aufgabe benötigt, bitten Sie einen Kundenadministrator, sie zu prüfen und zu entwerfen.

Wie die Seite aufgebaut ist

Öffnen Sie Bots über die Console-Seitenleiste. Ein Kopfbanner zeigt je nach Konto Nur Einrichtung oder Workspace-Übergabe aktiviert an, und eine Schaltfläche Neue Bot-Aufgabe sowie Aktualisieren befinden sich oben rechts.

Unter dem Kopf befindet sich eine Reihe von Abschnittsregistern, jedes mit einer Anzahl:

Eine Aufgabe im Chat gestalten

Das Register Aufgaben-Chat öffnet sich auf Mit Archibot chatten. Dies ersetzt das alte feste Formular: Sie beschreiben die Arbeit im Gespräch, und Archibot füllt das Aufgabenpaket aus, sobald Details klar werden.

1. Öffnen Sie Bots und bleiben Sie dann auf dem Register Aufgaben-Chat.
2. Verwenden Sie das Unterregister Mit Archibot chatten. Lesen Sie die Eröffnungsnachricht, die fragt, was sich ändern muss, was als erledigt gilt und wie QA es nachweisen soll.
3. Verwenden Sie eine Start-Pille, um das Gespräch zu fokussieren, oder geben Sie Ihre eigene Nachricht ein:
   • Akzeptanzkriterien verwandelt eine Beschreibung in Bestehen/Nicht-bestehen-Kriterien.
   • QA-Plan entwirft Browser-Prüfungen, Datenvorbereitung und was den Lauf zum Scheitern bringen soll.
   • Nachweis hinzufügen gestaltet die Aufgabe aus Notizen oder eingefügtem Nachweis.
   • Bereich einschränken verengt die Repository-Pfade, den Branch und die Dateien, die der Bot anfassen darf.
4. Geben Sie in Nachricht an Archibot ein und wählen Sie Senden (oder drücken Sie Strg+Eingabe). Jede Nachricht aktualisiert die QA-Notizen und kann einen Titel oder Bereich vorschlagen.
5. Wechseln Sie zum Unterregister Aufgabenpaket, um vor dem Speichern zu prüfen, was Archibot erfasst hat.

Halten Sie Anfragen spezifisch. „Ein Feld zu Space Console hinzufügen“ mit klaren Akzeptanzkriterien funktioniert; „die App reparieren“ oder „das Repo aufräumen“ nicht.

Das Aufgabenpaket prüfen und vervollständigen

Das Unterregister Aufgabenpaket zeigt die Werte, die mit der Aufgabe gespeichert und an den Workspace übergeben werden. Eine Feldanzahl erscheint oben rechts, und drei Übersichtskarten oben zeigen Kunde, Profil und Quelle.

Das Paket ist in eigene Unterregister gegliedert, jedes mit einer Anzahl:

1. Überblick listet die Paketfelder auf, darunter Kunde, Profil, Aufgabentitel und Basis-Branch.
2. Quelle enthält die Repository-URL und den Basis-Branch, von dem aus der Bot arbeitet, sowie den Pfadbereich (zum Beispiel src/, docs/), wenn die Änderung in bestimmten Ordnern bleiben soll.
3. Produkt ist optional. Aktivieren Sie Abhängiges Produkt-Repository hinzufügen, wenn der Bot ein Produkt-Repo bearbeiten muss, das vom Runtime-Repo abhängt. Sie legen dann die Produkt-Repository-URL, den Basis-Branch, den Checkout-Pfad und den Deploy-Befehl fest. Das Runtime-Repository wird zuerst vorbereitet, dann wird das Produkt-Repository ausgecheckt, deployt und als Worktree und Merge-Ereignis-Quelle verwendet.
4. QA & Speichern enthält die QA-Notizen (Browser-Prüfungen, Datenvorbereitung oder Grenzfälle) und das Speichern-Steuerelement.

Wenn Sie bereit sind, wird die Schaltfläche unter QA & Speichern je nach Kontostatus beschriftet:

• Im reinen Einrichtungsmodus steht dort Entwurf speichern und speichert nur einen prüfbaren Aufgabendatensatz. Workspace-Ausführung, Budgets und Merge-Ereignis-Übergabe bleiben deaktiviert.
• Wenn die Workspace-Übergabe aktiviert ist, steht dort Bot starten.

Die Schaltfläche bleibt deaktiviert, bis Aufgabentitel und Pflichtfelder gesetzt sind. Plattformbetreiber müssen außerdem zuerst ein Kunden-Konto wählen.

Bot-Aufgaben

Das Register Bot-Aufgaben listet entworfene und abgeschlossene Aufgaben mit ihrem Prüfungs-, QA-, Protokoll- und Freigabestatus auf. Öffnen Sie eine Aufgabe, um ihr Paket und ihren Verlauf zu sehen. Um einen Entwurf zu stoppen, den Sie nicht mehr möchten, brechen Sie ihn ab: Der Abbruch behält den Audit-Datensatz und setzt den Status auf canceled, statt die Aufgabe zu löschen.

Laufverlauf

Wenn die Ausführung aktiviert ist, kann ein Lauf einen Branch erstellen, einen Workspace vorbereiten und das Ergebnis als Merge-Ereignis an die Console übergeben. Das Register Laufverlauf zeigt jede Lauf-Anfrage links und ein Panel Lauf-Detail rechts.

Das Detail-Panel zeigt den Laufstatus, Modus, Branch, den Runner-Job, die Aktivitäts-Zeitleiste und bereinigte Lauf-Protokolle. Wenn ein Merge-Ereignis vorhanden ist, verlinkt Merge-Anfrage öffnen darauf. Die Console bleibt die Prüfungsebene: Eine Person genehmigt und merged aus der Console, nachdem die erforderlichen Prüfungs- und QA-Schranken bestanden sind. Siehe Persistente Umgebungen und CI-Prüfung für den Prüfungsablauf.

Bot-Richtlinie (Betreiber)

Das Register Bot-Richtlinie steuert, welche Bots ein Kunde anfordern darf, bevor irgendeine Workspace-Ausführung zugelassen wird. Ein Abzeichen zeigt Kunde aktiviert oder Kunde deaktiviert.

Wichtige Steuerelemente:

1. Bot-Läufe für diesen Kunden zulassen ist der Kundenschalter. Der Hinweis erinnert daran, dass der globale Plattformschalter und der Lauf-Orchestrator ebenfalls aktiviert sein müssen, bevor Workspaces starten können.
2. Standardprofil und Workspace-Ziel legen die auf neue Läufe angewendeten Standardwerte fest.
3. Monatliche Bot-Budgeteinheiten und Gleichzeitige Läufe bieten Voreinstellungen sowie eine freie Eingabe.
4. Aufbewahrungstage für Protokolle und Artefakte legt fest, wie lange Protokolle und Nachweise aufbewahrt werden.
5. Workspace-Bereinigung wählt, ob Workspaces nach jedem Lauf gelöscht, fehlgeschlagene zur Fehlersuche behalten oder alle bis zur manuellen Löschung behalten werden.
6. Artefaktbehandlung wählt, wie Nachweise aufbewahrt werden, einschließlich der Archivierung auf einem Gemeinsamen Laufwerk.
7. Zulässige Blueprints begrenzt, welche Blueprints dieser Kunde ausführen darf.

Wählen Sie Richtlinie speichern, um die Einstellungen zu persistieren.

Bot-Profile (Betreiber)

Das Register Bot-Profile erstellt kundenspezifische Profile, die die Worker-Vorlage, das Reasoning, die Tools und die Limits definieren, die von Aufgabenentwürfen verwendet werden.

1. Wählen Sie das Kunden-Konto, dem das Profil gehört.
2. Wählen Sie Neues Profil, legen Sie dann einen Profilnamen und das verwendete Blueprint fest.
3. Fügen Sie eine Profilbeschreibung dazu, was das Profil ändern darf und wie QA die Arbeit behandeln soll.
4. Aktivieren Sie Dieses Profil auswählbar machen, damit es für neue Läufe verwendet werden kann. Deaktivierte Profile bleiben für die Einrichtung sichtbar, sollten aber nicht verwendet werden.
5. Legen Sie das Workspace-Ziel, die Vorlage, den Reasoning-Aufwand, das Runtime-Limit (Sekunden), die Monatlichen Budgeteinheiten, die Gleichzeitigen Läufe und die Tool-Zulassungsliste fest.
6. Wählen Sie Profil speichern. Bestehende Profile bieten Profil bearbeiten, Als Vorlage verwenden und Profil löschen.

Blueprints (Betreiber)

Das Register Blueprints listet die festen Workflow-Vorlagen auf, etwa Console-verwaltetes Feature, Console-verwaltete Korrektur und Console-verwaltete Dokumentation. Jede Karte zeigt ihr Prüfungsmodell, ihren QA-Schritt, ihr Runtime-Limit und ihr Dateibudget, mit einem Abzeichen Aktiviert oder Nur Einrichtung.

Verwenden Sie Für Kunde aktivieren oder Für Kunde deaktivieren, um zu steuern, welche Workflows ein Kunde ausführen darf. Das Aktivieren eines Blueprints hier startet keine Arbeit; es erweitert nur, was eine Richtlinie und ein Profil auswählen können.

Sichere Inhalte

Platzieren Sie keine Passwörter, API-Schlüssel, Cookies, Einladungslinks, Webhook-Geheimnisse, Tokens für private Repositories, Datenbank-URLs, Pod-Umgebungsvariablen, Rohprotokolle oder Kundendaten in einer Bot-Aufgabe, QA-Notiz, einem Profil oder einer Blueprint-Einstellung.

Sichere Inhalte umfassen Repository-URLs, Branch-Namen, Ticket-Referenzen, Pfadbereiche, nicht geheime Einrichtungsnotizen, sichtbare Console-Fehler und zu prüfende Browser-Verhalten.

Was später passiert

Wenn die Bot-Ausführung für ein Konto aktiviert ist, kann eine gespeicherte Aufgabe zum Ausgangspunkt eines kontrollierten Workflows werden: Workspace-Einrichtung, Implementierung, Erstellung des Merge-Ereignisses, Prüfung, QA und menschliche Freigabe. Jeder Schritt durchläuft weiterhin die normalen Console-Prüfungsschranken, bevor etwas gemerged wird.

Verwandte Leitfäden

• Persistente Umgebungen und CI-Prüfung
• Operations-Center
• Workspace-Archibot und Gemeinsames Laufwerk
• Mandantenverwaltung für Betreiber
• Workspaces verwalten