Team-Protokolle

s01 > s02 > s03 > s04 > s05 > s06 | s07 > s08 > s09 > [ s10 ] s11 > s12

"Teamkollegen brauchen gemeinsame Kommunikationsregeln" -- Ein Anfrage-Antwort-Muster驱动t alle Verhandlungen.

Problem

In s09 arbeiten und kommunizieren Teamkollegen, aber es fehlt eine strukturierte Koordination:

Herunterfahren: Einen Thread zu töten hinterlässt Dateien halb geschrieben und config.json veraltet. Sie brauchen einen Handshake: der Lead fragt an, der Teamkollege genehmigt (beenden und beenden) oder lehnt ab (weiterarbeiten).

Plangenehmigung: Wenn der Lead "refaktorisiere das Auth-Modul" sagt, startet der Teamkollege sofort. Für risikoreiche Änderungen sollte der Lead den Plan zuerst überprüfen.

Beide teilen dieselbe Struktur: Eine Seite sendet eine Anfrage mit einer eindeutigen ID, die andere antwortet unter Verweis auf diese ID.

Lösung

Herunterfahren-Protokoll           Plangenehmigungs-Protokoll
=====================              ======================

Lead             Teamkollege    Teamkollege           Lead
  |                 |           |                 |
  |--shutdown_req-->|           |--plan_req------>|
  | {req_id:"abc"}  |           | {req_id:"xyz"}  |
  |                 |           |                 |
  |<--shutdown_resp-|           |<--plan_resp-----|
  | {req_id:"abc",  |           | {req_id:"xyz",  |
  |  approve:true}  |           |  approve:true}  |

Gemeinsame FSM:
  [pending] --approve--> [approved]
  [pending] --reject---> [rejected]

Tracker:
  shutdown_requests = {req_id: {target, status}}
  plan_requests     = {req_id: {from, plan, status}}

Wie es funktioniert

1. Der Lead initiiert das Herunterfahren durch Generieren einer request_id und Senden durch das Postfach.

shutdown_requests = {}

def handle_shutdown_request(teammate: str) -> str:
    req_id = str(uuid.uuid4())[:8]
    shutdown_requests[req_id] = {"target": teammate, "status": "pending"}
    BUS.send("lead", teammate, "Please shut down gracefully.",
             "shutdown_request", {"request_id": req_id})
    return f"Shutdown request {req_id} sent (status: pending)"

1. Der Teamkollege empfängt die Anfrage und antwortet mit genehmigen/ablehnen.

if tool_name == "shutdown_response":
    req_id = args["request_id"]
    approve = args["approve"]
    shutdown_requests[req_id]["status"] = "approved" if approve else "rejected"
    BUS.send(sender, "lead", args.get("reason", ""),
             "shutdown_response",
             {"request_id": req_id, "approve": approve})

1. Die Plangenehmigung folgt demselben Muster. Der Teamkollege reicht einen Plan ein (generiert eine request_id), der Lead überprüft (unter Verweis auf dieselbe request_id).

plan_requests = {}

def handle_plan_review(request_id, approve, feedback=""):
    req = plan_requests[request_id]
    req["status"] = "approved" if approve else "rejected"
    BUS.send("lead", req["from"], feedback,
             "plan_approval_response",
             {"request_id": request_id, "approve": approve})

Eine FSM, zwei Anwendungen. Derselbe pending -> approved | rejected Zustandsautomat behandelt jedes Anfrage-Antwort-Protokoll.

Was sich von s09 geändert hat

Komponente	Vorher (s09)	Nachher (s10)
Tools	9	12 (+shutdown_req/resp +plan)
Herunterfahren	Nur natürlicher Ausstieg	Anfrage-Antwort-Handshake
Plan-Gating	Keine	Einreichen/Überprüfen mit Genehmigung
Korrelation	Keine	request_id pro Anfrage
FSM	Keine	pending -> approved/rejected

Ausprobieren

python agents/s10_team_protocols.py

1. Spawn alice als Coder. Fordere dann ihr Herunterfahren an.
2. Liste Teamkollegen auf, um Alices Status nach Herunterfahren-Genehmigung zu sehen
3. Spawn bob mit einer risikoreichen Refactoring-Aufgabe. Überprüfe und lehne seinen Plan ab.
4. Spawn charlie, lasse ihn einen Plan einreichen, dann genehmige ihn.
5. Tippe /team um Status zu überwachen