Ein Freund sagte, dass der anhaltende Rückgang von Web3-AI-Agenten wie #ai16z, $arc durch das kürzlich beliebte MCP-Protokoll verursacht wurde? Auf den ersten Blick war ich etwas verwirrt, WTF hat das damit zu tun? Aber nach einigem Nachdenken fand ich, dass es tatsächlich eine gewisse Logik gibt: Die Bewertungslogik der bestehenden Web3-AI-Agenten hat sich geändert, die Erzählrichtung und Produktimplementierung müssen dringend angepasst werden. Im Folgenden möchte ich meine persönliche Meinung teilen:

1) MCP (Model Context Protocol) ist ein offenes standardisiertes Protokoll, das darauf abzielt, verschiedene AI LLM/Agenten nahtlos mit verschiedenen Datenquellen und Tools zu verbinden, vergleichbar mit einem Plug-and-Play-USB „universellen“ Anschluss, der die bisherigen spezifischen End-to-End-Verpackungen ersetzt.

Einfach gesagt, ursprünglich gab es zwischen den AI-Anwendungen deutliche Dateninseln, und Agenten/LLMs mussten jeweils entsprechende API-Schnittstellen entwickeln, um miteinander zu kommunizieren. Der Prozess ist nicht nur kompliziert, sondern es fehlt auch an bidirektionalen Interaktionsfunktionen, und es gibt normalerweise relativ begrenzten Modellzugang und Berechtigungseinschränkungen.

Das Erscheinen von MCP entspricht der Bereitstellung eines einheitlichen Rahmens, der es AI-Anwendungen ermöglicht, den früheren Zustand von Dateninseln zu entkommen und die Möglichkeit eines „dynamischen“ Zugriffs auf externe Daten und Tools zu realisieren, was die Komplexität der Entwicklung und die Effizienz der Integration erheblich senken kann, insbesondere bei der automatisierten Aufgabenausführung, der Echtzeitdatenabfrage und der plattformübergreifenden Zusammenarbeit. Wenn wir hier sind, denken viele sofort daran, ob die Manus-Integration, die auf die Zusammenarbeit mehrerer Agenten abzielt, das MCP-Open-Source-Framework nicht unschlagbar macht?

Ganz genau, Manus + MCP ist der Schlüssel für den Einfluss auf Web3-AI-Agenten.

2) Aber, es ist unglaublich, dass sowohl Manus als auch MCP auf Web2-LLM/Agenten ausgerichtete Frameworks und Protokollstandards sind, die alle das Problem der Dateninteraktion und -kooperation zwischen zentralisierten Servern lösen. Ihre Berechtigungen und Zugriffskontrollen hängen von der „aktiven“ Öffnung der einzelnen Serverknoten ab, anders gesagt, es ist nur eine Art von Open-Source-Werkzeug.

Eigentlich steht das im völligen Widerspruch zu den zentralen Ideen, die Web3-AI-Agenten verfolgen, wie „verteilte Server, verteilte Zusammenarbeit, verteilte Anreize“ usw. Wie kann eine zentralisierte italienische Kanone die dezentralisierte Festung sprengen?

Der Grund dafür liegt darin, dass die erste Phase der Web3-AI-Agenten zu sehr „web2isiert“ ist. Einerseits stammt dies von vielen Teams, die aus einem Web2-Hintergrund kommen und ein unzureichendes Verständnis der nativen Anforderungen von Web3 haben. Zum Beispiel war das ElizaOS-Framework ursprünglich ein Verpackungsrahmen, der Entwicklern half, AI-Agent-Anwendungen schnell zu implementieren, indem es Twitter, Discord und einige OpenAI-, Claude-, DeepSeek-API-Schnittstellen integrierte und einige generische Rahmen für Memory und Character angemessen verpackte, um Entwicklern zu helfen, AI-Agent-Anwendungen schnell zu entwickeln. Aber wenn man das genau betrachtet, was unterscheidet sich dieses Service-Framework von den Open-Source-Tools von Web2? Welche differenzierenden Vorteile hat es?

Äh, ist der Vorteil also ein Tokenomics-Anreizsystem? Und dann ein Framework, das mit einer Web2-Lösung vollständig ersetzt werden kann, um eine Gruppe von AI-Agenten zu motivieren, die hauptsächlich für die Schaffung neuer Token existieren? Furchtbar... Wenn man dieser Logik folgt, versteht man ungefähr, warum Manus + MCP einen Einfluss auf Web3-AI-Agenten haben können. Da viele Web3-AI-Agenten-Frameworks und -Dienste nur die Bedürfnisse nach schneller Entwicklung und Anwendung von Web2-AI-Agenten abdecken, aber in Bezug auf technische Dienstleistungen, Standards und differenzierte Vorteile nicht mit der Innovationsgeschwindigkeit von Web2 Schritt halten können, hat der Markt/Kapital die letzte Generation von Web3-AI-Agenten neu bewertet und eingepreist.

3) Wenn wir hier sind, haben wir wahrscheinlich das Kernproblem gefunden, aber wie können wir das Problem lösen? Es gibt nur einen Weg: Fokussieren Sie sich auf die Entwicklung von Web3-nativen Lösungen, denn der Betrieb und das Anreizsystem von verteilten Systemen sind der absolut differenzierende Vorteil von Web3.

Nehmen wir als Beispiel verteilte Cloud-Computing-, Daten-, Algorithmus- und andere Dienstleistungsplattformen: Auf den ersten Blick scheint es, dass diese auf der Grundlage ungenutzter Ressourcen aggregierten Rechenleistung und Daten kurzfristig die Bedürfnisse der ingenieurtechnischen Implementierungsinnovationen nicht erfüllen können. Aber in einer Zeit, in der viele AI-LLMs um zentrale Rechenleistung kämpfen, um Leistungsdurchbrüche zu erzielen, wird ein Dienstmodell, das mit „unbenutzten Ressourcen, niedrigen Kosten“ wirbt, die Web2-Entwickler und VC-Gruppen natürlich nicht beeindrucken.

