KI-Coding-Agent-Orchestrierung: Gate Jede Zusammenführung anhand von Beweisen

Parallele Codierungsagenten sollten nicht zusammengeführt werden, da jede Sitzung „erledigt“ sagt. Der vernünftige Standard ist strenger: Geben Sie jedem mutierenden Agenten einen isolierten Arbeitsbaum und Zweig, deklarieren Sie, was er ändern darf, und lassen Sie seinen Zweig nur zu, wenn sich Prüfungen, Überprüfung, Basisfrische und eine zu liefernde Quittung alle auf den genauen Haupt Commit beziehen. Das ist der operative Kern der Orchestrierung von KI Codierungsagenten . Der Orchestrator kann Arbeit planen und Aktivitäten anzeigen, aber die Zusammenführungsbereitschaft ist eine Beweisentscheidung. Ein Zweig kann funktionieren, rechtmäßig warten, blockiert, veraltet, außerhalb des Gültigkeitsbereichs oder vollständig, aber nicht verifiziert sein. Durch den Zusammenbruch dieser Zustände in fertige Zustände wird Parallelität zu stillem Integrationsversagen. Dieser Leitfaden erstellt einen inhaltsfreien Zusammenführungsbeleg und spielt acht Fälle dagegen ab. Das Ergebnis ist bewusst unpraktisch: Nur ein Koffer ist fertig. Die anderen bewahren den Grund des Wartens oder Ablehnens, anstatt ihn hinter einem grünen Sitzungsabzeichen zu verstecken. Orchestrieren Sie für die Merge Zulassung, nicht für den Abschluss der Sitzung Die aktuelle Toollandschaft erleichtert die parallele Ausführung. DerDas VS Code Team beschreibt die lokalen, Hintergrund und Cloud Agent Modi in Version 1.109; Seine Hintergrundagenten nutzen die Worktree Isolation, während parallele Subagenten die Erkundung vom Hauptkontext fernhalten. Die Open SourceAgent Orchestrator ProjektAuf ähnliche Weise werden Codierungssitzungen in isolierten Arbeitsbäumen abgelegt und CI Fehler, Überprüfungskommentare und Zusammenführungskonflikte werden an die entsprechende Sitzung weitergeleitet. Das sind nützliche Ausführungseigenschaften. Sie stellen für sich genommen kein Fusionsurteil dar. Gits git worktree Dokumentationerklärt die wichtige Grenze. Verknüpfte Arbeitsbäume teilen Repository Daten, aber jeder hat einen Status pro Arbeitsbaum, z HEAD und der Index.Gitweigert sich außerdem, einen Zweig in mehreren Arbeitsbäumen auszuchecken, es sei denn, die Sicherheitsmaßnahmen werden außer Kraft gesetzt. Dadurch wird eine Reihe von Dateisystem und Indexkollisionen verhindert. Es beweist nicht, dass zwei Patches kompatibel sind, dass ein Agent innerhalb seiner Zuweisung geblieben ist oder dass das gestrige Testergebnis für den heutigen Kopf gilt. Verwenden Sie eine Quittung pro Kandidatenfiliale: Die Bezeichner sind synthetisch. Es sind keine Eingabeaufforderung, keine Quelldatei, kein Geheimnis, kein Diff oder kein Testprotokoll erforderlich. Die Quittung enthält nur die minimalen Informationen, die für die Entscheidung erforderlich sind, ob der Filialleiter weiterkommen kann. Fünf Prüfungen machen die Standardeinstellung nützlich: 1. Isolierung: Der Arbeitsbaum und der Zweig gehören zu einer aktiven Mutationssitzung. 2. Eigentum: Jeder geänderte Pfad liegt innerhalb der deklarierten Zuweisung. 3. Frische: Der Kandidat basiert auf der erwarteten Basis und jede Prüfung bezieht sich auf seinen aktuellen Kopf. 4. Bewertung: Eine Genehmigung gilt für denselben Leiter, es gibt keine offenen Änderungswünsche. 5. Ergebnis: Ein deterministisches Artefakt beweist die angeforderte Arbeit und nicht nur die Befehlsvervollständigung. GitHubs Dokumentation für geschützte Zweigeunterstützt die Mitte dieses Vertrags: Zweigstellen können Überprüfungen und erfolgreiche Statusprüfungen verlangen, und strenge Prüfungen können erfordern, dass eine Zweigstelle mit der Basis auf dem neuesten Stand ist. Der Ergebnisbeleg erweitert diesen Mechanismus. Ein erfolgreicher Build beweist, dass ein Build Befehl erfolgreich war. Dies beweist nicht unbedingt, dass der angeforderte Export vorhanden ist, der API Vertrag funktioniert oder das für den Benutzer sichtbare Verhalten korrekt ist. Führen Sie das Merge Readiness Audit mit acht Fällen durch Den Vertrag habe ich klein kodiertNode.jsKlassifikator und spielte acht Filialbelege ab. Das Fixture verwendet eine aktuelle Basis, zwei erforderliche Prüfungen und keinen Repository Inhalt. Führen Sie es aus mit: Der Klassifikator wendet die Tore in dieser Reihenfolge an: Ordnung ist wichtig. Eine legitime Wartezeit sollte nicht zu einem fehlgeschlagenen Build werden, nur weil die Prüfungen nicht begonnen haben. Die Scope Drift sollte die Verzweigung vor einer teuren Auswertung stoppen. Veraltete Beweise sollten nicht als aktueller Fehler interpretiert werden: Es heißt „noch einmal gegen diesen Kopf vorgehen“ und nicht „Der Code ist kaputt“. Das Experiment ergab in jeder Kategorie ein Urteil: Fall Urteil Entscheidender Beweis Vollständiger Zweig merge ready Aktueller Kopf, eigene Pfade, neue Prüfungen, Genehmigung, verifiziertes Artefakt Gemeinsamer Arbeitsbereich isolation failed Eine andere mutierende Sitzung besitzt den Arbeitsbereich Zusätzliche Authentifizierungsbearbeitung scope drift src/auth.ts liegt außerhalb der Dokumentationszuweisung Schema Entscheidung waiting Name des Gutachters, Grund und Frist sind vorhanden Alte Zusammenführungsbasis stale base Kandidat sah base 101 ; aktuelle Basis ist base 104 Neuer Commit nach CI stale evidence Schecks und Nachprüfungen gehören dazu cli 8 , nicht cli 9 Gewünschte Änderungen review blocked Die Überprüfung gilt für den Kopf, wird jedoch nicht genehmigt Kein lieferbarer Beweis outcome unverified Build und Test bestanden, aber das angeforderte Ergebnis ist nicht bestätigt Dies ist ein stärkeres operatives Ergebnis als „sieben Ausfälle“. Der Schema Fall ist nicht fehlgeschlagen; es wartet auf eine explizite Entscheidung. Der Stale Check Fall kann vollkommen guten Code enthalten. Sein Beweis bezieht sich auf den falschen Commit. Der Fall mit fehlendem Ergebnis hat möglicherweise jeden generischen Test bestanden, hat aber dennoch die Aufgabe nicht bestanden, die die Verzweigung rechtfertigte. Die Prüfung ist fälschbar. Wenn der Klassifikator einen unvollständigen Fall als bereit markiert, ist die Arbeit fehlgeschlagen. Verweigert er den vollständigen Erhalt, ist der Vertrag zu streng oder fehlerhaft umgesetzt. In diesem Lauf wurde genau einer von acht Fällen registriert merge ready . Binden Sie jedes grüne Signal an den Kopf des Kandidaten Die am häufigsten wiederverwendbare Regel aus dem Fixture ist einfach: Angenommen, ein Agent übergibt CI beim Festschreiben cli 8 , führt dann einen kleinen „Aufräum“ Commit durch cli 9 . Auf einem Dashboard werden möglicherweise weiterhin grüne Häkchen und eine genehmigte Bewertung angezeigt. Der richtige Zustand ist nicht grün und nicht rot. Es handelt sich um veraltete Beweise. Führen Sie die betroffenen Prüfungen erneut durch und erneuern Sie die Überprüfung oder verwenden Sie einen Plattformmechanismus, der Genehmigungen ungültig macht, wenn sich der überprüfte Unterschied ändert. Wenden Sie dieselbe Identitätsbindung auf die Lieferung an. Zu den nützlichen Quittungen gehören: ein Vertragstest, der die neue API aufruft und ihre Antwort validiert; ein generierter Artefakt Hash plus eine Decoder oder Parser Prüfung; eine Browser Behauptung gegenüber der integrierten Route; eine Migrationsprobe gegen eine Wegwerfdatenbank; ein Paketimport und ein Rauchtest aus dem erstellten Paket, nicht aus dem Quellbaum; eine Zielsuche, die beweist, dass ein externer Effekt den beabsichtigten Datensatz erreicht hat. Vermeiden Sie eine LLM Zusammenfassung als einzige Ergebnisquittung, wenn das Ergebnis deterministisch ist. Ein Coding Agent kann getrost sagen, dass er eine fehlende Datei erstellt, Tests durchgeführt hat, die später ungültig wurden, oder einen Überprüfungskommentar in einem anderen Zweig korrigiert hat. Bevorzugen Sie eine direkte Inspektion. Verwenden Sie einen Modellrichter nur für Eigenschaften, die nicht mechanisch überprüft werden können, und zeichnen Sie die Richterversion, die Rubrik, die Eingabeidentität und die Unsicherheit auf. Auch Warten braucht Identität. Notieren Sie den Eigentümer, den Grund, die Frist und die Lebenslaufbedingung. „Warten auf Bewertung“ ohne Eigentümer kann ewig dauern. „Ich warte bis 12:00 UTC auf den Plattformprüfer, um die Schemakompatibilität zu genehmigen; Fortsetzung um schema 3 „ist umsetzbar und sollte aus der Fehlerwarteschlange bleiben, bis sich die Frist oder die Beweise ändern. Wissen Sie, wo das Tor stoppt Der Pfadbesitz ist ein früher Filter, keine semantische Konflikterkennung. Zwei Zweige können unterschiedliche Dateien bearbeiten und sich dennoch über einen gemeinsamen Typ, ein Ereignisschema, einen generierten Client, eine Migrationsreihenfolge, ein Feature Flag oder ein API Verhalten nicht einig sein. Die Worktree Isolation verhindert gleichzeitige Dateistatuskollisionen. Es kann nicht bewiesen werden, dass unabhängig voneinander korrekte Patches komponiert werden. Führen Sie daher ein abschließendes Integrationsgate für den tatsächlichen Zusammenführungskandidaten aus: 1. den Kandidaten anhand der beabsichtigten Basis aktualisieren oder neu erstellen; 2. die genehmigten Änderungen kombinieren, ohne Konflikte zu umgehen; 3. Führen Sie die erforderlichen Prüfungen am kombinierten Kopf durch. 4. Wiederholen Sie die deterministische Ergebnisüberprüfung. 5. Fügen Sie die resultierenden Beweise diesem kombinierten Kopf bei. 6. Für die Zusammenführung oder jeden unumkehrbaren Wiederherstellungsschritt ist eine menschliche Genehmigung erforderlich. Das bringt zusätzliche Arbeit mit sich. Eine strikte Grundfrische kann auch zu wiederholten Neuaufbauten führen, während andere Zweige landen.GitHub dokumentiert diesen Kompromiss: Strenge erforderliche Prüfungen verbessern die Basisausrichtung, können jedoch mehr Builds erfordern; Lose Prüfungen reduzieren die Anzahl der Neuerstellungen, können jedoch dazu führen, dass nach der Zusammenführung Inkompatibilitäten auftreten. Wählen Sie die Richtlinie nach Fehlerkosten und nicht nach dem Wunsch, jeden Agenten zu beschäftigen. Der Zusammenführungsvertrag ersetzt auch nicht die Codeüberprüfung, Sicherheitsüberprüfung, Bereitstellungskontrollen oder Reaktion auf Vorfälle. Es gibt diesen Systemen eine vertrauenswürdige Kandidatenidentität und einen klaren Grund, warum die Arbeit noch nicht fertig ist. Sidewisp befindet sich derzeit in einer privaten Vorschauphase.Die Produktausrichtung ist eine Gesundheitsschicht rund um bestehende Agentenlaufzeiten, wobei nützliche Fortschritts , Warte , Tool und Ergebnisnachweise getrennt gehalten werden. Adapter zur Sammlung und Wiederherstellung des Produktionsagentenzustands werden im Allgemeinen nicht ausgeliefert. Wenn Sie parallele Kodierungsagenten betreiben, ist dieser Zusammenführungsbeleg die Art von begrenztem Gesundheitsvertrag, den es wert ist, jetzt getestet zu werden – bevor autonome Intervention hinzugefügt wird. Die letzte Regel ist absichtlich konservativ: Das Anhalten eines Agenten ist Aktivität; Ein fest verankerter, überprüfter und ergebnisverifizierter Zweig ist ein Fortschritt, der für die Integration genehmigt werden kann.