Projektentwicklung

Methodik zur Projektentwicklung

Diese Fähigkeit umfasst die Prinzipien zur Identifizierung von Aufgaben, die für die LLM-Verarbeitung geeignet sind, zum Entwerfen effektiver Projektarchitekturen und zur schnellen Iteration mittels agentenunterstützter Entwicklung. Die Methodik gilt gleichermaßen für den Aufbau einer Batch-Verarbeitungspipeline, eines Multi-Agenten-Recherchesystems oder einer interaktiven Agentenanwendung.

Die Arbeitseinheit für diese Fähigkeit ist das gesamte Projekt oder eine mehrstufige Pipeline. Das individuelle Tool-Design (Beschreibungen, Schemata, Fehlermeldungen) gehört zu tool-design. Die aktivierungsspezifische Weiterleitung von Fähigkeiten gehört zur entsprechenden Fähigkeit plus zum Korpusindex. Diese Fähigkeit ist zuständig für die Fragen auf Projektebene: Sollte man dies überhaupt mit einem LLM bauen, welche Form sollte die Pipeline haben, was kostet es, wie sollte iteriert werden.

Wann aktivieren

Aktivieren Sie diese Fähigkeit, wenn die Arbeitseinheit ein gesamtes Projekt oder eine Pipeline ist:

• Entscheidung, ob ein LLM überhaupt das richtige Primitive für eine Aufgabe ist (Task-Model-Fit vor jeglichem Code).
• Formgebung einer mehrstufigen Batch- oder Agenten-Pipeline (erfassen / vorbereiten / verarbeiten / parsen / rendern).
• Schätzung von Token, Dollarkosten und Zeitplänen für ein LLM-lastiges Projekt.
• Wahl zwischen Single-Agent und Multi-Agent auf Projektebene.
• Strukturierung agentenunterstützter Iteration (bei der der Agent beim Aufbau des Projekts selbst hilft).
• Entwurf strukturierter Ausgaben auf Pipeline-Vertragsebene (übergreifendes Übergabeformat zwischen den Stufen).

Aktivieren Sie diese Fähigkeit nicht für angrenzende Arbeiten, die anderen Fähigkeiten gehören:

• Pro-Tool-Beschreibung, Schema, Benennung, Antwortformat, Fehlermeldung: tool-design.
• Pro-Trajektorien-Token-Effizienz-Taktiken (Maskieren, Partitionieren, Caching): context-optimization.
• Entscheidung über die Aufteilung der Arbeit auf Unter-Agenten auf der Ebene der Agententopologie: multi-agent-patterns.
• Entwurf der autonomen Regelschleife (gesperrte Metriken, Neuheitsgates, Grenzen der menschlichen Genehmigung): harness-engineering.

Kernkonzepte

Erkennung des Task-Model-Fits

Bewerten Sie den Task-Model-Fit, bevor Sie Code schreiben, denn die Automatisierung einer grundlegend nicht passenden Aufgabe verschwendet Tage an Arbeit. Prüfen Sie jede vorgeschlagene Aufgabe anhand dieser beiden Tabellen, um zu entscheiden, ob Sie fortfahren oder abbrechen.

Fortfahren, wenn die Aufgabe diese Merkmale aufweist:

Merkmal	Begründung
Synthese über Quellen hinweg	LLMs kombinieren Informationen aus mehreren Eingaben besser als regelbasierte Alternativen
Subjektives Urteil mit Bewertungsrastern	Benotung, Bewertung und Klassifizierung mit Kriterien lassen sich auf natürliche Weise auf Sprachlogik abbilden
Natürlichsprachliche Ausgabe	Wenn das Ziel menschenlesbarer Text ist, liefern LLMs diesen nativ
Fehlertoleranz	Einzelne Fehler bringen das Gesamtsystem nicht zum Scheitern, daher ist LLM-Nichtdeterminismus akzeptabel
Stapelverarbeitung	Zwischen den Elementen ist kein Gesprächsstatus erforderlich, was den Kontext sauber hält
Domänenwissen im Training	Das Modell hat bereits relevanten Kontext, was den Overhead beim Prompt-Engineering reduziert

