Сайты под управлением ИИ: что это на самом деле и сколько стоит. Часть 1 из 3

[d3d14]

Что насчет интерфейса MCP? Какие инструменты он должен предоставлять? Обвязка реализована на сайте или внешняя?

[mamontovtop]

Развёрнуто постараюсь ответить во второй части — уже дописываю.

Сам интерфейс: MCP-брокер — отдельный Node-процесс, грубо говоря, ~11 КБ на одном файле. Streamable HTTP + SSE, Bearer. Сайт о нём не знает и в рантайме не дёргает — связь только в момент изменений.

Инструменты:

• bash — базовый. Через него и правка файлов, и git, и сборка, и wp-cli, и логи. То есть всё то же, что человек делает в терминале руками.

• claude_prompt — вложенная автономная подзадача для длинных операций.

• list_screenshots / get_screenshot — автоскриншоты со стейджинга, посмотреть глазами.

Принцип — тонкий и общий интерфейс. Один bash вместо десятка узких ручек: меньше поверхность атаки, проще поддерживать, гибче в работе.

Сайт или внешняя. Брокер всегда внешний по отношению к сайту процесс. А вот по развёртыванию — два валидных формата:

• Совмещённый — dev и prod на одной VDS. Разные каталоги, разные пользователи, у dev нет прав записи в prod. Дёшево и сердито, хватает для большинства сайтов.

• Разнесённый — dev и prod на разных VDS, у нас сейчас Нидерланды и Россия соответственно. Физическая изоляция модели от прода: единственный путь на прод — GitHub Actions с узким CI-ключом. Плюс прод ближе к российской аудитории, а dev — в стабильной зоне для API-провайдера.

В обоих случаях правки идут в обычный код и контент (компоненты, конфиги, wp-cli) — туда же, куда их вносил бы человек.

Безопасность: Bearer с ротацией, least-privilege, аудит-лог bash-вызовов, прод — только через CI с build-гейтом. Несколько стен подряд; git тут последняя, а не первая.

[d3d14]

Спасибо за развернутый ответ.
Я сейчас делаю свой сайт/сервис и планирую также внедрить агентное управление. Но планирую встроить агента в сам сайт, т.е. обвязка будет в том же PHP пространстве кода, что даст возможность вызывать инструменты напрямую из кода, без MCP-слоя.

[copyhold]

не совсем понятно зачем править файлы на сервере. имеет смысл разве что wp-cli.
правка кода должна делаться отдельно, пусть даже тем же самым агентом.
но не напрямую на сервере а через гит и деплой пайплайн.
как у вотдпреса так и в next.

[GorkyUser]

В таблице "Скорость • Цена • Гибкость" вы упустили 2 из 5 подходов для создания сайтов. Еще CMS и Самопис.

[mamontovtop]

Я уж не стал так широко брать — материал и так объёмный выходит, а тут пришлось бы для корректного сравнения добавлять какие-то дополнительные параметры типа “Удобство управления контентом”, “Потенциал масштабирования”, “Требуемый уровень экспертности” и т.д. А ещё можно было бы разные CMS друг с другом сравнить, а для самописных сайтов — разные технологические стэки… В общем, волевым усилием принял решение сосредоточиться на ближайших субститутах именно по отношению к ИИ-сайтам.

Впрочем, если будет такой запрос, можем отдельный совместный материал потом подготовить по CMS и их применимости в связке с ИИ-управлением, ещё и в контексте разных отраслевых решений, например

[Bardakan]

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

ну да. А потом получается что-то вроде этого:
https://habr.com/ru/articles/1042156/
вы сами пробовали эту "гибкость"?

[mamontovtop]

Кейс, который вы прислали, я тоже читал, и мы тоже с чем-то подобным сталкивались (не такая жесть, конечно, но там автору просто не повезло натолкнуться на лютых глэков).

Но опять же, есть плюсы и минусы, множество факторов, которые будут удобны одним и неприменимы для других. Кому-то во сто крат любых других вариантов удобнее Тильда, например, и никак ты его не переубедишь — ну и хорошо, под задачу и инструмент.

Если принципиальные есть вопросы — спрашивайте, расскажу подробнее, как это работает у нас.