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

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

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

Хотя многие взаимодействия с агентом могут быть временными, для создания сложных систем с состоянием необходим способ уникальной идентификации и отслеживания Запроса и его итогового Решения. Объект 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 — это ключ, который превращает временный Запрос в постоянную, адресуемую Идею.

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

// 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: Свойства конкретного версионированного экземпляра.

    • 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: Постоянный, однозначный URI, указывающий на найденный ресурс.

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

Это делает всю единицу запрос-решение самоописываемой и адресуемой.