Большинство диалогов AI-приложений останавливаются слишком рано. Они останавливаются в момент "приложение сгенерировано".

Это было разумно на первой волне. Год назад, наблюдая, как набор подсказок превращается в работающий интерфейс, это само по себе было главной сенсацией. Сегодня создатели уже понимают, что естественный язык может генерировать программное обеспечение. Более сложный вопрос: что происходит с сгенерированным приложением после этого.

Может ли оно работать для реальных пользователей?
Может ли оно безопасно выполнять задачи?
Может ли оно измерять затраты, взимать плату по стоимости и выдавать документы?
Может ли создатель получать доход от этого?
Может ли пользователь найти его, не полагаясь на случайный список приложений?

В X-Agent мы постоянно возвращаемся к этой границе: создание необходимо, но только создание не превращает приложение Agent в настоящий продукт. Отсутствующий уровень — это все, что происходит "после завершения сборки".

Резюме

Следующий платформенный вопрос не в том, чтобы генерировать больше AI-приложений, а в том, чтобы превратить уже сгенерированные приложения Agent в исполняемые, распределяемые и прибыльные продукты. Путь сборки (Build Path) и путь выполнения (Runtime Path) должны рассматриваться как две разные системы. Первая создает приложение, вторая позволяет реальным пользователям работать с ним.

Платежи за приложения Agent должны быть связаны с самим выполнением — включая бюджет, измерение, подтверждение, расчет, документы и пути разрешения споров. Магазин Agent и рост должны начинаться с отобранного распределения и сигналов реального использования, а не с пустого списка на рынке.

Путь сборки — это только половина продукта

Путь сборки — это та часть, которую большинство людей уже осознали. Создатель → Студия → Harness (исполнительный фреймворк) → песочница → развернутое приложение Agent. Создатель описывает, что он хочет, система интерпретирует это намерение, генерирует приложение, предварительно просматривает его в песочнице, а затем продвигает к развертыванию.

Это уже очень ценно. Оно устраняет прошлые препятствия для неинженеров и замедляет работу инженеров: структура репозитория, конфигурация окружения, циклы предварительного просмотра, детали развертывания и первая волна сборки приложения. Но если мы остановимся на этом, по сути, мы просто получили способ "лучше создавать предложение". Больше создателей могут производить больше приложений, больше идей могут дойти до демонстрационной стадии, больше прототипов могут быть поделены, но это не отвечает на вопрос "продукта". Сгенерированное приложение все еще нуждается в пользователе, задаче, состоянии, разрешениях, ценообразовании, доверии и распределении.

Вот почему мы разделяем путь сборки и путь выполнения.

Время выполнения — это место, где приложение действительно становится полезным

Путь выполнения начинается после завершения развертывания приложения. Пользователь → приложение Agent → диалог Agent → инструменты/состояние/кошелек/платеж → результат. Этот путь обслуживает конечного пользователя, а не создателя. Развернутое приложение Agent не должно быть просто статической страницей с ярлыком AI. Пользователь должен иметь возможность открыть это приложение, выразить намерение, задать уточняющие вопросы, инициировать рабочий процесс, проверить состояние, вызвать инструменты и получить результат задачи.

Это звучит очевидно, пока вы не начнете его действительно строить.

Agent во время сборки и Agent во время выполнения — это две разные работы. Agent во время сборки отвечает за помощь в создании приложения; Agent во время выполнения отвечает за помощь пользователю в работе с приложением. Если эти две роли объединить в одном длинном наборе подсказок, система станет трудной для рассуждения, трудно обеспечивать безопасность и трудно реализовать прибыльность.

Время выполнения должно установить собственный "договор" с пользователем. Оно должно знать, какие состояния это приложение может читать и записывать; должно знать, какие инструменты доступны; должно знать, какие операции дешевы и обратимы, а какие дорогие, связаны с внешними системами или несут риски; должно знать, когда нужно запрашивать подтверждение; и должно оставлять следы аудита.

Вот в чем разница между "модель дала ответ" и "приложение выполнило задачу".

Конкретный пример: анализ лидов — это не просто набор подсказок

Возьмем простое приложение Agent: анализ лидов после завершения мероприятия или маркетинговой кампании. Версия, основанная только на подсказках, довольно распространена: пользователь вставляет список лидов и позволяет модели их отсортировать. Модель возвращает таблицу, возможно, с оценкой и предложением по дальнейшим действиям. Полезно, но не полно.

