Stellen Sie sich das Internet als eine riesige, geschäftige Stadt vor, in der Millionen von winzigen, superintelligenten Robotern (genannt „Agenten“) ständig Besorgungen für uns erledigen. Einige Roboter kaufen Lebensmittel ein, andere genehmigen Rechnungen und einige schreiben sogar Code. Damit diese Roboter zusammenarbeiten können, müssen sie einander finden. In den frühen Tagen des Internets lösten wir ein ähnliches Problem für Menschen: Wir erkannten, dass der Name einer Person (wie „Jane Smith“) etwas anderes sein sollte als ihre aktuelle Adresse (wie „123 Maple Street“). Wenn Jane in ein neues Haus zieht, bleibt ihr Name gleich, aber ihre Adresse ändert sich. Der Postdienst verwendet eine spezielle Karte, um ihr neues Zuhause zu finden, ohne wissen zu müssen, dass sich ihr Name geändert hat.

Heute hat die Roboterstadt einen Fehler. Anstatt den Robotern einen stabilen Namen zu geben, haben wir bisher deren aktuelle „Adresse“ (wie einen spezifischen Web-Link) als ihren Namen verwendet. Wenn ein Roboter auf einen neuen Server oder einen anderen Cloud-Anbieter umzieht, ändert sich seine Adresse, und plötzlich verliert jeder, der mit ihm kommunizieren wollte, die Verbindung. Es ist, als würde sich jedes Mal, wenn Sie in eine neue Wohnung ziehen, Ihr Name gesetzlich in Ihre neue Straßennummer ändern, und alle Ihre Freunde würden vergessen, wer Sie sind. Dieses Paper befasst sich genau mit diesem Problem. Es schlägt eine neue Art vor, diese Roboter zu benennen, damit sie sich um die Welt bewegen können, ohne ihre Identität zu verlieren, und damit andere Roboter sie auch basierend auf dem finden können, was sie tun (wie „Rechnungen genehmigen“), anstatt nur danach, wo sie leben.

Das Problem: Wenn Umzug gleich Vergessen bedeutet

Die Autoren weisen darauf hin, dass aktuelle Systeme einen grundlegenden Fehler machen: Sie koppeln die Identität eines Roboters direkt an seinen Standort. Stellen Sie sich einen Roboter namens „Invoice-Approver“ vor, der unter https://agents.acme.com/approver lebt. Wenn das Unternehmen seine Server zu einem neuen Cloud-Anbieter umzieht, ändert sich der Link. Plötzlich bricht jeder Workflow, jeder Vertrag und jedes Protokoll, das auf diesen alten Link verwies, ab. Der Roboter ist immer noch da, aber er ist nun ein Fremder, weil sein „Name“ (der Link) sich geändert hat.

Darüber hinaus hat ein Roboter derzeit keine Möglichkeit, nach einem Spezialisten zu fragen – zum Beispiel nach jemandem, der „Hazmat-Versandangebote“ bearbeiten kann –, wenn er über verschiedene Unternehmen hinweg fragt: „Wer kann das tun?“ Er kann nur fragen: „Ist der Roboter unter diesem spezifischen Link verfügbar?“ Dies macht das gesamte System fragil und schwer skalierbar.

Die Lösung: Ein neues ID-Karten-System

Das Paper führt ein neues Benennungsschema namens agent:// ein. Betrachten Sie dies als eine neue Art von ID-Karte für Roboter, die drei Dinge trennt: Wer sie sind, Was sie tun und Wo sie sind.

1. Die Vertrauenswurzel (Die ausstellende Behörde): Dies ist die Organisation, die für den Roboter bürgt, ähnlich wie eine Regierung, die einen Reisepass ausstellt. In dem neuen System wird dies als Domain-Name geschrieben (z. B. acme.com). Es sagt Ihnen, wer für den Roboter verantwortlich ist.
2. Der Capability Path (Die Stellenbeschreibung): Dieser beschreibt genau, was der Roboter tut, unter Verwendung eines hierarchischen Pfades wie /workflow/approval/invoice. Dies ist das „Fähigkeitsprofil“ des Roboters. Entscheidend ist, dass die Identität des Roboters an diesen Pfad gebunden ist. Wenn ein Roboter seinen Job ändert (z. B. von der Genehmigung von Rechnungen zur Genehmigung von Ausgaben), erhält er eine neue ID, da er effektiv ein anderer Arbeiter mit einer anderen Identität ist.
3. Die Agent-ID (Die eindeutige Seriennummer): Dies ist ein eindeutiger Code, der für immer gleich bleibt, aber nur, solange der Roboter denselben Job und dieselbe Organisation behält. Wenn der Roboter auf einen neuen Server umzieht, bleibt dieser Code gleich. Wenn er seinen Job-Pfad oder seine ausstellende Organisation ändert, ändert sich dieser Code, um die neue Identität widerzuspiegeln.

Die vollständige ID sieht so aus: agent://acme.com/workflow/approval/invoice/agent_01h.... Beachten Sie, dass die eigentliche Serveradresse (wie https://agents.acme.com) nicht in der ID enthalten ist. Die ID ist lediglich ein Name.

