Первая установка XTester с AI-агентом

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

Фактическая проверка: macOS alpha.4 заблокирован

Полный macOS arm64 ZIP проверен по размеру 729432875 байт и SHA-256 из манифеста; пути, внутренние symlink и CRC проверены до распаковки в отдельную пользовательскую папку. Нативный Mach-O arm64 host содержит runtime .NET 10.0.11, однако запуск с --studio завершился кодом 3: «XTester requires 64-bit Windows 10 version 2004 … Detected: non-Windows OS, Arm64 process.» Это отказ platform guard, а не доказанная нехватка SDK. Нужен исправленный релиз издателя, без обхода защиты и переделки бинарника.

Остальные шаги ниже описывают проверенный по исходникам маршрут, не успешный E2E этого macOS-релиза. Дата проверки: 2026-10-06 UTC. Полная версия и хеш проверенного snapshot — в Markdown.

Один запрос агенту

Короткий запрос: Установи XTester с https://xtester.pw. На главной есть ссылка «Для ИИ-агентов», в llms.txt — первый START. Полное руководство: https://xtester.pw/mcp/agent-onboarding.md. Автоматическое чтение llms.txt зависит от агента; разрешения остаются за пользователем.

Установи XTester с https://xtester.pw. Следуй руководству https://xtester.pw/mcp/agent-onboarding.md. Определи мою ОС, процессор и существующую установку XTester. Выбери текущий официальный дистрибутив и проверь SHA-256. Спроси перед установкой, запуском и изменением конфигурации агента. Создай отдельный проект, проверь initialize и tools/list, скомпилируй минимальный пример C# и выполни короткий тест на явно синтетических данных, если runtime поддерживает такой импорт; иначе отдельно предложи проверенную локальную историю. Сохрани настоящий отчёт и ограничения. Не трогай мои проекты, не подтверждай разрешения за меня, не запрашивай секреты брокера, не торгуй и не выдумывай доходность. Если есть блокер — назови точный этап и необходимое действие пользователя.

Предполагаемый путь после установки

Генератор заранее подставляет предполагаемый путь после установки, а не найденный файл. Браузер определяет только семейство ОС: имя пользователя, CPU, установленную версию и полный путь он не знает. Отсутствие установки не мешает просмотру и копированию; проверяется формат, не наличие файла. Выберите целевую ОС вручную при необходимости.

Windows: ожидаемая папка пользовательского setup — Programs / XTester Studio, имя папки пользователя yourname и диск C: служат примерами. macOS: пользовательская Applications — пример места распаковки; суффикс внутри XTester Studio.app проверен по архиву, ARM64 по умолчанию не означает определение CPU (Intel: osx-x64). Linux: /usr/share/xtester-studio — системная папка Debian-пакета по исходникам, не portable. Полные пути, источники alpha.4 и границы проверки — в едином Markdown-руководстве.

Измените имя папки пользователя или полный путь. Ручной путь сохраняется при смене клиента/ОС и перезагрузке; кнопка «Вернуть предполагаемый путь» явно возвращает пример. Переменные окружения не подставляются в command. Конфиг, копия и скачанный файл совпадают и не дают разрешений Studio.

Правила локальному агенту: проверить настоящую ОС/CPU и существующую установку. Если её нет — выбрать актуальный официальный артефакт из манифеста, проверить размер/SHA-256 и согласовать установку. После неё найти реальный executable, сохранить резервную копию и добавить его абсолютный путь в конфиг выбранного клиента, не удаляя другие серверы. Получить разрешение пользователя в Studio, проверить initialize и tools/list, затем выполнить поддерживаемый безопасный первый тест по шагам ниже. При блокере — остановиться. Пример пути не разрешает установку или запуск; macOS ARM64 alpha.4 остаётся заблокированным.

Маршрут первой установки

