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": []
}
Автономная эволюция и версионирование
- Принципы автономного улучшения описаны в 106: Концепция/Эволюция.
Ключевая роль объекта Meta
— обеспечивать автономную эволюцию агентных процессов. Включая текущую версию и ветки в context
и требуя новую версию в solution
, система ставит перед LLM задачу по обновлению версии. Создание нового solution
по той же schema
считается совместимым изменением, поэтому крайне важно, чтобы агент увеличивал минорную версию. Это создает новый, неизменяемый снимок его состояния и логики, формируя полную и проверяемую историю действий агента с течением времени.
Это создает проблему в распределенных системах: если два независимых процесса одновременно реагируют на разные события, они оба могут попытаться обновить версию с 1.2.3
до 1.2.4
, создавая состояние гонки.
- Это подробнее рассматривается в 108: Концепция/Видимость.
Архитектура решает эту проблему с помощью механизма ветвления. При создании новой линии разработки процесс добавляет новую ветку в массив branches
(например, ["main", "my-feature"]
) и создает версию для этой ветки. Версии становятся, соответственно, 1.2.3.branch-A.1
и 1.2.3.branch-B.1
. Это обеспечивает параллельную, бесконфликтную эволюцию, при этом различные истории могут быть объединены или согласованы позже.
Связывание идентификатора с адресом
- Конкретный синтаксис этой схемы адресации определен в 110: Концепция/Адресация.
Поля в объекте 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
- meta.domain:
-
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
- запрошено: последняя совместимая с
Это делает всю единицу запрос-решение самоописываемой и адресуемой.