（с точки зрения опыта разработчиков и комбинируемости долгосрочная ценность $VANRY ）
Если вы спросите меня: на чем основана победа инфраструктуры с приоритетом ИИ? Сначала я не буду говорить о TPS и не буду обсуждать нарратив. Я сначала задам более «инженерный» вопрос: смогут ли разработчики интегрировать способности агентов, как конструктор, и стабильно работать в течение года?
AI приводит Web3 в новую эру: на блокчейне не только активы и контракты, но и множество «умных модулей». Они очень похожи на библиотеки и сервисы в программной инженерии: кто-то занимается семантической памятью, кто-то интерпретацией выводов, кто-то автоматизацией выполнения, кто-то расчетами и соблюдением норм. Проблема в том, что если у этих возможностей нет единого способа доступа, нет повторно используемой базовой абстракции, разработчики окажутся в бесконечном «аду интеграции»:
Каждый раз, когда вы получаете интеллектуальный компонент, необходимо заново адаптировать структуру данных.
Каждый раз, когда вы меняете экосистему, вам нужно переписывать целый набор интеграционных уровней.
После настоящего запуска трудно определить, в чем проблема: потеря памяти? Ошибка в выводах? Условия выполнения не сработали? Или канал расчета заблокирован?
В конце концов, интеллектуальный агент превращается в набор разрозненных демо, не способных к масштабированию.
Вот как я понимаю вход в Vanar: это не похоже на создание «умнее ИИ», и не похоже на создание «быстрее цепи». Это больше похоже на то, чтобы делать долгосрочную, но ключевую вещь: снизить основные возможности, необходимые для интеллектуального агента, до стандартных компонентов инфраструктурного уровня, позволяя разработчикам создавать готовые к запуску интеллектуальные приложения с меньшими затратами.
Иными словами: конкуренция в эпоху ИИ часто сводится к тому, «кто лучше в использовании». Кто сможет снизить «стоимость подключения», «стоимость повторного использования» и «стоимость кросс-экосистемы», тот станет более вероятным выбором по умолчанию.
1) AI-first против AI-added: разница не в рекламных заявлениях, а в том, «было ли интерфейс изначально спроектирован для интеллектуальных модулей»
Многие цепи говорят: «мы также поддерживаем ИИ». Но вы видите реальный рабочий поток разработчиков, и понимаете разницу:
AI-added обычно рассматривает ИИ как функционал прикладного уровня, создавая несколько SDK, делая несколько демонстраций, а затем надеясь, что экосистема вырастет сама собой. Но для масштабирования интеллектуальных модулей самое страшное - это отсутствие правильного интерфейса и абстракции на нижнем уровне.
Значение AI-first более конкретно в инженерном плане:
С первого дня предполагается, что на цепочке существует множество вызовов интеллектуальных агентов и сотрудничество интеллектуальных модулей, поэтому необходимо более естественно поддерживать: долгосрочную доступность состояния, отслеживаемость процесса вывода, контролируемую автоматизацию действий и закрытый цикл расчетов. Эти вещи не могут быть компенсированы «добавлением функциональной кнопки», это больше похоже на то, что вы изначально решили, как должен быть спроектирован ядро операционной системы.
@Vanarchain Talking Points подчеркивает «согласование с реальным использованием, а не повествованием», и я предпочитаю перевести это на инженерный язык:
Не спрашивайте, можете ли вы сделать демонстрацию, сначала спросите, можете ли вы дать разработчикам базовый уровень интеллектуального агента, который можно повторно использовать и поддерживать.
2) Что такое «AI-ready»? С точки зрения разработчика это четыре «обязательных и совместимых» базовых возможности.
Многие люди неправильно понимают AI-ready как «более быстрое». Но когда вы действительно разрабатываете приложения для интеллектуальных агентов, вы обнаружите, что скорость - это лишь поверхностный уровень. Глубже лежит то, что четыре возможности должны сочетаться друг с другом, иначе вся система будет трудно выйти из POC.
Memory (память): это не «что обсуждали», а контекст и семантическое состояние, необходимые интеллектуальному агенту для долгосрочных задач.
Reasoning (вывод): это не «дать ответ», а сделать так, чтобы цепочка принятия решений могла быть понята, пересмотрена и доверена.
Automation (автоматизация): это не «возможность исполнения», а возможность превратить исполнение в стабильные процессуальные компоненты.
Расчет (Settlement): это не «возможность перевода», а возможность превратить действия интеллектуального агента в закрытый цикл реальной экономической активности.
Сделать все четыре вещи одновременно не сложно, сложно сделать это комбинируемыми: могут ли разработчики собрать их так, как стандартную библиотеку, с меньшими рисками, переписываниями и затратами на интеграцию.
@Vanarchain примеры продуктов (myNeutron / Kayon / Flows) я не рассматриваю как «три отдельные функции», а скорее как три базовых компонента:
Кто-то отвечает за преобразование «семантического состояния» в базовые возможности (соответствует myNeutron)
Кто-то отвечает за превращение «вывода и объяснения» в повторно используемую способность (соответствует Kayon)
Кто-то отвечает за то, чтобы превратить «интеллект → действие» в процессуальную способность (соответствует Flows)
Добавление «канала расчетов/платежей» для замыкания приложения - вот полное объяснение «AI-ready» с инженерной точки зрения.
3) Почему «выпуск новой L1» в эпоху ИИ более сложен? Потому что разработчикам не хватает цепей, им не хватает «зрелого промежуточного ПО для интеллектуальных агентов».
В прошлом новая цепочка могла привлечь разработчиков с помощью «более быстрого и более дешевого». В эпоху ИИ эта логика становится все более слабой:
У разработчиков уже достаточно много цепей на выбор, на самом деле им не хватает промежуточного ПО и стандартных компонентов, которые могли бы ускорить доставку интеллектуальных приложений, сделать их более стабильными в работе и облегчить их обслуживание.
Если вы команда, готовящаяся создать приложение, связанное с AI-агентами, вы больше всего боитесь не «отсутствия мест для развертывания в цепочке», а того, что:
Вам нужно создать собственную систему памяти, самостоятельно сделать вывод интерпретируемым, самостоятельно написать защитные барьеры для исполнения, самостоятельно подключить каналы расчетов.
Как только бизнес начнет работать, затраты на обслуживание резко возрастут.
Чем больше у вас успеха, тем легче системе разрушиться из-за недостаточной зрелости какого-либо модуля.
Таким образом, «новая L1 сложна» не означает, что рынок не нуждается в новых цепочках, а означает, что базовая инфраструктура новой цепочки больше не является дефицитом, дефицитом являются комбинации интеллектуальных компонентов, которые могут быть непосредственно использованы в производстве. Это также то, что отсутствует в Talking Points Vanar: «не хватает продуктов, подтверждающих готовность ИИ» - я перевожу это как: «не хватает вещей, которые позволят разработчикам сэкономить полгода времени на интеграцию».
4) Кросс-цепочка начинается с Base: это не «добавление одной развертки», а «позволение компонентам перейти к распространению», поместив комбинируемость в более крупную плотность разработчиков для проверки.
Если вы действительно создаете «стандартные компоненты», вы будете естественно заботиться о распространении: компоненты должны использоваться в большом количестве, чтобы быстрее развиваться, становиться более стабильными и в конечном итоге стать выбором по умолчанию.
Инфраструктура AI-first, если она работает только в одной сети, имеет ограниченную область применения компонентов, ограниченные отзывы разработчиков, и экосистема может легко стать закрытым садом. Vanar начинает кросс-цепочку с Base, в этом контексте это больше похоже на реальный выбор:
Поместите компоненты в места с более плотным развитием разработчиков и большим количеством приложений, увеличьте частоту взаимодействия и использования, чтобы «комбинируемость» действительно вышла на масштаб.
Это также напрямую повлияет на $VANRY пути ценности: когда больше экосистем могут вызывать один и тот же набор интеллектуальных компонентов и расчетных возможностей, область использования расширяется, а потенциальные пути накопления ценности также становятся более ясными.
5) Почему расчеты/платежи являются обязательным курсом для AI-first? Потому что без замыкания разработчики всегда остаются на уровне «полезно, но не создаёт ценности».
Вы увидите, что многие AI-приложения «выглядят очень полезными», но долго не могут расти: потому что они остаются на уровне предложений и инструментов, им не хватает замыкания, которое может вызвать реальные экономические действия. Это особенно актуально для Web3 - если интеллектуальный агент делает вывод, и не может плавно перейти к расчетному каналу, он может лишь делать «подсказки», но трудно превращаться в «действие».
Vanar Talking Points подчеркивает, что «интеллектуальные агенты не используют UX кошельков», это действительно очень важное заявление:
Интеллектуальному агенту нужен оркеструемый канал расчетов, а не чтобы он нажимал кнопки, как человек. Только когда канал расчета стабильно существует, разработчики будут готовы адаптировать интеллектуальные приложения к корпоративным или реальным бизнес-формам.
Верните это к перспективе «комбинируемости»: возможность расчетов не является дополнительным модулем, а последним кусочком, который обязательно должен присутствовать в стандартной библиотеке. В противном случае созданная вами система всегда будет недоставать «выхода для выполнения задачи».
6) $VANRY: больше похоже на «накопление ценности от использования разработчиками и вызовами компонентов», а не на краткосрочные билеты, движимые эмоциями.
Если вы согласны с маршрутом «стандартные компоненты + распространение», то $VANRY легче понять с точки зрения логики инфраструктуры:
это не ставка на какую-то краткосрочную популярность, а ставка на то, что этот уровень базовых возможностей интеллектуального агента будет принят большим количеством приложений и вызван большим количеством экосистем, что приведет к долгосрочному спросу на использование.
Это также последняя строка Talking Points: «готовность, а не повествования». Говоря более прямо:
Когда продукт действительно используется, ценность накапливается очень простым образом; а когда ценность зависит от повествования, рост часто более хрупок.
В эпоху ИИ эта разница станет более очевидной. Поскольку компании, учреждения и команды, серьезно занимающиеся приложениями, будут все более чувствительны к «доставляемости». Кто сможет снизить стоимость доставки интеллектуальных приложений, тот с большей вероятностью станет следующим выбором для инфраструктуры.
Заключение: победителем эпохи ИИ часто становится тот, кто «делает сложные способности простыми».
Оглядываясь на @Vanarchain ключевую информацию, вы обнаружите, что она не спешит упаковать себя как «самая рассказчивая AI-цепочка». Это больше похоже на то, чтобы создать «уровень, удобный для разработчиков»: сделать память, вывод, автоматизацию, расчеты и другие сложные способности в виде комбинируемых компонентов, а затем расширить область использования с помощью кросс-цепочного распространения.
Этот путь не обязательно самый шумный, но если AI-агенты действительно станут важной формой пользователей Web3, ценность инфраструктуры будет больше исходить от «постоянного использования». А в долгосрочной перспективе сделать сложные способности простыми часто более ценно, чем «расширить концепцию».