1. Проверить реальную ОС, нативную архитектуру, свободное место, права на выбранную папку и уже установленную версию. Повторная установка не нужна, если версия подходит. До загрузки проверить наличие curl, выбранного JSON-парсера, checksum и archive tools (в Windows — соответствующих PowerShell-команд); список отсутствующих согласовать, не устанавливать всё или SDK заранее. Выбрать реального клиента агента, не подменять его. Обновление — только с резервной копией настроек и проектов, без распаковки поверх них.
2. Получить актуальный манифест, выбрать артефакт по ОС/CPU/формату из реально возвращённого списка, сохранить версию, URL, размер и SHA-256. Не брать хеши старой версии как «текущие». Сначала проверить файл, только затем открывать. Хеш — не подпись издателя.
3. Windows: проверенный интерактивный setup или portable ZIP. macOS: ZIP нужной архитектуры в новой пользовательской папке. Linux: portable tar.gz либо пакет deb/rpm после отдельного разрешения на системную установку. Не отключать Gatekeeper, SmartScreen, антивирус и sandbox. Диалоги ОС подтверждает пользователь.
4. Запустить проверенную Studio, создать отдельный пустой C#-проект. Внешние агенты → конфигурация конкретного клиента. Копировать настоящий абсолютный путь из установленного приложения, а не пример пути. Сохранить резервную копию клиентского конфига и показать diff.
5. Проверить MCP handshake, список инструментов и список окон Studio. Пользователь выбирает окно и выдаёт доступ; read-only не разрешает компиляцию и запись. Пустой список окон — не ошибка транспорта и не успешный бэктест.
6. Прочитать окружение и исходники, скомпилировать пустой lifecycle-пример. Это честный smoke-тест без сделок, а не пример прибыльной стратегии. Не создавать второй класс поверх существующего.
7. Запросить фактические возможности данных и точные схемы. Для первого smoke предпочесть явно синтетический небольшой набор, только если есть поддерживаемый импорт/генератор; запись — в новом workspace. Не придумывать инструмент импорта. Иначе предложить проверенную локальную историю отдельно. Проверить покрытие и пропуски; сетевую загрузку согласовать. Синтетический стакан не означает, что свечи уже установлены; синтетические цены нельзя выдавать за исторические.
8. Выполнить один короткий прогон. Получить настоящий runId, затем отчёт, сделки и equity именно этого прогона. Сохранить исходник, параметры, данные и диагностические ответы. Компиляция, анимация сайта и старый отчёт не доказывают новый бэктест.

Важное различие MCP

Канонический каталог Windows --mcp и Studio --studio — разные поверхности. В portable macOS/Linux предусмотрен Studio-режим. Например, Studio run_backtest принимает depositUsdt и confirm, а чтение отчёта требует runId. Не переносить параметры из другого каталога. Использовать живые tools/list, поиск и схему инструмента.

Языки и безопасность

Доступны направления C#, Python, JavaScript, TypeScript, Pine Script, Java, C++, Rust, Go и R, но зрелость отдельных возможностей и наличие toolchain различаются. Для первого прогона рекомендуем C#. Подсветка синтаксиса не доказывает выполнение. Pine использует интерпретатор XTester, а не гарантированно идентичные правила TradingView. Если toolchain отсутствует — честно остановиться или согласовать C#; не устанавливать всё автоматически.

API-ключи брокера, торговый счёт и реальные заявки для этого маршрута не нужны. Модель агента может отправлять код и результаты своему провайдеру даже при локальном stdio. Установка, загрузка данных, запись в проект и разрешения требуют соответствующего согласия.

Что проверено и чего это не доказывает

Проверены опубликованные точки входа, текущий манифест и исходники релиза alpha.4. Команды и параметры в полном руководстве разделяют source-проверку и реальный запуск. Windows/Linux end-to-end в этом аудите не запускались. Успешный первый бэктест можно заявлять только после разрешённой сессии Studio, настоящих данных и сохранённого результата. Результаты бэктеста не гарантируют будущей доходности.

Полное машиночитаемое руководство: выбор актуального манифеста, команды, MCP-вызовы, диагностика и критерии приёмки (English)

Полная HTML-версия (English) · Подключение MCP · Безопасность