Nachdem der Agent die Aufgabe übernommen hat, muss zunächst die Arbeitseinheit gestrafft werden.

Ich habe in letzter Zeit viele Diskussionen über Agent gelesen und am Ende komme ich immer wieder auf die gleiche Frage zurück: An wen sollte man ein Werk abgeben, wie sollte es vor der Übergabe verpackt werden und wie wird es nach der Rückgabe angenommen? Tritt dieses Problem in einem Projekt auf, steigen oft zunächst nicht die Kosten des Modells, sondern die Komplexität der Arbeitseinheit. Wenn die Aufgabe zu groß ist, wirkt das Modell „als wäre es machbar“; Die eigentlichen Probleme liegen meist im Rollback, der Reproduktion und der Akzeptanz.

Die Arbeitseinheit muss zunächst angenommen werden können

Nachdem ich in den letzten Tagen Martin Fowlers fragmentarische Notizen und mehrere Diskussionen beim Thoughtworks Future of Software Development Retreat aneinandergereiht hatte, war das offensichtlichste Gefühl, dass die Gespräche in dem Meeting oberflächlich verstreut waren, sich aber im Grunde nur um eines drehten – die Übergabe eines großen Arbeitsstücks an den Agenten.

Der Abschluss von Kief Morris ist der einfachste. In verschiedenen Sitzungen wurden Codeüberprüfung, Produktionsunfälle, Arbeitsteilung im Team und Modellrouting besprochen. Sie schienen über unterschiedliche Dinge zu sprechen, aber die Schlussfolgerung war dieselbe: Die Leute haben den Umfang der „Einheitsarbeit“ angepasst. Je größer die Einheit ist, desto einfacher ist die Übergabe; Je größer die Einheit ist, desto schwieriger wird es, sie nach der Rückkehr zu akzeptieren. Es liegt nicht daran, dass das Modell das nicht kann, sondern daran, dass der anschließende Bestätigungslink zunächst nicht standhalten kann.

Aus diesem Grund wird immer wieder von Geschirr gesprochen. Kontextmanagement, rechnerische Sensoren, eigenschaftsbasiertes Testen, formale Methoden – diese Dinge klingen wie zusätzliche Werkzeuge, aber sie sammeln tatsächlich Arbeitseinheiten. Manche Leute steuern agents.md auf weniger als 200 Zeilen, nicht um eine saubere Form zu erreichen, sondern um das System zu zwingen, nur den Teil der Informationen zu empfangen, der wirklich nützlich ist und wirklich überprüft werden kann. Der Kontext ist zu locker, der Agent kann natürlich ausgeführt werden. Aber nach dem Ausführen weiß niemand, welche Schicht von Einschränkungen es verschluckt hat.

Selbsthosting bringt die Bedienoberfläche zum Vorschein

Auch Diskussionen über selbst gehostete Modelle deuten auf dasselbe hin. Nachdem Token teurer geworden sind, die Compliance-Anforderungen strenger geworden sind und Daten nicht nach außen dringen können, werden Open-Source-Modelle und lokale Modelle natürlich attraktiver. Sobald Sie das Modell jedoch selbst tragen, treten auch Probleme auf: GPU, Inferenzraum, Routing, Rollback, Feinabstimmung und Modellauswahl. Dabei handelt es sich nicht um die Modellfähigkeiten selbst, sie bestimmen jedoch, ob das System letztendlich stabil ist.

Solche Kosten werden oft unterschätzt. Viele Teams konzentrierten sich zunächst darauf, „ob das Modell stärker ist“, stellten jedoch später fest, dass die stabile Übertragung von Arbeitseinheiten zwischen mehreren Modellen wirklich Zeit kostet. Wann ein großes Modell, wann ein leichtes Modell und wann einfach ein lokales Modell verwendet werden sollte, hängt nicht von der verbalen Präferenz ab, sondern von einer Kontrollebene, die zur Ablenkung und Vertuschung genutzt werden kann. Ohne diese Ebene von Dingen wird das Selbsthosting von „die Initiative ergreifen“ zu „die Übernahme der Betriebs- und Wartungskomplexität selbst“ abgleiten.

