Якщо A2A від Google та MCP від Anthropic стануть золотим стандартом комунікації для розвитку web3 AI Agent, що станеться? Інтуїтивно це викликає відчуття "незручності". На мою думку, середовище, з яким стикаються web3 AI Agent, має явні відмінності від екосистеми web2, а виклики, з якими стикається реалізація основного комунікаційного протоколу, є абсолютно іншими:
Розрив зрілості застосунків: A2A і MCP можуть швидко поширюватися в сфері web2, оскільки вони обслуговують достатньо зрілі сценарії застосування, по суті є «підсилювачами вартості», а не творцями вартості. Натомість web3 AI Agent в основному залишається на початковій стадії однокнопкової публікації агентів, відсутні глибокі сценарії застосування (DeFAI, GameFAi тощо), що ускладнює використання цих протоколів для досягнення вартості.
Наприклад, користувач, що пише код у Cursor, може використовувати протокол MCP як з'єднувач, не виходячи з поточного робочого середовища, щоб одним натисканням кнопки оновити код і опублікувати його на Github, протокол MCP відіграє роль вишуканого доповнення. Але якщо користувач у середовищі web3 намагається виконати транзакції в ланцюзі, використовуючи стратегії, які були налаштовані локально, то може статися так, що коли він намагається проаналізувати дані в ланцюзі, йому буде важко зрозуміти, що відбувається.
Відсутність інфраструктури: щоб web3 AI Agent зміг побудувати повноцінну екосистему, необхідно спершу заповнити серйозні прогалини в базовій інфраструктурі, включаючи єдиний рівень даних, рівень Oracle, рівень виконання намірів, рівень децентралізованого консенсусу тощо. Часто протокол A2A в середовищі web2 дозволяє Agent легко викликати стандартизовані API для реалізації функціональної співпраці, але в середовищі web3 навіть проста арбітражна операція через DEX стикається з величезними викликами.
Уявіть собі сцену, де користувач вказує AI Agent «купити на Uniswap, коли ціна ETH опуститься нижче 1600 доларів, і продати, коли ціна підніметься». Здається, що це простий процес, але Agent повинен одночасно вирішувати ряд специфічних проблем web3, таких як реальний аналіз даних на ланцюгу, динамічна оптимізація Gas, контроль за сліпим котируванням, захист від MEV тощо. Натомість AI Agent у web2 просто викликає стандартизовані API, щоб реалізувати функціональну співпрацю, і рівень розвитку його інфраструктури в порівнянні з середовищем web3 просто разюче відрізняється.
Побудова диференційованого попиту на web3 AI: якщо web3 AI агент просто використовує протоколи та моделі функцій web2, йому буде складно реалізувати особливості ланцюгових транзакцій, зокрема складні проблеми, такі як шум даних, точність транзакцій, різноманітність Router тощо.
Як приклад торгівлі за наміром, у середовищі web2 користувач вказує «зарезервувати найдешевший рейс», протокол A2A може дозволити кільком агентам легко співпрацювати для виконання цього; але в середовищі web3, коли користувач очікує «перекласти мої USDC на Solana з найнижчими витратами та брати участь у видобутку ліквідності», необхідно не лише зрозуміти намір користувача, але й зважити безпеку, атомарність і витрати, а також виконати ряд складних операцій в ланцюгу. Іншими словами, якщо здається, що зручна операція піддає користувача більшому ризику безпеки, то така зручна практика не має сенсу, а попит є псевдопопитом.
Вищезазначене.
Отже, я хочу висловити думку: цінність A2A та MCP безсумнівна, але не можна очікувати, що вони без жодних змін одразу адаптуються до сектора web3 AI Agent. Чи не є це вакуумом у розгортанні інфраструктури, що відкриває можливості для Builder-ів?
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Чи можуть A2A та MCP стати золотим стандартом Web3 AI агентів?
Автор: Haotian
Якщо A2A від Google та MCP від Anthropic стануть золотим стандартом комунікації для розвитку web3 AI Agent, що станеться? Інтуїтивно це викликає відчуття "незручності". На мою думку, середовище, з яким стикаються web3 AI Agent, має явні відмінності від екосистеми web2, а виклики, з якими стикається реалізація основного комунікаційного протоколу, є абсолютно іншими:
Наприклад, користувач, що пише код у Cursor, може використовувати протокол MCP як з'єднувач, не виходячи з поточного робочого середовища, щоб одним натисканням кнопки оновити код і опублікувати його на Github, протокол MCP відіграє роль вишуканого доповнення. Але якщо користувач у середовищі web3 намагається виконати транзакції в ланцюзі, використовуючи стратегії, які були налаштовані локально, то може статися так, що коли він намагається проаналізувати дані в ланцюзі, йому буде важко зрозуміти, що відбувається.
Уявіть собі сцену, де користувач вказує AI Agent «купити на Uniswap, коли ціна ETH опуститься нижче 1600 доларів, і продати, коли ціна підніметься». Здається, що це простий процес, але Agent повинен одночасно вирішувати ряд специфічних проблем web3, таких як реальний аналіз даних на ланцюгу, динамічна оптимізація Gas, контроль за сліпим котируванням, захист від MEV тощо. Натомість AI Agent у web2 просто викликає стандартизовані API, щоб реалізувати функціональну співпрацю, і рівень розвитку його інфраструктури в порівнянні з середовищем web3 просто разюче відрізняється.
Як приклад торгівлі за наміром, у середовищі web2 користувач вказує «зарезервувати найдешевший рейс», протокол A2A може дозволити кільком агентам легко співпрацювати для виконання цього; але в середовищі web3, коли користувач очікує «перекласти мої USDC на Solana з найнижчими витратами та брати участь у видобутку ліквідності», необхідно не лише зрозуміти намір користувача, але й зважити безпеку, атомарність і витрати, а також виконати ряд складних операцій в ланцюгу. Іншими словами, якщо здається, що зручна операція піддає користувача більшому ризику безпеки, то така зручна практика не має сенсу, а попит є псевдопопитом.
Вищезазначене.
Отже, я хочу висловити думку: цінність A2A та MCP безсумнівна, але не можна очікувати, що вони без жодних змін одразу адаптуються до сектора web3 AI Agent. Чи не є це вакуумом у розгортанні інфраструктури, що відкриває можливості для Builder-ів?