Zusammenarbeit im Team

AWR lässt mehrere Personen — und die Agents, mit denen sie arbeiten — an einem gemeinsamen Projekt koordinieren: Alle sehen dieselben Aufgaben, claimen die Arbeit, die sie erledigen, melden Fortschritt im Laufenden und übergeben fertige Arbeit an einen unabhängigen Reviewer. Du steuerst all das aus deiner normalen Agent-Konversation; du musst keine Aufgaben-IDs in einem Browser hin- und herkopieren.

Verfügbarkeit: Dieser Artikel beschreibt den Team-Dienst, der sich noch in Entwicklung befindet. Er ist nicht Teil des veröffentlichten 0.5.0 Personal-MCP-Servers. Die unten genannten Fähigkeiten gelten für ein Team-Projekt, das von deinem Projektadministrator gehostet wird, nicht für eine persönliche lokale Einrichtung.

Für die zugrunde liegenden Ideen (Arbeitselemente, Verträge, Nachweise, Sessions) lies zuerst Konzepte. Für die tägliche Einzelperson-Schleife siehe Dein täglicher Workflow.

Das Kollaborationsmodell auf einen Blick

Vier Ideen tragen das ganze Modell:

• Workstreams und gemeinsame Arbeit. Das Remote-Projekt ist die gemeinsame Arbeitsautorität — der eine Ort, an dem Aufgaben, Abhängigkeiten, Fortschritt und Ergebnisse leben. Dein lokaler Checkout ist nur für Code und Tests; initialisiere keinen zweiten lokalen Aufgaben-Ledger, um das Remote-Projekt zu ersetzen.
• Claiming. Bevor ein Agent Ausführungsarbeit beginnt, nimmt er einen Live-Claim auf die Aufgabe, unter seiner Session. Ein Live-Claim einer anderen Person darf nicht ersetzt werden, sodass zwei Agents nicht unbemerkt an derselben Sache arbeiten können.
• Review. Lieferung und Abnahme sind getrennte Fakten. Eine autorisierte, unabhängige Person prüft eingereichte Arbeit, bevor sie abgenommen wird. Ein zweiter Agent, der dir gehört, ist kein unabhängiger Reviewer.
• Übergabe. Sessions sind dauerhaft: Sie überleben MCP-Reconnects, tragen Checkpoints und Wiederherstellungszustand und können wieder aufgenommen werden — von dir nach einer Pause oder von einem Teammitglied eingesehen — ohne Kontext zu verlieren.

Einmal verbinden

Bitte deinen Projektadministrator um eine Projekt-MCP-URL und deine individuellen Zugangsdaten. Jeder Teilnehmer nutzt seine eigenen Zugangsdaten, und Repository-Berechtigungen bleiben von AWR-Berechtigungen getrennt — dem AWR-Projekt beizutreten gewährt keinen Git-Zugang, und umgekehrt.

Hinter den Kulissen öffnet ein autorisierter Administrator Members im Inspector, fügt dich hinzu, wählt deine Projektrolle und Workstreams und kopiert eine einmalige persönliche Verbindungsanleitung mit dem Endpunkt und deinen Zugangsdaten. Du erhältst sie über einen privaten Kanal. Der Administrator kann deren Klartext nach dem Schließen des Ausstellungspanels nicht mehr abrufen; wenn du die Zugangsdaten verlierst, können sie explizit ersetzt werden.

Füge den Remote-MCP-Server in jedem Agent-Client hinzu, der Remote-MCP über Streamable HTTP mit Bearer-Authentifizierung unterstützt:

Das sind Verbindungseinstellungen, kein Konfigurationsdateiformat oder Shell-Befehl; jeder Client hat seine eigenen Einstellungen und Versionsanforderungen. Wenn dein Client nur lokales stdio-MCP unterstützt, kann diese URL nicht direkt verwendet werden — nutze eine Client-Version oder Integration, die den Remote-Transport unterstützt.

Ein paar Sicherheitsregeln für die Zugangsdaten:

