App ConfigMCP connectorProject configurationSettings automationAgentic engineeringArchitecture

Использование MCP для настроек приложения в агентной инженерии | Как агент меняет app config

Как ИИ-агент управляет конфигурацией приложения в агентной инженерии — название, описание, SEO, PWA и языки меняются обычной просьбой и применяются на следующей загрузке страницы, без пересборки. Разбор коннектора App Config (MCP).

8 мин чтение
App Config automation: an AI agent updating a deployed app’s project configuration through the app-settings MCP connector — branding, SEO, PWA and languages written to app-config.json and applied on the next page load.
Меняй название сайта, описание или SEO — даже языки — просто попросив ИИ-агента словами, в чате или голосом. Не нужно кликать админ-панель. Не нужно ждать пересборку.

Fractera — это Agentic Engineering Infrastructure: защищённое, self-hosted рабочее пространство, где ИИ-модели пишут и запускают твоё приложение на твоём собственном сервере. Этот документ просто и по делу объясняет один его кусок — автоматизацию конфигурации в агентной инженерии: как агент меняет то, что приложение говорит о себе, почему это безопасно и как изменение мгновенно доходит до посетителей. Текст рассчитан и на технического человека, и на ИИ-агента.

Что мы автоматизировали: настройки проекта голосом агента

Раньше, чтобы поменять название сайта, описание, SEO или иконку, нужно было руками зайти в админ-панель и кликать поля. Теперь то же самое можно сделать, просто попросив ИИ-агента словами — в чате или голосом. Агент сам найдёт нужное поле, проверит значение и запишет его. И изменение появится на сайте уже при следующей загрузке страницы, без полной пересборки.

Где живут настройки — простая модель

Представь один обычный текстовый файл, `app/APP-CONFIG/app-config.json` — это «паспорт» твоего сайта:

{
  "name": "Fractera",
  "description": "Production-Coding AI Server ...",
  "url": "https://fractera.ai",
  "seo": { "titleTemplate": "%s | Fractera" },
  "jsonLd": { "organization": false }
}

Почему файл — а не база данных и не переменные окружения:

  • Файл прозрачен — агент может прочитать его как есть, без запросов к БД.
  • Держит вложенность (`seo.*`, `jsonLd.*`, `geo.*`) — плоские env-переменные так не умеют.
  • Применяется без пересборки — env-переменным пересборка нужна, поэтому именно там живут языки (об этом ниже).

Менять файл руками опасно — сломаешь скобку, и сайт упадёт. Поэтому изменение никогда не идёт «сырым»: оно проходит через валидируемый сеттер (умный записывающий механизм), который проверяет значение по каталогу и пишет аккуратно и атомарно. Файл — это *где лежат байты*; сеттер — *как они записываются*. И пишет только сеттер.

Как это работает под капотом: поток за пять шагов

Ты (чат/голос): "поменяй описание на 'Рога и копыта'"
        |
        v
Агент вызывает инструмент MCP на :3218  ->  set_text_value { path:"description", value:"Рога и копыта" }
        |
        v
Сеттер проверяет (поле есть? тип верный?) и пишет в app-config.json  (атомарно -- без риска порчи)
        |
        v
Сеттер дёргает /api/revalidate  <-- кусок, который и делает изменение мгновенным
        |
        v
Сайт сбрасывает кэш страницы  ->  при следующей загрузке видно новое описание

Инструменты, которые теперь есть у каждого агента

Инструмент                      Что делает
──────────────────────────────  ─────────────────────────────────────────────────────────────
list_text_fields                Показать ВСЕ настройки: путь, что значит, текущее значение, задано ли
list_unfilled_fields            Показать только незаполненные (чтобы подсказать, что дозаполнить)
set_text_value { path, value }  Изменить одно поле (проверка + запись + ревалидация)
list_languages / set_languages  Прочитать / изменить набор языков

Кейсы: как это выглядит в жизни

  • Описание. Ты: «Поменяй описание на „Рога и копыта“.» → `set_text_value { path:"description", value:"Рога и копыта" }` → новый текст в сниппете поиска и соцсетях на следующей загрузке. Без панели, без пересборки.
  • Свой домен. Ты: «Мой домен теперь example.com.» → агент меняет два поля, `url` и `seo.canonicalBase` → канонические ссылки и OG-теги подхватывают новый домен.
  • Разметка для Google. Ты: «Включи Organization schema.» → `set_text_value { path:"jsonLd.organization", value:true }` → в HTML появляется структурированная разметка организации.
  • Языки (особый случай). Ты: «Добавь французский.» → `set_languages(["en","ru","fr"])` → пишет в env и честно отвечает: «французский появится после пересборки, несколько минут». Языки определяют, какие страницы вообще генерируются — это решается на этапе сборки, поэтому мгновенно нельзя.
  • Помощь с заполнением. Ты: «Что ещё стоит заполнить для SEO?» → `list_unfilled_fields` → «не заданы: ключевые слова, проверка Google, twitter автора…» и агент предлагает заполнить.

Одна способность — во всех шести агентах рабочего пространства агентной инженерии

Способность реальна только если она выживает при любом единственном агенте — проект может работать всего с одним, без оркестратора. Поэтому коннектор и навык продублированы в каждого агента:

Агент                  MCP :3218 в                    Навык manage-app-settings
─────────────────────  ─────────────────────────────  ──────────────────────────────
Claude Code            .mcp.json                      своя копия в .claude/skills
Codex                  .codex/config.toml             читает .agents/skills
Gemini CLI             .gemini/settings.json          своя копия в .gemini/skills
Qwen Code              .qwen/settings.json            своя копия в .qwen/skills
Kimi Code              .kimi/config.toml              читает .agents/skills
Hermes (оркестратор)   его конфиг (mcp_servers)        services/hermes-skills/manage-app-settings.md

