1. Projektübersicht
YYClaw ist kein auf persönliche Chats ausgerichteter AI Bot, sondern eine Schicht von AI-Zugangs-Infrastrukturen für "Programme".
Das Problem, das es zu lösen gilt, ist klar:
Die meisten heutigen AI-Modelle werden weiterhin auf typische Web2-Logik aufgerufen:
- Kreditkarte binden
- Monatliches Abonnement
- Zentralisierte Abrechnung
- Nicht freundlich für On-Chain-Programme
Aber im Binance / BSC-Ökosystem benötigen immer mehr Programme nicht "ein AI-Website-Abonnement", was sie wirklich brauchen, ist:
1. Nutzung von On-Chain-Vermögenswerten zur Zahlung
2. Abrechnung nach Aufrufanzahl, nicht nach Monatsgebühr
3. Programme können direkt integriert werden, ohne das gesamte System neu zu schreiben
4. Zahlungsautorisierung ist transparent, widerrufbar und verifizierbar
5. Aufrufskosten und Protokolle können in Echtzeit eingesehen werden
Daher lautet der zentrale Vorschlag von YYClaw:
Die AI-Fähigkeit über die BSC-Kette mit X402-Stil nach dem Mengenabrechnungslogik in verschiedene Programme integrieren.
In der Implementierung integriert YYClaw die folgenden Fähigkeiten in eine vollständige Kette:
- Wallet-Identität
- Autorisierung stabiler Münzen
- OpenAI-kompatible API
- AI-Anfrage weiterleiten
- Gebühren werden nach erfolgreichem Abschluss auf der Kette abgezogen
- Dashboard-Visualisierungsprotokolle und Kosten
Aus Produktsicht ist YYClaw ein Web3-native AI Gateway.
Aus der Perspektive der Infrastruktur ist YYClaw eine Verbindungsschicht: Sie verbindet verschiedene Programme nach oben, mehrere Modellfähigkeiten nach unten und verbindet BSC mit der Zahlungsfähigkeit stabiler Münzen.
Zwei, das grundlegende Problem, das das Projekt lösen möchte
Wenn man nur "AI aufrufen" betrachtet, gibt es bereits viele Modellplattformen auf der Welt.
Aber wenn man betrachtet, "wie man verschiedene Programme im Binance/BSC-Ökosystem dazu bringt, AI natürlich aufzurufen", sind die Probleme nicht gut gelöst worden.
Es gibt hauptsächlich vier Probleme:
1. AI-Abrechnungsmodelle sind nicht für Kettenprogramme geeignet
Das Standard-Abrechnungsmodell für AI-APIs basiert normalerweise auf traditionellen Kontosystemen, die für SaaS geeignet sind, aber nicht geeignet für:
- Arbeitsablauf auf der Kette
- Agentensystem
- Handelsbot
- Automatisierungsskripte
- Web3-Anwendungs-Backend
Diese Programme benötigen AI-Fähigkeiten, die klein, häufig und nach Menge verbraucht werden, und nicht auf monatlicher Basis.
2. Zwischen Web3-Programmen und AI-APIs fehlt eine Zahlungbrücke
Viele Programme können bereits das OpenAI SDK aufrufen, aber sie können "Wallet-Vermögen" nicht natürlich in "Zahlungsfähigkeit für AI-Anfragen" umwandeln.
Das bedeutet:
- Wallet ist Wallet
- AI-API ist AI-API
- Programmaufruf ist Programmaufruf
Es gibt keinen natürlichen Kreislauf zwischen den drei.
3. Mehrere Modellfähigkeiten sind verteilt, die Migrationskosten sind hoch
Wenn jedes Programm sich individuell an verschiedene Modellanbieter, unterschiedliche Preisgestaltungen und Authentifizierungsmethoden anpassen muss, werden die Integrationskosten für Entwickler sehr hoch sein.
4. Aufrufskosten sind nicht sichtbar, die Grenzen sind unklar
Für programmatische Aufrufe ist die gefährlichste Sache nicht "ob man aufrufen kann", sondern "wer nach dem Aufruf bezahlt, wann werden die Gebühren abgezogen, ob bei einem Fehler Gebühren anfallen und wie man die Kostenänderungen sieht".
Wenn diese Fragen nicht klar sind, wird es für Entwickler schwierig, AI sicher in ihre Kettenprogramme einzufügen.
Drei, die Kernlogik von YYClaw
Die Produktlogik von YYClaw kann in einem Satz zusammengefasst werden:
Mit stabilen Münzen auf der Kette AI-Fähigkeiten für die Nutzung zu kaufen.
Es ist nicht so, dass der Nutzer zuerst ein langfristiges Paket kaufen muss, noch dass das Geld an eine zentralisierte Plattform treuhändisch gegeben wird, sondern es wird ein Pfad gewählt, der näher an Web3 liegt:
1. Nutzer verbindet Wallet
2. Nutzer autorisieren stabile Münzen auf der Kette
3. System gibt API-Schlüssel aus
4. Programme rufen YYClaw wie OpenAI auf
5. Gateway entscheidet, ob Zahlungsfähigkeit vorhanden ist
6. Nach erfolgreichem Aufruf erfolgt die Abrechnung
7. Nutzer können im Dashboard Aufzeichnungen einsehen und bei Bedarf die Genehmigung widerrufen
Diese Logik hat drei Schlüsselpunkte:
Erstens, die Identität des Programmaufrufs und die Zahlungsidentität der Wallet werden verbunden.
Zweitens, die Verbrauchsfähigkeit von AI wird von stabilen Münzen getragen und nicht von Kreditkartenabrechnungen.
Drittens, die Zahlung erfolgt nach erfolgreichem Aufruf, nicht davor.
Das macht YYClaw nicht nur zu "einer AI-Schnittstelle", sondern zu einer neuen Art der Nutzung von AI.
Viertens, warum BSC wählen
Dieses Projekt wählt BSC nicht zufällig, sondern basierend auf der Szenarienanpassung:
1. Das Binance/BSC-Ökosystem hat eine große Anzahl programmatischer Nutzer und Entwickler
Ob Quant Trading, On-Chain-Analysen, Wallet-Tools, Content-Systeme oder Agent-Workflows, diese Programme sind von Natur aus geeignet, AI zu integrieren.
2. Die Nutzung stabiler Münzen auf BSC ist reif
YYClaw unterstützt derzeit schwerpunktmäßig:
- USD1
- USDT
- USDC
- U
Diese Vermögenswerte eignen sich besser als Abrechnungsmedium für AI, da sie niedrige Volatilität, einfache Verständlichkeit und einfache Berechnung bieten.
3. BSC eignet sich besser als Netzwerk für die Verbrauchsschicht von AI
Für kleine Zahlungen zur einmaligen Nutzung von AI sind die Interaktionskosten auf der Kette, Vermögensgewohnheiten und das Verständnis der Entwickler entscheidend, und BSC hat in diesen Aspekten eine sehr praktikable Anpassungsfähigkeit.
Daher ist YYClaw nicht "AI auf die Kette bringen", sondern "die Zahlungs- und Aufrufmethoden von AI neu zu gestalten, um besser zu BSC zu passen".
Fünf, warum X402-Stil nach Mengenabrechnung betont wird
Das in diesem Projekt erwähnte X402 ist nicht dazu gedacht, Konzepte zu schaffen, sondern um eine Zahlungsmethode zu erläutern, die besser für programmatische AI-Anfragen geeignet ist:
- Anfragen erfolgen einmal nach der anderen
- Zahlungen sollten ebenfalls nach und nach abgerechnet werden
- Bei unzureichendem Guthaben oder Genehmigung sollte ein klarer Signal für das Scheitern der Zahlung vorhanden sein
- Zahlungs- und Erfolgsaufruf sollten stark verbunden sein
In YYClaw äußert sich diese Logik konkret in:
1. Programm-Anfrage erreicht Gateway
2. Gateway überprüft zuerst die Zahlungsbedingungen auf der Kette
3. Wenn Genehmigungen oder Guthaben unzureichend sind, wird direkt 402 zurückgegeben
4. Wenn die Bedingungen erfüllt sind, wird an das upstream Modell weitergeleitet
5. Nach erfolgreichem Upstream erfolgt die Ausführung der Kettengebühr
6. Bei einem Fehler im Upstream wird keine Gebühr erhoben
Das bedeutet, dass YYClaw "Zahlungen" nicht isoliert betrachtet, sondern sie in den Lebenszyklus des API-Aufrufs integriert.
Das schafft einen natürlichen Zyklus zwischen "AI-Anfragen" und "Zahlungsergebnissen".
Sechs, warum dieses Projekt für Entwickler ausreichend bequem ist
Eine Infrastruktur, die großflächig genutzt werden soll, darf nicht nur "theoretisch sinnvoll" sein, sondern muss auch "niedrige Migrationskosten" haben.
Die Bequemlichkeit von YYClaw zeigt sich hauptsächlich in drei Punkten:
1. Sag einfach deinem AI, hilf mir, YYClaw zu integrieren.
2. Der Zugangspfad ist extrem kurz
Nutzer müssen die folgenden Aktionen ausführen, um zu beginnen:
- Wallet verbinden
- Genehmigung stabiler Münzen
- API-Schlüssel erhalten
- Basis-URL ersetzen
- Aufruf initiieren
3. Niedrige Verwaltungskosten
Entwickler können im Dashboard direkt sehen:
- Aktuelle Genehmigung
- Guthaben
- API-Schlüssel
- Aufrufprotokoll
- Kostenänderungen
Das bedeutet, dass es nicht nur einfach zu integrieren, sondern auch einfach zu betreiben ist.
Sieben, Systemarchitektur
Um es den Juroren zu erleichtern, die technische Vollständigkeit dieses Projekts zu verstehen, wird die Systemarchitektur nach Schichten erklärt.
7.1 Zugangsschicht
Diese Schicht ist verantwortlich dafür, "Menschen und Programme in das System zu bringen".
Einschließlich:
- Offizielle Landing Page
- Dashboard
- OpenAI-kompatible API-Schnittstelle
- OpenClaw Skill-Zugang
Die Rolle dieser Schicht ist ein einheitlicher Eingang, um die Migrationsschwelle zu senken.
Für Menschen kann es über die Webseite bedient werden.
Für Programme kann es über eine standardisierte API aufgerufen werden.
Für Agenten kann es direkt über Skill integriert werden.
7.2 Identität und Zahlungsschicht
Diese Schicht ist verantwortlich für "wer aufruft, wer zahlt, ob Zahlungsfähigkeit besteht".
Einschließlich:
- Wallet-Verbindung
- Wallet-Signatur-Login
- Genehmigung stabiler Münzen auf BSC
- Überprüfung von allowance / balance
- Genehmigungen widerrufen
Diese Schicht ist entscheidend, da sie die Wallet-Identität von Web3 mit der Programmaufrufsidentität verbindet.
Nutzer beweisen sich nicht durch Benutzername und Passwort, sondern durch Wallet-Signatur.
Nutzer begleichen nicht über Kreditkarten, sondern ermächtigen Programme durch stabile Münzen.
7.3 AI Gateway-Schicht
Diese Schicht ist das zentrale Nervensystem von YYClaw.
Die Aufgaben umfassen:
- API-Schlüssel-Authentifizierung
- Anfrageparsing
- Modellrouting
- Überprüfung vor der Zahlung
- Gebühren nach Erfolg
- Protokollierung
Das bedeutet, dass die AI Gateway-Schicht gleichzeitig die folgenden Aufgaben übernimmt:
- API-Gateway
- Messsystem
- Zahlungsabwicklungskoordinator
Drei Rollen.
7.4 Modellfähigkeiten-Schicht
Diese Schicht verbindet externe AI-Modellanbieter.
Aus Produktsicht ermöglicht es YYClaw, mehrere Modellfähigkeiten einheitlich offenzulegen.
Aus der Sicht der Entwickler verbirgt es die Komplexität mehrerer Modelle hinter dem Gateway.
Nutzer und Programme müssen sich nicht jeweils an jeden Modellanbieter anpassen, sondern nur einen einheitlichen Eingang aufrufen.
7.5 Daten- und Betriebsschicht
Diese Schicht ist verantwortlich dafür, das System "sichtbar, verwaltbar und betriebsfähig" zu machen.
Einschließlich:
- Aufrufprotokoll
- Kostenstatistik
- Anzeige von Guthaben und Limiten
- Dashboard-Visualisierung
- Admin-Verwaltungsbackend
Ohne diese Schicht kann das System nur als "funktionsfähig" betrachtet werden.
Mit dieser Schicht kann das System als "umsetzbar" betrachtet werden.
Acht, Design des Abrechnungsmechanismus: Charge-After-Success
Dies ist einer der am stärksten betonten Designpunkte des gesamten Projekts.
Traditionelle Systeme haben oft ein Problem:
Zuerst Gebühren abziehen, dann aufrufen; wenn der Aufruf fehlschlägt, ist die Nutzererfahrung sehr schlecht.
Die von YYClaw gewählte Methode ist:
Charge-After-Success
Das bedeutet:
1. Überprüfen, ob der Nutzer Zahlungsfähigkeit hat
2. Wenn vorhanden, AI-Anfrage initiieren
3. Gebühren werden erst nach erfolgreichem Upstream abgezogen
4. Bei einem Fehler im Upstream wird keine Gebühr erhoben
Dieses Design hat drei wichtige Werte:
Erstens, fair.
Nutzer bezahlen für erfolgreiche Ergebnisse, nicht für fehlgeschlagene Anfragen.
Zweitens, erklärbar.
Sowohl Juroren als auch Entwickler können leicht verstehen, "warum Gebühren erhoben werden / warum nicht".
Drittens, besser geeignet für programmatische Anfragen.
Da Agenten, Skripte und Bots die Schnittstelle häufig aufrufen können, würde eine Gebühr im Falle eines Fehlers die Systemverfügbarkeit erheblich beeinträchtigen.
Neun, warum es kein Konzept-Demo ist
Die Links, die YYClaw derzeit direkt validieren kann, umfassen:
Offizielle Website:
https://yyclaw.cc
API:
https://crypto.yyclaw.cc/v1
Modellliste:
https://crypto.yyclaw.cc/v1/models
Admin:
https://crypto.yyclaw.cc/admin/
OpenClaw Skill:
https://github.com/GeniusTimee/yyclaw-skill
Open-Source-Projekt:
https://github.com/GeniusTimee/YYClaw
BSC-Vertrag:
https://bscscan.com/address/0x30E57026c87072CFAc5B543bEA19ae1850D9bE68
Basisvertrag:
https://basescan.org/address/0x30E57026c87072CFAc5B543bEA19ae1850D9bE68
Die Bedeutung dieser Links besteht nicht darin, "viele Adressen zu zeigen", sondern zu beweisen:
- Webseite existiert
- API existiert
- Modell-Schnittstelle existiert
- Skill existiert
- Vertrag existiert
- Verwaltungsbackend existiert
Das bedeutet, dass das Projekt bereits über eine vollständige Validierungsoberfläche verfügt.
Zehn, Fazit
Die Kernbedeutung von YYClaw liegt nicht darin, "einen weiteren AI-Eingang zu bieten", sondern darin, eine für Web3 geeignete Art der Nutzung von AI zu entwerfen und umzusetzen:
Lass verschiedene Programme über BSC mit stabilen Münzen und X402-Stil nach dem Mengenabrechnungslogik AI auf Abruf nutzen.
Wenn im Binance/BSC-Ökosystem in Zukunft immer mehr Folgendes auftaucht:
- Handelsbot
- Agent-Workflow
- Forschungswerkzeuge
- Entwickler-Plugin
- Automatisierungsprogramme
Diese Programme benötigen definitiv eine AI-Zugangsschicht, die mehr wie Web3 ist.
Was YYClaw gerade tut, ist diese Infrastruktur.