sgr-agent-core: Schema-Guided Reasoning als Agenten-Gerüst
Schema-Guided Reasoning (SGR) has agentic system design created by neuraldeep community
Auf einen Blick
- Was ist das?
- Ein Python-Framework, das Recherche-Agenten um ein festes Antwortschema herum baut und optional Function Calling dazuschaltet. Die Idee ist überzeugend, die Konfigurationslast und die Abhängigkeit von externen Suchdiensten sind der Preis.
- Für wen ist es gedacht?
- Wer einen OpenAI-kompatiblen Endpunkt braucht und die Suchwerkzeuge selbst bereitstellt, findet hier eine schlanke, MIT-lizenzierte Basis mit klarer Zwei-Phasen-Struktur. Wer einen Agenten ohne externen Suchdienst oder mit eigenen, nicht OpenAI-kompatiblen Modellen betreiben will, sollte zuerst die Tool-Schicht und den llm-Block in config.yaml prüfen, bevor er sich auf die Beispielkonfiguration festlegt.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 20 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem das Schema lösen soll
Ein freier Agent, der abwechselnd denkt und Werkzeuge aufruft, produziert Antworten in einer Form, die sich schlecht weiterverarbeiten lässt. Das Modell entscheidet von Schritt zu Schritt neu, welche Struktur es verwendet, und jede nachgelagerte Auswertung muss raten. Schema-Guided Reasoning dreht das um: Die Antwortform steht vorher fest, und das Modell füllt sie aus. Das Projekt beschreibt den Ansatz als Kombination aus strukturiertem Schlussfolgern und flexibler Werkzeugauswahl. Zielgruppe sind laut Repository Entwickler, die Recherche-Agenten bauen und dabei nicht bei jedem Modellwechsel die Auswertungslogik neu schreiben wollen. Der Nutzen liegt weniger in besseren Antworten als in vorhersagbaren. Wer die Ausgabe eines Agenten in eine Datenbank schreiben, gegen ein Schema validieren oder an einen zweiten Dienst weiterreichen will, gewinnt dadurch mehr als jemand, der nur eine lesbare Zusammenfassung braucht. Genau dort liegt auch die Grenze: Für offene Dialogaufgaben ohne feste Ausgabestruktur ist der Ansatz zusätzlicher Aufwand ohne Gegenwert.
Zwei Phasen, drei Agententypen, ein BaseAgent
Das Framework stellt eine erweiterbare BaseAgent-Schnittstelle bereit und baut darauf eine Zwei-Phasen-Architektur auf. Aus dem Repository geht hervor, dass es drei mitgelieferte Agententypen gibt: SGRAgent, ToolCallingAgent und SGRToolCallingAgent. Die Namensgebung legt die Vermutung nahe, dass der dritte Typ beide Ansätze verbindet, also schemageführtes Schlussfolgern mit klassischem Function Calling. Die README benennt das nicht explizit, und die verlinkte Hybrid-FC-Forschung deutet darauf hin, dass dieses Feld noch in Arbeit ist. Wer die genaue Abgrenzung braucht, muss die Dokumentation unter vamplabai.github.io/sgr-agent-core lesen; aus dem Repository-Auszug allein lässt sie sich nicht belegen. Klar erkennbar ist dagegen die Werkzeugschicht: Suche, Schlussfolgern und Rückfragen sind als eigene Tools angelegt, und die Beispiele zeigen web_search_tool sowie extract_page_content_tool mit eigenen API-Schlüsseln. Der Datenfluss verläuft damit über den Agenten, der ein Schema ausfüllt, dabei Werkzeuge aufruft und die Ergebnisse zurück in das Schema schreibt. Rückfragen an den Nutzer sind als eigener Pfad vorgesehen, was die CLI mit einem Dialogmodus aufgreift.
Inbetriebnahme über Docker, pip oder die sgr-CLI
Der schnellste Weg laut README ist ein Container. Nach dem Klonen werden zwei Verzeichnisse angelegt und beschreibbar gemacht (logs und reports), danach wird die Beispieldatei kopiert: cp examples/sgr_deep_research/config.yaml.example examples/sgr_deep_research/config.yaml. In dieser YAML-Datei sind llm.api_key, tools.web_search_tool.api_key und tools.extract_page_content_tool.tavily_api_key zu setzen. Die beiden Tavily-Schlüssel sind im README als optional markiert, was bedeutet, dass der Agent ohne sie zwar startet, aber nicht suchen kann. Der Container lauscht auf Port 8010, die Swagger-Oberfläche liegt unter /docs. Wer die Bibliothek direkt einbinden will, installiert mit pip install sgr-agent-core. Für den Server gibt es zwei gleichwertige Aufrufe: sgr --config-file examples/sgr_deep_research/config.yaml oder python -m sgr_agent_core.server --config-file ... . Für die Kommandozeile existiert sgrsh, das ohne Argument in einen interaktiven Chatmodus wechselt und mit --agent einen bestimmten Agenten auswählt. Ein dritter Einstieg ist sgracp, das denselben YAML-Aufbau über stdio als newline-delimited JSON-RPC spricht und über einen acp-Block in der Konfiguration festlegt, welcher Agent exponiert wird.
Der Benchmark sagt weniger, als er zu sagen scheint
Das Repository nennt für SimpleQA mit gpt-4.1-mini eine Genauigkeit von 86,08 Prozent, aufgeschlüsselt in 3.724 korrekte, 554 falsche und 48 nicht versuchte Antworten. Diese Zahlen stammen aus dem Projekt selbst, nicht aus einer unabhängigen Auswertung, und sie gelten für ein einziges Modell. Interessant ist vor allem die dritte Kategorie: 48 Fragen wurden nicht versucht. Ein System, das Fragen lieber auslässt als falsch beantwortet, verschiebt das Problem von der Genauigkeit zur Abdeckung, und wer den Agenten produktiv einsetzt, muss entscheiden, ob ihm das recht ist. Die README macht dazu keine Angabe. Ein weiterer Vorbehalt: SimpleQA ist ein Frage-Antwort-Benchmark mit kurzen, faktischen Antworten. Er misst genau das, wofür ein festes Antwortschema gebaut ist. Ob der Vorteil bei mehrstufigen Rechercheaufträgen mit langen Berichten bestehen bleibt, lässt sich aus dem Material nicht ableiten. Die vollständigen Ergebnisse liegen unter benchmark/simpleqa_benchmark_results.md.
Wo das Gerüst im Weg steht
Ein festes Schema ist eine Einschränkung, und sie wird dann teuer, wenn die Aufgabe nicht in das Schema passt. Wer einen Agenten für offene Exploration, für Code-Review oder für mehrstufige Verhandlungen mit unklarem Ausgang baut, zahlt für Struktur, die er nicht nutzt, und verliert die Freiheit, die er braucht. Dazu kommt die Betriebsseite: Die Beispielkonfiguration bindet die Websuche an Tavily. Ist kein Schlüssel gesetzt, bleibt der Agent formal lauffähig, aber die Recherche fehlt, und der Fehler zeigt sich erst zur Laufzeit in Form leerer Ergebnisse. Das ist ein Konfigurationsmodell, das Fehler spät sichtbar macht. Die Container-Anleitung verlangt außerdem chmod 777 auf logs und reports, was in einer geteilten Umgebung zu weit geht; ein benannter Benutzer oder ein Volume mit passenden Rechten wäre enger. Und schließlich: Obwohl das Projekt mit jedem OpenAI-kompatiblen Modell arbeiten soll, hängt die Qualität des schemageführten Ausfüllens stark davon ab, wie zuverlässig das jeweilige Modell strukturierte Ausgaben erzeugt. Kleine lokale Modelle, die dieses Versprechen nicht einlösen, machen den Ansatz wertlos, ohne dass das Framework das abfangen könnte.
Was andere Frameworks anders machen
Der naheliegende Vergleich ist LangGraph. Dessen Modell ist ein expliziter Zustandsgraph: Knoten sind Funktionen, Kanten sind Übergänge, und der Entwickler zeichnet den Kontrollfluss selbst. Der Agent ist dort ein Graph, den man geschrieben hat. sgr-agent-core geht den umgekehrten Weg: Der Kontrollfluss liegt im Schema und in der Werkzeugauswahl des Modells, und der Entwickler liefert die Struktur der Antwort, nicht den Ablauf. Das ist weniger Code für Standardrecherche und mehr Kontrolle über die Ausgabeform, aber es nimmt einem die Möglichkeit, einen bestimmten Zwischenschritt zu erzwingen, etwa eine feste Reihenfolge aus Suche, Extraktion und Zusammenfassung. Wer solche Garantien braucht, ist mit einem Graph-Framework besser bedient. Wer dagegen viele ähnliche Rechercheaufträge mit gleichbleibender Ausgabestruktur fährt, spart mit dem Schema-Ansatz die Modellierung des Ablaufs. Die beiden Ansätze schließen sich nicht aus, und der Hybrid-Agent SGRToolCallingAgent deutet an, dass das Projekt selbst in Richtung klassischer Werkzeugsteuerung nachjustiert.
Wartung, Versionen und Lizenz
Die letzten drei Veröffentlichungen liegen bei 0.7.1 vom 15. Juli 2026, 0.7.0 vom 18. März 2026 und 0.6.0 vom 24. Januar 2026. Der Abstand zwischen 0.6.0 und 0.7.0 beträgt rund acht Wochen, der zwischen 0.7.0 und 0.7.1 knapp vier Monate. Alle Versionen tragen eine 0 an der ersten Stelle, das Projekt versteht sich also nicht als stabil. Wer es einsetzt, sollte die Konfigurationsdatei als versionierte Datei behandeln und bei jedem Sprung zwischen Minor-Versionen die Schlüssel unter llm und tools prüfen, weil die Beispieldatei die einzige dokumentierte Referenz für gültige Schlüssel ist. Die Lizenz ist MIT, was kommerzielle Nutzung, Änderung und Weitergabe erlaubt, solange Lizenztext und Urheberrechtshinweis beibehalten werden. Das betrifft nur den Code dieses Projekts. Die angebundenen Dienste, etwa Tavily oder ein OpenAI-kompatibler Endpunkt, haben eigene Bedingungen, und die MIT-Lizenz sagt darüber nichts. Wer den Agenten weitergibt, sollte außerdem prüfen, ob die mitgelieferten Beispielkonfigurationen Zugangsdaten enthalten; die Anleitung geht davon aus, dass Schlüssel erst nach dem Kopieren eingetragen werden.
Redaktionelles Fazit
Wer einen OpenAI-kompatiblen Endpunkt braucht und die Suchwerkzeuge selbst bereitstellt, findet hier eine schlanke, MIT-lizenzierte Basis mit klarer Zwei-Phasen-Struktur. Wer einen Agenten ohne externen Suchdienst oder mit eigenen, nicht OpenAI-kompatiblen Modellen betreiben will, sollte zuerst die Tool-Schicht und den llm-Block in config.yaml prüfen, bevor er sich auf die Beispielkonfiguration festlegt.
Community-Notizen