Настоящее исполняемое приложение Agent должно обрабатывать оставшуюся часть рабочего процесса:

Импортировать лиды из форм, электронных таблиц, CRM или систем мероприятий;
Стандартизировать поля, сохраняя при этом оригинальный источник;
Классифицировать с помощью модели и при необходимости вызывать расширенные API для дополнения данных;
Отметить, какие внешние вызовы будут стоить денег;
Запрашивать подтверждение перед отправкой сообщений или записью в CRM;
Записывать, кто одобрил это действие;
Показать, какие расходы были понесены, какие ресурсы были использованы, какие результаты были получены;
Поддерживать возврат, повторную попытку или разрешение споров, когда задача не выполнена.

Вот где многие AI-приложения тихо терпят крах. Модель может предложить, что делать дальше, но уровень продукта должен нести ответственность за авторизацию, выполнение, затраты и ответственность. Этот уровень продуктовых возможностей — это то, что мы называем "временем выполнения (Runtime)".

Выполнение требует договора

Мы не считаем, что "выполнение Agent" означает предоставление модели неограниченной власти. Лучший подход должен быть более сдержанным: намерение пользователя → модель предлагает решение → проверка времени выполнения → выполнение инструмента → запись аудита. Модель отвечает за понимание и планирование, время выполнения отвечает за проверку и выполнение.

Для любой значимой операции время выполнения должно быть в состоянии составить "договор на выполнение (Execution Contract)". Это не обязательно документ, видимый на интерфейсе, а внутренний объект, который сообщает платформе "что произойдет дальше".

Договор на выполнение должен отвечать на следующие вопросы:

Плательщик (payer): кто будет платить;
Приложение Agent (agentapp): какое приложение выполняется; Создатель (builder): кто создал это приложение; Задача (task): какую задачу выполняют; Ценообразование (pricing): как оценивается эта задача; Максимальный бюджет (budgetcap): какова максимальная допустимая стоимость;
Подтверждение (confirmation): требуется ли подтверждение от пользователя;
Измерение (metering): что должно измеряться;
Расчет (settlement): как будет производиться расчет;
Аудит (audit): как будет отслеживаться процесс выполнения.

Уровень пользовательского опыта может оставаться простым:

"Эта задача может стоить максимум 0,50 долларов. Продолжить?"

Но бэкэнд не может быть таким простым. Он должен знать, одобрил ли пользователь эту задачу, сколько бюджета было зарезервировано, какие инструменты были вызваны, какова фактическая стоимость выполнения, завершена ли задача и какие документы должны быть выданы. Без этого договора платеж будет просто интерфейсом для расчета; с ним платеж становится частью процесса выполнения.

Платеж не является кнопкой расчета

Для приложений Agent платеж не должен быть жестко прикреплен к продукту. В тот момент, когда Agent начинает действительно работать, затраты и ценность становятся вопросами уровня выполнения. Некоторые операции будут потреблять токены модели, некоторые будут вызывать платные API, некоторые будут использовать вычисления, хранение, поиск, услуги данных, инфраструктуру развертывания или сторонние сервисы, а некоторые операции будут непосредственно создавать коммерческую ценность.

Поэтому вопрос платежа не просто "картой или кошельком?"

А именно:

Кто инициировал эту задачу?
Кто одобрил этот бюджет?
Какие ресурсы были использованы?
Завершен ли результат?
Сколько должно быть взято?
Как должны делиться доходы?
Что произойдет, если задача не выполнена?
Какие записи могут подтвердить, что что-то произошло?

Вот почему мы рассматриваем платежи за приложения Agent как "Коммерческий уровень Agent (Agent Commerce Layer)". Практическая "состояние выполнения-торговля" машина состояний может выглядеть примерно так: предложение → авторизация → резервирование → выполнение → измерение → расчет → выдача документов → распределение → возврат/разрешение споров.

Большинство пользователей никогда не должны видеть всю эту механику. Они должны видеть только четкую границу затрат и четкий результат. Например, примерная ценовая стратегия для приложения Agent по анализу лидов может быть:

Бесплатный лимит: первые 10 запусков бесплатно;
Единица измерения: за задачу;
Цена задачи: 3 доллара за партию лидов;
Максимальный бюджет: максимальная допустимая внутренняя стоимость за задачу;
Перекладываются ли внешние затраты: да/нет;
Требуется ли подтверждение: требуется перед отправкой внешних сообщений или записью в CRM.

