Skalierung: Multiagentensysteme und Feedbacksteuerung

Harte Regel: Lassen Sie niemals mehrere Worker gleichzeitig dieselben Dateien bearbeiten, ohne Ownership, Locking oder Merge-Regeln.

Sobald Arbeit auf mehrere Agents verteilt wird, erben Sie die klassischen Probleme verteilter Systeme, darunter Race Conditions, widersprüchliche Änderungen, veralteten Context und doppelte Arbeit, aber ohne das ausgereifte Tooling, das es für konventionelle verteilte Systeme gibt. Der Durchsatz skaliert selten mit der Anzahl der Agents, während die Kosten für das Zusammenführen und Abgleichen ihrer Arbeit rasch steigen. Genau hier scheitern beeindruckende Demos am häufigsten an echten Workloads.

Ein Zyklus aus Generieren, Bewerten und Reparieren ist ein Feedback-Regler, und er scheitert so, wie Regler scheitern: durch Oszillieren zwischen zwei Lösungen, durch Überkorrektur, bei der eine Korrektur ein anderes Kriterium bricht, durch Verharren in einem lokalen Optimum, durch Erfüllen des Bewertungskriteriums ohne das eigentliche Ziel oder schlicht dadurch, dass er sich nie für fertig erklärt. Jede Iteration kostet Geld und Zeit, deshalb sind diese Fehlermodi Budgetrisiken, keine Kuriositäten. Die Kontrollen sind gewöhnlich: ein Ziel, eine Obergrenze, ein Budget und explizite Stoppbedingungen.

Langlaufende Arbeit muss aus explizitem, gespeichertem State fortsetzen. Wenn der Fortschritt nur in einem wachsenden Transkript lebt, steigen die Kosten mit der Länge, ältere Entscheidungen werden verdrängt und stillschweigend vergessen, und eine Unterbrechung verliert Arbeit, die bereits bezahlt wurde. Ein Checkpoint-State macht einen Lauf fortsetzbar, auditierbar und günstig weiterzuführen, und er ist der Unterschied zwischen einem Prozess, der ein Deployment übersteht, und einem, der von vorn beginnen muss.

Jede Entscheidung sollte an die günstigste Ebene geleitet werden, die sie zuverlässig tragen kann: zuerst deterministischer Code, dann ein kleines Modell, dann ein starkes Modell und ein Mensch nur dort, wo Urteilsvermögen oder Verantwortung es wirklich erfordern. Alles an das größte verfügbare Modell zu schicken ist der häufigste Grund, warum ein vielversprechendes Feature Kosten pro Anfrage hat, die nicht skalieren, und es erzeugt außerdem spürbare Latenz. Routing ist eine Designentscheidung mit direkter Wirkung auf die Marge.