Abbrechen, wenn die Aufgabe diese Merkmale aufweist:

Merkmal	Begründung
Präzise Berechnung	Mathematik, Zählen und exakte Algorithmen sind in Sprachmodellen unzuverlässig
Echtzeitanforderungen	Die LLM-Latenz ist für Antworten unter einer Sekunde zu hoch
Anforderungen an perfekte Genauigkeit	Das Halluzinationsrisiko macht 100%ige Genauigkeit unmöglich
Abhängigkeit von proprietären Daten	Dem Modell fehlt der notwendige Kontext und es kann ihn nicht allein durch Prompts erlangen
Sequenzielle Abhängigkeiten	Jeder Schritt hängt stark vom vorherigen Ergebnis ab, was Fehler verstärkt
Anforderungen an deterministische Ausgabe	Gleiche Eingabe muss identische Ausgabe erzeugen, was LLMs nicht garantieren können

Der manuelle Prototypenschritt

Validieren Sie den Task-Model-Fit immer mit einem manuellen Test, bevor Sie in die Automatisierung investieren. Kopieren Sie eine repräsentative Eingabe in die Modellschnittstelle, bewerten Sie die Ausgabequalität und verwenden Sie das Ergebnis, um diese Fragen zu beantworten:

• Hat das Modell das für diese Aufgabe erforderliche Wissen?
• Kann das Modell die Ausgabe im benötigten Format erzeugen?
• Welches Qualitätsniveau ist im großen Maßstab zu erwarten?
• Gibt es offensichtliche Fehlermodi, die behoben werden müssen?

Tun Sie dies, weil ein fehlgeschlagener manueller Prototyp ein fehlgeschlagenes automatisiertes System vorhersagt, während ein erfolgreicher Prototyp sowohl eine Qualitätsbasislinie als auch eine Prompt-Design-Vorlage liefert. Der Test dauert Minuten und verhindert stundenlange verschwendete Entwicklungsarbeit.

Pipeline-Architektur

Strukturieren Sie LLM-Projekte als gestufte Pipelines, da die Trennung von deterministischen und nicht-deterministischen Stufen schnelle Iteration und Kostenkontrolle ermöglicht. Entwerfen Sie jede Stufe so, dass sie:

• Diskret ist: Klare Grenzen zwischen den Stufen, damit jede unabhängig debuggt werden kann
• Idempotent ist: Wiederholtes Ausführen führt zum gleichen Ergebnis und verhindert doppelte Arbeit
• Cache-fähig ist: Zwischenergebnisse werden auf der Festplatte gespeichert, was teure Neuberechnungen vermeidet
• Unabhängig ist: Jede Stufe kann separat ausgeführt werden, was eine selektive Wiederholung ermöglicht

Verwenden Sie diese kanonische Pipeline-Struktur:

erfassen -> vorbereiten -> verarbeiten -> parsen -> rendern

1. Erfassen: Rohdaten aus Quellen abrufen (APIs, Dateien, Datenbanken)
2. Vorbereiten: Daten in Prompt-Format umwandeln
3. Verarbeiten: LLM-Aufrufe ausführen (der teure, nicht-deterministische Schritt)
4. Parsen: Strukturierte Daten aus LLM-Ausgaben extrahieren
5. Rendern: Endgültige Ausgaben generieren (Berichte, Dateien, Visualisierungen)

Die Stufen 1, 2, 4 und 5 sind deterministisch. Stufe 3 ist nicht-deterministisch und teuer. Halten Sie diese Trennung aufrecht, da sie es ermöglicht, die teure LLM-Stufe nur bei Bedarf erneut auszuführen, während gleichzeitig schnell an Parsing und Rendering iteriert werden kann.

Dateisystem als Zustandsmaschine

Verwenden Sie das Dateisystem, um den Pipeline-Zustand zu verfolgen, anstatt Datenbanken oder In-Memory-Strukturen, da die Existenz von Dateien eine natürliche Idempotenz und menschenlesbares Debugging bietet.