(Эти цифры являются лишь примером модели продукта и не представляют собой фактические цены, открытые X-Agent в настоящее время.)

Создателям не нужно учитывать исходные затраты токенов, пользователи также не должны видеть каждую внутреннюю метрику — платформа должна переводить процесс выполнения в понятные пользователю цены. На ранних этапах практическая отправная точка очень проста: бесплатный лимит + лимит использования + SKU задач. Ценообразование по использованию подходит для вызовов модели, вызовов API, поиска, хранения и вычислений; ценообразование за задачу подходит для четко определенных сценариев, таких как анализ лидов, создание страницы, развертывание приложения, генерация отчета, обобщение набора данных или выполнение четко определенного рабочего процесса.

Ценообразование по сессиям или подписке подходит для инструментов с высокой частотой использования. Ценообразование по результату заманчиво, но должно быть отложено на более поздний срок — прежде чем большинство приложений Agent смогут взимать плату по коммерческим результатам, механизмы атрибуции, рисков, доверия, ответственности и разрешения споров должны стать достаточно сильными.

Абстрактный платежный канал, сохранение договора выполнения

Платежный канал не должен определять пользовательский опыт продукта. Пользователь покупает результат задачи, а не сам платежный протокол. Создатель хочет знать:

Какова цена этого приложения Agent?
Кто будет платить?
Как контролируются затраты?
Когда доход создателя может стать реальностью?
Что произойдет, если задача не выполнена?

Им не нужно беспокоиться о том, является ли нижний канал банковской картой, Apple Pay, баллами платформы, счетом, стейблкоином, кошельком или каким-то платежным протоколом Agent к Agent. На уровне продукта эти концепции должны оставаться простыми: баланс, баллы, счета, кошельки.

А на нижнем уровне могут сосуществовать различные платежные каналы:

Банковские карты или Apple Pay для массовых пользователей;
Платформенные баллы для распространенных платных задач;
Счета или предоплаченные баллы для корпоративных клиентов;
Каналы кошельков или стейблкоинов для нативных пользователей Web3;
Бюджеты на авторизацию и автоматический расчет для сценариев Agent к Agent.

Примеры новых инфраструктур включают агентские кошельки, подобные x402, протоколы платных вызовов, расчеты стейблкоинов и программируемые платежные системы. Все они указывают в одном направлении: программное обеспечение должно иметь платежные каналы, работающие на уровне выполнения. Это не означает, что каждое приложение Agent должно использовать криптовалюту, а скорее, что уровень приложения должен абстрагировать платежный канал, сохраняя при этом договор выполнения.

Разные пользователи будут нуждаться в разных платежных каналах, но сам контракт должен оставаться единым.

Распределение также является частью проблемы выполнения в реальном времени.

Как только создание становится простым, распределение становится более сложным. Создатели ИИ увеличат предложение приложений, но это не означает, что пользователи смогут найти подходящее приложение, и не означает, что создатели смогут извлечь прибыль из того, что они создали. Экосистема приложений Agent требует не только открытого списка приложений. Она нуждается в механизмах обнаружения, доверия, ранжирования, стимулов и обратной связи, а также в понимании рисков выполнения в реальном времени.

Обычный магазин приложений, как правило, задает следующие вопросы:

Что это за приложение?
Кто его разработал?
Могу ли я его установить?
Какова оценка?

А магазин Agent должен задавать больше вопросов:

Что может делать это приложение Agent?
Какие разрешения ему нужны?
Какие инструменты оно может использовать?
Сколько это будет стоить?
Какие задачи оно уже выполнило?
Какие сигналы использования могут подтвердить его полезность?
Какова история платежей или удостоверений?
Какова репутация этого создателя?
Кто помогает в распределении или отборе контента?

Это направление продукта, не означает, что каждая его часть уже зрелая. Наша точка зрения такова: магазин Agent не должен начинаться с пустого открытого рынка, а должен начинать с "слоя, предоставляющего отборочное распределение и поддержку роста для качественных приложений Agent". Это означает отбор высококачественных приложений, предоставление им первоначальной видимости, операционных мероприятий, проверка реального использования, вознаграждение за эффективные действия по распределению, а также фильтрация низкокачественных или ложных активных данных.

Механизмы роста могут помочь, но при условии, что они должны быть связаны с реальным использованием. Рекомендательные вознаграждения, задания, рейтинги, экосистемные стимулы — эти механизмы имеют смысл только тогда, когда они действительно направляют пользователей к приложениям Agent, которые могут решить проблемы, иначе они просто создадут трафик, но не принесут доверия.

