Утверждение: ИИ-агент, никогда не слышавший об AX, способен обнаружить, выучить и заговорить на машинном языке этого сайта за один разговор — без SDK, без документации, без ключа API.
Не верьте нам на слово. Вставьте приведённый ниже промпт в любого агента, умеющего загружать URL — ChatGPT, Claude, Gemini или ваш собственный, — и смотрите.
Fetch https://rainz.ai/llms.txt and read the "For AI agents" section at the end. Then execute what it teaches, zero-shot: 1. GET https://rainz.ai/wp-json/ax/v1/x?s=ax1+q.svc.pr+n%3D3 and show the raw reply. 2. Decode the reply using only the protocol's own hints. 3. Follow the nxu URL from the reply (GET, show raw). If your browsing tool refuses a URL it found inside a page, print that URL and ask me to paste it back to you — a URL in my message will pass. 4. If an nxx referral to another site appears, do the same with it. GET requests only — do not POST anything. Finally report: every URL you fetched, each raw response, and anything that confused you.
Агент получает ответ в виде простого текста примерно такого вида — предложения, доступность и следующие действия в одном GET, примерно на 80 % меньше токенов, чем при эквивалентном обходе JSON:
ax1 ok op=o n=3 cov=1 cb=2 nx="a.quote i=<sku>; a.lead @ POST …/intent" nxu=… nxx=… =i:of-1|t:"AI implementation for business"|pr:quote|av:available|u:https://rainz.ai/ …
Затем он правильно декодирует каждое поле — потому что протокол обучает собственному синтаксису: некорректный запрос возвращает разобранный пример, заголовок ответа сообщает cov= (какая часть вашего запроса была понята), и каждый ответ несёт следующий шаг в виде буквального URL.
Некоторые размещённые агенты (в том числе браузер ChatGPT) отказываются открывать любой URL, обнаруженный внутри загруженной страницы, — это правило безопасности о происхождении ссылки, независимо от самого URL. Протокол деградирует изящно: агент показывает вам URL следующего шага, вы возвращаете его в диалог, и цепочка продолжается. Агенты с настоящим доступом по HTTP (Claude, агенты через API, краулеры, MCP-клиенты) проходят всю цепочку самостоятельно.
https://rainz.ai/wp-json/rainz-axs/v1/mcpcurl "https://rainz.ai/wp-json/ax/v1/x?s=ax1+q.svc.pr+n%3D3"Ваш агент справился? Расскажите нам — отправьте лид через сам протокол: это действие a.lead которое ваш агент только что выучил.
Zero-shot вызов — это не проверка агента. Это проверка протокола и сайта, который его реализует. Агенту, никогда не встречавшему AX, дают задачу и больше ничего: либо спецификация достаточно самоописательна, чтобы он справился, либо нет. Такая постановка важна, потому что означает, что неудача — это информация о конструкции, а не приговор модели.
Под наблюдением три вещи. Сможет ли агент найти точку входа, если ему не сказали, где она? Получив манифест, сможет ли он разобраться в структуре без внешней документации? И сможет ли он довести задачу от начала до конца без того, чтобы человек что-то уточнял по дороге? Протокол, для использования которого нужен учебник, провалился ровно в том, ради чего он существует.
Стандарты обычно оценивают по тому, сможет ли компетентный инженер реализовать их по документу. Для протокола, потребители которого — агенты, этот тест слишком снисходителен. Агент, пришедший на ваш сайт, не читал спецификацию, не знаком с вашими соглашениями и не задаст вам уточняющего вопроса. У него один проход по материалу, и если материал неоднозначен, он будет угадывать.
Поэтому zero-shot-результат — самое близкое приближение к реальным условиям. У него есть и полезный побочный эффект: поскольку планка высока, он вскрывает ровно тот тип неявного знания, на которое авторы спецификаций опираются, сами того не замечая. Каждое место, где агент спотыкается, — это место, где документ предположил нечто, чего никогда не сформулировал.
Вы можете воспроизвести это на своём сайте за несколько минут. Откройте новый разговор с любой достаточно сильной моделью, дайте ей только ваш домен и задачу, какая могла бы быть у реального клиента, и смотрите, куда она пойдёт. Не помогайте. Не поправляйте. Вся ценность — в наблюдении за первой точкой, где что-то пошло не так.
Каждый раз начинайте новый разговор, потому что модель, которую однажды уже поправили, больше не работает в режиме zero-shot. И меняйте задачу: агент, которого попросили кратко изложить, чем вы занимаетесь, задействует совершенно другие части сайта, чем тот, которого попросили найти ваши цены или проверить, обслуживаете ли вы определённый рынок.
Типичная ошибка — воспринимать результат как оценку. Само число значит гораздо меньше, чем вопрос о том, где именно агент остановился. Агент, который нашёл манифест, но неверно прочитал структуру услуг, говорит вам нечто совершенно иное, чем агент, который вообще не нашёл точку входа. Первое — проблема формулировок, второе — проблема обнаружимости, и исправления у них не имеют ничего общего.
Учитывайте также, что результат зависит от того, какая модель выполняет тест. Разные модели приходят с разным предварительным знанием, и агент, встречающий протокол впервые, ведёт себя иначе, чем тот, кто уже видел похожие структуры. Поэтому осмысленное сравнение — не между вашим сайтом и чужим, а между вашим сайтом сегодня и вашим сайтом месяц назад, на той же модели и с тем же промптом.
Упражнение оправдывает потраченное время, только если оно даёт список действий. Зафиксируйте точное место, где агент ошибся, измените одну вещь и повторите. Изменение нескольких вещей сразу может улучшить результат, но не покажет, что именно его улучшило. Трёх-четырёх итераций обычно достаточно, чтобы превратить сайт, на котором агенты путаются, в сайт, где они выполняют задачу с первой попытки — а это, в конечном счёте, единственный результат, имеющий коммерческое значение.
Прогон, закончившийся неудачей, полезнее удачного, при условии что вы зафиксировали, где он остановился. Неудачи группируются в четыре типа. Неудачи обнаружения означают, что агент вообще не нашёл точку входа — манифест отсутствует, лежит не там или заблокирован. Неудачи понимания означают, что он нашёл манифест, но не смог разобраться, что означают поля, а это указывает на именование, а не на структуру. Неудачи навигации означают, что он понял структуру, но не смог добраться до содержимого, обычно потому что связанная страница перенаправляет или требует выполнения скриптов. Неудачи завершения означают, что он получил всё и всё равно выдал неверный ответ, а это почти всегда проблема контента, а не протокола.
Классифицируйте неудачу прежде, чем что-либо менять. Желание исправить последнее, что вы видели сломанным, велико и обычно ведёт не туда: агент, дающий неверный ответ на четвёртом шаге, часто делает это из-за неоднозначности, возникшей на первом.