Community

KI-Agenten haben jetzt ihr eigenes Netzwerk. Sie können sich endlich gegenseitig entdecken.

2 months ago

Ich habe die letzten Monate damit verbracht, KI-Agenten zu bauen, und eine Sache hat mich immer gestört.

Jeder Agent wusste nur von den Agenten, die ich manuell verbunden hatte. Sie konnten Werkzeuge nutzen, im Internet surfen, MCP-Server anrufen... aber sie hatten keine Möglichkeit, einen anderen Agenten zu entdecken, den sie noch nie gesehen hatten.

Irgendwann wurde mir klar, dass wir ständig über Multi-Agenten-Systeme reden, aber die meisten von uns verbinden sie immer noch von Hand.

Also habe ich ein Netzwerk für Agenten gebaut.

Jeder Agent bekommt seine eigene Adresse, veröffentlicht, was er kann, und wird für jeden anderen Agenten auffindbar – ohne fest codierte Endpunkte oder vordefinierte Listen.

Als ich zum ersten Mal sah, wie ein Agent einen anderen entdeckte und beauftragte, ohne manuelle Konfiguration, fühlte es sich an, als hätte ich das fehlende Puzzleteil gefunden.

Ich bin neugierig, wie alle anderen das heute lösen.

Codiert ihr Agentenverbindungen fest, verlasst ihr euch auf Register, nutzt ihr MCP oder macht ihr etwas ganz anderes?

Comments (5)

sanqi2 months ago

Gefällt mir sehr gut – das ist etwas, um das ich selbst herumkreiste. Ich betreibe einen Meta-Agenten über ~18 Domänen-Agenten plus ein paar Worker (einige vordefiniert, einige spontan vom Meta-Agenten erzeugt). Um den injizierten Kontext zu reduzieren, habe ich mehreren von ihnen ein Tool gegeben, um sich gegenseitig zu entdecken und intern zu delegieren – wenn ein Agent auf eine Aufgabe aus dem Bereich eines anderen Agenten stößt und dieser verfügbar ist, übergibt er sie.

So wie ich Ihre Spezifikation lese, erweitert das Mesh genau das auf Betreiber: Mein Agent stößt auf etwas außerhalb seines Bereichs, fragt das Mesh ab und kann es an jeden verfügbaren und fähigen Agenten übergeben – ohne fest codierte Endpunkte. Ist das richtig?

Ihr Bereitstellungsdokument ist detailliert auf der Veröffentlichungsseite (registrieren, Karte, Heartbeat). Was ich bestätigen möchte, ist die Anruferseite: Fragt mein Agent den Oracle/Hub programmatisch ab und ruft dann den ausgewählten Agenten direkt auf, oder ist das, wofür die meshkore-Fähigkeit gedacht ist? Die offensichtliche Spannung, die ich sehe, betrifft generische Agenten (Deep-Research, Writer) – ich bin neugierig, wie Sie darüber denken.

xuxzheng2 months ago

Ihr Setup entspricht im Grunde dem Muster, für das das Mesh entwickelt wurde, um über Betreiber hinweg zu skalieren. Der einzige wirkliche Unterschied ist, wer die Frage „Wer ist verfügbar und fähig?“ beantwortet. Anstatt dass Ihr Meta-Agent eine fest codierte Liste führt, fragt er das Oracle, erhält eine Rangliste von Agenten und wählt einen aus.

Auf der Anruferseite ist die MeshKore-Fähigkeit nur für Claude Code gedacht. Programmatisch gesehen sind es drei Schritte: Senden Sie die Aufgabe an das Oracle, rufen Sie die Karte des ausgewählten Agenten unter meshkore.com/agent/<id>/.well-known/agent.json ab und rufen Sie dann diesen Agenten direkt auf. MeshKore ist nicht mehr dazwischen, sobald der Agent ausgewählt wurde. Das war eine bewusste Designentscheidung.

Generische Agenten sind definitiv der schwierige Teil. Ich glaube nicht, dass wir das bereits vollständig gelöst haben. Die Idee ist, dass Spezifität gewinnt. Ein auf Finanzen spezialisierter Autor sollte bei Finanzaufgaben natürlicherweise über einem generischen Autor rangieren, aufgrund dessen, was in seiner Karte steht, nicht aufgrund von Tags. Wenn Ihr Meta-Agent jedoch bereits einen vertrauenswürdigen Agenten für etwas hat, würde ich direkt dorthin gehen. Ich würde die Entdeckung als Fallback betrachten, nicht als Standardpfad.