daten/{id}/
  rohdaten.json         # Erfassungsstufe abgeschlossen
  prompt.md        # Vorbereitungsstufe abgeschlossen
  antwort.md      # Verarbeitungsstufe abgeschlossen
  geparst.json      # Parsing-Stufe abgeschlossen

Prüfen Sie, ob ein Element verarbeitet werden muss, indem Sie prüfen, ob die Ausgabedatei existiert. Führen Sie eine Stufe erneut aus, indem Sie ihre Ausgabedatei und nachgelagerte Dateien löschen. Debuggen Sie, indem Sie die Zwischendateien direkt lesen. Dieses Muster funktioniert, weil jedes Verzeichnis unabhängig ist, was eine einfache Parallelisierung und triviales Caching ermöglicht.

Entwurf strukturierter Ausgaben

Entwerfen Sie Prompts für strukturierte, parsbare Ausgaben, da das Prompt-Design die Parsing-Zuverlässigkeit direkt bestimmt. Fügen Sie diese Elemente in jeden strukturierten Prompt ein:

1. Abschnittsmarkierungen: Explizite Überschriften oder Präfixe, auf die Parser abgleichen können
2. Formatbeispiele: Zeigen Sie genau, wie die Ausgabe aussehen soll
3. Offenlegung der Begründung: Geben Sie an „Ich werde dies programmatisch parsen“, damit das Modell der Formateinhaltung Priorität einräumt
4. Eingeschränkte Werte: Aufgezählte Optionen, Bewertungsspannen und feste Formate

Bauen Sie Parser, die Variationen in der LLM-Ausgabe elegant handhaben, da LLMs Anweisungen nicht perfekt befolgen. Verwenden Sie Regex-Muster, die flexibel genug für kleinere Formatierungsvariationen sind, stellen Sie sinnvolle Standardwerte bereit, wenn Abschnitte fehlen, und protokollieren Sie Parsing-Fehler zur Überprüfung, anstatt abzustürzen.

Agentenunterstützte Entwicklung

Verwenden Sie agentenfähige Modelle, um die Entwicklung durch schnelle Iteration zu beschleunigen: Beschreiben Sie das Projektziel und die Einschränkungen, lassen Sie den Agenten eine erste Implementierung generieren, testen und iterieren Sie an bestimmten Fehlern und verfeinern Sie dann Prompts und Architektur basierend auf den Ergebnissen.

Übernehmen Sie diese Praktiken, weil sie die Agentenausgabe fokussiert und qualitativ hochwertig halten:

• Geben Sie klare, spezifische Anforderungen im Voraus, um Überarbeitungszyklen zu reduzieren
• Teilen Sie große Projekte in diskrete Komponenten auf, damit jede unabhängig validiert werden kann
• Testen Sie jede Komponente, bevor Sie zur nächsten übergehen, um Fehler frühzeitig zu erkennen
• Halten Sie den Agenten jeweils auf eine Aufgabe konzentriert, um eine Verschlechterung des Kontexts zu verhindern

Kosten- und Skalenschätzung

Schätzen Sie die LLM-Verarbeitungskosten, bevor Sie beginnen, da sich die Token-Kosten im großen Maßstab schnell summieren und eine späte Entdeckung von Budgetüberschreitungen kostspielige Nacharbeiten erzwingt. Verwenden Sie diese Formel:

Gesamtkosten = (Anzahl_der_Elemente x Tokens_pro_Element x Preis_pro_Token) + API-Overhead

Schätzen Sie für die Stapelverarbeitung die Eingabe-Tokens pro Element (Prompt + Kontext), schätzen Sie die Ausgabe-Tokens pro Element (typische Antwortlänge), multiplizieren Sie mit der Anzahl der Elemente und fügen Sie einen Puffer von 20-30 % für Wiederholungen und Fehler hinzu.

Verfolgen Sie die tatsächlichen Kosten während der Entwicklung. Wenn die Kosten die Schätzungen erheblich übersteigen, reduzieren Sie die Kontextlänge durch Kürzung, verwenden Sie kleinere Modelle für einfachere Elemente, cachen und verwenden Sie Teilergebnisse wieder oder fügen Sie Parallelverarbeitung hinzu, um die Wanduhrzeit zu reduzieren.

