Agent-Framework evaluieren

Strukturierte Bewertung der Investitionsbereitschaft eines Open-Source-Agent-Frameworks. Der neuartige Wert liegt in Schritten 2-3: Quantifizierung der Community-Gesundheit durch Beitrags-Ueberlebensraten und Messung des Supersession-Risikos — der haeufigste Grund warum externer Engineering-Aufwand verschwendet wird. Die finale Klassifikation (INVEST / EVALUATE-FURTHER / CONTRIBUTE-CAUTIOUSLY / AVOID) kalibriert Ressourcenallokation bevor Entwicklungszyklen verpflichtet werden.

Wann verwenden

• Bewerten ob ein Agent-Framework fuer Production-Use uebernommen werden soll
• Abhaengigkeitsrisiko auf einem Framework einschaetzen auf das das Projekt sich verlaesst
• Entscheiden ob Engineering-Aufwand zu einem externen Projekt beigetragen werden soll
• Konkurrierende Frameworks fuer eine Build-vs-Adopt-Entscheidung vergleichen
• Ein Framework nach einem Major-Release, Governance-Wechsel oder Acquisition neu bewerten

Eingaben

• Erforderlich: framework_url — GitHub-URL des Framework-Repositories
• Optional:
  • comparison_frameworks — Liste alternativer Framework-URLs zum Benchmarken
  • use_case — beabsichtigter Anwendungsfall fuer Architektur-Alignment-Bewertung (z.B. "multi-agent orchestration", "tool-use pipelines")
  • contribution_budget — geplante Engineering-Stunden, zur Kalibrierung der Investitions-Stufe

Vorgehensweise

Schritt 1: Framework-Zensus sammeln

Grundlegende Daten ueber Groesse, Aktivitaet und Landscape-Position des Projekts vor tieferer Analyse sammeln.

1. README.md, CONTRIBUTING.md, LICENSE und alle Architektur-Docs (docs/, ARCHITECTURE.md) abrufen und lesen
2. Quantitative Metriken sammeln:
   • Stars, Forks, offene Issues, offene PRs: gh repo view <repo> --json stargazerCount,forkCount,issues,pullRequests
   • Abhaengige Repositories: GitHubs "Used by"-Anzahl pruefen oder gh api repos/<owner>/<repo>/dependents
   • Release-Kadenz: gh release list --limit 10 — Frequenz vermerken und ob Releases semver folgen
3. Bus-Faktor berechnen: Top-5-Contributors nach Commit-Anzahl ueber die letzten 12 Monate identifizieren. Wenn der Top-Contributor >60% der Commits ausmacht, ist der Bus-Faktor kritisch niedrig
4. Landscape-Position kartieren:
   • Pioneer: First Mover, definiert die Kategorie (hoher Einfluss, hohes Supersession-Risiko fuer Follower)
   • Fast-Follower: innerhalb 6 Monaten nach dem Pioneer gestartet, iteriert ueber das Konzept
   • Spaet-Einsteiger: nach Stabilisierung der Kategorie angekommen, konkurriert ueber Features oder Governance
5. Wenn comparison_frameworks angegeben ist, dieselben Metriken fuer jede Alternative sammeln

Erwartet: Zensus-Tabelle mit Stars, Forks, Dependents, Release-Kadenz, Bus-Faktor und Landscape-Position fuer das Ziel (und Vergleiche falls bereitgestellt).

Bei Fehler: Wenn das Repository privat oder API-rate-limitiert ist, auf manuelle README-Analyse zurueckfallen. Wenn Metriken nicht verfuegbar sind (z.B. selbst gehostetes GitLab), die Luecke vermerken und mit qualitativer Bewertung fortfahren.

Schritt 2: Community-Gesundheit bewerten

Quantifizieren ob das Projekt externe Beitragende willkommen heisst, unterstuetzt und haelt.

