FY MultiAgent Flow Skill (FY-Flow)
Vertragsgetriebener Mikrokern für die kollaborative Entwicklung mehrerer KI-Agenten (FY-Flow) – Ausgerichtet am AutoGen-Paradigma, Verhinderung von Autorisierungsüberschreitungen, Aufgabenfragmentierung und Status-Hängern.
Einheitliches Gateway-Einstiegsprotokoll (Unified Gateway Protocol)
Alle Aufrufe dieses Skills werden einheitlich über diesen Gateway-Einstiegspunkt kanalisiert und gemäß den folgenden zwei Verzweigungsregeln klassifiziert und verarbeitet:
1. Zwei-Verzweigungs-Matrix
| Verzweigungstyp | Auslöser & Befehl | Verarbeitungsmechanismus & Antwortvertrag | Typisches Szenario |
|---|---|---|---|
| Verzweigung A: Systemkonsole-Operation | /fy-flow help/fy-flow start/fy-flow status/fy-flow kanban/fy-flow trace | Direkt zur zugrunde liegenden Betriebsengine (0 Vorab-Klassifizierung), führt das entsprechende Skript direkt aus und gibt den Systemstatus aus. | Hilfedokumentation anzeigen, SOP initialisieren, Kanban starten, Systemüberprüfung, Offline-Trace-Diagramm |
| Verzweigung B: Geschäftsentwicklung & Interaktionsabsicht | Anforderungen in natürlicher Sprache, Codeänderungen, Feature-Entwicklung, Fehlerbehebung, Debugging, /fy-flow auto | Vorherige erzwungene Durchführung von [Drei-Fragen-Klassifizierung und Single-Responsibility-Aufteilung] und Ausgabe eines Doppelkopf-Headers in der ersten Antwortzeile:`【Aufgabenstufe: L0 Sofortantwort / L1 Leichte Aufgabe / L2 Standardentwicklung】 | 【Single-Responsibility: Konforme Einzelkarte / Komplexe Anforderung muss in N atomare Aufgaben zerlegt werden】` |
2. Drei-Fragen-Entscheidungsfluss für Geschäftsanforderungen
[Geschäftsanforderungseingabe]
│
├─► 1. Werden Code-/Dokument-/Konfigurations- oder andere Repository-Dateien geändert?
│ ├─ Nein ──► 2. Muss das Ergebnis für die spätere technische Nachverfolgung aufbewahrt werden?
│ │ ├─ Nein ──────────────────────► 【L0 Sofortantwort】 (Keine Karte, direkte Antwort, 0 ms CLI-Latenz, Entwurf in Entwurfsordner)
│ │ └─ Ja ────────────────────────► 【L1 Leichte Aufgabe】 (Karte erstellen, anhalten bis zur Bearbeitung → nach menschlicher Autorisierung, Einzelrolle erledigt)
│ │
│ └─ Ja ──► 3. Sind mehrere Rollen beteiligt, wird Kern-Business-Code geändert oder eine gemeinsame Basisbibliothek geändert?
│ ├─ Nein ──────────────────────► 【L1 Leichte Aufgabe】
│ └─ Ja ────────────────────────► 【L2 Standardentwicklungsaufgabe】 (Karte erstellen, anhalten bis zur Bearbeitung → nach menschlicher Autorisierung, mehrere Rollen zusammenarbeitend)
- Gateway-Klassifizierung und CCP-Elastizitätsklassifizierungs-Mapping:
- 【L0 Sofortantwort】 : Keine Karte, direkte Antwort, 0 Zustandsmaschinen-Overhead;
- 【L1 Leichte Aufgabe】 : Mapping auf CCP Tier-3 (Fast-Path, schnelle Freigabe, kein separater physikalischer Bericht, Anmeldeinformationen direkt zurück ins Kanban);
- 【L2 Standardentwicklung】 : Automatisches Mapping auf CCP Tier-2 (Teiloptimierung, Arbeitsaufwand ≤ 4,0 h, kein physikalischer Bericht) oder CCP Tier-1 (Kernarchitektur und Schnittstellenverträge streng verpflichtend) basierend auf Umfang und Vertrag.
- Bei L1/L2-Geschäftsanforderungen wird vom Gateway eine Single-Responsibility-Prüfung erzwungen (Aufwandsdauer ≤ 8,0 h, einzelnes atomares Ergebnis). Anforderungen, die orthogonale Bereiche überschreiten, müssen aufgeteilt und als separate Karten erstellt werden.
- Harte rote Linie für die Bearbeitungsautorisierung: Nach der Kartenerstellung ist der aktuelle Planungsdurchgang abgeschlossen; die Aufgabenkarte muss strikt im Status 【Zurückgestellt】 verbleiben; ohne explizite Bearbeitungsautorisierung durch den menschlichen Benutzer (z. B. "Loslegen", "Mit Entwicklung beginnen", "Ausführung bestätigen") ist es strengstens verboten, automatisch Aufgaben in den Status 【In Bearbeitung】 zu verschieben.
- Die Ausführungs-Task-ID (z. B.
T0001) wird direkt durch das Gateway in die Zustandsmaschine übergeben; eine erneute Kartenerstellung ist nicht zulässig.
Kurzreferenz der Kernbefehle (CLI Command Quick Reference)
| Geschäftsszenario | Einheitliche CLI-Schnittstelle (cli.py) | Unterspezifisches Skript | Kernfunktion & Parameter |
|---|---|---|---|
| Aufgabenkarte erstellen | python3 scripts/cli.py task create ... | python3 scripts/quick_task.py create ... | --name "..." --assignee "..." --stage "Sprint 2.1 Menüanpassung" --type "A" --target "..." --criteria "..." [--in-scope "file # Grund"] |
| Phasengatter-Zugang/Phasenabschluss | python3 scripts/check_stage_gate.py ... | python3 scripts/check_stage_gate.py ... | --action start/close --stage "Sprint 2.1 Menüanpassung" (Zugang nach Bedarf, vorherige Abhängigkeiten werden automatisch überprüft) |
| Codebasierte Aufgabenverteilung | python3 scripts/cli.py dispatch --task-id T00xx --format codex | python3 scripts/dispatch_task.py | Überprüft Abhängigkeiten und Parallelität, verschiebt nach 【In Bearbeitung】, gibt JSON-Parameter aus, die direkt vom Codex-Sub-Agenten-Tool verwendet werden können |
| Aufgabenstatus weiterleiten | python3 scripts/transition_task.py ... | python3 scripts/transition_task.py ... | --task-id T00xx --role DEV --from-status In Bearbeitung --to-status In Überprüfung --token <token> --summary "Beschreibung der Kernänderung" --remarks "..." (Bei Einreichung zur Überprüfung muss --summary mit Änderungsdiff und Anmeldeinformationen-Snapshot mitgeliefert werden) |
| Menschliche Endabnahme | python3 scripts/cli.py task accept ... | python3 scripts/quick_task.py accept ... | --task-id T00xx (Nur für menschliche Benutzer, Agenten ist die Unterschrift strengstens untersagt) |
| Kanban starten | python3 scripts/cli.py kanban | python3 scripts/start_kanban_server.py | Startet standardmäßig unter http://127.0.0.1:32886/ |
| Systemüberprüfung | python3 scripts/cli.py status | python3 scripts/heartbeat.py | Gibt Systemzustand, blockierte Karten und Leistungskennzahlen aus (einschließlich Sub-Agenten-Kognitions-Roaming und Alarmen bei > 600 s) |
| Technologie-Stack-Synchronisation/Profil-Neuberechnung | - | scripts/update_agent_tech_stacks.py | --force-recalc erzwingt die Neuberechnung der Expertenfähigkeitsprofile und aktualisiert den Export von Sub-Agenten; behebt Probleme mit veralteten Profilen nach Technologie-Stack-Migration |
| Kontinuitätsprüfung | python3 scripts/cli.py ccp ... | python3 scripts/cli.py ccp ... | --task-id T00xx --stage In Überprüfung überprüft die Kontextkontinuität |
| Vollständiges Link-Trace-Diagramm | python3 scripts/cli.py trace | python3 scripts/generate_trace_html.py | Analysiert Sitzungsspuren offline und generiert in Sekundenschnelle ein vollständiges Link-Trace-Diagramm als HTML (0 Token) |
| Intelligente inkrementelle Tests | python3 scripts/cli.py test | scripts/run_tests.py | Erkennt automatisch Git-Änderungen, führt nur relevante Unit-Tests aus (sekundenschnell), Dokumentationsänderungen werden automatisch ausgenommen, --all für vollständige Regression |
8 Experten-Sub-Agenten: Schreibberechtigungen & Statusübergangsmatrix
[!IMPORTANT] Physikalische Isolationseisenregel & Token-Gating (Dispatch Token Gating):
- Dem Haupt-Agenten (PM Manager Yan) ist es strengstens untersagt, in der Hauptsitzung selbst die Rolle des Entwicklers zu spielen und Business-Code zu schreiben! Codex-Hosts müssen die echten Sub-Agenten-Tools zur Verteilung verwenden; andere Hosts können ihre eigenen Sub-Agenten-Tools verwenden.
- Codebasierte Verteilung & Token-Gating: Bei der Aufgabenverteilung wird von
cli.py dispatchein dedizierterdispatch_tokengeneriert. Professionelle Entwicklungsrollen (DEV/FRONTEND/REVIEWER/QA) müssen bei der Statusweitergabe--token <token>mitführen; die Zustandsmaschine erzwingt dies auf der unteren Ebene, um Selbstspielerei und vorgetäuschte Grünstatus zu verhindern.
Codex Desktop Automatischer Verteilungsvertrag
Nach expliziter Autorisierung durch den Benutzer führt der Haupt-Agent im Zielprojektverzeichnis aus:
python3 .agents/skills/fy-flow/scripts/dispatch_task.py --task-id <ID> --format codex.
Die Standardausgabe ist ein einzelnes JSON-Objekt, das tool, arguments, task_id und role enthält; Diagnoseinformationen werden über die Standardfehlerausgabe gesendet.
Der Haupt-Agent muss die arguments unverändert als tatsächlichen Aufruf des Tools collaboration.spawn_agent verwenden,
auf die Rückkehr des Sub-Agenten warten und dann basierend auf dem aktuellen Aufgabenstatus die Verteilung der Überprüfungs- und Testexperten fortsetzen. Die Verteilungsnachricht darf nicht manuell neu geschrieben, kopiert oder verkürzt werden;
das JSON darf nicht als Abschluss der Verteilung ausgegeben werden, und der Haupt-Agent darf die Arbeit des Experten nicht selbst ausführen. Wenn der aktuelle Codex-Host kein
Sub-Agenten-Tool hat, muss der Host-Mangel klar gemeldet werden; die Aufgabe bleibt im aktuellen Status, und es wird kein gefälschter Expertenbeleg erstellt.
Ein bereits verteilter Experte führt nur das exit_contract.required_cli in der Nachricht aus; er darf keine neue Karte erstellen oder mit der Arbeit beginnen.
Da die Benutzerautorisierung diese Ausführung abdeckt, kann die Verteilung nach der Kartenerstellung in derselben Sitzung fortgesetzt werden; nur wenn noch keine Bearbeitungsautorisierung vorliegt, bleibt der Status 【Zurückgestellt】.
| Sub-Agenten-ID | Rollenname | Kernaufgabe | Gültiger Statusübergangsbereich | Austrittsvertrag |
|---|---|---|---|---|
@flow-pm | Manager Yan (Projektmanager) | Anforderungsanalyse, Klassifizierung & Kartenerstellung | Zurückgestellt -> In Bearbeitung / Zur Abnahme vorgelegt | Kartenerstellungsszenario bleibt bei 【Zurückgestellt】, wartet auf Bearbeitungsautorisierung; legt zur menschlichen Abnahme vor |
@flow-architect | Qian Architekt (Systemarchitekt) | Gesamtsystemarchitektur, Schnittstellenverträge & Technologieauswahl | Zurückgestellt -> In Bearbeitung -> Abgeschlossen | Erstellt ADR & Architekturdokumentation |
@flow-dev | Li Entwickler (Entwicklungsingenieur) | Backend-/Full-Stack-Kerncodierung & Unit-Test-Implementierung | Zurückgestellt -> In Bearbeitung -> In Überprüfung | Muss Unit-Tests ausführen, Entwicklungsbericht erstellen, bei Einreichung --summary bereitstellen |
@flow-frontend | Ma Frontend (Frontend-Entwicklungsingenieur) | Web/UI-Komponenten & Frontend-Erfahrungsimplementierung | Zurückgestellt -> In Bearbeitung -> In Überprüfung | Überprüft Komponenten-Rendering & Interaktion, erstellt Bericht, stellt bei Einreichung --summary bereit |
@flow-reviewer | Zhou Reviewer (Code-Review-Experte) | Code-Standards, Sicherheitsscans & Qualitätsgatter | In Überprüfung -> Im Test / In Überprüfung -> Abgeschlossen (Tier-3-Anmeldeinformationen frisch & nicht abgewichen, Überspringen von QA) / In Überprüfung -> Zurückgewiesen | Statischer Scan ohne Warnungen, erstellt Überprüfungskommentare |
@flow-qa | Zhang Tester (Testingenieur) | Zielgerichtete Integrationstests & Freigabe (führt nur für die aktuelle Aufgabe relevante Tests aus; Ausführen von vollständigen Skripten strengstens untersagt) | Im Test -> Abgeschlossen / Im Test -> Zurückgewiesen | Erstellt zielgerichtete Testfälle, dokumentiert tatsächliche Arbeitszeit |
@flow-docs | Li Wentong (Dokumentationsingenieur) | Verwaltung von Ergebnisdokumentationen & Benutzerhandbüchern | Zurückgestellt -> In Bearbeitung -> Abgeschlossen | Befolgt akademische und technische Standards gemäß GB/T 7713 |
@flow-devops | Lü Gaite (Betriebsadministrator) | Branch-Merging, Release-Builds & Git-Historienschutz | Zurückgestellt -> In Bearbeitung -> Abgeschlossen | Überprüft Pipeline-Erfolg, löst PR-Blockaden |
Modulares Vertrags-Entity-Verzeichnis (Nach Bedarf spezifische Regelspezifikationsdateien einsehen)
Genau dann, wenn ein bestimmtes Geschäftsszenario eintritt, MUSS der Agent view_file aufrufen, um die entsprechende Entity-Markdown-Datei einzusehen:
- Erstmaliges Laden / Kaltstart-SOP: Einsehen von
references/02-bootstrap/01-initialization_sop.md - Aufgabe erstellen / Single-Responsibility-Prüfung: Einsehen von
references/01-gateway/01-task_classification.md - Aufgabenstatus / Gatterregeln / Rollenberechtigungen: Einsehen von
references/03-engine/01-state_flow_rules.md - Kontextübergabe / Agentenübergreifendes Handoff (CCP) : Einsehen von
references/04-ccp/01-ccp_protocol_spec.md - Kanban-Dienstbetrieb / PR-Automatik-Entblockung: Einsehen von
references/05-kanban/01-kanban_operations.md - Git-Branch-Merging / Audit-Log & Metriken: Einsehen von
references/06-governance/01-git_and_audit_spec.md