Detaillierte Themen

Wahl zwischen Single- und Multi-Agent-Architektur

Standardmäßig bevorzugen Sie Single-Agent-Pipelines für die Stapelverarbeitung mit unabhängigen Elementen, da sie einfacher zu verwalten, billiger auszuführen und leichter zu debuggen sind. Steigen Sie nur dann auf Multi-Agent-Architekturen um, wenn eine dieser Bedingungen erfüllt ist:

• Eine parallele Untersuchung verschiedener Aspekte ist erforderlich
• Die Aufgabe übersteigt die Kapazität eines einzelnen Kontextfensters
• Spezialisierte Unter-Agenten verbessern nachweislich die Qualität in Benchmarks

Wählen Sie Multi-Agent zur Kontextisolierung, nicht zur Rollen-Anthropomorphisierung. Unter-Agenten erhalten frische Kontextfenster für fokussierte Teilaufgaben, was eine Verschlechterung des Kontexts bei langlebigen Aufgaben verhindert.

Siehe die Fähigkeit multi-agent-patterns für eine detaillierte Architektur-Anleitung.

Architektonische Reduktion

Beginnen Sie mit einer minimalen Architektur und fügen Sie Komplexität nur hinzu, wenn Produktionserfahrung dies als notwendig erweist, da übertechnisierte Gerüste die Modellleistung oft eher einschränken als ermöglichen.

Die Fallstudie d0 von Vercel berichtet von verbesserten Erfolgen nach der Reduzierung vieler spezialisierter Tools auf zwei Primitive: Befehlsausführung und SQL (claim-project-development-vercel-d0-reduction). Das Dateisystem-Agenten-Muster verwendet standardmäßige Unix-Dienstprogramme anstelle von benutzerdefinierten Erkundungswerkzeugen.

Reduzieren, wenn:

• Die Datenschicht gut dokumentiert und konsistent strukturiert ist
• Das Modell über ausreichende Denkfähigkeiten verfügt
• Spezialisierte Tools eher einschränken als ermöglichen
• Mehr Zeit mit der Wartung des Gerüsts als mit der Verbesserung der Ergebnisse verbracht wird

Komplexität hinzufügen, wenn:

• Die zugrunde liegenden Daten chaotisch, inkonsistent oder schlecht dokumentiert sind
• Die Domäne spezialisiertes Wissen erfordert, das dem Modell fehlt
• Sicherheitsauflagen die Einschränkung der Agentenfähigkeiten erfordern
• Operationen wirklich komplex sind und von strukturierten Arbeitsabläufen profitieren

Siehe die Fähigkeit tool-design für eine detaillierte Anleitung zur Tool-Architektur.

Iteration und Refactoring

Planen Sie von Anfang an mehrere architektonische Iterationen ein, da Produktions-Agentensysteme im großen Maßstab immer ein Refactoring erfordern. Manus hat ihr Agenten-Framework seit dem Start fünfmal umgebaut. Die Bittere Lektion legt nahe, dass Strukturen, die für aktuelle Modelleinschränkungen hinzugefügt wurden, zu Einschränkungen werden, wenn sich Modelle verbessern.

Bauen Sie für Veränderungen, indem Sie diese Praktiken befolgen:

• Halten Sie die Architektur einfach und meinungsfrei, damit Refactoring billig ist
• Testen Sie über Modellgenerationen hinweg, um zu überprüfen, ob das Gerüst die Leistung nicht einschränkt
• Entwerfen Sie Systeme, die von Modellverbesserungen profitieren, anstatt Einschränkungen zu verankern

Praktische Anleitung

Projektplanungsvorlage

Befolgen Sie diese Vorlage der Reihe nach, da jeder Schritt Annahmen validiert, bevor der nächste Schritt Aufwand investiert.