1. Die externe Beitrags-Ueberlebensrate berechnen:
   • Die letzten 50 geschlossenen PRs ziehen: gh pr list --state closed --limit 50 --json author,mergedAt,closedAt,labels
   • Jeden PR-Autor als intern (Org-Mitglied) oder extern klassifizieren
   • Berechnen: survival_rate = merged_external_PRs / total_external_PRs
   • Gesunder Schwellwert: >50% Ueberlebensrate; bedenklich: <30%
2. Reaktivitaet messen:
   • Issue-Erstantwort-Zeit: Median-Zeit von Issue-Erstellung zu erstem Maintainer-Kommentar
   • PR-Merge-Latenz: Median-Zeit von PR-Eroeffnung bis Merge fuer externe PRs
   • Gesund: <7 Tage Erstantwort, <30 Tage Merge; bedenklich: >30 Tage Erstantwort
3. Contributor-Diversitaet einschaetzen:
   • Externes/internes Contributor-Verhaeltnis ueber die letzten 6 Monate
   • Anzahl einzigartiger externer Contributors mit >=2 gemergten PRs (wiederkehrende Contributors signalisieren ein gesundes Oekosystem)
4. Governance-Artefakte pruefen:
   • CONTRIBUTING.md existiert und ist umsetzbar (nicht nur "PR einreichen")
   • CODE_OF_CONDUCT.md existiert
   • Governance-Docs beschreiben den Entscheidungsprozess
   • Issue-/PR-Templates leiten Beitragende

Erwartet: Community-Gesundheits-Scorecard mit Ueberlebensrate, Antwortzeiten, Diversitaets-Verhaeltnis und Governance-Artefakt-Checkliste.

Bei Fehler: Wenn PR-Daten unzureichend sind (neues Projekt mit <20 geschlossenen PRs), die Stichprobengroessen-Beschraenkung vermerken und andere Signale staerker gewichten. Wenn das Projekt eine Nicht-GitHub-Plattform nutzt, die Queries an die API dieser Plattform anpassen.

Schritt 3: Supersession-Risiko berechnen

Bestimmen wie wahrscheinlich es ist dass externe Beitraege durch interne Entwicklung obsolet gemacht werden — das groesste Einzelrisiko fuer Framework-Adopters und -Beitragende.

1. Die letzten 50-100 gemergten externen PRs sampeln (oder alle wenn weniger existieren)
2. Fuer jeden gemergten externen PR pruefen ob der beigetragene Code spaeter:
   • Reverted: expliziter Revert-Commit der den PR referenziert
   • Rewritten: dieselbe Datei/Modul innerhalb 90 Tagen wesentlich von einem internen Contributor geaendert
   • Obsoleted: Feature in einem nachfolgenden Release entfernt oder ersetzt
3. Berechnen: supersession_rate = (reverted + rewritten + obsoleted) / total_merged_external
4. Die veroeffentlichte Roadmap (falls verfuegbar) gegen Bereiche kartieren in denen externe Contributors aktiv sind:
   • Hohe Ueberlappung = hohes Supersession-Risiko (Interne werden ueber externe Arbeit bauen)
   • Niedrige Ueberlappung = niedrigeres Supersession-Risiko (Externe fuellen Luecken die Interne nicht fuellen werden)
5. Auf "Beitrags-Fallen" pruefen: Bereiche die beitragsfreundlich aussehen aber fuer internen Rewrite geplant sind
6. Referenz-Benchmark: NemoClaw-Analyse zeigte 71% externe PRs innerhalb 6 Monaten superseded — als Kalibrierungspunkt nutzen

Erwartet: Supersession-Rate als Prozentsatz, mit Aufschluesselung nach Typ (reverted/rewritten/obsoleted). Roadmap-Ueberlappungs-Bewertung.

Bei Fehler: Wenn die Commit-Historie flach oder squash-merged ist (Attribution verloren), Supersession schaetzen indem externe PR-Dateipfade gegen in nachfolgenden Releases geaenderte Dateien verglichen werden. Reduziertes Vertrauen in die Schaetzung vermerken.