Wie es funktioniert: Das magische Telefonbuch

Wie findet man also einen Roboter, wenn man dessen Adresse nicht kennt? Das Paper schlägt die Verwendung eines dezentralen „Telefonbuchs“ vor, das als DHT (Distributed Hash Table) bezeichnet wird. Anstatt einer einzigen riesigen Liste in einem zentralen Büro ist dieses Telefonbuch auf tausende Computer verteilt.

• Suche nach Fähigkeiten: Wenn Sie einen Agenten suchen, der „Rechnungen genehmigen“ kann, suchen Sie nicht nach einer spezifischen Adresse. Sie suchen im Telefonbuch nach dem Skill-Pfad /workflow/approval/invoice. Das System berechnet einen speziellen Schlüssel basierend auf der Organisation (acme.com) und der Fähigkeit und fragt dann das Netzwerk: „Wer besitzt diesen Schlüssel?“
• Das Ergebnis: Das Netzwerk liefert eine Liste von Robotern zurück, die diese Fähigkeit besitzen. Entscheidend ist, dass das System ein digitales „Siegel“ (ein kryptografisches Token) prüft, um sicherzustellen, dass der Roboter tatsächlich das Recht hat, zu behaupten, diese Aufgabe ausführen zu können.
• Bewegen ohne Unterbrechung: Wenn der Roboter auf einen neuen Server umzieht, aktualisiert er einfach seinen Standort im Telefonbuch. Seine ID (agent://...) bleibt exakt dieselbe. Wer ihn aufruft, findet ihn weiterhin, da sich der Name nie geändert hat.

Was die Autoren herausgefunden haben

Das Team hat diese Idee getestet, um zu sehen, ob sie in der realen Welt tatsächlich funktioniert.

• Kann es alles benennen? Sie haben 369 reale Werkzeuge aus populären Roboter-Frameworks (wie LangChain und CrewAI) genommen und versucht, sie diesem neuen System zuzuordnen. Das Ergebnis? 100 % Abdeckung. Jedes einzelne Werkzeug konnte mit ihrer neuen Grammatik einen eindeutigen, kollisionsfreien Namen erhalten.
• Funktioniert die Suche? Sie simulierten ein Netzwerk mit 10.000 registrierten Robotern. Als sie nach Agenten mit bestimmten Fähigkeiten fragten, fand das System jedes Mal genau die richtigen. Bei breiten Suchen (wie „finde jeden Workflow-Agenten“) lieferte es im Durchschnitt 128 Agenten zurück. Bei spezifischen Suchen wurden etwa 39 gefunden.
• Ist es schnell? Die Mathematik hinter den Namen ist unglaublich schnell. Das Parsen eines Namens und das Finden des richtigen Schlüssels dauert weniger als 7 Mikrosekunden. Das ist so schnell, dass es im Vergleich zur Zeit, die Daten über das Internet benötigen, praktisch instantan ist.
• Ist es sicher? Das System verwendet digitale Signaturen (PASETO-Token), die von der Organisation ausgestellt werden. Das bedeutet, dass Sie nicht dem Wort des Roboters vertrauen müssen, sondern der Organisation, die die ID signiert hat. Wenn ein Roboter über seine Fähigkeiten lügt, stimmt die Signatur nicht überein und das System weist ihn ab.

Was es nicht tut (Und was noch unbekannt ist)

Das Paper ist vorsichtig darin, zu sagen, was es nicht ist. Es löst nicht das Problem, wie man Menschen dazu bringt, die DHT-Knoten (die Computer, die die Liste speichern) zu betreiben. Die Autoren schlagen vor, dass Organisationen dies tun könnten, weil sie wollen, dass ihre eigenen Roboter gefunden werden, oder dass sie ein „Tit-for-Tat“-System nutzen könnten, bei dem man hilft, um selbst Hilfe zu erhalten. Aber sie geben zu, dass dieser Teil noch mehr Arbeit erfordert.

Sie merken auch an, dass das System zwar verschiedene Organisationen gut handhabt, aber nicht automatisch weiß, dass „Genehmigung von Rechnungen“ bei Firma A dasselbe ist wie „Autorisierung von Käufen“ bei Firma B. Dies erfordert einen separaten Mapping-Dienst, den sie als zukünftige Idee vorschlagen.

Das große Ganze

Die Autoren behaupten nicht, die endgültige, perfekte Roboterstadt gebaut zu haben. Stattdessen haben sie das Fundament repariert. Indem sie den Namen eines Roboters von seiner Adresse trennen, haben sie ein System geschaffen, in dem Roboter sich bewegen, skalieren und über verschiedene Unternehmen hinweg zusammenarbeiten können, ohne die Verbindungen zu unterbrechen, die sie zusammenhalten. Es ist ein wenig so, als würde man jedem Roboter einen permanenten Reisepass statt eines temporären Adressetiketts geben, um sicherzustellen, dass er, egal wohin er geht, immer dieselbe Person bleibt.