1. Aufgabenanalyse

   • Definieren Sie die Eingabe und die gewünschte Ausgabe explizit
   • Klassifizieren Sie: Synthese, Generierung, Klassifizierung oder Analyse
   • Legen Sie eine akzeptable Fehlerrate basierend auf den geschäftlichen Auswirkungen fest
   • Schätzen Sie den Wert pro erfolgreicher Fertigstellung, um die Kosten zu rechtfertigen

2. Manuelle Validierung

   • Testen Sie ein repräsentatives Beispiel mit dem Zielmodell
   • Bewerten Sie Ausgabequalität und -format anhand der Anforderungen
   • Identifizieren Sie Fehlermodi, die eine Härtung des Parsers oder eine Prompt-Überarbeitung erfordern
   • Schätzen Sie Tokens pro Element für die Kostenprognose

3. Architekturauswahl

   • Wählen Sie basierend auf den obigen Kriterien eine einzelne Pipeline oder Multi-Agent
   • Identifizieren Sie erforderliche Tools und Datenquellen
   • Entwerfen Sie eine Speicher- und Caching-Strategie unter Verwendung des Dateisystemzustands
   • Planen Sie einen Parallelisierungsansatz für die Verarbeitungsstufe

4. Kostenschätzung

   • Berechnen Sie Elemente x Tokens x Preis mit einem Puffer von 20-30 %
   • Schätzen Sie die Entwicklungszeit für jede Pipelinestufe
   • Identifizieren Sie Infrastrukturanforderungen (API-Schlüssel, Speicher, Rechenleistung)
   • Prognostizieren Sie die laufenden Betriebskosten für Produktionsläufe

5. Entwicklungsplan

   • Implementieren Sie Stufe für Stufe und testen Sie jede, bevor Sie fortfahren
   • Definieren Sie eine Teststrategie pro Stufe mit erwarteten Ausgaben
   • Legen Sie Iterationsmeilensteine fest, die an Qualitätsmetriken gebunden sind
   • Planen Sie einen Bereitstellungsansatz mit Rollback-Fähigkeit

Beispiele

Beispiel 1: Batch-Analyse-Pipeline (Karpathys HN-Zeitkapsel)

Aufgabe: Analysieren Sie 930 HN-Diskussionen von vor 10 Jahren mit einer retrospektiven Bewertung.

Architektur:

• 5-stufige Pipeline: abrufen -> prompten -> analysieren -> parsen -> rendern
• Dateisystemzustand: daten/{datum}/{item_id}/ mit Stufenausgabedateien
• Strukturierte Ausgabe: 6 Abschnitte mit expliziten Formatanforderungen
• Parallele Ausführung: 15 Worker für LLM-Aufrufe

Ergebnisse: Gesamtkosten 58 $, ~1 Stunde Ausführungszeit, statische HTML-Ausgabe.

Beispiel 2: Architektonische Reduktion (Vercel d0)

Aufgabe: Text-zu-SQL-Agent für interne Analysen.

Vorher: viele spezialisierte Tools mit geringerem gemessenen Erfolg und längerer durchschnittlicher Ausführungszeit.

Nachher: zwei Tools (bash + SQL) mit höherem gemessenen Erfolg und kürzerer durchschnittlicher Ausführungszeit (claim-project-development-vercel-d0-reduction).

Wichtige Erkenntnis: Die semantische Schicht war bereits eine gute Dokumentation. Claude brauchte nur direkten Zugriff zum Lesen von Dateien.

Siehe Fallstudien für eine detaillierte Analyse.

Richtlinien

1. Validieren Sie den Task-Model-Fit mit manuellen Prototypen, bevor Sie Automatisierung aufbauen
2. Strukturieren Sie Pipelines als diskrete, idempotente, cache-fähige Stufen
3. Verwenden Sie das Dateisystem für Zustandsverwaltung und Debugging
4. Entwerfen Sie Prompts für strukturierte, parsbare Ausgaben mit expliziten Formatbeispielen
5. Beginnen Sie mit minimaler Architektur; fügen Sie Komplexität nur hinzu, wenn sie nachweislich notwendig ist
6. Schätzen Sie Kosten frühzeitig und verfolgen Sie sie während der gesamten Entwicklung
7. Bauen Sie robuste Parser, die ...