Schritt 4: Architektur-Alignment evaluieren

Bewerten ob die Architektur des Frameworks deinen Anwendungsfall ohne uebermaessigen Lock-in unterstuetzt.

1. Erweiterungspunkte kartieren:
   • Plugin-/Extension-API: legt das Framework eine dokumentierte Plugin-Schnittstelle offen?
   • Konfigurations-Oberflaeche: kann Verhalten ohne Forking angepasst werden?
   • Hook-/Callback-System: kannst du Framework-Verhalten an Schluesselpunkten abfangen und modifizieren?
2. Lock-in-Risiko einschaetzen:
   • Rewrite-Kosten: Engineering-Aufwand zum Wegmigrieren schaetzen (Tage/Wochen/Monate)
   • Datenportabilitaet: koennen Daten/State in Standardformaten exportiert werden?
   • Standard-Compliance: nutzt das Framework offene Standards (agentskills.io, MCP, A2A) oder proprietaere Protokolle?
3. API-Stabilitaet evaluieren:
   • Breaking Changes pro Major-Release zaehlen (CHANGELOG, Migrations-Guides)
   • Auf Deprecation-Policy pruefen (Vorwarnung vor Entfernung)
   • Semver-Compliance einschaetzen (Breaking Changes nur in Major-Versionen)
4. Alignment mit dem spezifischen Anwendungsfall pruefen:
   • Wenn use_case angegeben ist, evaluieren ob die Framework-Architektur ihn natuerlich unterstuetzt
   • Architektonische Mismatches identifizieren die Workarounds erfordern wuerden
5. Interoperabilitaet evaluieren:
   • agentskills.io-Kompatibilitaet (Skill-Modell-Alignment)
   • MCP-Unterstuetzung (Tool-Integration)
   • A2A-Protokoll-Unterstuetzung (Agent-zu-Agent-Kommunikation)

Erwartet: Architektur-Alignment-Bericht mit Erweiterungspunkt-Inventar, Lock-in-Risiko-Bewertung (niedrig/mittel/hoch), API-Stabilitaets-Score und Anwendungsfall-Fit-Bewertung.

Bei Fehler: Wenn Architektur-Dokumentation duenn ist, die Bewertung aus Code-Struktur und oeffentlicher API-Oberflaeche ableiten. Wenn das Framework zu jung fuer Stabilitaets-Historie ist, dies vermerken und Governance-Signale staerker gewichten.

Schritt 5: Governance und Nachhaltigkeit bewerten

Evaluieren ob das Governance-Modell des Projekts langfristige Lebensfaehigkeit und faire Behandlung externer Beitragender unterstuetzt.

1. Governance-Modell klassifizieren:
   • BDFL (Benevolent Dictator for Life): einzelner Entscheider — schnelle Entscheidungen, Bus-Faktor-Risiko
   • Komitee/Core-Team: verteilte Entscheidungsfindung — langsamer aber widerstandsfaehiger
   • Foundation-backed: formale Governance (Apache, Linux Foundation, CNCF) — am nachhaltigsten
   • Corporate-controlled: einzelnes Unternehmen treibt Entwicklung — auf Rug-Pull-Risiko achten
2. Funding und Nachhaltigkeit einschaetzen:
   • Funding-Quellen: VC-backed, corporate-sponsored, Grants, community-finanziert, unfinanziert
   • Vollzeit-Maintainer-Anzahl: >=2 ist gesund; 0 ist eine rote Flagge
   • Umsatzmodell (falls vorhanden): wie haelt sich das Projekt selbst?
3. Contributor-Schutz evaluieren:
   • Lizenztyp: permissiv (MIT, Apache-2.0) vs. copyleft (GPL) vs. custom
   • CLA-Anforderungen: ueberfuehrt das Unterzeichnen einer CLA Rechte die Beitragende benachteiligen?
   • Contributor-Anerkennung: werden externe Beitragende in Releases, Changelogs, Docs gewuerdigt?