Колесо экономики создателей

Коммерческие возможности возникают, когда создание, выполнение, платежи и распределение соединяются.

Создатели создают приложения Agent
→ Пользователи обнаруживают и используют их
→ Выполнение измеряется в реальном времени
→ Пользователи платят за полезные задачи
→ Доход создателей становится возможным
→ Рекомендатели или кураторы контента помогают в распределении
→ Данные реального использования улучшают ранжирование и шаблоны
→ Больше создателей присоединяются

Платежи связаны с использованием продукта, распределение связано с качеством выполнения, стимулы создателей связаны с измерением в реальном времени. Чтобы эта система действительно заработала, платформе в конечном итоге нужна реальная бухгалтерская книга (ledger). Каждое значимое платёжное выполнение должно быть записано:

Общая сумма сбора (grosscharge) Стоимость модели (modelcost)
Стоимость инструмента (toolcost) Стоимость инфраструктуры (infracost)
Плата за обработку платежей (paymentfee) Плата платформы (platformfee)
Доход создателя (builderrevenue) Вознаграждение рекомендателя (referrerreward)
Сумма возврата (refundamount) Статус расчета (settlementstatus)

Без этой основы распределение доходов, возвраты, корпоративное выставление счетов, контроль за мошенничеством, налоговая отчетность, выплаты и аудит станут очень уязвимыми. С ней приложения Agent могут стать настоящими экономическими единицами: создатели могут выпустить приложение, пользователи могут платить за полезные задачи, кураторы контента могут помогать в распределении, платформа может ранжировать приложения на основе качества выполнения, а не только маркетинговых текстов. Это и есть переход от "генерации приложений" к "коммерциализации приложений Agent".

Где находится X-Agent

X-Agent строится как "слой приложений Agent".

Он не собирается заменять базовые модели, не собирается заменять облачных провайдеров, не собирается заменять инфраструктуру кошельков и не является просто еще одним программным агентом. Стек технологий, который мы строим, примерно такой:

Базовая модель
→ Создатель / Исполнительная рамка (Builder / Harness)
→ Безопасное выполнение в реальном времени / Инструменты / Кошелек
→ Приложения Agent
→ Магазин / Распределение / Рост

Базовая модель предоставляет интеллект;
Создатель и исполнительная рамка превращают намерения в приложения;
Безопасное выполнение, инструменты, кошельки и платежные системы определяют границы выполнения;
Приложения Agent ориентированы на реальных пользователей;
Магазин, распределение и системы роста помогают качественным приложениям Agent достичь масштабного принятия пользователями.

Суть не в том, что сегодня каждая часть головоломки завершена, а в том, что приложения Agent должны пройти через полный жизненный цикл: создание → развертывание → выполнение → измерение → выставление счетов → расчет → распределение → итеративное улучшение. Если платформа просто помогает людям создавать приложения, то она конкурирует только на уровне "создателя приложений"; если она просто предоставляет кошелек, то она лишь инфраструктура; если она только проводит мероприятия по росту, то она просто инструмент распределения.

А слой приложений Agent связывает эти три аспекта.

От сгенерированных приложений к коммерческому телу Agent

Первая фаза программного обеспечения ИИ сосредоточена на интеллекте — моделях, которые могут отвечать, рассуждать, генерировать и предоставлять помощь. Следующая фаза сосредоточена на выполнении — приложениях Agent, которые могут использовать инструменты, управлять состоянием и выполнять задачи. Затем следующая фаза сосредоточена на экономике — приложениях Agent, которые могут быть обнаружены, оценены, оплачены, распределены и постоянно улучшены на основе реального использования.

Сгенерированные приложения являются лишь начальной точкой этой цепочки преобразования, а не конечным продуктом. Будущее приложений ИИ не будет определяться тем, "сколько демонстрационных демо можно сгенерировать", а тем, "сколько приложений Agent могут выполнять реальные задачи, достигать реальных пользователей и поддерживать реальные экономические активности".

Это именно то направление, в котором X-Agent строит слой приложений.

Если вы создаете приложения Agent, инфраструктуру кошельков для агентов или строите каналы распределения для программного обеспечения, родившегося из ИИ, добро пожаловать следить за X-Agent, чтобы получить больше заметок о построении в области выполнения, коммерциализации и распределения.