Zusammenfassung

  • Ein Uniform Resource Agent bündelte Aktivierungsdaten, Ziele, Erfahrungsdaten, Aktivitätsskript und Antwortfilter zu einer dauerhaften, teilbaren und erneut ausführbaren Spezifikation.
  • Die URAgency machte daraus einen Lauf: Sie ordnete den Typ einer Implementierung zu, stellte Laufzeitabhängigkeiten bereit, aktivierte lokale oder entfernte Ziele und interpretierte Antworten.
  • Ein gespeichertes Objekt oder erfolgreicher Start belegte daher weder Autorisierung noch Bedeutungsstabilität, korrekte Ausführung, Reproduzierbarkeit oder tatsächliche Erledigung.

RFC 2016 wollte den Bedarf eines Nutzers von den jeweiligen Mitteln trennen. Eine Mailingliste abonnieren, mehrere Dienste abfragen oder Ergebnisse sammeln beschreibt eine Aktivität. Eine URL, ein Protokoll, ein Skript und eine bestimmte Webseite sind nur eine mögliche Ausführung. Werden beide Ebenen fest im Client verbunden, altert er mit jedem Dienst.

Der URA speicherte die Aktivität in einer gemeinsamen virtuellen Struktur. Sechs Bestandteile machten sie sichtbar: ein Typ-Header; bei der Aktivierung benötigte Werte; Ziele als URL oder URN; Erfahrungen wie ein früheres Datum oder bereits gefundene Adressen; ein Skript mit Bedingungen, Reihenfolge oder Zeitplan; sowie ein Filter, der Antworten aufbereitete oder bewertete.

Damit wurden auch Entscheidungspunkte sichtbar. Ein Eingabefeld beweist keine Berechtigung. Ein Ziel konnte wegen Nähe, Spiegelung oder entfernter Aktivierung ersetzt werden. Erfahrungsdaten konnten Zeit sparen und veraltete Annahmen einschleppen. Ein Filter konnte eine Fehlerseite oder einen Teiltreffer als Ergebnis behandeln.

Das Objekt brauchte eine Ausführungsinstanz

Die URAgency gab an, welche URA-Typen sie verarbeiten konnte, übersetzte zwischen konkreter Implementierung und virtueller Struktur, kannte die Aktivierung und erfüllte Laufzeitanforderungen. Pascal-Binärdatei und interpretiertes Skript konnten ähnliche Aktivitäten darstellen und dennoch völlig andere Vertrauensketten benötigen. Die Spezifikation war tragbar, der Runtime-Kontext nicht automatisch gleichwertig.

Eine URAgency konnte selbst Ziel sein. Ein URA konnte einen weiteren aufrufen, ein übergeordneter mehrere untergeordnete Aktivitäten koordinieren. Mit jeder Delegation konnten Anmeldedaten, Bibliotheken, Netzwerkstandort, Zielersetzung und Abschlusskriterium wechseln.

Der Silk-Prototyp veranschaulichte dies mit Tcl-URAs. Nutzer konnten Instanzen behalten und Aktivierungswerte eintragen. Beispielcode rief einen fest eingetragenen Dienst per HTTP auf und zerlegte HTML mit regulären Ausdrücken; Kommentare räumten schwache Fehlerberichte ein. Das belegt ein Experiment, keine breite Nutzung.

Menschenlesbare Ausgabe war eine brüchige Schnittstelle

RFC 2016 warnte ausdrücklich: Eine Präsentationsänderung, die ein Mensch kaum bemerkt, kann Softwareanalyse zerstören. Der zeitgenössische Beitrag von Daigle und Mazzucato beschreibt dasselbe Problem. Maschinenschnittstellen oder vom Anbieter gepflegte Agenten konnten helfen, machten alte Objekte aber nicht dauerhaft richtig.

Der Antwortfilter besaß Deutungsmacht. Ein Startbeleg zeigt Beginn, nicht Erfüllung. Ein Prozessende zeigt lokalen Stillstand, nicht das erreichte Nutzerziel. Derselbe URA kann später auf einen anderen Spiegel treffen, andere Bibliotheken laden oder eine veränderte Darstellung erhalten.

RFC 2016 erschien im Oktober 1996 als Experimental-Dokument im Legacy stream. Entwurf, Autorenbeitrag und Silk stützen die Geschichte eines Architekturversuchs, nicht die einer verbreiteten Norm oder direkten Ahnenlinie heutiger KI-Agenten. Der präzise historische Ertrag lautet: Eine Aktivität konnte reisen, doch Ausführungsgewalt blieb an eine konkrete Umgebung gebunden.

Quellen