4. Sicherheits-Posture pruefen:
   • Sicherheits-Disclosure-Policy (SECURITY.md oder Aequivalent)
   • Median-Zeit von CVE-Disclosure zu Patch-Release
   • Dependency-Update-Praktiken (Dependabot, Renovate, manuell)
5. Trajektorie einschaetzen:
   • Entwickelt sich das Governance-Modell (z.B. Bewegung in Richtung Foundation)?
   • Gab es kuerzlich einen Leadership-Wechsel, eine Acquisition oder Re-Lizenzierung?
   • Gibt es oeffentliche Konflikte zwischen Maintainern und Beitragenden?

Erwartet: Governance-Bewertung mit Modell-Klassifikation, Nachhaltigkeitsbewertung (nachhaltig/at-risk/kritisch), Contributor-Schutz-Bewertung und Sicherheits-Posture-Zusammenfassung.

Bei Fehler: Wenn Governance-Information undokumentiert ist, die Abwesenheit selbst als Gelb-Flagge behandeln. Auf implizite Governance pruefen indem geprueft wird wer PRs merged, wer Issues schliesst und wer Release-Entscheidungen trifft.

Schritt 6: Investitions-Bereitschaft klassifizieren

Alle Befunde in eine Vier-Stufen-Klassifikation mit spezifischen Begruendungen und umsetzbaren Empfehlungen synthetisieren.

1. Jede Dimension scoren (1-5-Skala):
   • Community-Gesundheit: Ueberlebensrate, Reaktivitaet, Diversitaet
   • Supersession-Risiko: Rate, Roadmap-Ueberlappung, Beitrags-Fallen (invertieren: niedriger ist besser)
   • Architektur-Alignment: Erweiterungspunkte, Lock-in, Stabilitaet, Anwendungsfall-Fit
   • Governance-Nachhaltigkeit: Modell, Funding, Schutz, Sicherheit
2. Klassifikations-Schwellwerte anwenden:
   • INVEST (alle Dimensionen >=4): Gesunde Community, niedriges Supersession (<20%), aligntierte Architektur, nachhaltige Governance. Sicher zu uebernehmen und Engineering-Aufwand beizutragen.
   • EVALUATE-FURTHER (gemischt, keine Dimension <2): Gemischte Signale die spezifische Follow-ups erfordern. Dokumentieren was Klaerung braucht und ein Re-Evaluierungs-Datum setzen.
   • CONTRIBUTE-CAUTIOUSLY (irgendeine Dimension 2, keine <2): Hohes Supersession (>40%) oder Governance-Bedenken. Beitraege auf explizit angefragte Arbeit, vom Maintainer genehmigten Scope oder Plugin-/Extension-Entwicklung beschraenken die vom Core entkoppelt ist.
   • AVOID (irgendeine Dimension 1): Kritische rote Flaggen — verlassenes Projekt, externen-feindlich (Ueberlebensrate <15%), inkompatible Lizenz oder unmittelbare Rug-Pull-Indikatoren. Keinen Engineering-Aufwand investieren.
3. Den Klassifikations-Bericht schreiben:
   • Mit der Stufen-Klassifikation und einsatzartiger Begruendung beginnen
   • Jeden Dimensions-Score mit Schluessel-Evidenz zusammenfassen
   • Wenn contribution_budget angegeben war, empfehlen wie diese Stunden gegeben der Stufe alloziert werden sollen
   • Fuer EVALUATE-FURTHER spezifische Fragen auflisten die Antworten brauchen und einen Zeitplan vorschlagen
   • Fuer CONTRIBUTE-CAUTIOUSLY spezifizieren welche Beitragstypen sicher (Plugins, Docs, Tests) vs. riskant (Core-Features) sind
4. Wenn comparison_frameworks evaluiert wurden, eine Vergleichsmatrix produzieren die alle Frameworks rangiert

