Zum Hauptinhalt springen

Goose Architektur und Laufzeit

1. Die Workspace-Struktur​

Das Repo-Layout erzählt eine klare Geschichte:

BereichZweck
crates/Rust-Laufzeit und Kernbibliotheken
ui/Arbeit an der Desktop-Benutzeroberfläche
documentation/Produkt- und Beitragenden-Doku
examples/Referenz-Nutzungsmuster
workflow_recipes/Wiederholbare Agent-Workflows auf höherer Ebene
oidc-proxy/ und ServicesUnterstĂĽtzende Infrastruktur fĂĽr Auth- und Embedding-Szenarien

Das ist ein größerer Workspace als eine Single-Binary-Coding-CLI, aber immer noch klein genug, um sich gezielt zurechtzufinden.

2. Die drei Laufzeit-Oberflächen​

Goose stellt bewusst einen Agenten über mehrere Oberflächen bereit:

  • Desktop-App
  • CLI
  • API

Diese architektonische Entscheidung ist wichtig, weil sie die Kern-Laufzeit dazu drängt, wiederverwendbar zu bleiben, statt das gesamte Verhalten in eine UI zu backen.

3. Provider und Erweiterungen sind zentral, nicht optional​

Die offizielle Doku behandelt Provider-UnterstĂĽtzung und Erweiterungen als Kern-Produktbereiche. Das bedeutet, dass die reale Goose-Architektur nicht nur Folgendes ist:

Modell plus Terminal

Sie liegt näher an:

Agent-Kern plus Provider-Abstraktion plus Erweiterungs-Laufzeit

Deshalb kann das Projekt viele Provider, lokale Modell-Runner und MCP-basierte Fähigkeiten unterstützen, ohne zu einem anbieter-gebundenen Tool zu werden.

4. Workflow-Recipes sind wichtig​

Das Verzeichnis workflow_recipes/ ist ein nützlicher Hinweis auf die Projektrichtung. Goose versucht nicht nur, Prompts zu beantworten; es versucht auch, wiederholbare Agent-Workflows zu paketieren, die wiederverwendet und geteilt werden können.

FĂĽr viele Teams ist das der Punkt, an dem Goose wertvoller wird als ein einfacher Chat-Assistent.

5. Wie du die Codebase liest​

Beginne in dieser Reihenfolge:

  1. README.md,
  2. Provider-Doku,
  3. crates/,
  4. ui/,
  5. Recipes und Embedding-Oberflächen, sobald die Kernschleife klar ist.