Движение запроса: один агент vs оркестратор

Напрямую на одном агенте — реальный кейс «один агент», без оркестратора:

Ты -> Codex: "поменяй описание на 'Рога и копыта'"
  1. Codex видит навык manage-app-settings (его description загружен) -> знает шаги
  2. Codex подключается к :3218 через .codex/config.toml (с секретом)
  3. (опц.) list_text_fields -> { path:"description", current:"...", is_set:false, role:"meta description..." }
  4. set_text_value { path:"description", value:"Рога и копыта" }
       -> проверка -> запись app-config.json (атомарно) -> дёргает /api/revalidate
  5. ответ: { ok:true, path:"description", value:"Рога и копыта", is_set:true }
  -> Codex: "Готово -- появится на следующей загрузке."

Через Hermes, оркестратор — те же инструменты плюс координация:

Ты -> Hermes: "поменяй описание на 'Рога и копыта' и заодно включи Organization schema"
  1. Hermes держит те же инструменты в своём MCP-клиенте
  2. set_text_value { path:"description", value:"Рога и копыта" }
     set_text_value { path:"jsonLd.organization", value:true }
  3. Hermes собирает оба результата, отвечает одним сообщением и может запустить смежные шаги
     (проверить страницу, записать в память, скоординировать других агентов)

Разница одной строкой: механика записи идентична — оба идут в один коннектор `:3218`. Hermes лишь добавляет оркестрацию (несколько шагов, автономные циклы, координация агентов). Для одной правки он не нужен, и проект с единственным Codex делает всё то же сам.

Откуда агент знает об этом нативно

  1. Навык — его описание подгружается в список навыков агента при старте сессии, и агент видит, что есть способность «управлять настройками приложения».
  2. Инструменты MCP — агент запрашивает у `:3218` `tools/list`; инструменты появляются в его наборе с описаниями, готовые к вызову.
  3. Вектор-память — этот документ загружен в общую память (LightRAG), и агент с памятью «вспоминает» детали — как и почему — по запросу.

Даже без памяти и без оркестратора у агента всё равно есть навык и MCP локально — в этом весь смысл самодостаточности. Языки остаются осознанным исключением: они кормят статическую генерацию, поэтому build-time, и агент говорит об этом прямо, а не делает вид, что изменение мгновенно.

Безопасность и внешний доступ в агентной инженерии

Конфигурация — это изменение файловой системы, поэтому доступ к коннектору ограничен по умолчанию, в несколько слоёв:

  • Личность, а не просто ключ. Запись конфигурации (и базы данных) доступна только роли архитектор и проверяется на каждом слое — коннектор MCP, HTTP-роуты конфигурации и сервис данных. Чтение может быть шире; запись — только архитектор.
  • Сетевая изоляция. Коннектор слушает только `127.0.0.1` и не виден из интернета. Публичная поверхность — за nginx и шлюзом авторизации; коннектор доступен исключительно изнутри рабочего пространства.
  • Секрет на развёртывание. Каждый вызов коннектора несёт секрет, уникальный для твоего развёртывания, — достучаться могут только твои внутренние агенты.
  • Подтверждение перед изменением. Записывающий инструмент проговаривает изменение (было → станет) и ждёт твоего согласия, прежде чем писать.

Разверни рабочее пространство, где ИИ-агенты не просто пишут приложение, но и перенастраивают его облик по просьбе — безопасно, на твоём собственном сервере.

Развернуть с ИИ

Постоянно экспериментируйте. Если работать «как принято», то потолок достижений заранее известен. Старайтесь делать что-то «по-другому», не так как остальные.

Roma Armstrong photoRoma ArmstrongFounder at Fractera.ai

Частые вопросы

Как ИИ-агент меняет настройку проекта?
Ты просишь его словами. Агент находит нужное поле, проверяет значение и записывает его через коннектор App Config (порт 3218) — например, set_text_value с путём и значением. Сначала он читает через list_text_fields (чтение ничего не ломает), подтверждает изменение с тобой, затем пишет и запускает ревалидацию — новое значение видно на следующей загрузке страницы.
Где хранятся настройки — база данных, переменные окружения или файл?
Обычный JSON-файл на диске, app/APP-CONFIG/app-config.json — это «паспорт» сайта. Файл выигрывает у базы данных (непрозрачна для агента, нужен слой запросов) и у переменных окружения (плоские, а NEXT_PUBLIC_* запекаются в сборку — потребуется пересборка): файл прозрачен, держит вложенность и применяется без пересборки. Единственное исключение — набор языков: он живёт в build-time env, потому что определяет, какие страницы вообще генерируются.
Нужна ли полная пересборка, чтобы изменение появилось?
Нет. Публичные страницы заранее собраны и закэшированы для скорости; сеттер сбрасывает этот кэш по требованию, и уже следующий визит пересобирает только нужную страницу с новым значением — она остаётся статической и работает даже с выключенным JavaScript. Единственное исключение — набор языков: добавление/удаление языка это build-time и требует пересборки (несколько минут), о чём агент честно предупреждает.
Может ли кто-то снаружи изменить мою конфигурацию?
Нет. Запись конфигурации доступна только роли «архитектор» и проверяется на каждом слое; коннектор слушает только localhost и не виден из интернета; каждый вызов несёт секрет, уникальный для твоего развёртывания; и агент подтверждает изменение перед записью. Перенастроить приложение могут только твои авторизованные агенты — изнутри твоего рабочего пространства.
Спросите у ИИ