Erwartet: Klassifikations-Bericht mit Stufe, Dimensions-Scores, Evidenz-Zusammenfassung und umsetzbaren Empfehlungen massgeschneidert auf den Investitions-Kontext.

Bei Fehler: Wenn Datenluecken sichere Klassifikation verhindern, auf EVALUATE-FURTHER defaulten mit expliziter Dokumentation was an Daten fehlt und wie man sie erhaelt. Niemals auf INVEST defaulten wenn unsicher.

Validierung

• Zensus-Daten gesammelt: Stars, Forks, Dependents, Release-Kadenz, Bus-Faktor, Landscape-Position
• Community-Gesundheit quantifiziert: Ueberlebensrate, Antwortzeiten, Contributor-Diversitaet, Governance-Artefakte
• Supersession-Risiko berechnet mit Aufschluesselung nach Typ (reverted/rewritten/obsoleted)
• Architektur-Alignment bewertet: Erweiterungspunkte, Lock-in-Risiko, API-Stabilitaet, Anwendungsfall-Fit
• Governance evaluiert: Modell, Funding, Contributor-Schutz, Sicherheits-Posture
• Klassifikation produziert: eine von INVEST / EVALUATE-FURTHER / CONTRIBUTE-CAUTIOUSLY / AVOID
• Jeder Dimensions-Score mit spezifischer Evidenz aus der Analyse begruendet
• Empfehlungen sind umsetzbar und auf das Beitragsbudget kalibriert (falls bereitgestellt)
• Datenluecken und Vertrauensbeschraenkungen explizit dokumentiert

Haeufige Stolperfallen

• Popularitaet mit Gesundheit verwechseln: Hohe Stars aber niedrige Contributor-Diversitaet bedeutet einen Single Point of Failure. Ein 50k-Star-Projekt mit einem Maintainer ist weniger gesund als ein 2k-Star-Projekt mit 15 aktiven Contributors.
• Supersession-Risiko ignorieren: Der haeufigste Grund warum externe Beitraege scheitern. Eine einladende Community bedeutet nichts wenn interne Entwicklung externe Arbeit routinemaessig ueberschreibt.
• Architektur ueberzgewichten ohne Governance zu pruefen: Ein wunderschoen entworfenes Framework kann immer noch scheitern wenn das Governance-Modell unhaltbar oder externen-feindlich ist.
• EVALUATE-FURTHER als AVOID behandeln: Gemischte Signale erfordern Untersuchung, nicht Ablehnung. Ein konkretes Re-Evaluierungs-Datum setzen und die spezifischen zu beantwortenden Fragen auflisten.
• Snapshot-Verzerrung: Alle Metriken sind Punkt-in-Zeit. Ein abnehmendes Projekt mit grossartigen aktuellen Metriken ist schlimmer als ein verbesserndes Projekt mit mittelmaessigen aktuellen Metriken. Immer die Trend-Richtung ueber 6-12 Monate pruefen.
• CLA-Selbstzufriedenheit: Manche CLAs ueberfuehren Copyright zum Projekteigentuemer, was bedeutet dass deine Beitraege ihr proprietaerer Vermoegenswert werden. Den CLA-Text lesen, nicht nur die Checkbox.
• Auf einem einzelnen Framework ankern: Ohne Vergleichsframeworks sieht jedes Projekt entweder grossartig oder schrecklich aus. Immer gegen mindestens eine Alternative benchmarken, auch informell.

Verwandte Skills

• polish-claw-project — Beitrags-Workflow den diese Bewertung informiert
• review-software-architecture — in Schritt 4 fuer Architektur-Bewertung verwendet
• forage-solutions — Alternative-Framework-Entdeckung fuer Vergleich
• search-prior-art — Landscape-Mapping und Prior-Work-Analyse
• security-audit-codebase — Sicherheits-Posture-Bewertung in Schritt 5 referenziert
• assess-ip-landscape — Lizenz- und IP-Risiko-Analyse