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

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

Структурированный объект, который содержит явную идентификацию Запроса, включая его имя, пространство имён, версию, дату создания и ассоциации с ветками. Он предоставляет стабильный, машиночитаемый якорь для отслеживания происхождения и адресуемости запроса.

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

Ключевым моментом является то, что, делая идентификацию явной частью solution, объект Meta даёт LLM возможность создавать новые идентификаторы или ответвлять существующие в прямой реакции на свой контекст, превращая простой ответ в акт творения.>

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

Объект Meta является полноправным участником жизненного цикла Запроса. Он появляется в context, чтобы информировать LLM о текущей идентификации запроса, и в schema как обязательная часть solution.

  • В context: Сообщение meta предоставляет LLM идентификатор состояния или процесса, который он в данный момент обновляет.
  • В schema: Схема solution требует свойство meta, заставляя LLM рассматривать и обновлять идентификатор как часть своей задачи.
  • В solution: LLM генерирует новый объект meta, часто с обновлённой версией, отражающей эволюцию процесса.

Этот цикл превращает LLM из простого обработчика в активного участника жизненного цикла версионируемой сущности с состоянием.

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

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

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

// LLM получает текущие метаданные как контекст,
// и ей поручается создать новые в решении.
{
  "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"
      }
    }
  }
}

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

// Решение LLM включает следующее состояние игры
// и обновлённую версию в новом мета-объекте.
{
  "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, система поручает LLM обновление версии. Создание нового solution по той же schema считается совместимым изменением, и поэтому агент должен инкрементировать минорную версию. Это создаёт новый, неизменяемый снимок его состояния и логики, формируя полную и проверяемую историю действий агента с течением времени.

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

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

Связывание идентификатора с адресом

Поля в объекте 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
  • Ссылка: Динамический запрос к сущности.

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

    • 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

Это делает весь блок запрос-решение самоописываемым и адресуемым.