Три "смертельні зони" впровадження A2A та протоколу MCP у Web3 AI Agent

Якщо A2A від Google та MCP від Anthropic стануть золотим стандартом комунікації для розвитку web3 AI Agent, що станеться? Інтуїтивно здається, що “воді не підходить”. На мою думку, середовище, в якому стикається web3 AI Agent, суттєво відрізняється від екосистеми web2, виклики, з якими стикається реалізація основного комунікаційного протоколу, також кардинально різні:

1. Розрив у зрілості додатків: A2A та MCP можуть швидко стати популярними у сфері web2, оскільки вони обслуговують досить зрілі сценарії додатків і, по суті, є «підсилювачами цінності», а не творцями цінності. Однак більшість агентів штучного інтелекту web3 перебувають на початковій стадії випуску агента в один клік і не мають поглиблених сценаріїв застосування (DeFAI, GameFA тощо), що ускладнює безпосереднє використання цих протоколів для відігравання цінної ролі.

Наприклад, користувач, що пише код у Cursor, може використовувати MCP протокол як з’єднувач, без необхідності виходити з поточного робочого середовища, просто натиснувши кнопку, щоб оновити та опублікувати код на Github. MCP протокол виконує корисну функцію. Але якщо користувач у середовищі web3 виконує транзакції в ланцюзі, використовуючи стратегії, налаштовані локально, то, можливо, намагаючись проаналізувати дані в ланцюзі, він може заплутатися і не знати, куди рухатися далі.

2）Відсутність інфраструктури: щоб web3 AI Agent зміг побудувати повноцінну екосистему, необхідно спочатку заповнити серйозні прогалини в базовій інфраструктурі, включаючи єдиний рівень даних, рівень Oracle, рівень виконання намірів, рівень децентралізованого консенсусу тощо. Часто A2A протокол у середовищі web2 дозволяє Agent легко викликати стандартизовані API для реалізації функціональної співпраці, але в середовищі web3 навіть проста операція арбітражу між DEX стикається з величезними викликами.

Уявіть собі сценарій, коли користувач наказує агенту штучного інтелекту «купувати в Uniswap, коли ціна ETH нижча за 1 600 доларів, і продавати його після того, як ціна відновиться», здавалося б, простий операційний агент повинен вирішити низку специфічних для web3 проблем, таких як аналіз даних у ланцюжку в реальному часі, динамічна оптимізація комісій за газ, контроль прослизання та захист MEV. З іншого боку, Web2 AI Agent потрібно лише викликати стандартизовані API для досягнення функціональної співпраці, і його інфраструктура повністю відрізняється від інфраструктури середовища web3.

3. Побудова диференційованого попиту на web3 AI: Якщо web3 AI Agent просто застосовує протокол та функціональні моделі web2, буде важко реалізувати особливості ланцюгових транзакцій, особливо такі складні проблеми, як шум даних, точність транзакцій, різноманітність Router тощо.

Візьмемо для прикладу транзакції з намірами, у середовищі web2 користувач інструктує «забронювати найдешевший рейс», а протокол A2A дозволяє кільком агентам легко співпрацювати. Але в середовищі web3, коли користувачі очікують «кросчейн мого USDC до Solana та брати участь у майнінгу ліквідності за найнижчою ціною», їм потрібно не лише розуміти наміри користувача, але й зважувати безпеку, атомарність і знос витрат, а також виконувати низку складних операцій у мережі. Іншими словами, якщо, здавалося б, зручна операція наражає користувача на більші ризики безпеки, то такий зручний досвід безглуздий, а попит також є псевдопопитом.

Вище.

Отже, я хочу висловити думку: цінність A2A та MCP безсумнівна, але не слід очікувати, що вони без жодних змін безпосередньо адаптуються до сегменту web3 AI Agent. Чи не є ця відсутня інфраструктурна розгортка можливістю для Будівельників?