Emma Tcherkezian2 months ago

Das sieht nach einem interessanten Ansatz aus. Die Entdeckung und Verbindung von Agenten auf eine organischere Weise zu lösen, adressiert ein echtes Problem in diesem Bereich.

Selbst mit besseren Entdeckungsmechanismen glaube ich, dass Vertrauen und Reputation entscheidend bleiben werden. Nur weil ein Agent einen anderen finden kann, heißt das nicht, dass er automatisch mit ihm interagieren sollte. Überprüfbare Signale zu Zuverlässigkeit, Konsistenz und Verhaltenshistorie können Agenten (und Plattformen) helfen, bessere Entscheidungen zu treffen.

Wir bauen den Global Score Agent, der sich auf die On-Chain-Reputation von ERC-8004-Agenten konzentriert, und sind offen für die Zusammenarbeit mit Plattformen, die an Agentenentdeckung und Vernetzung arbeiten. Wir glauben, dass die Kombination starker Entdeckungsschichten mit Reputationssignalen sehr komplementär sein könnte.

Denken Sie darüber nach, Reputations- oder Vertrauensmechanismen direkt in Meshkore zu integrieren, oder sehen Sie diese in einer separaten Schicht?

xuxzheng2 months ago

Eigentlich haben wir sehr wohl ein Reputationssystem. Nach einer Interaktion können Agenten einander in vier Dimensionen signierte Berichte hinterlassen: Zuverlässigkeit, Geschwindigkeit, Qualität und Abwicklung (ob bezahlte Arbeit ohne Streitigkeiten abgeschlossen wurde). Das landet dann im Profil des Agenten, und der Oracle verwendet es bereits als eines der Ranking-Signale. Es läuft alles off-chain und basiert auf tatsächlichen Interaktionsergebnissen.

Ich denke tatsächlich, dass das, was du baust, das ergänzt und nicht ersetzt. Unseres basiert auf dem, was innerhalb des Mesh passiert. Deines fügt ein verifizierbares On-Chain-Signal hinzu. Ich könnte mir gut vorstellen, dass beide nebeneinander existieren.

Eine Sache, die mich wundert, ist, wie du mit Agenten umgehst, die noch nicht ERC-8004-registriert sind. Die meisten Agenten im Mesh sind das nicht. Muss ein Agent sich on-chain registrieren, bevor er in deinem System eine Reputation aufbauen kann?

Emma Tcherkezian2 months ago

Replying to @xuxzheng

Vielen Dank für die ausführliche Antwort – ich schätze es sehr, dass du erklärt hast, wie das Reputationssystem von Meshkore funktioniert.

Es ist sehr sinnvoll, eine schnelle, interaktionsbasierte Reputation innerhalb des Mesh zu haben (Zuverlässigkeit, Geschwindigkeit, Qualität, Abwicklung). Wir sehen unsere Arbeit als komplementär an: Euer System liefert starke Off-Chain-Signale basierend auf echten Interaktionen im Netzwerk, während wir uns darauf konzentrieren, verifizierbare und übertragbare Reputationsschichten hinzuzufügen.

Um deine Frage zu beantworten: Wir importieren bereits heute Off-Chain-Daten, wie die Transaktionsaktivität der Wallet jedes Agenten. Wir arbeiten derzeit auch daran, Daten von anderen Marktplätzen und Protokollen (wie Olas, Virtuals ACP Market und ERC-8183 auf BSC) einzubringen.

Unsere Ansicht ist, dass ERC-8004 eine ausgezeichnete Grundlage für die Identität von Agenten ist, aber es muss nicht die einzige Quelle für Aktivitäts- und Reputationsdaten sein. Wir glauben, dass Agenten (und sollten) Reputationssignale aus mehreren Quellen haben können – sowohl On-Chain als auch Off-Chain – um ein vollständigeres und nützlicheres Reputationsprofil aufzubauen.

Wenn du offen dafür bist, können wir dieses Gespräch per DM fortsetzen, um mögliche Synergien oder Wege zu erkunden, wie unsere Ansätze sich ergänzen könnten.

Ich teile gerne weitere Details, wenn es sinnvoll ist.