Акты Становления

015: Агент/Мета

Это как паспорт для запроса. Он содержит всю важную информацию: имя, адрес, версию, дату создания и к каким группам (веткам) он относится. Это надёжная, понятная компьютеру метка, которая помогает отслеживать историю запроса и легко его находить.

Хотя многие простые команды для искусственного интеллекта могут быть одноразовыми, для создания сложных систем, которые помнят, что было раньше, нужен способ точно определять и отслеживать каждый запрос и его решение. Для этого и служит объект Meta. Это «визитная карточка» запроса, которая даёт ему уникальное имя, понятное компьютеру. С её помощью можно сохранять результаты, создавать новые версии, отправлять задачи по нужному адресу и просматривать всю историю изменений.

Самое важное: когда эта «визитка» становится обязательной частью ответа, искусственный интеллект (ИИ) сам может создавать новые «личности» для задач или делать их копии (ветки) в зависимости от ситуации. Так простой ответ превращается в акт творения чего-то нового.>

Объект Meta в жизненном цикле запроса

Объект Meta — это главный участник в жизни запроса. Он появляется в context (входных данных), чтобы ИИ знал, с чем работает, и в schema (правилах), как обязательная часть solution (ответа).

  • В context: Сообщение meta передаёт ИИ «паспорт» той задачи или процесса, который он сейчас обновляет.
  • В schema: Правила для solution требуют наличия свойства meta. Это заставляет ИИ думать об «личности» задачи и обновлять её как часть своей работы.
  • В solution: ИИ создаёт новый объект meta, обычно с новой версией, показывая, что задача развилась и перешла на следующий этап.

Такой цикл превращает ИИ из простого исполнителя в активного участника, который помогает жить и развиваться сложным, версионным системам.

На заметку: от Запроса к Идее

Вся эта цепочка — context (включая сообщение Meta), schema и итоговый solution — образует единый, самодостаточный блок. Когда этот блок сохраняется, система называет его Идеей. Объект Meta — это ключ, который превращает одноразовый Запрос в постоянную, адресуемую Идею.

Пример структуры Запроса

// ИИ получает текущие метаданные как контекст
// и должен создать новые в своём решении.
{
  "context": [
    {
      "type": "meta",
      "meta": {
        "domain": "reactor.ideas.services",
        "path": "/games/321",
        "version": "1.2.3",
        "branches": ["main"],
        "createdAt": "2025-10-26T10:00:00Z"
      }
    },
    {
      "type": "state",
      "state": {
        "...текущее состояние игры..."
      }
    }
  ],
  "schema": {
    "type": "object",
    "properties": {
      "meta": {
        "$ref": "MetaSchema"
      },
      "output": {
        "$ref": "GameSchema"
      }
    }
  }
}

Пример Решения

// Решение ИИ включает следующее состояние игры
// и обновлённую версию в новом мета-объекте.
{
  "meta": {
    "domain": "reactor.ideas.services",
    "path": "/games/321",
    "version": "1.2.4",
    "branches": ["main"],
    "createdAt": "2025-10-26T10:05:00Z"
  },
  "output": {
    "...следующее состояние игры..."
  },
  "calls": []
}

Самостоятельное развитие и управление версиями

Одна из ключевых ролей объекта Meta — позволить системам на базе ИИ развиваться самостоятельно. Когда мы передаём ИИ текущую версию в context и требуем новую в solution, мы даём ему задачу обновить версию. Если ИИ вносит совместимое изменение, он должен увеличить номер версии (например, с 1.2.3 до 1.2.4). Это создаёт новый, неизменяемый «снимок» состояния и логики, формируя полную и прозрачную историю действий агента.

Это создаёт проблему в больших системах: если два разных процесса одновременно отреагируют на разные события, они оба могут попытаться обновить версию с 1.2.3 до 1.2.4. Это называется «состояние гонки».

Система решает эту проблему с помощью механизма веток. Когда нужно начать новую линию разработки, процесс добавляет новую ветку в массив branches (например, ["main", "my-feature"]) и создаёт специальную версию для неё. Версии становятся такими: 1.2.3.branch-A.1 и 1.2.3.branch-B.1. Это позволяет работать параллельно, не мешая друг другу, а позже эти истории можно будет объединить.

Как «паспорт» становится адресом

Поля внутри объекта Meta содержат всё необходимое, чтобы дать запросу уникальный адрес, известный во всём мире. Это позволяет программе найти, вызвать или сослаться на конкретную версию пары «запрос-решение».

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

  • Метаданные (Meta): Свойства конкретной версии.

    • meta.domain: my-project.com
    • meta.path: bob
    • meta.version: 1.2.staging.1
    • meta.branches: ['staging']
    • meta.createdAt: 2025-10-26T10:00:00Z
  • Ссылка (Reference): Динамический запрос чего-либо.

    • idea://my-project.com/bob?1.2
    • В каких ветках искать: ['staging']
    • Не старше чем: 2025-10-26T10:00:00Z (из createdAt)
  • Результат (Resolved): Постоянный, однозначный адрес, указывающий на найденный ресурс.

    • idea://my-project.com/~:staging/bob?1.2:1.2.staging.1
    • Ветка: ~:staging
      • Искали в: любой ветке из списка поиска
      • Нашли в: staging
    • Версия: 1.2:1.2.staging.1
      • Искали: последнюю, совместимую с 1.2
      • Нашли: 1.2.staging.1

Это делает каждую пару «запрос-решение» полностью самоописываемой и адресуемой.