Друг сказав, що безперервний занепад агентів штучного інтелекту web3, таких як #ai16z і $arc, викликаний нещодавнім вибухом протоколу MCP? На перший погляд, вся людина трохи розгублена, чи має до цього відношення WTF? Але, подумавши, я виявив, що дійсно є певна логіка: оцінка та цінова логіка існуючого агента зі штучним інтелектом web3 змінилася, а напрямок наративу та маршрут посадки продукту потрібно терміново коригувати! Нижче хотілося б поділитися своїми особистими думками:
MCP (Model Context Protocol) — це стандартизований протокол з відкритим вихідним кодом, призначений для того, щоб дозволити різним LLM/агентам штучного інтелекту безперешкодно підключатися до різних джерел даних та інструментів, що еквівалентно «універсальному» інтерфейсу USB plug-and-play, який замінює наскрізний «специфічний» метод інкапсуляції в минулому.
Простіше кажучи, між додатками штучного інтелекту існують очевидні острівці даних, і агентам і LLM необхідно розробити відповідні API викликів для досягнення сумісності, не кажучи вже про складність операційного процесу та відсутність функцій двосторонньої взаємодії, які зазвичай мають відносно обмежені обмеження доступу до моделі та дозволів.
Поява MCP забезпечує єдину основу для додатків штучного інтелекту, щоб позбутися розрізненості даних минулого та реалізувати можливість «динамічного» доступу до зовнішніх даних та інструментів, що може значно знизити складність розробки та ефективність інтеграції, особливо з точки зору автоматизованого виконання завдань, запиту даних у реальному часі та міжплатформної співпраці.
Говорячи про це, багато хто відразу подумав, що якби Manus для мультиагентної співпраці та інновацій був інтегрований з цим фреймворком MCP з відкритим вихідним кодом, який може сприяти співпраці з кількома агентами, чи не був би він непереможним?
Правильно, Manus + MCP — це ключ до впливу web3 AI Agent.
Однак неймовірно, що і Manus, і MCP є фреймворками та стандартами протоколів для web2 LLM/Agent, які вирішують проблему взаємодії даних та співпраці між централізованими серверами, а їхні дозволи та контроль доступу також покладаються на «активну» відкритість кожного вузла сервера, іншими словами, це лише атрибут інструменту з відкритим вихідним кодом.
Зрозуміло, що це повністю суперечить центральним ідеям «розподілених серверів, розподіленої співпраці та розподілених стимулів», яких дотримується web3 AI Agent.
Причина в тому, що перша фаза web3 AI Agent занадто «орієнтована на web2», з одного боку, тому що багато команд мають досвід роботи з web2 і не мають повного розуміння нативних вимог web3 Native. «Інтерфейси API», такі як DeepSeek, належним чином інкапсулюють деякі загальні фреймворки Memory і Charater, щоб допомогти розробникам швидко розробляти додатки-агенти ШІ. Але в чому різниця між цим набором сервісних фреймворків та інструментами з відкритим вихідним кодом web2? У чому полягають відмінності?
Ух, чи є перевага в тому, що є набір стимулів Tokenomics? А потім використовувати набір фреймворків, які web2 може повністю замінити, щоб стимулювати групу більшої кількості агентів штучного інтелекту, які існують з метою випуску нових монет? Страшний.. Дивлячись на цю логіку, ви можете приблизно зрозуміти, чому Manus +MCP може вплинути на web3 AI Agent?
Оскільки багато фреймворків і сервісів агентів штучного інтелекту web3 вирішують лише потреби швидкої розробки та застосування, подібно до агентів штучного інтелекту web2, але вони не встигають за швидкістю інновацій web2 з точки зору технічних послуг і стандартів та переваг диференціації, ринок/капітал переоцінив і оцінив останню партію агентів ШІ web3.
До речі, суть загальної проблеми повинна бути знайдена, але як зламати ситуацію? Лише один спосіб: зосередьтеся на web3-нативних рішеннях, тому що робота та архітектура стимулювання розподілених систем є абсолютними перевагами web3.
Беручи за приклад розподілені хмарні обчислювальні потужності, дані, алгоритми та інші сервісні платформи, на перший погляд, здається, що такого роду обчислювальна потужність і дані, агреговані на основі незадіяних ресурсів, не можуть задовольнити потреби інженерних інновацій у короткостроковій перспективі, але коли велика кількість LLM зі штучним інтелектом борються за централізовану обчислювальну потужність, щоб прорватися через гонку озброєнь за продуктивність, сервісна модель із трюком «простої ресурсів і низької вартості», природно, зневажатиме розробників web2 та венчурні групи.
Однак, коли агент штучного інтелекту web2 пройде етап інновацій у продуктивності, він обов'язково займеться розширенням сценаріїв вертикального застосування та оптимізацією моделей поділу та тонкого налаштування, і переваги ресурсів web3 AI будуть справді очевидними на той час.
Насправді, коли web2 AI, який піднімається на позицію гіганта у вигляді ресурсної монополії, досягає певної стадії, важко відступити від ідеї оточити місто сільською місцевістю та розділити сцену одну за одною, і в цей час настає час для спільної роботи надлишкових розробників web2 AI + ресурсів web3 AI.
Насправді, на додаток до набору швидкого розгортання web2 + фреймворку для спільної комунікації з кількома агентами + наративу випуску токеномів, існує багато інноваційних напрямків web3 Native, які варто вивчити:
Наприклад, оснащений набором фреймворку для спільної роботи розподіленого консенсусу, враховуючи характеристики офчейн-обчислень + ончейн-сховище станів великих моделей LLM, потрібно багато адаптивних компонентів.
Децентралізована система автентифікації DID дозволяє агенту мати перевірену ончейн-ідентифікацію, яка схожа на унікальну адресу, згенеровану віртуальною машиною виконання для смарт-контракту, головним чином для безперервного відстеження та запису наступного стану;
Децентралізована система оракула Oracle в основному відповідає за довірене отримання та перевірку позаланцюгових даних, що відрізняється від попереднього Oracle, і цьому оракулу, адаптованому до агента штучного інтелекту, також може знадобитися виконати комбінацію кількох агентів, включаючи рівень збору даних, рівень консенсусу прийняття рішень і рівень зворотного зв'язку щодо виконання, щоб дані в ланцюжку, необхідні агенту, а також офчейн-обчислення та прийняття рішень могли бути отримані в режимі реального часу;
Децентралізована система DA зберігання даних, у зв'язку з невизначеністю стану бази знань під час роботи агента ШІ, а процес висновків також є тимчасовим, необхідно записувати ключові бібліотеки станів і шляхи висновків за LLM і зберігати їх у розподіленій системі зберігання, а також забезпечувати контрольований за вартістю механізм перевірки даних для забезпечення доступності даних перевірки публічного ланцюга;
Набір обчислювального рівня конфіденційності ZKP із доказом із нульовим розголошенням може бути пов'язаний із рішеннями для обчислень конфіденційності, включаючи час TEE, PHE тощо, для досягнення обчислень конфіденційності в реальному часі + перевірки доказу даних, щоб агент міг мати ширший спектр вертикальних джерел даних (медичні, фінансові), а потім зверху з'являються більш професійні індивідуальні агенти обслуговування;
Набір міжланцюгових протоколів сумісності, дещо схожий на фреймворк, визначений протоколом MCP з відкритим вихідним кодом, відмінність полягає в тому, що цей набір рішень для взаємодії повинен мати механізм ретрансляції та планування зв'язку, який адаптується до операції, доставки та перевірки агента, і може завершити передачу активів і синхронізацію станів агента між різними ланцюгами, особливо складними станами, такими як контекст і підказка агента, база знань, пам'ять тощо;
……
На мою думку, фокус справжнього агента штучного інтелекту web3 має бути на тому, як максимально підігнати «складний робочий процес» агента штучного інтелекту та «потік перевірки довіри» блокчейну. Що стосується цих поступових рішень, то їх можна оновити та повторити з існуючих старих наративних проєктів або переробити з проєктів на новоствореному наративному треку AI Agent.
Це напрямок, до якого має прагнути web3 AI Agent, і він відповідає основам інноваційної екосистеми в рамках макронаративу AI + Crypto. Без встановлення відповідних інновацій та диференційованих бар'єрів конкуренції щоразу, коли трек web2 AI перевертається з ніг на голову, web3 AI може перевернутися з ніг на голову.
Контент має виключно довідковий характер і не є запрошенням до участі або пропозицією. Інвестиційні, податкові чи юридичні консультації не надаються. Перегляньте Відмову від відповідальності , щоб дізнатися більше про ризики.
Чи викликаний подальший занепад AI Agent нещодавнім вибухом протоколу MCP?
Написано: Haotian
Друг сказав, що безперервний занепад агентів штучного інтелекту web3, таких як #ai16z і $arc, викликаний нещодавнім вибухом протоколу MCP? На перший погляд, вся людина трохи розгублена, чи має до цього відношення WTF? Але, подумавши, я виявив, що дійсно є певна логіка: оцінка та цінова логіка існуючого агента зі штучним інтелектом web3 змінилася, а напрямок наративу та маршрут посадки продукту потрібно терміново коригувати! Нижче хотілося б поділитися своїми особистими думками:
Простіше кажучи, між додатками штучного інтелекту існують очевидні острівці даних, і агентам і LLM необхідно розробити відповідні API викликів для досягнення сумісності, не кажучи вже про складність операційного процесу та відсутність функцій двосторонньої взаємодії, які зазвичай мають відносно обмежені обмеження доступу до моделі та дозволів.
Поява MCP забезпечує єдину основу для додатків штучного інтелекту, щоб позбутися розрізненості даних минулого та реалізувати можливість «динамічного» доступу до зовнішніх даних та інструментів, що може значно знизити складність розробки та ефективність інтеграції, особливо з точки зору автоматизованого виконання завдань, запиту даних у реальному часі та міжплатформної співпраці.
Говорячи про це, багато хто відразу подумав, що якби Manus для мультиагентної співпраці та інновацій був інтегрований з цим фреймворком MCP з відкритим вихідним кодом, який може сприяти співпраці з кількома агентами, чи не був би він непереможним?
Правильно, Manus + MCP — це ключ до впливу web3 AI Agent.
Зрозуміло, що це повністю суперечить центральним ідеям «розподілених серверів, розподіленої співпраці та розподілених стимулів», яких дотримується web3 AI Agent.
Причина в тому, що перша фаза web3 AI Agent занадто «орієнтована на web2», з одного боку, тому що багато команд мають досвід роботи з web2 і не мають повного розуміння нативних вимог web3 Native. «Інтерфейси API», такі як DeepSeek, належним чином інкапсулюють деякі загальні фреймворки Memory і Charater, щоб допомогти розробникам швидко розробляти додатки-агенти ШІ. Але в чому різниця між цим набором сервісних фреймворків та інструментами з відкритим вихідним кодом web2? У чому полягають відмінності?
Ух, чи є перевага в тому, що є набір стимулів Tokenomics? А потім використовувати набір фреймворків, які web2 може повністю замінити, щоб стимулювати групу більшої кількості агентів штучного інтелекту, які існують з метою випуску нових монет? Страшний.. Дивлячись на цю логіку, ви можете приблизно зрозуміти, чому Manus +MCP може вплинути на web3 AI Agent?
Оскільки багато фреймворків і сервісів агентів штучного інтелекту web3 вирішують лише потреби швидкої розробки та застосування, подібно до агентів штучного інтелекту web2, але вони не встигають за швидкістю інновацій web2 з точки зору технічних послуг і стандартів та переваг диференціації, ринок/капітал переоцінив і оцінив останню партію агентів ШІ web3.
Беручи за приклад розподілені хмарні обчислювальні потужності, дані, алгоритми та інші сервісні платформи, на перший погляд, здається, що такого роду обчислювальна потужність і дані, агреговані на основі незадіяних ресурсів, не можуть задовольнити потреби інженерних інновацій у короткостроковій перспективі, але коли велика кількість LLM зі штучним інтелектом борються за централізовану обчислювальну потужність, щоб прорватися через гонку озброєнь за продуктивність, сервісна модель із трюком «простої ресурсів і низької вартості», природно, зневажатиме розробників web2 та венчурні групи.
Однак, коли агент штучного інтелекту web2 пройде етап інновацій у продуктивності, він обов'язково займеться розширенням сценаріїв вертикального застосування та оптимізацією моделей поділу та тонкого налаштування, і переваги ресурсів web3 AI будуть справді очевидними на той час.
Насправді, коли web2 AI, який піднімається на позицію гіганта у вигляді ресурсної монополії, досягає певної стадії, важко відступити від ідеї оточити місто сільською місцевістю та розділити сцену одну за одною, і в цей час настає час для спільної роботи надлишкових розробників web2 AI + ресурсів web3 AI.
Насправді, на додаток до набору швидкого розгортання web2 + фреймворку для спільної комунікації з кількома агентами + наративу випуску токеномів, існує багато інноваційних напрямків web3 Native, які варто вивчити:
Наприклад, оснащений набором фреймворку для спільної роботи розподіленого консенсусу, враховуючи характеристики офчейн-обчислень + ончейн-сховище станів великих моделей LLM, потрібно багато адаптивних компонентів.
Децентралізована система автентифікації DID дозволяє агенту мати перевірену ончейн-ідентифікацію, яка схожа на унікальну адресу, згенеровану віртуальною машиною виконання для смарт-контракту, головним чином для безперервного відстеження та запису наступного стану;
Децентралізована система оракула Oracle в основному відповідає за довірене отримання та перевірку позаланцюгових даних, що відрізняється від попереднього Oracle, і цьому оракулу, адаптованому до агента штучного інтелекту, також може знадобитися виконати комбінацію кількох агентів, включаючи рівень збору даних, рівень консенсусу прийняття рішень і рівень зворотного зв'язку щодо виконання, щоб дані в ланцюжку, необхідні агенту, а також офчейн-обчислення та прийняття рішень могли бути отримані в режимі реального часу;
Децентралізована система DA зберігання даних, у зв'язку з невизначеністю стану бази знань під час роботи агента ШІ, а процес висновків також є тимчасовим, необхідно записувати ключові бібліотеки станів і шляхи висновків за LLM і зберігати їх у розподіленій системі зберігання, а також забезпечувати контрольований за вартістю механізм перевірки даних для забезпечення доступності даних перевірки публічного ланцюга;
Набір обчислювального рівня конфіденційності ZKP із доказом із нульовим розголошенням може бути пов'язаний із рішеннями для обчислень конфіденційності, включаючи час TEE, PHE тощо, для досягнення обчислень конфіденційності в реальному часі + перевірки доказу даних, щоб агент міг мати ширший спектр вертикальних джерел даних (медичні, фінансові), а потім зверху з'являються більш професійні індивідуальні агенти обслуговування;
Набір міжланцюгових протоколів сумісності, дещо схожий на фреймворк, визначений протоколом MCP з відкритим вихідним кодом, відмінність полягає в тому, що цей набір рішень для взаємодії повинен мати механізм ретрансляції та планування зв'язку, який адаптується до операції, доставки та перевірки агента, і може завершити передачу активів і синхронізацію станів агента між різними ланцюгами, особливо складними станами, такими як контекст і підказка агента, база знань, пам'ять тощо;
……
На мою думку, фокус справжнього агента штучного інтелекту web3 має бути на тому, як максимально підігнати «складний робочий процес» агента штучного інтелекту та «потік перевірки довіри» блокчейну. Що стосується цих поступових рішень, то їх можна оновити та повторити з існуючих старих наративних проєктів або переробити з проєктів на новоствореному наративному треку AI Agent.
Це напрямок, до якого має прагнути web3 AI Agent, і він відповідає основам інноваційної екосистеми в рамках макронаративу AI + Crypto. Без встановлення відповідних інновацій та диференційованих бар'єрів конкуренції щоразу, коли трек web2 AI перевертається з ніг на голову, web3 AI може перевернутися з ніг на голову.