Simon Willison erwähnte, dass stärkere Modelle kleinere Modelle für die Arbeit wählen sollten. Diese Idee ist auch sehr ähnlich zu dem, was die Kontrollebene tut. Das Modell selbst kennt nicht unbedingt die Kostengrenzen des Teams, das System jedoch. Das Modell als Makler zu behandeln und es zur Aufgabenverteilung zu nutzen, kommt einer echten Lieferung näher als die blinde Verfolgung eines einzelnen Modells für eine allumfassende Lieferung.

Akzeptanz und Ziele können nicht ausgelagert werden

Sam Rubys „Bring me a Rock“ brachte ein weiteres Problem ans Licht. Dem Modell die Arbeit zu übertragen ist gleichbedeutend mit dem Hinzufügen eines Ausführenden; Die Verantwortung verschwindet nicht. Manager können LLM zur Erkundung nutzen und es zunächst eine Reihe möglicher Lösungen ausspucken lassen, aber die endgültigen Akzeptanzkriterien müssen immer noch in die Hände von Menschen fallen. Versteckte Ziele sind am problematischsten. Berechtigungen, Datenschutz, destruktive Aktionen und Kontextlecks sind oft nicht in den ursprünglichen Anforderungen enthalten.

Daher sind Konformitätstests oft nützlicher als Spezifikationen. Spezifikationen können gut beschreiben, „was erforderlich ist“, und Tests sind besser geeignet, aufzudecken, „was nicht passieren darf“. Dies gilt insbesondere für Agentensysteme. Das Modell kann die expliziten Ziele sehr gut ausgleichen, die impliziten Grenzen müssen jedoch durch eine härtere Verifizierung verifiziert werden. Solange die Akzeptanzbedingungen in vagen Beschreibungen bleiben, wird das System umso mehr so ​​aussehen, als würde es auf Wahrscheinlichkeit wetten, je mehr der Agent tut.

Daher nehmen Codeüberprüfung, Vorfallbehandlung und Aufgabenzuweisung, die früher sehr menschenähnliche Aufgaben waren, jetzt andere Formen an. Führungskräfte nutzen das Modell direkt. Oberflächlich betrachtet scheint es, die Effizienz zu verbessern, aber auf der untersten Ebene verändern sie tatsächlich eine Managementmethode: von Managementmethoden zur Verwaltung von Zielen. Wenn das Ziel klar formuliert ist, hat das Modell eine Chance zu funktionieren; Wenn das Ziel unklar ist, wird das Modell die Unklarheit für andere nur verstärken.

Erfahrung und Lesefähigkeit verbessern sich immer noch

Auch die von Dan Davies erwähnte Interaktions- und Beitragskompetenz ist für diesen Wandel von großer Bedeutung. Das Modell kann viele Materialien lesen und ein gutes Urteil fällen, aber damit das System stabil ist, muss es immer noch jemanden geben, der die Spezifikationen lesen, die Ergebnisse sehen und wissen kann, was falsch ist. Der Schlüssel liegt hier nicht darin, dass die Menschen mit dem Modell konkurrieren sollten, um herauszufinden, wer schlauer ist, sondern dass die Menschen weiterhin in einer Position stehen sollten, die die Grenzen definiert.

Bei der Softwarebereitstellung ist diese Angelegenheit einfacher. Nach der Übernahme durch den Agenten wird sich die menschliche Arbeit weniger auf die manuelle Ausführung als vielmehr auf die Aufgabensegmentierung, Grenzdefinition, Akzeptanzdesign und Ausnahmebehandlung konzentrieren. Ob Aufgaben übergeben werden können, bestimmt eindeutig, ob sich die anschließende Kontextverwaltung, das Modellrouting und die Tool-Orchestrierung lohnen. Wenn die Einheit nicht klar ist, verschiebt es das Problem nur, egal wie viele Schichten es gibt.

Nachdem ich diese Fragmente in den letzten Tagen gelesen habe, ist mir weder ein bestimmter Modellname noch ein neues Framework in Erinnerung geblieben, sondern ein einfacheres Urteil: Das erste, was das Agentensystem verschärfen muss, ist nicht die Modellfähigkeit, sondern die Arbeitseinheit. Wenn die Einheit kleiner ist, die Akzeptanz strenger ist und die Berechtigungen strenger sind, hat das System die Möglichkeit, die Komplexität in einem kontrollierbaren Bereich zu halten.