Wenn die Web2-AI-Agenten jedoch die Phase des Leistungsinnovationswettbewerbs hinter sich gelassen haben, werden sie zwangsläufig die Expansion in vertikale Anwendungsszenarien und die Optimierung von Feinabstimmungen des Modells anstreben. Erst dann werden die Vorteile der Web3-AI-Ressourcendienste wirklich sichtbar. Tatsächlich, wenn Web2-AI, die durch Ressourcenmonopol in eine herausragende Position aufgestiegen sind, eine bestimmte Phase erreicht haben, wird es sehr schwierig sein, mit der Philosophie der Umzingelung durch ländliche Gebiete zurückzukehren und nacheinander spezifische Szenarien zu durchbrechen. Dann ist es die Zeit der überzähligen Web2-AI-Entwickler + Web3-AI-Ressourcen, die zusammenarbeiten.

Deshalb ist der Chancenraum der Web3-AI-Agenten jetzt auch sehr klar: Vor den überschüssigen Web2-Entwicklern auf der Web3-AI-Ressourcenplattform muss eine praktikable Lösung und ein Weg gefunden werden, die nicht auf ein Web3-verteiltes Architekturmodell angewiesen sind. Tatsächlich gibt es viele innovative Richtungen, die es wert sind, erkundet zu werden, abgesehen von der schnellen Bereitstellung + Multi-Agent-Zusammenarbeit und dem Tokenomic-Token-Narrativ von Web2.

Zum Beispiel, ausgestattet mit einem verteilten Konsens-Kooperationsrahmen, wobei die Eigenschaften der LLM-Großmodelle für Offline-Berechnungen und On-Chain-Zustandspeicherung viele anpassungsfähige Komponenten erfordern.

1) Ein dezentrales DID-Identitätssystem, das es Agenten ermöglicht, eine verifizierbare On-Chain-Identität zu besitzen, ähnlich wie die einzigartigen Adressen, die von virtuellen Maschinen für Smart Contracts erzeugt werden, hauptsächlich um die kontinuierliche Verfolgung und Aufzeichnung des nachfolgenden Zustands zu gewährleisten.

2) Ein dezentrales Oracle-System, das hauptsächlich für den vertrauenswürdigen Zugriff und die Validierung von Off-Chain-Daten verantwortlich ist. Im Unterschied zu früheren Oracles muss dieses Oracle, das auf AI-Agenten abgestimmt ist, möglicherweise eine Kombination aus mehreren Agenten für die Datenakquisitionsschicht, die Konsensentscheidungsschicht und die Ausführungsfeedbackschicht schaffen, um sicherzustellen, dass die benötigten Daten der Agenten auf der Kette und die Off-Chain-Berechnungen und Entscheidungen in Echtzeit erreicht werden können.

3) Ein dezentrales Speichersystem, DA, da der Wissensstand des AI-Agenten im Betrieb ungewiss ist und der Schlussfolgerungsprozess auch vorübergehend ist, wird ein System benötigt, das die wichtigen Zustandsdatenbanken und Schlussfolgerungswege hinter dem LLM aufzeichnet und in einem verteilten Speichersystem speichert und einen kosteneffizienten Datenvalidierungsmechanismus bietet, um die Datenverwendbarkeit während der Validierung in der öffentlichen Kette sicherzustellen.

4) Eine Zero-Knowledge-Proof-ZKP-Privatberechnungsschicht, die mit Lösungen zur privaten Berechnung wie TEE und FHE verbunden werden kann, um Echtzeit-Privatberechnungen und Datenvalidierungsnachweise zu ermöglichen, sodass Agenten breitere vertikale Datenquellen (Medizin, Finanzen) haben können, und darauf basierend könnten mehr spezialisierte, maßgeschneiderte Dienst-Aggregatoren entstehen.

5) Ein interchain Interoperabilitätsprotokoll, das ein wenig dem von MCP definierten Open-Source-Protokoll ähnelt, der Unterschied besteht jedoch darin, dass diese Interoperabilitätslösung Mechanismen für Relay und Kommunikation benötigt, die an die Ausführung, Übertragung und Validierung des Agenten angepasst sind, um die Probleme der Vermögensübertragung und des Statusabgleichs von Agenten zwischen verschiedenen Ketten zu lösen, insbesondere wenn es um den Kontext der Agenten und komplexe Zustände wie Prompts, Wissensdatenbanken, Memory usw. geht.

……

Meiner Meinung nach sollte der Schwerpunkt der echten Web3-AI-Agenten darauf liegen, wie die „komplexen Arbeitsabläufe“ von AI-Agenten und der „Vertrauensvalidierungsfluss“ der Blockchain so gut wie möglich zusammenpassen können. Was diese inkrementellen Lösungen betrifft, so könnte es sowohl aus bestehenden narrativen Projekten, die ein Upgrade durchlaufen, als auch aus neu gebildeten AI-Agenten-narrativen Projekte kommen, die neu geformt werden.

Das ist die Richtung, in die Web3-AI-Agenten bauen sollten, und es entspricht den grundlegenden Aspekten des innovativen Ökosystems unter der großen Makronarrative von AI + Crypto. Wenn es nicht gelingt, relevante Innovationen und differenzierende Wettbewerbshürden zu schaffen, könnte jede kleinste Bewegung auf dem Web2-AI-Sektor das Web3-AI-Ökosystem ins Chaos stürzen.