• Nutze die unterstützten Secret-Einstellungen deines Clients oder eine vertrauenswürdige private Agent-Eingabe.
• Bringe die Zugangsdaten niemals in eine URL, eine geteilte Konversation oder das Repository.
• Verbinde dich nach Konfigurationsänderungen neu und öffne dann dein lokales Code-Checkout im Agent.

Gib deinem Agent das Ergebnis

Du arbeitest in derselben Konversation, die du für die Entwicklung nutzt. Beschreibe das Ergebnis und lass den Agent koordinieren, zum Beispiel:

Nutze das verbundene AWR-Team-Projekt, um die Issue-API zu implementieren. Aktualisiere die aktuellen Aufgaben und setze meine bestehende Arbeit fort, oder claime eine geeignete Aufgabe, die zu dieser Anfrage passt. Lies den Vertrag, die Abhängigkeiten und den jüngsten Checkpoint vor dem Bearbeiten. Halte Fortschritt und Nachweise in AWR, reiche die getestete Änderung als PR ein und fordere ein unabhängiges Review an.

Der Agent liest gemeinsame Arbeit, claimt eine geeignete Aufgabe und hält das Projekt aktuell, während er lokal entwickelt. Wenn er auf einen echten Berechtigungs-, Abhängigkeits- oder Zuständigkeitskonflikt stößt, meldet er dir das, statt daran vorbeizuarbeiten.

Was der Agent für dich tut

Der Agent spricht mit dem Team-Dienst über zwei entdeckte MCP-Tools, awr_team_query für Lesevorgänge und awr_team_command für Schreibvorgänge. Jede Abfrage und jeder Befehl prüft deine aktuellen Berechtigungen erneut, sodass eine Rollenänderung wirkt, ohne dass jemand lokale Konfiguration bearbeitet.

Eine typische Session läuft so ab:

1. Starten oder neu verbinden. Der Agent fragt capabilities ab, um seine Identität und Berechtigungen zu bestätigen, dann work.next, um deine eigenen Sessions fortzusetzen oder sichtbare unvollendete Arbeit zu entdecken, und folgt dem zurückgegebenen next_query. (Auf älteren Servern ohne work.next fällt er auf workstreams.list und eingegrenzte work.list- / work.search-Aufrufe zurück.)
2. Vorbereiten. Für eine ausgewählte Aufgabe liefert work.prepare den aktuellen Vertrag, erforderliche Spezifikationen, Abhängigkeiten, Wiederherstellungszustand und einen Kontext-Hash — ein Snapshot, den der Agent vor dem Bearbeiten tatsächlich konsumieren muss. work.prepare und work.observe können außerdem ein kurzes guidance-Element zurückgeben (seine Bedingung, faktische Grundlage, nächste Aktion und Neubewertungsauslöser); es ist ein Rat, keine Ausführungsrechte.
3. Claimen. Der Agent untersucht bestehende Claims mit claim.inspect und erwirbt oder erneuert dann einen Live-Claim unter seiner Session.
4. Ausführen. Mit execution.prepare und einer frischen execution.start-Antwort mit execution_authorized=true darf der Agent eine Ausführung innerhalb des deklarierten Umfangs durchführen. Deine Maschine führt den Code und die Werkzeuge aus — der Dienst führt selbst niemals etwas aus. Ein Claim allein ist keine Ausführungszulassung.
5. Fortschritt melden. Der Agent sendet session.checkpoint mit dem konsumierten Kontext-Hash, nächster Aktion, offenen Schleifen und einer kurzen progress-Zusammenfassung, gebündelt, wenn eine Phase oder ein Test abschließt, ein Blocker sich ändert, deine Eingabe gebraucht wird oder die Lieferung bereit ist — nicht bei jedem Tool-Aufruf. Bedenke, dass Checkpoint-Zusammenfassungen mit autorisierten Arbeitslesern geteilt werden, sodass rohe sensible Logs nicht hineingehören.
6. Abschließen oder stoppen. execution.report zeichnet ein terminales Ergebnis mit versionsgebundenen Nachweisen auf. Claims werden freigegeben und Sessions beendet erst, nachdem aktive Arbeit und unbekannte Ergebnisse geklärt sind.

Review und Abnahme

Wenn Arbeit bereit ist, reicht der Agent Nachweise ein und fordert ein Review über delivery.submit_and_request_review oder review.open an. Eine autorisierte, unabhängige Person prüft die Lieferung, und die autorisierte Finalisierung folgt der Abnahmerichtlinie des Projekts.

Halte diese als getrennte Fakten: Implementierung, Verifizierung, der GitHub-Merge und die AWR-Abnahme. Einen PR zu mergen ist nicht dasselbe wie die AWR-Abnahme der Aufgabe, und dein eigener zweiter Agent zählt nicht als unabhängiger Reviewer.

Übergabe und Wiederherstellung

Die Übergabe funktioniert, weil Sessions und Checkpoints im gemeinsamen Projekt leben, nicht im Chat-Verlauf einer Person:

• Ein MCP-Reconnect beendet keine dauerhafte Arbeitssession und erneuert nicht ihr Lease.
• Wiederherstellungszustand und registrierte Lieferungen haben Vorrang vor alten Checkpoint-Anweisungen, sodass ein zurückkehrender Agent dem vertraut, was tatsächlich passiert ist.
• Wenn ein Schreibvorgang in einen Timeout läuft, untersucht der Agent das ursprüngliche Befehlsergebnis, bevor er exakt wiederholt; wiedergegebene Belege sind historische Fakten, keine Erlaubnis, Effekte erneut auszuführen.
• Wenn Ausführungseffekte unbekannt sind (eine Unterbrechung mitten in der Aufgabe), erfordern sie Untersuchung und autorisierte Klärung. Eine neue Session zu erstellen umgeht diese Anforderung nicht.

Zwei praktische Grenzen: AWR kann einen inaktiven Agent nicht aufwecken (die Lease-Erneuerung nutzt die Planung deines Hosts, getrennt von Checkpoints), und eine blockierte oder wartende Phase ist ein Bericht — sie erstellt kein Warteelement und erneuert keinen Claim von selbst.

Inspector: die optionale Workspace-Ansicht

Inspector ist eine Web-Ansicht über dasselbe Projekt. Sich anzumelden oder über eine Website zu claimen ist keine Voraussetzung für irgendetwas oben — der Agent bleibt die Koordinationsfläche. Nutze Inspector, wenn du Folgendes willst:

• Aufgabenbeziehungen, Zuständigkeit, Fortschritt und aufgezeichnete Ergebnisse einsehen.
• Client-neutrale MCP-Einstellungen und eine Projektanweisung aus Connect Agent kopieren oder ein aufgabenbezogenes Briefing (Text kopieren erstellt keine Session und keinen Claim).
• Als Administrator Mitglieder und projektbezogene Zugangsdaten in Members verwalten.
• Activity einsehen, das authentifizierte Zugriffsaufzeichnungen von der committeten Entwicklungshistorie trennt. Gewöhnliche Mitglieder sehen ihre eigene autorisierte Aktivität; Projekt-Auditoren können nach Mitglied oder Aufgabe filtern. Audit-Aufzeichnungen schließen Zugangsdatenwerte, Konversationen und beliebige Tool-Ein-/Ausgaben aus, und Anfrage-Metadaten haben eine begrenzte Aufbewahrung — es ist kein dauerhaftes Compliance-Archiv.

Administrator- und Review-Berechtigungen werden vom zentralen Dienst durchgesetzt, egal welchen Client du nutzt, sodass die Regeln gelten, ob jemand über einen Agent, Inspector oder beides arbeitet.

Nächste Schritte

• Neu bei AWR? Beginne mit Was ist AWR und dem Schnellstart.
• Verbinde deine eigenen Werkzeuge über MCP: MCP.
• Täglich mit Agents arbeiten: Agents und Dein täglicher Workflow.
• Etwas funktioniert nicht? Siehe Fehlerbehebung.